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.199904 < prev    next >
Internet Message Format  |  1999-04-29  |  1MB
  1. From: "Ray Whelan" <Ray_Whelan@eur.3com.com>
  2. Subject: Re: (usr-tc) How do you setup Multilink PPP on a HiperARC?
  3. Date: 01 Apr 1999 10:19:40 +0100
  4.  
  5.  
  6.  
  7.  
  8.   MLPPP It set up by defaulf.
  9.  set net user default ppp max_CHANNELS 2
  10.  set net user default ppp max_CHANNELS 1 disable MLPPP
  11.  
  12. Regards
  13. Ray W
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20. "Matthew Pearson" <mpearson@tiac.net> on 01/04/99 02:57:22
  21.  
  22. Please respond to usr-tc@lists.xmission.com
  23.  
  24. cc:    (Ray Whelan/IE/3Com)
  25.  
  26.  
  27.  
  28.  
  29. Anyone have a quick doc on this? I've scoured 3com's site with no luck!
  30.  
  31. Help!
  32.  
  33. Thanks
  34.  
  35. -
  36.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  37.  with "unsubscribe usr-tc" in the body of the message.
  38.  For information on digests or retrieving files and old messages send
  39.  "help" to the same address.  Do not use quotes in your message.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49. -
  50.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  51.  with "unsubscribe usr-tc" in the body of the message.
  52.  For information on digests or retrieving files and old messages send
  53.  "help" to the same address.  Do not use quotes in your message.
  54.  
  55.  
  56. -------------------------------------------------------------------------------
  57.  
  58. From: "Sam Lowe" <slowe@universalcom.net>
  59. Subject: (usr-tc) performance on quad modems
  60. Date: 01 Apr 1999 08:29:45 -0600
  61.  
  62. This is a multi-part message in MIME format.
  63.  
  64. ------=_NextPart_000_009E_01BE7C19.CC02E140
  65. Content-Type: text/plain;
  66.     charset="iso-8859-1"
  67. Content-Transfer-Encoding: quoted-printable
  68.  
  69. We have a old style chassis running 6 quad modems and a Hiper Arc card =
  70. that we use for backup analog access in one of our POPs.  For some =
  71. reason, users cannot access this chassis above 33.6, and it is usually =
  72. much lower connection.
  73.  
  74. The quads are running 5.10.9, the hiper arc 4.1.59.
  75.  
  76. It is fed by a channelized T-1 via a dual t-1 board.  We have both a =
  77. hunt group and DS0 dial numbers, and testing from here indicates that it =
  78. does not matter which DS0 you dial in on.
  79.  
  80. Any ideas???
  81.  
  82. Samuel S. Lowe
  83. Director, Data Network Services
  84. UniversalCom, Inc.
  85. slowe@universalcom.net
  86.  
  87.  
  88. ------=_NextPart_000_009E_01BE7C19.CC02E140
  89. Content-Type: text/html;
  90.     charset="iso-8859-1"
  91. Content-Transfer-Encoding: quoted-printable
  92.  
  93. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  94. <HTML><HEAD>
  95. <META content=3Dtext/html;charset=3Diso-8859-1 =
  96. http-equiv=3DContent-Type>
  97. <STYLE></STYLE>
  98.  
  99. <META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD>
  100. <BODY bgColor=3D#ffffff>
  101. <DIV><FONT size=3D2>
  102. <DIV><FONT size=3D2>We have a old style chassis running 6 quad modems =
  103. and a Hiper=20
  104. Arc card that we use for backup analog access in one of our POPs.  =
  105. For some=20
  106. reason, users cannot access this chassis above 33.6, and it is usually =
  107. much=20
  108. lower connection.</FONT></DIV>
  109. <DIV> </DIV>
  110. <DIV><FONT size=3D2>The quads are running 5.10.9, the hiper arc=20
  111. 4.1.59.</FONT></DIV>
  112. <DIV> </DIV>
  113. <DIV><FONT size=3D2>It is fed by a channelized T-1 via a dual t-1 =
  114. board.  We=20
  115. have both a hunt group and DS0 dial numbers, and testing from here =
  116. indicates=20
  117. that it does not matter which DS0 you dial in on.</FONT></DIV>
  118. <DIV> </DIV>
  119. <DIV><FONT size=3D2>Any ideas???</FONT></DIV>
  120. <DIV></FONT><FONT size=3D2><BR>Samuel S. Lowe<BR>Director, Data Network=20
  121. Services<BR>UniversalCom, Inc.<BR><A=20
  122. href=3D"mailto:slowe@universalcom.net">slowe@universalcom.net</A><BR></FO=
  123. NT></DIV></DIV></BODY></HTML>
  124.  
  125. ------=_NextPart_000_009E_01BE7C19.CC02E140--
  126.  
  127.  
  128. -
  129.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  130.  with "unsubscribe usr-tc" in the body of the message.
  131.  For information on digests or retrieving files and old messages send
  132.  "help" to the same address.  Do not use quotes in your message.
  133.  
  134.  
  135. -------------------------------------------------------------------------------
  136.  
  137. From: "Fred Williams" <fwilliams@gtnet.gov.uk>
  138. Subject: (usr-tc) Failure to negociate V90
  139. Date: 01 Apr 1999 15:29:38 +0100
  140.  
  141. We have a user with a Compaq 420 Microcom K56/V90 PCMCIA 
  142. modem.  He is failing to get a connection better than 31.2K when 
  143. dialiing into our TC Racks (mix of Quads and Netserver plus Hiper 
  144. DSP and ARC).  He regularly gets a 41 to 44K connection into other 
  145. ISPs.  He claims to have the latest V90 code on his modem.  Can 
  146. anyone offer a solution please?
  147.  
  148.  
  149.  
  150. ****************************************************************
  151. * Fred Williams                 email   fwilliams@gtnet.gov.uk *
  152. * CCTA                          voice   01603 704706           *
  153. * Rosebery Court                GTN     3040 4706              *
  154. * St Andrews Business Park      fax     01603 704817           *
  155. * NORWICH                       GTN fax 3040 4817              *
  156. * NR7 0HS  UK                                                  *
  157. ****************************************************************
  158.  
  159. -
  160.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  161.  with "unsubscribe usr-tc" in the body of the message.
  162.  For information on digests or retrieving files and old messages send
  163.  "help" to the same address.  Do not use quotes in your message.
  164.  
  165.  
  166. -------------------------------------------------------------------------------
  167.  
  168. From: Alessandro Alves <aalves@mpcnet.com.br>
  169. Subject: Re: (usr-tc) performance on quad modems
  170. Date: 01 Apr 1999 12:00:26 -0300
  171.  
  172. --=====================_263311451==_.ALT
  173. Content-Type: text/plain; charset="us-ascii"
  174.  
  175. Hi,
  176.  
  177. To connect 56 K, you need to put the latest version in NMC and T1 boards too.
  178. And you need to put the ability key for X2 in the NMC board.
  179. At 08:29 AM 4/1/99 -0600, you wrote: 
  180. >
  181. > We have a old style chassis running 6 quad modems and a Hiper Arc card that
  182. > we use for backup analog access in one of our POPs.  For some reason, users
  183. > cannot access this chassis above 33.6, and it is usually much lower
  184. > connection.
  185. >  
  186. > The quads are running 5.10.9, the hiper arc 4.1.59.
  187. >  
  188. > It is fed by a channelized T-1 via a dual t-1 board.  We have both a hunt
  189. > group and DS0 dial numbers, and testing from here indicates that it does not
  190. > matter which DS0 you dial in on.
  191. >  
  192. > Any ideas???
  193. >
  194. > Samuel S. Lowe
  195. > Director, Data Network Services
  196. > UniversalCom, Inc.
  197. > <mailto:slowe@universalcom.net>slowe@universalcom.net
  198.  
  199.  
  200.  
  201. --=====================_263311451==_.ALT
  202. Content-Type: text/html; charset="us-ascii"
  203.  
  204. <html>
  205. Hi,<br>
  206. <br>
  207. To connect 56 K, you need to put the latest version in NMC and T1 boards
  208. too. And you need to put the ability key for X2 in the NMC board.<br>
  209. At 08:29 AM 4/1/99 -0600, you wrote: <br>
  210. <font size=2><blockquote type=cite cite>We have a old style chassis
  211. running 6 quad modems and a Hiper Arc card that we use for backup analog
  212. access in one of our POPs.  For some reason, users cannot access
  213. this chassis above 33.6, and it is usually much lower connection.<br>
  214.  <br>
  215. The quads are running 5.10.9, the hiper arc 4.1.59.<br>
  216.  <br>
  217. It is fed by a channelized T-1 via a dual t-1 board.  We have both a
  218. hunt group and DS0 dial numbers, and testing from here indicates that it
  219. does not matter which DS0 you dial in on.<br>
  220.  <br>
  221. Any ideas???<br>
  222. <br>
  223. Samuel S. Lowe<br>
  224. Director, Data Network Services<br>
  225. UniversalCom, Inc.<br>
  226. <font size=2><a href="mailto:slowe@universalcom.net">slowe@universalcom.net</a><br>
  227. </blockquote><br>
  228. </font></html>
  229.  
  230. --=====================_263311451==_.ALT--
  231.  
  232.  
  233. -
  234.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  235.  with "unsubscribe usr-tc" in the body of the message.
  236.  For information on digests or retrieving files and old messages send
  237.  "help" to the same address.  Do not use quotes in your message.
  238.  
  239.  
  240. -------------------------------------------------------------------------------
  241.  
  242. From: "Ray Whelan" <Ray_Whelan@eur.3com.com>
  243. Subject: Re: (usr-tc) Failure to negociate V90
  244. Date: 01 Apr 1999 17:24:55 +0100
  245.  
  246.  
  247.  
  248. Hi Fred,
  249.  
  250. I have a document which I will send you offline which will enable you to further
  251. trouble shoot this problem
  252.  
  253. Ray W
  254.  
  255.  
  256.  
  257.  
  258. "Fred Williams" <fwilliams@gtnet.gov.uk> on 01/04/99 14:29:38
  259.  
  260. Please respond to usr-tc@lists.xmission.com
  261.  
  262. cc:    (Ray Whelan/IE/3Com)
  263.  
  264.  
  265.  
  266.  
  267. We have a user with a Compaq 420 Microcom K56/V90 PCMCIA
  268. modem.  He is failing to get a connection better than 31.2K when
  269. dialiing into our TC Racks (mix of Quads and Netserver plus Hiper
  270. DSP and ARC).  He regularly gets a 41 to 44K connection into other
  271. ISPs.  He claims to have the latest V90 code on his modem.  Can
  272. anyone offer a solution please?
  273.  
  274.  
  275.  
  276. ****************************************************************
  277. * Fred Williams                 email   fwilliams@gtnet.gov.uk *
  278. * CCTA                          voice   01603 704706           *
  279. * Rosebery Court                GTN     3040 4706              *
  280. * St Andrews Business Park      fax     01603 704817           *
  281. * NORWICH                       GTN fax 3040 4817              *
  282. * NR7 0HS  UK                                                  *
  283. ****************************************************************
  284.  
  285. -
  286.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  287.  with "unsubscribe usr-tc" in the body of the message.
  288.  For information on digests or retrieving files and old messages send
  289.  "help" to the same address.  Do not use quotes in your message.
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299. -
  300.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  301.  with "unsubscribe usr-tc" in the body of the message.
  302.  For information on digests or retrieving files and old messages send
  303.  "help" to the same address.  Do not use quotes in your message.
  304.  
  305.  
  306. -------------------------------------------------------------------------------
  307.  
  308. From: "John Verreault" <verreaul@aei.ca>
  309. Subject: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
  310. Date: 01 Apr 1999 14:48:49 -0500
  311.  
  312. I have set up a Primary Accounting Server and a Primary Backup Accounting
  313. Server.
  314.  
  315. I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH
  316.  
  317. This works fine, except when the backup server takes over authentication it
  318. doesn't switch back to the primary automatically.
  319.  
  320. What is the correct config ????
  321.  
  322. Thanks
  323. JOhn
  324. AEI Internet
  325.  
  326.  
  327.  
  328. -
  329.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  330.  with "unsubscribe usr-tc" in the body of the message.
  331.  For information on digests or retrieving files and old messages send
  332.  "help" to the same address.  Do not use quotes in your message.
  333.  
  334.  
  335. -------------------------------------------------------------------------------
  336.  
  337. From: "Sam Lowe" <slowe@universalcom.net>
  338. Subject: Re: (usr-tc) performance on quad modems
  339. Date: 01 Apr 1999 14:18:50 -0600
  340.  
  341. This is a multi-part message in MIME format.
  342.  
  343. ------=_NextPart_000_016F_01BE7C4A.90633F00
  344. Content-Type: text/plain;
  345.     charset="Windows-1252"
  346. Content-Transfer-Encoding: quoted-printable
  347.  
  348. All done already.  Everything is running latest sw and x2 key applied.
  349.  
  350. Any other ideas?
  351.   ----- Original Message -----=20
  352.   From: Alessandro Alves=20
  353.   To: usr-tc@lists.xmission.com=20
  354.   Sent: Thursday, April 01, 1999 9:00 AM
  355.   Subject: Re: (usr-tc) performance on quad modems
  356.  
  357.  
  358.   Hi,
  359.  
  360.   To connect 56 K, you need to put the latest version in NMC and T1 =
  361. boards too. And you need to put the ability key for X2 in the NMC board.
  362.   At 08:29 AM 4/1/99 -0600, you wrote:=20
  363.  
  364.     We have a old style chassis running 6 quad modems and a Hiper Arc =
  365. card that we use for backup analog access in one of our POPs.  For some =
  366. reason, users cannot access this chassis above 33.6, and it is usually =
  367. much lower connection.
  368.  
  369.     The quads are running 5.10.9, the hiper arc 4.1.59.
  370.  
  371.     It is fed by a channelized T-1 via a dual t-1 board.  We have both a =
  372. hunt group and DS0 dial numbers, and testing from here indicates that it =
  373. does not matter which DS0 you dial in on.
  374.  
  375.     Any ideas???
  376.  
  377.     Samuel S. Lowe
  378.     Director, Data Network Services
  379.     UniversalCom, Inc.
  380.     slowe@universalcom.net
  381.  
  382.  
  383.  
  384.  
  385. ------=_NextPart_000_016F_01BE7C4A.90633F00
  386. Content-Type: text/html;
  387.     charset="Windows-1252"
  388. Content-Transfer-Encoding: quoted-printable
  389.  
  390. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  391. <HTML><HEAD>
  392. <META content=3Dtext/html;charset=3DWindows-1252 =
  393. http-equiv=3DContent-Type>
  394. <STYLE></STYLE>
  395.  
  396. <META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD>
  397. <BODY bgColor=3D#ffffff>
  398. <DIV><FONT size=3D2>All done already.  Everything is running latest =
  399. sw and x2=20
  400. key applied.</FONT></DIV>
  401. <DIV> </DIV>
  402. <DIV><FONT size=3D2>Any other ideas?</FONT></DIV>
  403. <BLOCKQUOTE=20
  404. style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
  405. 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  406.   <DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
  407.   <DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
  408.   href=3D"mailto:aalves@mpcnet.com.br" =
  409. title=3Daalves@mpcnet.com.br>Alessandro=20
  410.   Alves</A> </DIV>
  411.   <DIV><B>To:</B> <A href=3D"mailto:usr-tc@lists.xmission.com"=20
  412.   title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV>
  413.   <DIV><B>Sent:</B> Thursday, April 01, 1999 9:00 AM</DIV>
  414.   <DIV><B>Subject:</B> Re: (usr-tc) performance on quad =
  415. modems</DIV></DIV>
  416.   <DIV><BR></DIV>Hi,<BR><BR>To connect 56 K, you need to put the latest =
  417. version=20
  418.   in NMC and T1 boards too. And you need to put the ability key for X2 =
  419. in the=20
  420.   NMC board.<BR>At 08:29 AM 4/1/99 -0600, you wrote: <BR><FONT size=3D2>
  421.   <BLOCKQUOTE cite type =3D cite>We have a old style chassis running 6 =
  422. quad=20
  423.     modems and a Hiper Arc card that we use for backup analog access in =
  424. one of=20
  425.     our POPs.  For some reason, users cannot access this chassis =
  426. above=20
  427.     33.6, and it is usually much lower connection.<BR><BR>The quads are =
  428. running=20
  429.     5.10.9, the hiper arc 4.1.59.<BR><BR>It is fed by a channelized T-1 =
  430. via a=20
  431.     dual t-1 board.  We have both a hunt group and DS0 dial =
  432. numbers, and=20
  433.     testing from here indicates that it does not matter which DS0 you =
  434. dial in=20
  435.     on.<BR><BR>Any ideas???<BR><BR>Samuel S. Lowe<BR>Director, Data =
  436. Network=20
  437.     Services<BR>UniversalCom, Inc.<BR><FONT size=3D2><A=20
  438.     =
  439. href=3D"mailto:slowe@universalcom.net">slowe@universalcom.net</A><BR></BL=
  440. OCKQUOTE><BR></FONT></FONT></BLOCKQUOTE></BODY></HTML>
  441.  
  442. ------=_NextPart_000_016F_01BE7C4A.90633F00--
  443.  
  444.  
  445. -
  446.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  447.  with "unsubscribe usr-tc" in the body of the message.
  448.  For information on digests or retrieving files and old messages send
  449.  "help" to the same address.  Do not use quotes in your message.
  450.  
  451.  
  452. -------------------------------------------------------------------------------
  453.  
  454. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  455. Subject: Re: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
  456. Date: 01 Apr 1999 15:25:59 -0600 (CST)
  457.  
  458. On Thu, 1 Apr 1999, John Verreault wrote:
  459.  
  460. > I have set up a Primary Accounting Server and a Primary Backup Accounting
  461. > Server.
  462. > 
  463. > I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH
  464.  
  465. If the primary is down it will go to the primary_backup and if the 
  466. primary back up is down then it will go to the primary - that is how 
  467. fall_through works with primary back and primary server.
  468.  
  469. There should be an option set radius authentication_algo active_server
  470.  
  471. that is what you need.
  472.  
  473. krish
  474.  
  475. > 
  476. > This works fine, except when the backup server takes over authentication it
  477. > doesn't switch back to the primary automatically.
  478. > 
  479. > What is the correct config ????
  480. > 
  481. > Thanks
  482. > JOhn
  483. > AEI Internet
  484. > 
  485. > 
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  496.  with "unsubscribe usr-tc" in the body of the message.
  497.  For information on digests or retrieving files and old messages send
  498.  "help" to the same address.  Do not use quotes in your message.
  499.  
  500.  
  501. -------------------------------------------------------------------------------
  502.  
  503. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  504. Subject: RE: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
  505. Date: 01 Apr 1999 15:15:22 -0600
  506.  
  507.  
  508.  
  509. |-----Original Message-----
  510. |From: owner-usr-tc@lists.xmission.com
  511. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Verreault
  512. |Sent: Thursday, April 01, 1999 1:49 PM
  513. |To: usr-tc@lists.xmission.com
  514. |Subject: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
  515. |
  516. |
  517. |I have set up a Primary Accounting Server and a Primary Backup Accounting
  518. |Server.
  519. |
  520. |I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH
  521. |
  522. |This works fine, except when the backup server takes over authentication it
  523. |doesn't switch back to the primary automatically.
  524. |
  525. |What is the correct config ????
  526.  
  527. That config only applies to "AUTHENTICATION" like the name implies. To set this
  528. up for "ACCOUNTING"
  529. set the following "ENABLE PRIORITIZE".
  530.  
  531. -M
  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: "John Verreault" <verreaul@aei.ca>
  544. Subject: RE: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
  545. Date: 01 Apr 1999 16:25:56 -0500
  546.  
  547. Works like a charm, Thanks
  548. John
  549.  
  550. > -----Original Message-----
  551. > From: owner-usr-tc@lists.xmission.com
  552. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski
  553. > Sent: Thursday, April 01, 1999 4:15 PM
  554. > To: usr-tc@lists.xmission.com
  555. > Subject: RE: (usr-tc) Problem - Primary Backup radius server w/ARC
  556. > 4.1.59-6
  557. >
  558. >
  559. >
  560. >
  561. > |-----Original Message-----
  562. > |From: owner-usr-tc@lists.xmission.com
  563. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Verreault
  564. > |Sent: Thursday, April 01, 1999 1:49 PM
  565. > |To: usr-tc@lists.xmission.com
  566. > |Subject: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
  567. > |
  568. > |
  569. > |I have set up a Primary Accounting Server and a Primary Backup Accounting
  570. > |Server.
  571. > |
  572. > |I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH
  573. > |
  574. > |This works fine, except when the backup server takes over
  575. > authentication it
  576. > |doesn't switch back to the primary automatically.
  577. > |
  578. > |What is the correct config ????
  579. >
  580. > That config only applies to "AUTHENTICATION" like the name
  581. > implies. To set this
  582. > up for "ACCOUNTING"
  583. > set the following "ENABLE PRIORITIZE".
  584. >
  585. > -M
  586. >
  587. >
  588. > -
  589. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  590. >  with "unsubscribe usr-tc" in the body of the message.
  591. >  For information on digests or retrieving files and old messages send
  592. >  "help" to the same address.  Do not use quotes in your message.
  593. >
  594.  
  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: "Randy Cosby" <dcosby@infowest.com>
  606. Subject: (usr-tc) Primary first backup vs. secondary accounting
  607. Date: 01 Apr 1999 14:37:26 -0700
  608.  
  609. How do I set the server IP for the primary first backup server, and primary
  610. third backup server?  What's the difference between the primary first backup
  611. and the secondary server?
  612.  
  613. The Primary Server Status is:              ENABLED
  614. Primary Server is:                         x.x.x.x
  615. Primary First Backup Server is:            0.0.0.0
  616. Primary Second Backup Server is:           0.0.0.0
  617. Primary Destination Port is:               1646
  618. Primary First Backup Destination Port:     1646
  619. Primary Second Backup Destination Port:    1646
  620. Max Primary Retranmissions:                20
  621. The Secondary Server Status is:            ENABLED
  622. Secondary Server is:                       0.0.0.0
  623. Secondary First Backup Server is:          0.0.0.0
  624. Secondary Second Backup Server is:         0.0.0.0
  625. Secondary Destination Port is:             1646
  626. Secondary First Backup Destination Port:   1646
  627. Secondary Second Backup Destination Port:  1646
  628. Max Secondary Retranmissions:              0
  629. Source Port is:                            1646
  630. Retransmission  Timeout:                   60 seconds
  631. Accounting Start Time:                     CONNECTION
  632. Log Unauthenticated Calls:                 FALSE
  633. Vendor Specific Attribute:                 ENABLED
  634. Active Accounting Server (Primary):        x.x.x.x
  635. Active Accounting Server (Secondary):      0.0.0.0
  636. Attribute Style:                           STANDARD
  637. Prioritize First Server in a Server Group: DISABLED
  638.  
  639. ---
  640.  
  641. set accounting
  642. CLI - Missing Required Argument(s):
  643.  
  644. This field is a KEYWORD. The possible values are:
  645. ATTRIBUTE_STYLE              PRIMARY_SERVER               SOURCE_PORT
  646. LOG_UNAUTHENTICATED_CALLS    SECONDARY_DESTINATION_PORT   START_TIME
  647. PRIMARY_DESTINATION_PORT     SECONDARY_RETRANSMISSIONS    TIMEOUT
  648. PRIMARY_RETRANSMISSIONS      SECONDARY_SECRET             VSA
  649. PRIMARY_SECRET               SECONDARY_SERVER
  650. Required Arguments are:
  651.  
  652. End of Command
  653.  
  654.  
  655. _sho ver
  656. V4.1.59 - 6
  657.  
  658. ---
  659.  
  660. I  see how to set the secondary server, but not the primary first or second
  661. backup.
  662.  
  663. thanks,
  664.  
  665. Randy
  666.  
  667.  
  668. -
  669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  670.  with "unsubscribe usr-tc" in the body of the message.
  671.  For information on digests or retrieving files and old messages send
  672.  "help" to the same address.  Do not use quotes in your message.
  673.  
  674.  
  675. -------------------------------------------------------------------------------
  676.  
  677. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  678. Subject: RE: (usr-tc) Primary first backup vs. secondary accounting
  679. Date: 01 Apr 1999 17:17:45 -0600
  680.  
  681.  
  682.  
  683. |-----Original Message-----
  684. |From: owner-usr-tc@lists.xmission.com
  685. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Cosby
  686. |Sent: Thursday, April 01, 1999 3:37 PM
  687. |To: usr-tc@lists.xmission.com
  688. |Subject: (usr-tc) Primary first backup vs. secondary accounting
  689. |
  690. |
  691. |How do I set the server IP for the primary first backup server, and primary
  692. |third backup server?  What's the difference between the primary first backup
  693. |and the secondary server?
  694. |
  695. |
  696. |I  see how to set the secondary server, but not the primary first or second
  697. |backup.
  698.  
  699. If a Secondary is configured then accounting packets are send to both primary and
  700. secondary "EVERY" time. This is for database duplication,etc.
  701.  
  702. For a fallback server (ie main server goes down, use fallback) you configure a
  703. PRIMARY_BACKUP with the command
  704. "set accounting_backup primary first_server X.X.X.X"
  705. "set accounting_backup primary first_secret secret"
  706.  
  707. You get the idea..
  708.  
  709. -M
  710.  
  711.  
  712. -
  713.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  714.  with "unsubscribe usr-tc" in the body of the message.
  715.  For information on digests or retrieving files and old messages send
  716.  "help" to the same address.  Do not use quotes in your message.
  717.  
  718.  
  719. -------------------------------------------------------------------------------
  720.  
  721. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  722. Subject: (usr-tc) FYI: Webramp DOS
  723. Date: 01 Apr 1999 12:14:44 -0600
  724.  
  725. Just saw this on BUGTRAQ. Thought it would be of interest to some of you.
  726.  
  727.  
  728. Quote from ISS Vulnerability Notice:
  729.  
  730. "WebRamp is vulnerable to two denial of service attacks that allow an
  731. attacker to either crash the WebRamp device or change its IP address.
  732. When the device crashes, it will have to be manually reset before
  733. it will dial up. If an attacker changes the IP address of the WebRamp,
  734. none of the machines on your network will be able to find it, so no
  735. machines will be able to access the Internet via the WebRamp. The device
  736. will still function as a network hub, so your intra-LAN connectivity will
  737. not be disrupted."
  738.  
  739. Fix Information:
  740.  
  741. Go to http://www.rampnet.com/upgrades to get the latest firmware for your
  742. model of WebRamp.
  743.  
  744.  
  745. Mike Wronski (mike@coredump.ae.usr.com)     
  746. Rogue 3Com Network Systems Engineer / BETA Engineer 
  747. PGP:http://coredump.ae.usr.com/pgp iCQ:15796141
  748. "If at first you do succeed, try not to look astonished."  
  749.  
  750. -
  751.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  752.  with "unsubscribe usr-tc" in the body of the message.
  753.  For information on digests or retrieving files and old messages send
  754.  "help" to the same address.  Do not use quotes in your message.
  755.  
  756.  
  757. -------------------------------------------------------------------------------
  758.  
  759. From: "Roy, Richard" <richard.roy@nbtel.nb.ca>
  760. Subject: (usr-tc) SLIP start message
  761. Date: 31 Mar 1999 16:42:07 -0400
  762.  
  763. Hi,
  764.  
  765. I'm trying to find a way to customize a SLIP start message string with the
  766. command "set slip session_start_message ..."
  767.  
  768. What I have before:
  769. SL/IP session from (1.2.3.4) to 1.2.3.4 beginning....
  770.  
  771. Now with HA version 4.1.59-6, I have
  772. SL/IP session from ( 1.2.3.4  ) to  1.2.3.4 beginning....
  773.  
  774. I'm trying to get rid of the spaces in "( 1.2.3.4  )". Is anyone have a
  775. recipe for this.
  776.  
  777. Thanks.
  778.  
  779. Richard Roy
  780. NBTel Internet.
  781.  
  782. -
  783.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  784.  with "unsubscribe usr-tc" in the body of the message.
  785.  For information on digests or retrieving files and old messages send
  786.  "help" to the same address.  Do not use quotes in your message.
  787.  
  788.  
  789. -------------------------------------------------------------------------------
  790.  
  791. From: "Randy McMillan" <randy@pacinfo.com>
  792. Subject: Re: (usr-tc) modem configs
  793. Date: 01 Apr 1999 16:39:16 -0800
  794.  
  795. I can disable the v.90 on the quad modems, but then the fastest speed I can
  796. get on the line is 28800 or less.  It seems to be disabling v.34+ speeds.
  797. Does anyone know why or a way to work around it?  Actually, it works the
  798. same if I disable v.90 on my sportster and dial in to a v.90 enabled line.
  799. Thanks.
  800.  
  801. Randy McMillan
  802. PacInfo
  803.  
  804. ----- Original Message -----
  805. Sent: Friday, March 26, 1999 2:00 PM
  806.  
  807.  
  808. > On Mon, 22 Mar 1999, Mike Andrews wrote:
  809. >
  810. > > I'm also having a problem that maybe someone else can help with here.
  811. The
  812. > > above init string doesn't disable v.90/x2 correctly on the Quads. (Works
  813. > > great on DSP's.)  If I call in with a Courier, it chokes during the
  814. > > handshake -- it sounds as if one side is attempting x2 (not v.90) and
  815. the
  816. > > other side is trying v.34.  (It dies during the line frequency probe
  817. > > sequence, in other words.)  If I call in with an LT Winmodem it seems to
  818. > > be more or less OK.
  819. > >
  820. > > So...  What's the *correct* AT sequence to completely kill all 56K
  821. > > modulations on a Quad modem and leave v.34 intact?
  822. >
  823. > If anyone cares, I fixed this by disabling all 3 x2 modes -- client,
  824. > server, and symmetric.  Apparently disabling just server wasn't good
  825. > enough for the Quads.  Go figure...
  826. >
  827. >
  828. > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort
  829. KY
  830. > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without
  831. a
  832. > Microsoft operating system is like a dog without a brick tied to its
  833. head."
  834. >
  835. >
  836. > -
  837. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  838. >  with "unsubscribe usr-tc" in the body of the message.
  839. >  For information on digests or retrieving files and old messages send
  840. >  "help" to the same address.  Do not use quotes in your message.
  841. >
  842.  
  843.  
  844. -
  845.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  846.  with "unsubscribe usr-tc" in the body of the message.
  847.  For information on digests or retrieving files and old messages send
  848.  "help" to the same address.  Do not use quotes in your message.
  849.  
  850.  
  851. -------------------------------------------------------------------------------
  852.  
  853. From: Brian <signal@shreve.net>
  854. Subject: (usr-tc) [isp-services] FS:USR Total Control Units (fwd)
  855. Date: 02 Apr 1999 09:41:16 -0600 (EST)
  856.  
  857.  
  858. This is damn cheap in case anyone is looking for some older hardware.
  859. Thats $47 a port.
  860.  
  861.  
  862. Brian Feeny (BF304)     signal@shreve.net   
  863. 318-222-2638 x 109    http://www.shreve.net/~signal      
  864. Network Administrator   ShreveNet Inc. (ASN 11881)           
  865.  
  866. ---------- Forwarded message ----------
  867.  
  868. Have (2) Total Control Units, in Stock of Analog:
  869.  
  870. USR Total Control Units 
  871.  1 Netserver PRI
  872. 1 Net Mgt card
  873. 15 Quad V.34 modem cards.
  874. 2 Power supplies (45amp)
  875. 1 Fantray
  876. Set up token ring
  877.  
  878. $2,300 each
  879.  
  880. Also, 
  881.  
  882. Have (2) Digital Total Control Units -with PRI T-1 cards
  883.  
  884. $3,500 each
  885.  
  886. Have a great day!
  887.  
  888. Andrew Shlensky 
  889. ****************************
  890. PC Global, Incorporated 
  891. (305) 667-2111 TEL
  892. (305) 667-3636 FAX
  893. URL:     http://www.pcglobal.net
  894. E-MAIL: andrew@pcglobal.net
  895. ICQ:       21219089    
  896.  
  897.  
  898. To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org
  899. For additional commands, e-mail: isp-services-help@ispc.org
  900. =========================================================================
  901. ISPF - The Forum for ISPs by ISPs(tm)  ||  Nov 15-17, 1999, New Orleans
  902. 3 days of clues, news, and views from the industry's best and brightest.
  903.      Visit <http://www.ispf.com/> for information and registration.
  904. =========================================================================
  905.  
  906.  
  907. -
  908.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  909.  with "unsubscribe usr-tc" in the body of the message.
  910.  For information on digests or retrieving files and old messages send
  911.  "help" to the same address.  Do not use quotes in your message.
  912.  
  913.  
  914. -------------------------------------------------------------------------------
  915.  
  916. From: Brian <signal@shreve.net>
  917. Subject: (usr-tc) Rockwell HCF 56k PCI
  918. Date: 02 Apr 1999 09:51:57 -0600 (EST)
  919.  
  920.  
  921. does anyone know of any issues with these modems?  We are running 4.1.59-1
  922. and 1.2.6.  I got the below message from our Tech Support Mgr.
  923.  
  924. Brian
  925.  
  926.  
  927. Brian Feeny (BF304)     signal@shreve.net   
  928. 318-222-2638 x 109    http://www.shreve.net/~signal      
  929. Network Administrator   ShreveNet Inc. (ASN 11881)           
  930.  
  931. ---------- Forwarded message ----------
  932.  
  933. Rockwell HCF 56k PCI modems are giving all of us hell more than the LT
  934. Winmodems  I saw one yesterday but we have 2 right now that can connect
  935. but they get dropped w/in 2-15 minutes of being online.  Can you find out
  936. if there is an issue out there with these modems.
  937.  
  938. The one I had yesterday was a Hayes todays ones are Rockwell but they all
  939. use the same chip.  Even putting an init string in it doesnt help
  940.  
  941. THanks,
  942.  
  943. Scarlett
  944.  
  945.  
  946.  
  947.  
  948. -
  949.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  950.  with "unsubscribe usr-tc" in the body of the message.
  951.  For information on digests or retrieving files and old messages send
  952.  "help" to the same address.  Do not use quotes in your message.
  953.  
  954.  
  955. -------------------------------------------------------------------------------
  956.  
  957. From: Steve Rivera <sales@wrca.net>
  958. Subject: (usr-tc) USR Total Control Units for sale
  959. Date: 02 Apr 1999 11:08:37 -0500
  960.  
  961. All sold with 30 day warranty!
  962.  
  963. 10-USR Total Control Units 
  964. configured as:)
  965.  
  966. 1 Chassis
  967. 1 Net Mgt card
  968. 15 Quad dig/analog
  969. 2 Power supplies (45amp)
  970. set up for ethernet
  971. $2500
  972.  
  973.  
  974. 1-USR Total Control Units 
  975.  
  976. 1 Chassis
  977. 1 Netserver PRI
  978. 1 Net Mgt card
  979. 15 Quad digital/analog
  980. 2 Power supplies (70amp)
  981. set up for ethernet
  982. Fan Tray
  983.  
  984. $4500
  985.  
  986. Steve Rivera  sales@wrca.net 
  987. Check out product information and inventory.
  988. http://www.wrca.net(All New 3/22/99)
  989.     732-833-2111
  990. '''''''''''''''''''''''''''''''''''''''''''''''
  991. De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  992. '''''''''''''''''''''''''''''''''''''''''''''''
  993.  
  994.  
  995.  
  996.      
  997.   
  998.  
  999.  
  1000.  
  1001.  
  1002. -
  1003.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1004.  with "unsubscribe usr-tc" in the body of the message.
  1005.  For information on digests or retrieving files and old messages send
  1006.  "help" to the same address.  Do not use quotes in your message.
  1007.  
  1008.  
  1009. -------------------------------------------------------------------------------
  1010.  
  1011. From: Jeff Mcadams <jeffm@iglou.com>
  1012. Subject: Re: (usr-tc) Rockwell HCF 56k PCI
  1013. Date: 02 Apr 1999 11:13:06 -0500 (EST)
  1014.  
  1015. Thus spake Brian
  1016. >does anyone know of any issues with these modems?  We are running 4.1.59-1
  1017. >and 1.2.6.  I got the below message from our Tech Support Mgr.
  1018.  
  1019. There's a huge amount of discussion about these at www.56k.com in the
  1020. message boards...a flash upgrade helps tremendously typically (2.1.2.135
  1021. I believe is known to work pretty well).
  1022. -- 
  1023. Jeff McAdams                            Email: jeffm@iglou.com
  1024. Head Network Administrator              Voice: (502) 966-3848
  1025. IgLou Internet Services                        (800) 436-4456
  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. From: Brian <signal@shreve.net>
  1037. Subject: Re: (usr-tc) Rockwell HCF 56k PCI
  1038. Date: 02 Apr 1999 10:21:30 -0600 (EST)
  1039.  
  1040.  
  1041. Thanks Jeff, I have sent them to check it out.
  1042.  
  1043.  
  1044. On Fri, 2 Apr 1999, Jeff Mcadams wrote:
  1045.  
  1046. > Thus spake Brian
  1047. > >does anyone know of any issues with these modems?  We are running 4.1.59-1
  1048. > >and 1.2.6.  I got the below message from our Tech Support Mgr.
  1049. > 
  1050. > There's a huge amount of discussion about these at www.56k.com in the
  1051. > message boards...a flash upgrade helps tremendously typically (2.1.2.135
  1052. > I believe is known to work pretty well).
  1053. > -- 
  1054. > Jeff McAdams                            Email: jeffm@iglou.com
  1055. > Head Network Administrator              Voice: (502) 966-3848
  1056. > IgLou Internet Services                        (800) 436-4456
  1057. > 
  1058. > -
  1059. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1060. >  with "unsubscribe usr-tc" in the body of the message.
  1061. >  For information on digests or retrieving files and old messages send
  1062. >  "help" to the same address.  Do not use quotes in your message.
  1063. > 
  1064.  
  1065. Brian Feeny (BF304)     signal@shreve.net   
  1066. 318-222-2638 x 109    http://www.shreve.net/~signal      
  1067. Network Administrator   ShreveNet Inc. (ASN 11881)           
  1068.  
  1069.  
  1070. -
  1071.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1072.  with "unsubscribe usr-tc" in the body of the message.
  1073.  For information on digests or retrieving files and old messages send
  1074.  "help" to the same address.  Do not use quotes in your message.
  1075.  
  1076.  
  1077. -------------------------------------------------------------------------------
  1078.  
  1079. From: "Jamie Orzechowski" <mhz@recorder.ca>
  1080. Subject: Re: (usr-tc) Rockwell HCF 56k PCI
  1081. Date: 02 Apr 1999 11:38:10 -0500
  1082.  
  1083. I can;t seem to find the new Rockwell HCF flash anywhere?? anyone know where
  1084. I can snag it?
  1085.  
  1086. -----Original Message-----
  1087.  
  1088.  
  1089. >Thus spake Brian
  1090. >>does anyone know of any issues with these modems?  We are running 4.1.59-1
  1091. >>and 1.2.6.  I got the below message from our Tech Support Mgr.
  1092. >
  1093. >There's a huge amount of discussion about these at www.56k.com in the
  1094. >message boards...a flash upgrade helps tremendously typically (2.1.2.135
  1095. >I believe is known to work pretty well).
  1096. >--
  1097. >Jeff McAdams                            Email: jeffm@iglou.com
  1098. >Head Network Administrator              Voice: (502) 966-3848
  1099. >IgLou Internet Services                        (800) 436-4456
  1100. >
  1101. >-
  1102. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1103. > with "unsubscribe usr-tc" in the body of the message.
  1104. > For information on digests or retrieving files and old messages send
  1105. > "help" to the same address.  Do not use quotes in your message.
  1106. >
  1107. >
  1108.  
  1109.  
  1110. -
  1111.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1112.  with "unsubscribe usr-tc" in the body of the message.
  1113.  For information on digests or retrieving files and old messages send
  1114.  "help" to the same address.  Do not use quotes in your message.
  1115.  
  1116.  
  1117. -------------------------------------------------------------------------------
  1118.  
  1119. From: Hofmann <jay@iglou.com>
  1120. Subject: RE: (usr-tc) Rockwell HCF 56k PCI
  1121. Date: 02 Apr 1999 12:14:46 -0500
  1122.  
  1123. http://www.radi.com/software.htm
  1124.  
  1125.  
  1126. I can;t seem to find the new Rockwell HCF flash anywhere?? anyone know where
  1127. I can snag it?
  1128.  
  1129.  
  1130.  
  1131. >Thus spake Brian
  1132. >>does anyone know of any issues with these modems?  We are running 4.1.59-1
  1133. >>and 1.2.6.  I got the below message from our Tech Support Mgr.
  1134. >
  1135. >There's a huge amount of discussion about these at www.56k.com in the
  1136. >message boards...a flash upgrade helps tremendously typically (2.1.2.135
  1137. >I believe is known to work pretty well).
  1138. >
  1139. >
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146. -
  1147.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1148.  with "unsubscribe usr-tc" in the body of the message.
  1149.  For information on digests or retrieving files and old messages send
  1150.  "help" to the same address.  Do not use quotes in your message.
  1151.  
  1152.  
  1153. -------------------------------------------------------------------------------
  1154.  
  1155. From: "Greg Owens" <gowens@magnolia-net.com>
  1156. Subject: Re: (usr-tc) Rockwell HCF 56k PCI
  1157. Date: 02 Apr 1999 12:13:17 -0600
  1158.  
  1159.  We are experiencing the same issues with the Rockwell HCF/PCI modems with
  1160. the 4.1.59-1 code also. What I am curious about has anyone had success with
  1161. the code listed on this page http://www.radi.com/software.htm  Reason for
  1162. asking..In the last two days I have hooked up 2 Compaq computers with these
  1163. type  modems and neither would connect unitl I disabled V-90. These
  1164. computers were bought in Dec98 and Jan99. I notice the file date for the HCF
  1165. modems are Dec 2nd. Is this the newest code? Before I send my users to
  1166. download this file wanted to make sure..As for the brand new Compaqs with
  1167. the HCF's they apperar to connect very well.
  1168.  
  1169. -----Original Message-----
  1170.  
  1171.  
  1172. >http://www.radi.com/software.htm
  1173. >
  1174. >
  1175. >I can;t seem to find the new Rockwell HCF flash anywhere?? anyone know
  1176. where
  1177. >I can snag it?
  1178. >
  1179. >
  1180. >
  1181. >>Thus spake Brian
  1182. >>>does anyone know of any issues with these modems?  We are running
  1183. 4.1.59-1
  1184. >>>and 1.2.6.  I got the below message from our Tech Support Mgr.
  1185. >>
  1186. >>There's a huge amount of discussion about these at www.56k.com in the
  1187. >>message boards...a flash upgrade helps tremendously typically (2.1.2.135
  1188. >>I believe is known to work pretty well).
  1189. >>
  1190. >>
  1191. >
  1192. >
  1193. >
  1194. >
  1195. >
  1196. >
  1197. >-
  1198. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1199. > with "unsubscribe usr-tc" in the body of the message.
  1200. > For information on digests or retrieving files and old messages send
  1201. > "help" to the same address.  Do not use quotes in your message.
  1202. >
  1203.  
  1204.  
  1205. -
  1206.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1207.  with "unsubscribe usr-tc" in the body of the message.
  1208.  For information on digests or retrieving files and old messages send
  1209.  "help" to the same address.  Do not use quotes in your message.
  1210.  
  1211.  
  1212. -------------------------------------------------------------------------------
  1213.  
  1214. From: "John C Hill II" <carroll@netexas.net>
  1215. Subject: RE: (usr-tc) Rockwell HCF 56k PCI
  1216. Date: 02 Apr 1999 12:29:04 -0600
  1217.  
  1218. We had one Rockwell PCI in our shop recently. I don't know if it was made or
  1219. sold by Powercom-usa. Anyway, I went to Powercom's webpage
  1220. (www.powercom-usa.com) webpage and downloaded the latest driver. We haven't
  1221. had any problems. We are running DSP code .69
  1222.  
  1223.  
  1224. John C Hill II
  1225. North East Texas Internet
  1226.  
  1227.  
  1228. -
  1229.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1230.  with "unsubscribe usr-tc" in the body of the message.
  1231.  For information on digests or retrieving files and old messages send
  1232.  "help" to the same address.  Do not use quotes in your message.
  1233.  
  1234.  
  1235. -------------------------------------------------------------------------------
  1236.  
  1237. From: "Richard Gamberg" <bbhi@shaka.com>
  1238. Subject: RE: (usr-tc) Rockwell HCF 56k PCI
  1239. Date: 02 Apr 1999 09:30:12 -1000
  1240.  
  1241. Also see
  1242. http://808hi.com/56k/rockhcf.htm
  1243. for the HCF page at 56k=v.Unreliable;
  1244. has a table of vendors w/ links to their firmware updates, and other useful
  1245. info.
  1246.  
  1247. Aloha,
  1248. Richard
  1249. http://808hi.com/56k/ 56k=v.Unreliable
  1250.  
  1251.  
  1252. -> -----Original Message-----
  1253. -> From: owner-usr-tc@lists.xmission.com
  1254. -> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  1255. -> Sent: Friday, April 02, 1999 5:52 AM
  1256. -> To: USRobotics TC Mailing List
  1257. -> Subject: (usr-tc) Rockwell HCF 56k PCI
  1258. ->
  1259. ->
  1260. ->
  1261. -> does anyone know of any issues with these modems?  We are
  1262. -> running 4.1.59-1
  1263. -> and 1.2.6.  I got the below message from our Tech Support Mgr.
  1264. ->
  1265. -> Brian
  1266. ->
  1267. ->
  1268. -> -----------------------------------------------------
  1269. -> Brian Feeny (BF304)     signal@shreve.net
  1270. -> 318-222-2638 x 109    http://www.shreve.net/~signal
  1271. -> Network Administrator   ShreveNet Inc. (ASN 11881)
  1272. ->
  1273. -> ---------- Forwarded message ----------
  1274. -> Date: Fri, 2 Apr 1999 09:47:43 -0600 (EST)
  1275. -> From: Scarlett <scarlett@shreve.net>
  1276. -> To: Brian <signal@shreve.net>
  1277. -> Subject: Modem ISSUE
  1278. ->
  1279. -> Rockwell HCF 56k PCI modems are giving all of us hell more than the LT
  1280. -> Winmodems  I saw one yesterday but we have 2 right now that can connect
  1281. -> but they get dropped w/in 2-15 minutes of being online.  Can you find out
  1282. -> if there is an issue out there with these modems.
  1283. ->
  1284. -> The one I had yesterday was a Hayes todays ones are Rockwell but they all
  1285. -> use the same chip.  Even putting an init string in it doesnt help
  1286. ->
  1287. -> THanks,
  1288. ->
  1289. -> Scarlett
  1290. ->
  1291. ->
  1292. ->
  1293. ->
  1294. -> -
  1295. ->  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1296. ->  with "unsubscribe usr-tc" in the body of the message.
  1297. ->  For information on digests or retrieving files and old messages send
  1298. ->  "help" to the same address.  Do not use quotes in your message.
  1299. ->
  1300.  
  1301.  
  1302. -
  1303.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1304.  with "unsubscribe usr-tc" in the body of the message.
  1305.  For information on digests or retrieving files and old messages send
  1306.  "help" to the same address.  Do not use quotes in your message.
  1307.  
  1308.  
  1309. -------------------------------------------------------------------------------
  1310.  
  1311. From: "David Bachta" <David_Bachta@mw.3com.com>
  1312. Subject: (usr-tc) Hiper DSP T1/PRI 1.2.43 Service Release
  1313. Date: 02 Apr 1999 16:40:17 -0600
  1314.  
  1315.  
  1316.  
  1317.  
  1318.    3Com Carrier Customer Support has posted HiPer DSP T1/PRI Service Release
  1319.    version 1.2.43 on the Totalservice technical support web site.
  1320.  
  1321.    This release will be available for download, free-of-charge, through the end
  1322.    of May, 1999.
  1323.  
  1324.    Version 1.2.43 is an effort to combine many previous Engineering Releases
  1325.    into a generally available code
  1326.    release.  It addresses a series of P1 and P2 issues identified with previous
  1327.    HiPer DSP code release.
  1328.  
  1329.    It can be accessed in either of the following locations:
  1330.  
  1331.         http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+latest
  1332.                    ( posted under Total Control Hubs )
  1333.                   or
  1334.         http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+software
  1335.                    ( search by Total Control Hubs : Hiper DSP )
  1336.  
  1337.  
  1338.    For a list of the issues addressed in this Service Release please review the
  1339.    Service Release Note, 24209600.pdf.  The release note is posted along side
  1340.    the code on the Totalservice website.   The release note is also available
  1341.    bundled with the code in the file hd010243.zip.
  1342.  
  1343.    Regards,
  1344.  
  1345.    David Bachta
  1346.    Network Engineer
  1347.    3Com
  1348.  
  1349.  
  1350.  
  1351. -
  1352.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1353.  with "unsubscribe usr-tc" in the body of the message.
  1354.  For information on digests or retrieving files and old messages send
  1355.  "help" to the same address.  Do not use quotes in your message.
  1356.  
  1357.  
  1358. -------------------------------------------------------------------------------
  1359.  
  1360. From: Pete Ashdown <pashdown@xmission.com>
  1361. Subject: (usr-tc) ATS48 and "optimum" settings
  1362. Date: 02 Apr 1999 16:13:29 -0700 (MST)
  1363.  
  1364. I'm just installing the DNIS stuff that Lon came up with, and I ran over
  1365. register S48 and noticed that it had disabled 300,1200,2400 and "high
  1366. speed".  What does this entail?  With the first three disabled, I presume I
  1367. can not take 300-2400 bps calls?  What does "high speed" cover?
  1368.  
  1369. Aside from the fact that anyone using a 300 bps modem must be a goof, I
  1370. prefer to support everything rather than cut someone out.  Is there any
  1371. harm in enabling all four of the above?  If not, why does it default with
  1372. them off?
  1373.  
  1374. -
  1375.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1376.  with "unsubscribe usr-tc" in the body of the message.
  1377.  For information on digests or retrieving files and old messages send
  1378.  "help" to the same address.  Do not use quotes in your message.
  1379.  
  1380.  
  1381. -------------------------------------------------------------------------------
  1382.  
  1383. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  1384. Subject: Re: (usr-tc) ATS48 and "optimum" settings
  1385. Date: 02 Apr 1999 18:31:52 -0500 (EST)
  1386.  
  1387.  
  1388. On Fri, 2 Apr 1999, Pete Ashdown wrote:
  1389.  
  1390. > I'm just installing the DNIS stuff that Lon came up with, and I ran over
  1391. > register S48 and noticed that it had disabled 300,1200,2400 and "high
  1392. > speed".  What does this entail?  With the first three disabled, I presume I
  1393. > can not take 300-2400 bps calls?  What does "high speed" cover?
  1394.  
  1395. That's my understanding (that it prevents those speeds). High Speed is
  1396. the old USR 'HST' protocol, I believe.
  1397.  
  1398. > Aside from the fact that anyone using a 300 bps modem must be a goof, I
  1399. > prefer to support everything rather than cut someone out.  Is there any
  1400. > harm in enabling all four of the above?  If not, why does it default with
  1401. > them off?
  1402.  
  1403. I have 'em enabled here; havent' noted any troubles...I have a handful
  1404. of 1200 and 2400 people still so need 'em (I still run my old text-based
  1405. bbs and some of the callers there still have ancient equipment; my
  1406. 'bbs' username does a rlogin to the bbs).
  1407.  
  1408.  
  1409.  
  1410. -
  1411.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1412.  with "unsubscribe usr-tc" in the body of the message.
  1413.  For information on digests or retrieving files and old messages send
  1414.  "help" to the same address.  Do not use quotes in your message.
  1415.  
  1416.  
  1417. -------------------------------------------------------------------------------
  1418.  
  1419. From: Kirk Mitchell <mitch@keyconn.net>
  1420. Subject: Re: (usr-tc) Rockwell HCF 56k PCI
  1421. Date: 02 Apr 1999 18:36:04 -0500
  1422.  
  1423. At 12:13 PM 4/2/99 -0600, you wrote:
  1424. > We are experiencing the same issues with the Rockwell HCF/PCI modems with
  1425. >the 4.1.59-1 code also. What I am curious about has anyone had success with
  1426. >the code listed on this page http://www.radi.com/software.htm  Reason for
  1427. >asking..In the last two days I have hooked up 2 Compaq computers with these
  1428. >type  modems and neither would connect unitl I disabled V-90. These
  1429. >computers were bought in Dec98 and Jan99. I notice the file date for the HCF
  1430. >modems are Dec 2nd. Is this the newest code? Before I send my users to
  1431. >download this file wanted to make sure..As for the brand new Compaqs with
  1432. >the HCF's they apperar to connect very well.
  1433.  
  1434. Try the driver at http://www.wellmodem.com.tw/hcf56drv.htm dated Dec 22,
  1435. we've had a fair amount of success with it.
  1436.  
  1437. Kirk
  1438.  
  1439.  
  1440.  
  1441. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  1442. Keystone Connect                http://www.keyconn.net
  1443. Altoona, PA   814-941-5000         We Unlock the World
  1444.  
  1445.  
  1446. -
  1447.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1448.  with "unsubscribe usr-tc" in the body of the message.
  1449.  For information on digests or retrieving files and old messages send
  1450.  "help" to the same address.  Do not use quotes in your message.
  1451.  
  1452.  
  1453. -------------------------------------------------------------------------------
  1454.  
  1455. From: Brian <signal@shreve.net>
  1456. Subject: (usr-tc) compaq Rockwell HCF modems (fwd)
  1457. Date: 02 Apr 1999 20:56:01 -0600 (EST)
  1458.  
  1459.  
  1460. some people here I thought may want this
  1461.  
  1462.  
  1463. Brian Feeny (BF304)     signal@shreve.net   
  1464. 318-222-2638 x 109    http://www.shreve.net/~signal      
  1465. Network Administrator   ShreveNet Inc. (ASN 11881)           
  1466.  
  1467. ---------- Forwarded message ----------
  1468.  
  1469.  
  1470. the main file area for the Rockwell HCF modem at compaq
  1471. http://www.compaq.com/athome/support/softpaq/pages/sp8897.html
  1472.  
  1473.  
  1474. VERSION:  4.1
  1475. LANGUAGE:  Multi-lingual 
  1476.  
  1477. CATEGORY:  Driver
  1478.  
  1479. DIVISIONS:  Consumer
  1480.  
  1481. PRODUCTS AFFECTED:  Compaq Presario 2262, 2264, 2266, 2275, 2278;
  1482.                         5010, 5015, 5020, 5027, 5030, 5032, 5035; 
  1483.                         5037, 5038, 5050, 5062, 5150, 5151, 5152, 
  1484.                         5155, 5170, 5177, 5190, 5192, 5110, 5140, 
  1485.                         5147, 5600 (Rockwell Modem only), 5610, 
  1486.                         5612, 5630, 5635, 5660, 5665 
  1487.  
  1488.  
  1489. OPERATING SYSTEM:  Microsoft Windows 95,
  1490.                    Microsoft Windows 98
  1491.  
  1492. SYSTEM CONFIGURATION:  Integrated 56K PCI modem 
  1493.                        (U.S., Canada, Latin America, and Brazil)
  1494.  
  1495. PREREQUISITES:  N/A
  1496.  
  1497. EFFECTIVE DATE:  January 8, 1999
  1498.  
  1499. ELECTRONIC DISTRIBUTION ALLOWED:  Yes
  1500.  
  1501. SOFTPAQ UTILITY VERSION:  3.x
  1502.  
  1503. SUPERSEDES:  SP7953
  1504.  
  1505. DESCRIPTION:  Unpacks files that are used with the Presario models
  1506. mentioned above to upgrade the drivers in the integrated modem.
  1507. The new driver version is 2.1.2.134.
  1508.  
  1509. Enhancements/Fixes
  1510.  In this version:
  1511.   - Improves V.90 performance 
  1512.   - Improves V.90 connections to US Robotics Total Control Modem Banks
  1513.   - Improves performance when playing Quake and Quake 2 over the Internet
  1514.  
  1515.  In previous version (2.1.2.120.1):
  1516.   - Corrects errors in connect rate messages when connected to a V.90
  1517. modem at 
  1518.     the Internet Service Provider (ISP)
  1519.   - Fixes Windows 98 issue that causes computer to lock up when an
  1520. incoming call
  1521.     is received when no communications applications are running
  1522.  
  1523. ........................................................................
  1524. joseph kamm        http://www.biohazard.net    jkamm@shreve.net
  1525. tech support, shrevenet inc., http://www.shreve.net
  1526.  
  1527.  
  1528. -
  1529.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1530.  with "unsubscribe usr-tc" in the body of the message.
  1531.  For information on digests or retrieving files and old messages send
  1532.  "help" to the same address.  Do not use quotes in your message.
  1533.  
  1534.  
  1535. -------------------------------------------------------------------------------
  1536.  
  1537. From: Bryan Wann <bwann@cwis.net>
  1538. Subject: Re: (usr-tc) compaq Rockwell HCF modems (fwd)
  1539. Date: 03 Apr 1999 00:41:16 -0600 (CST)
  1540.  
  1541. On Fri, 2 Apr 1999, Brian wrote:
  1542.  
  1543. > some people here I thought may want this
  1544. > 
  1545. > ---------- Forwarded message ----------
  1546. > Date: Fri, 2 Apr 1999 20:27:03 -0600 (EST)
  1547. > From: Joe <jkamm@shreve.net>
  1548. > To: tech@shreve.net
  1549. > Subject: compaq Rockwell HCF modems
  1550. > 
  1551. > 
  1552. > the main file area for the Rockwell HCF modem at compaq
  1553. > http://www.compaq.com/athome/support/softpaq/pages/sp8897.html
  1554. > 
  1555. > SUPERSEDES:  SP7953
  1556. > 
  1557. > DESCRIPTION:  Unpacks files that are used with the Presario models
  1558. > mentioned above to upgrade the drivers in the integrated modem.
  1559. > The new driver version is 2.1.2.134.
  1560.  
  1561.  
  1562. FWIW, we just had two customers over the past 2 days try to upgrade their
  1563. Compaq modems running 2.1.2.120.1 with SoftPaq 8897, and the modem died
  1564. and became unresponsive after the upgrade.  Trying to re-upgrade the modem 
  1565. or trying to uninstall/reinstall failed.  As of yet have not heard if
  1566. Compaq has been able to help them, as there really wasn't much more we
  1567. could do.  
  1568.  
  1569.  
  1570. HCFs running 2.1.2.120.1 and 2.1.2.134.* are total hell trying to get to
  1571. work on our PM3s too, usually wind up forcing to V.34 with +MS=V34.
  1572. So far we haven't had any reports of problems with HCF's dialing into our
  1573. POP with a USR TC (DSP 1.2.60), that could be because we don't have that
  1574. many dialing with HCFs there, or customers not reporting problems even
  1575. after we solicited for problem reports for two weeks.
  1576.  
  1577.  
  1578.  
  1579.  
  1580. ---
  1581. Bryan Wann        bwann@cwis.net    
  1582. CWIS Internet Services    http://www.cwis.net 918-967-2858
  1583.  
  1584. Give a man a fish, he eats for a day;
  1585. Teach a man to fish, he eats for a lifetime;
  1586. Enlighten him further, and he opens a chain of seafood restaurants
  1587.  
  1588.  
  1589. -
  1590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1591.  with "unsubscribe usr-tc" in the body of the message.
  1592.  For information on digests or retrieving files and old messages send
  1593.  "help" to the same address.  Do not use quotes in your message.
  1594.  
  1595.  
  1596. -------------------------------------------------------------------------------
  1597.  
  1598. From: Charles Sprickman <spork@inch.com>
  1599. Subject: Re: (usr-tc) Hiper DSP T1/PRI 1.2.43 Service Release
  1600. Date: 03 Apr 1999 12:20:34 -0500 (EST)
  1601.  
  1602. Just a quick positive comment to the folks doing the doc work there:
  1603.  
  1604. Everything (including the release notes) has gotten much, much better than
  1605. the old Netserver days.  I was shocked to see instructions on how to
  1606. download code using a MIB browser and tftp.  Very nice, very complete.
  1607. Throw them boys in the docs department a party, they've been doing great
  1608. work!
  1609.  
  1610. Charles
  1611.  
  1612. -- 
  1613. =-----------------=                                        = 
  1614. | Charles Sprickman                       Internet Channel |
  1615. | INCH System Administration Team         (212)243-5200    |
  1616. | spork@inch.com                          access@inch.com  |
  1617. =                                         =----------------=
  1618.  
  1619. On Fri, 2 Apr 1999, David Bachta wrote:
  1620.  
  1621. > 
  1622. > 
  1623. > 
  1624. >    3Com Carrier Customer Support has posted HiPer DSP T1/PRI Service Release
  1625. >    version 1.2.43 on the Totalservice technical support web site.
  1626. > 
  1627. >    This release will be available for download, free-of-charge, through the end
  1628. >    of May, 1999.
  1629. > 
  1630. >    Version 1.2.43 is an effort to combine many previous Engineering Releases
  1631. >    into a generally available code
  1632. >    release.  It addresses a series of P1 and P2 issues identified with previous
  1633. >    HiPer DSP code release.
  1634. > 
  1635. >    It can be accessed in either of the following locations:
  1636. > 
  1637. >         http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+latest
  1638. >                    ( posted under Total Control Hubs )
  1639. >                   or
  1640. >         http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+software
  1641. >                    ( search by Total Control Hubs : Hiper DSP )
  1642. > 
  1643. > 
  1644. >    For a list of the issues addressed in this Service Release please review the
  1645. >    Service Release Note, 24209600.pdf.  The release note is posted along side
  1646. >    the code on the Totalservice website.   The release note is also available
  1647. >    bundled with the code in the file hd010243.zip.
  1648. > 
  1649. >    Regards,
  1650. > 
  1651. >    David Bachta
  1652. >    Network Engineer
  1653. >    3Com
  1654. > 
  1655. > 
  1656. > 
  1657. > -
  1658. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1659. >  with "unsubscribe usr-tc" in the body of the message.
  1660. >  For information on digests or retrieving files and old messages send
  1661. >  "help" to the same address.  Do not use quotes in your message.
  1662. > 
  1663.  
  1664.  
  1665. -
  1666.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1667.  with "unsubscribe usr-tc" in the body of the message.
  1668.  For information on digests or retrieving files and old messages send
  1669.  "help" to the same address.  Do not use quotes in your message.
  1670.  
  1671.  
  1672. -------------------------------------------------------------------------------
  1673.  
  1674. From: <pferraro@wna-linknet.com>
  1675. Subject: (usr-tc) Hiper code 4.1.59-6 and Quads
  1676. Date: 03 Apr 1999 14:26:17 -0500 (EST)
  1677.  
  1678.  
  1679.     Has anyone noticed any improvements or problems while running the
  1680. HiperArc code 4.1.59-6 in a quad modem configuration?  We currently have
  1681. version 4.1.72-4 on the HiperArc and want to push it up to 4.1.59-6, but
  1682. not sure if it will create more problems than it would fix!
  1683.  
  1684.   Any comments appreciated!
  1685.  
  1686. ==============================================================================
  1687. Phillip Ferraro                WorldNet Access, Inc
  1688. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  1689. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  1690. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  1691. ==============================================================================
  1692.  
  1693.  
  1694.  
  1695. -
  1696.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1697.  with "unsubscribe usr-tc" in the body of the message.
  1698.  For information on digests or retrieving files and old messages send
  1699.  "help" to the same address.  Do not use quotes in your message.
  1700.  
  1701.  
  1702. -------------------------------------------------------------------------------
  1703.  
  1704. From: "Marshall Morgan" <marshall@netdoor.com>
  1705. Subject: (usr-tc) USR/3com OFFICIAL dictionary
  1706. Date: 04 Apr 1999 00:35:24 -0600
  1707.  
  1708. Can someone mail me a CURRENT dictionary.  I would prefer no personal
  1709. modifications or fixes for that matter but the one they actually ship to
  1710. customers today.  I checked for max_channels in a Cistron Radius dict today and
  1711. did not find it so I would like to start from scratch with something more up to
  1712. date.
  1713.  
  1714. Thank you in advance,
  1715.  
  1716. Marshall Morgan
  1717.  
  1718. Internet Doorway, Inc (aka NETDOOR)
  1719. http://www.netdoor.com
  1720.  
  1721.  
  1722.  
  1723. -
  1724.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1725.  with "unsubscribe usr-tc" in the body of the message.
  1726.  For information on digests or retrieving files and old messages send
  1727.  "help" to the same address.  Do not use quotes in your message.
  1728.  
  1729.  
  1730. -------------------------------------------------------------------------------
  1731.  
  1732. From: Jose Roberto Bulcao <bulcao@rio.com.br>
  1733. Subject: (usr-tc) V.90 code for Managed MP/16 V.34+
  1734. Date: 04 Apr 1999 12:28:41 -0200 (GRNLNDDT)
  1735.  
  1736.  
  1737.  
  1738. Does anybody know if 3Com is planning to release V.90 firmware to the
  1739. Managed MP/16 V.34+ modems? If not, is there any firmware newer then
  1740. v.2.0.8?
  1741. I think there was a US only V.90 Beta program to analog MP/16 v.90 code
  1742. but don't know if it was for the Managed boxes or not. Anyway, it seems to
  1743. be withdrawn (at least I can't see this entry anymore in totalservice).
  1744.  
  1745. Tks,
  1746.  
  1747. Jose Roberto Bulcao - RioLink Internet
  1748. Tel    : (021) 577-8899
  1749. e-mail : bulcao@rio.com.br
  1750.  
  1751.  
  1752. -
  1753.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1754.  with "unsubscribe usr-tc" in the body of the message.
  1755.  For information on digests or retrieving files and old messages send
  1756.  "help" to the same address.  Do not use quotes in your message.
  1757.  
  1758.  
  1759. -------------------------------------------------------------------------------
  1760.  
  1761. From: Brian Elfert <brian@citilink.com>
  1762. Subject: (usr-tc) Disconnect problem on first call only
  1763. Date: 04 Apr 1999 10:59:18 -0500 (CDT)
  1764.  
  1765. I'm running quad modems with the V.90 code from last spring.
  1766.  
  1767. I have two or three customers who claim they get disconnected on the first
  1768. call after a few minutes, but when they call back right away, they can
  1769. connect as long as they want.
  1770.  
  1771. I'm running CT1s.  The hunt group chooses the channel that is idle the
  1772. longest to use.  The likelyhood of someone hitting the same chassis on a
  1773. second call is about 25%, and the likelyhood of hitting the same modem is
  1774. basically 0%.
  1775.  
  1776. Any ideas why this might happen?
  1777.  
  1778. Brian
  1779.  
  1780.  
  1781.  
  1782. -
  1783.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1784.  with "unsubscribe usr-tc" in the body of the message.
  1785.  For information on digests or retrieving files and old messages send
  1786.  "help" to the same address.  Do not use quotes in your message.
  1787.  
  1788.  
  1789. -------------------------------------------------------------------------------
  1790.  
  1791. From: "Michael R. Gile" <gilem@wsg.net>
  1792. Subject: Re: (usr-tc) V.90 code for Managed MP/16 V.34+
  1793. Date: 05 Apr 1999 00:45:01 -0400
  1794.  
  1795. My guess is not.
  1796.  
  1797. The US v.90 code was/is very buggy.  So much so, that when a call hung up on one port, it reset the modem causing the other BRI channel to disconnect as well.
  1798.  
  1799. When I spoke last with 3com tech support (last week), they indicated that these boxen will be discontinued soon, and continued support was questionable at best.
  1800.  
  1801. *step up on i-modem^H^H^H^H^H^Hsoapbox*
  1802.  
  1803. After this experience, we are planning on avoiding ALL 3com/USR products in the future.  It has been almost a year since our purchase of these units, and despite the promises of v.90 compatibility, it has still not been delivered in a useful form.  Companies which pull this bait-and-switch should not be tolerated.
  1804.  
  1805. *step down*
  1806.  
  1807. -Mike
  1808.  
  1809. At 12:28 PM 4/4/1999 -0200, you wrote:
  1810.  
  1811.  
  1812. >Does anybody know if 3Com is planning to release V.90 firmware to the
  1813. >Managed MP/16 V.34+ modems? If not, is there any firmware newer then
  1814. >v.2.0.8?
  1815. >I think there was a US only V.90 Beta program to analog MP/16 v.90 code
  1816. >but don't know if it was for the Managed boxes or not. Anyway, it seems to
  1817. >be withdrawn (at least I can't see this entry anymore in totalservice).
  1818. >
  1819. >Tks,
  1820. >
  1821. >--------------------------------------
  1822. >Jose Roberto Bulcao - RioLink Internet
  1823. >Tel    : (021) 577-8899
  1824. >e-mail : bulcao@rio.com.br
  1825. >
  1826. >
  1827. >-
  1828. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1829. > with "unsubscribe usr-tc" in the body of the message.
  1830. > For information on digests or retrieving files and old messages send
  1831. > "help" to the same address.  Do not use quotes in your message.
  1832.  
  1833. ======================================================
  1834. Michael Gile                             gilem@wsg.net
  1835. President                                (518)435-0682
  1836. Web Services Group                 http://www.wsg.net/
  1837.  
  1838. -
  1839.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1840.  with "unsubscribe usr-tc" in the body of the message.
  1841.  For information on digests or retrieving files and old messages send
  1842.  "help" to the same address.  Do not use quotes in your message.
  1843.  
  1844.  
  1845. -------------------------------------------------------------------------------
  1846.  
  1847. From: Bob Purdon <bobp@southcom.com.au>
  1848. Subject: (usr-tc) Surplus HiPerARC?
  1849. Date: 05 Apr 1999 18:11:54 +1000 (EST)
  1850.  
  1851.  
  1852. Hi All,
  1853.  
  1854. Anyone got any surplus HiPerARC cards?
  1855.  
  1856. I'm kicking tyres at the moment to see what's about and at what price.  I
  1857. seem to remember some of you have surplus cards from various trade-up
  1858. deals...
  1859.  
  1860. Regards,
  1861.  
  1862. Bob Purdon,
  1863. Technical Manager (Tas/Vic),
  1864. Southern Internet Services.
  1865.  
  1866.  
  1867. -
  1868.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1869.  with "unsubscribe usr-tc" in the body of the message.
  1870.  For information on digests or retrieving files and old messages send
  1871.  "help" to the same address.  Do not use quotes in your message.
  1872.  
  1873.  
  1874. -------------------------------------------------------------------------------
  1875.  
  1876. From: "Mark Starr" <squid@greenapple.com>
  1877. Subject: (usr-tc)Syslog info
  1878. Date: 05 Apr 1999 09:06:36 -0400
  1879.  
  1880.  
  1881. Hello,
  1882.  I have set up the primary syslog server on all my hiper hubs. When a user
  1883. loga in, it sends over 3 lines, call coming in, id verified, call complete.
  1884. But it does NOT send over the IP assigned to the call. Thus is can not go
  1885. back and track a call from IP to user. I have set the level to verbose even
  1886. and get tons of stuff, but no IP. Any ideas on how to get the IP over to the
  1887. syslog machine?
  1888.  
  1889. Thanks,
  1890. Mark
  1891. Green Apple Inc
  1892.  
  1893.  
  1894. -
  1895.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1896.  with "unsubscribe usr-tc" in the body of the message.
  1897.  For information on digests or retrieving files and old messages send
  1898.  "help" to the same address.  Do not use quotes in your message.
  1899.  
  1900.  
  1901. -------------------------------------------------------------------------------
  1902.  
  1903. From: Steve Rivera <sales@wrca.net>
  1904. Subject: Re: (usr-tc) Surplus HiPerARC?
  1905. Date: 05 Apr 1999 09:57:33 -0400
  1906.  
  1907. Currently I am out of stock on these cards but I do come across them. I
  1908. will be in touch when I come across more:)
  1909.  
  1910. Do have total control units (No hyper chassis), mp, netservers, total
  1911. switches.
  1912.  
  1913.  
  1914. At 06:11 PM 4/5/99 +1000, you wrote:
  1915. >
  1916. >Hi All,
  1917. >
  1918. >Anyone got any surplus HiPerARC cards?
  1919. >
  1920. >I'm kicking tyres at the moment to see what's about and at what price.  I
  1921. >seem to remember some of you have surplus cards from various trade-up
  1922. >deals...
  1923. >
  1924. >Regards,
  1925. >
  1926. >Bob Purdon,
  1927. >Technical Manager (Tas/Vic),
  1928. >Southern Internet Services.
  1929. >
  1930. >
  1931. >-
  1932. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1933. > with "unsubscribe usr-tc" in the body of the message.
  1934. > For information on digests or retrieving files and old messages send
  1935. > "help" to the same address.  Do not use quotes in your message.
  1936. >
  1937.  
  1938. Steve Rivera  sales@wrca.net 
  1939. Check out product information and inventory.
  1940. http://www.wrca.net(All New 3/22/99)
  1941.     732-833-2111
  1942. '''''''''''''''''''''''''''''''''''''''''''''''
  1943. De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  1944. '''''''''''''''''''''''''''''''''''''''''''''''
  1945.  
  1946.  
  1947.  
  1948.      
  1949.   
  1950.  
  1951.  
  1952.  
  1953.  
  1954. -
  1955.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1956.  with "unsubscribe usr-tc" in the body of the message.
  1957.  For information on digests or retrieving files and old messages send
  1958.  "help" to the same address.  Do not use quotes in your message.
  1959.  
  1960.  
  1961. -------------------------------------------------------------------------------
  1962.  
  1963. From: "John Verreault" <verreaul@aei.ca>
  1964. Subject: RE: (usr-tc) Surplus HiPerARC?
  1965. Date: 05 Apr 1999 11:10:37 -0400
  1966.  
  1967. How much are you asking for the TC units (and which chassis' are they)???
  1968. Reply direct
  1969. Thanks
  1970. John@aei.ca
  1971.  
  1972. > -----Original Message-----
  1973. > From: owner-usr-tc@lists.xmission.com
  1974. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera
  1975. > Sent: Monday, April 05, 1999 9:58 AM
  1976. > To: usr-tc@lists.xmission.com
  1977. > Subject: Re: (usr-tc) Surplus HiPerARC?
  1978. >
  1979. >
  1980. > Currently I am out of stock on these cards but I do come across them. I
  1981. > will be in touch when I come across more:)
  1982. >
  1983. > Do have total control units (No hyper chassis), mp, netservers, total
  1984. > switches.
  1985. >
  1986. >
  1987. > At 06:11 PM 4/5/99 +1000, you wrote:
  1988. > >
  1989. > >Hi All,
  1990. > >
  1991. > >Anyone got any surplus HiPerARC cards?
  1992. > >
  1993. > >I'm kicking tyres at the moment to see what's about and at what price.  I
  1994. > >seem to remember some of you have surplus cards from various trade-up
  1995. > >deals...
  1996. > >
  1997. > >Regards,
  1998. > >
  1999. > >Bob Purdon,
  2000. > >Technical Manager (Tas/Vic),
  2001. > >Southern Internet Services.
  2002. > >
  2003. > >
  2004. > >-
  2005. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2006. > > with "unsubscribe usr-tc" in the body of the message.
  2007. > > For information on digests or retrieving files and old messages send
  2008. > > "help" to the same address.  Do not use quotes in your message.
  2009. > >
  2010. >
  2011. > Steve Rivera  sales@wrca.net
  2012. > Check out product information and inventory.
  2013. > http://www.wrca.net(All New 3/22/99)
  2014. >     732-833-2111
  2015. > '''''''''''''''''''''''''''''''''''''''''''''''
  2016. > De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  2017. > '''''''''''''''''''''''''''''''''''''''''''''''
  2018. >
  2019. >
  2020. >
  2021. >
  2022. >
  2023. >
  2024. >
  2025. >
  2026. >
  2027. > -
  2028. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2029. >  with "unsubscribe usr-tc" in the body of the message.
  2030. >  For information on digests or retrieving files and old messages send
  2031. >  "help" to the same address.  Do not use quotes in your message.
  2032. >
  2033.  
  2034.  
  2035. -
  2036.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2037.  with "unsubscribe usr-tc" in the body of the message.
  2038.  For information on digests or retrieving files and old messages send
  2039.  "help" to the same address.  Do not use quotes in your message.
  2040.  
  2041.  
  2042. -------------------------------------------------------------------------------
  2043.  
  2044. From: "C Thompson" <cthompson@wingnet.net>
  2045. Subject: (usr-tc) FS:USR TC / Hiper ARC combo
  2046. Date: 05 Apr 1999 12:09:27 -0500
  2047.  
  2048. We are looking at the possiblity of selling one of 
  2049. our USR/3com Total 
  2050. Control racks.  Specs are as follows:
  2051.  
  2052. Rackmount chassis
  2053. Integrated fan tray
  2054. 1 70 amp PS
  2055. 1 NMC with memory upgrade
  2056. 1 Dual PRI/T1 card
  2057. 12 digital/analog quad modem cards
  2058. 1 Hiper ARC card (relatively new)
  2059.  
  2060. Asking price = $7500
  2061.  
  2062. Contact me if interested, or if you wish to register 
  2063. a bid.
  2064.  
  2065.  
  2066.  
  2067. Craig Thompson
  2068. WingNET Internet Services,
  2069. P.O. Box 3000 // Cleveland, TN 37320-3000
  2070. 423-559-LINK (v)  423-559-5444 (f)
  2071. http://www.wingnet.net
  2072.  
  2073. Suicide is the most sincere form of self-criticism.
  2074.  
  2075.  
  2076. -
  2077.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2078.  with "unsubscribe usr-tc" in the body of the message.
  2079.  For information on digests or retrieving files and old messages send
  2080.  "help" to the same address.  Do not use quotes in your message.
  2081.  
  2082.  
  2083. -------------------------------------------------------------------------------
  2084.  
  2085. From: Stefanita Vilcu <vsv@dnt.ro>
  2086. Subject: (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation
  2087. Date: 05 Apr 1999 20:07:52 +0300
  2088.  
  2089. Hi folks,
  2090.  
  2091. I wonder if someone of you can tell me how can I setup an TC chassis for
  2092. leased line operation.
  2093. I want that the phone line to be plugged in an Analog Quad Modem and the
  2094. modem "to be connected" in a speciffic interface from the HiperArc. The
  2095. ARC will be configured to make ppp over that line, with no
  2096. authentication, and give the same IP address every time. Of course that
  2097. modem will not be available for the dual E1 card.
  2098.  
  2099.  
  2100. Thank you,
  2101.  
  2102. Stefanita Vilcu, Network Administrator - Dynamic Network Technologies,
  2103. Bucharest, Romania
  2104. vsv@dnt.ro
  2105.  
  2106.  
  2107. -
  2108.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2109.  with "unsubscribe usr-tc" in the body of the message.
  2110.  For information on digests or retrieving files and old messages send
  2111.  "help" to the same address.  Do not use quotes in your message.
  2112.  
  2113.  
  2114. -------------------------------------------------------------------------------
  2115.  
  2116. From: Pete Ashdown <pashdown@xmission.com>
  2117. Subject: Re: (usr-tc) Surplus HiPerARC?
  2118. Date: 05 Apr 1999 11:11:09 -0600 (MDT)
  2119.  
  2120. Bob Purdon said once upon a time:
  2121.  
  2122. >Anyone got any surplus HiPerARC cards?
  2123. >
  2124. >I'm kicking tyres at the moment to see what's about and at what price.  I
  2125. >seem to remember some of you have surplus cards from various trade-up
  2126. >deals...
  2127.  
  2128. I've got one, maybe two.  No idea on what I'd ask for them.
  2129.  
  2130. -
  2131.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2132.  with "unsubscribe usr-tc" in the body of the message.
  2133.  For information on digests or retrieving files and old messages send
  2134.  "help" to the same address.  Do not use quotes in your message.
  2135.  
  2136.  
  2137. -------------------------------------------------------------------------------
  2138.  
  2139. From: Carl Jagerski <carll@forcomm.net>
  2140. Subject: Re: (usr-tc) Disconnect problem on first call only
  2141. Date: 05 Apr 1999 13:15:06 -0400
  2142.  
  2143. See if they are Rockwell HCF modems.  If they are, that would explain it 
  2144. all.  If your customers are trying to load IE or Mail during the initial load,
  2145. it puts too much usage on the processor and slows the modem down
  2146. .  
  2147. Why are they making modems cheaper when most people use them?  It's the
  2148. weakest link in the chain now.
  2149.  
  2150.  
  2151. At 10:59 AM 4/4/99 -0500, you wrote:
  2152. >I'm running quad modems with the V.90 code from last spring.
  2153. >
  2154. >I have two or three customers who claim they get disconnected on the first
  2155. >call after a few minutes, but when they call back right away, they can
  2156. >connect as long as they want.
  2157. >
  2158. >I'm running CT1s.  The hunt group chooses the channel that is idle the
  2159. >longest to use.  The likelyhood of someone hitting the same chassis on a
  2160. >second call is about 25%, and the likelyhood of hitting the same modem is
  2161. >basically 0%.
  2162. >
  2163. >Any ideas why this might happen?
  2164. >
  2165. >Brian
  2166. >
  2167. >
  2168. >
  2169. >-
  2170. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2171. > with "unsubscribe usr-tc" in the body of the message.
  2172. > For information on digests or retrieving files and old messages send
  2173. > "help" to the same address.  Do not use quotes in your message.
  2174. >
  2175. Carl Jagerski
  2176. Network Administrator, Forward Communications
  2177. carll@forcomm.net
  2178. 412-378-4490   Fax: 412-375-0156
  2179.  
  2180.  
  2181. -
  2182.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2183.  with "unsubscribe usr-tc" in the body of the message.
  2184.  For information on digests or retrieving files and old messages send
  2185.  "help" to the same address.  Do not use quotes in your message.
  2186.  
  2187.  
  2188. -------------------------------------------------------------------------------
  2189.  
  2190. From: "Chris" <hender@rconnect.com>
  2191. Subject: (usr-tc) PRI on AMI encoding
  2192. Date: 02 Apr 1999 21:11:22 -0600
  2193.  
  2194. I am setting up a chassis with an ARC and 2 HiperDSP's. Latest versions =
  2195. of the code on both. Setting this up for PRI, phone company has a DMS100 =
  2196. and the are running D4 and AMI on the line at 56k. Has anyone had any =
  2197. luck setting a PRI up on D4 and AMI or is this just not gonna work? I've =
  2198. spent hours on the phone with the telco and have talked to 3com and have =
  2199. had mixed answers from them as to whether it will work, they start off =
  2200. telling me it will work and then whittle it down to it won't work. Seems =
  2201. like every question I ask they say, "Yeah it'll do that just fine" and =
  2202. then I call back when I'm having trouble and they try some things and =
  2203. then after a while decide that its not gonna work. Any one out there =
  2204. have any input on whether or not this will work. The telco is leasing =
  2205. the fiber from another telco so it is going to be a pain to get it =
  2206. switched over to ESF and B8ZS.
  2207.  
  2208. -
  2209.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2210.  with "unsubscribe usr-tc" in the body of the message.
  2211.  For information on digests or retrieving files and old messages send
  2212.  "help" to the same address.  Do not use quotes in your message.
  2213.  
  2214.  
  2215. -------------------------------------------------------------------------------
  2216.  
  2217. From: matthews <matthews@brunnet.net>
  2218. Subject: RE: (usr-tc) PRI on AMI encoding
  2219. Date: 05 Apr 1999 14:29:25 -0300
  2220.  
  2221.  
  2222. I was told by a tech at USR that for a PRI you MUST use B8ZS and ESF. 
  2223.  That's the only thing I use so I don't know from personal experience 
  2224. whether that's correct or not.
  2225.  
  2226. On Friday, April 02, 1999 11:11 PM, Chris [SMTP:hender@rconnect.com] wrote:
  2227. > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest versions 
  2228. of the code on both. Setting this up for PRI, phone company has a DMS100 
  2229. and the are running D4 and AMI on the line at 56k. Has anyone had any luck 
  2230. setting a PRI up on D4 and AMI or is this just not gonna work? I've spent 
  2231. hours on the phone with the telco and have talked to 3com and have had 
  2232. mixed answers from them as to whether it will work, they start off telling 
  2233. me it will work and then whittle it down to it won't work. Seems like every 
  2234. question I ask they say, "Yeah it'll do that just fine" and then I call 
  2235. back when I'm having trouble and they try some things and then after a 
  2236. while decide that its not gonna work. Any one out there have any input on 
  2237. whether or not this will work. The telco is leasing the fiber from another 
  2238. telco so it is going to be a pain to get it switched over to ESF and B8ZS.
  2239. >
  2240. > -
  2241. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2242. >  with "unsubscribe usr-tc" in the body of the message.
  2243. >  For information on digests or retrieving files and old messages send
  2244. >  "help" to the same address.  Do not use quotes in your message.
  2245.  
  2246.  
  2247.  
  2248.  
  2249. -
  2250.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2251.  with "unsubscribe usr-tc" in the body of the message.
  2252.  For information on digests or retrieving files and old messages send
  2253.  "help" to the same address.  Do not use quotes in your message.
  2254.  
  2255.  
  2256. -------------------------------------------------------------------------------
  2257.  
  2258. From: Brian Elfert <brian@citilink.com>
  2259. Subject: (usr-tc) RIP updates on assigned pool
  2260. Date: 05 Apr 1999 13:02:21 -0500 (CDT)
  2261.  
  2262. For some reason, some of my Netservers (All running 3.7.24) won't
  2263. broadcast any IPs in their assigned pool via RIP (v1).  They will
  2264. broadcast static IPs not in the assigned pool.
  2265.  
  2266. Any ideas?  On the Cisco, I can see updates coming in, but none from any
  2267. of the IP pools on some of the Netservers.
  2268.  
  2269. Brian
  2270.  
  2271.  
  2272. -
  2273.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2274.  with "unsubscribe usr-tc" in the body of the message.
  2275.  For information on digests or retrieving files and old messages send
  2276.  "help" to the same address.  Do not use quotes in your message.
  2277.  
  2278.  
  2279. -------------------------------------------------------------------------------
  2280.  
  2281. From: K Mitchell <mitch@keyconn.net>
  2282. Subject: (usr-tc) HiPer gone wacko!
  2283. Date: 05 Apr 1999 16:37:10 -0400
  2284.  
  2285. HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2286. connecting with varied error messages, messages coming through my console
  2287. ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2288. Here's an example of console messages coming through during the reboot:
  2289. HiPer enabling networks on rfaces....
  2290.  
  2291. Configuring Networrvices.....
  2292.  
  2293. Starting the CLI......
  2294. Please Waor Prompt...
  2295.  
  2296. Running;
  2297. ARC 4.1.72
  2298. NMC 5.5.5
  2299. DSP 1.2.5
  2300. Has my ARC gone bad, or is there something else I can try that may correct
  2301. this?
  2302.  
  2303. Thanks,
  2304. A frustrated Kirk
  2305.  
  2306.  
  2307.  
  2308. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  2309. Keystone Connect                http://www.keyconn.net
  2310. Altoona, PA   814-941-5000         We Unlock the World
  2311.  
  2312.  
  2313. -
  2314.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2315.  with "unsubscribe usr-tc" in the body of the message.
  2316.  For information on digests or retrieving files and old messages send
  2317.  "help" to the same address.  Do not use quotes in your message.
  2318.  
  2319.  
  2320. -------------------------------------------------------------------------------
  2321.  
  2322. From: Ricky Beam <jfbeam@beaker.interpath.net>
  2323. Subject: Re: (usr-tc) HiPer gone wacko!
  2324. Date: 05 Apr 1999 17:35:13 -0400 (EDT)
  2325.  
  2326. On Mon, 5 Apr 1999, K Mitchell wrote:
  2327. >HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2328. >connecting with varied error messages, messages coming through my console
  2329. >ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2330. >Here's an example of console messages coming through during the reboot:
  2331. >HiPer enabling networks on rfaces....
  2332. >
  2333. >Configuring Networrvices.....
  2334. >
  2335. >Starting the CLI......
  2336. >Please Waor Prompt...
  2337. ...
  2338.  
  2339. Umm, reseat the card (front and back) and if that does nothing, try reflashing
  2340. the card from the console port with the AT{ZF}??? command to reformat the
  2341. flash.
  2342.  
  2343. The test ARC did that once, but that was because the NIC wasn't screwed down.
  2344.  
  2345. --Ricky
  2346.  
  2347.  
  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: Paul Farber <farber@admin.f-tech.net>
  2359. Subject: Re: (usr-tc) HiPer gone wacko!
  2360. Date: 05 Apr 1999 17:48:31 -0400 (EDT)
  2361.  
  2362. Try restoring the firmware from the factory default? I think it's sw 5 to
  2363. on, then reboot.  Maybe replace the SIMM module?  Or send it back for
  2364. warranty repair?
  2365.  
  2366. Paul D. Farber II
  2367. Farber Technology
  2368. Ph. 570-628-5303
  2369. Fax 570-628-5545
  2370. farber@admin.f-tech.net
  2371.  
  2372. On Mon, 5 Apr 1999, K Mitchell wrote:
  2373.  
  2374. > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2375. > connecting with varied error messages, messages coming through my console
  2376. > ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2377. > Here's an example of console messages coming through during the reboot:
  2378. > HiPer enabling networks on rfaces....
  2379. > 
  2380. > Configuring Networrvices.....
  2381. > 
  2382. > Starting the CLI......
  2383. > Please Waor Prompt...
  2384. > 
  2385. > Running;
  2386. > ARC 4.1.72
  2387. > NMC 5.5.5
  2388. > DSP 1.2.5
  2389. > Has my ARC gone bad, or is there something else I can try that may correct
  2390. > this?
  2391. > 
  2392. > Thanks,
  2393. > A frustrated Kirk
  2394. > 
  2395. > 
  2396. > 
  2397. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  2398. > Keystone Connect                http://www.keyconn.net
  2399. > Altoona, PA   814-941-5000         We Unlock the World
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2412.  with "unsubscribe usr-tc" in the body of the message.
  2413.  For information on digests or retrieving files and old messages send
  2414.  "help" to the same address.  Do not use quotes in your message.
  2415.  
  2416.  
  2417. -------------------------------------------------------------------------------
  2418.  
  2419. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  2420. Subject: Re: (usr-tc) HiPer gone wacko!
  2421. Date: 05 Apr 1999 17:01:02 -0500
  2422.  
  2423.  
  2424.  
  2425.      You will probably want to upgrade to latest code.  Current code is now
  2426. 4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90
  2427. connectivity.   This combination seems to be very stable.  As for this exact
  2428. issue that you are experiencing, if the reboot does not fix it, it is usually
  2429. time to re-flash the code.  Since you are in need of an upgrade this is a good
  2430. time to do this.
  2431.      If you don't have this code, please send me a email, I will forward it to
  2432. you.
  2433.  
  2434.      Todd      ;-}
  2435.  
  2436.  
  2437.  
  2438.  
  2439.  
  2440.  
  2441. K Mitchell <mitch@keyconn.net> on 04/05/99 03:37:10 PM
  2442.  
  2443. Please respond to usr-tc@lists.xmission.com
  2444.  
  2445. cc:    (Todd Keister/MW/US/3Com)
  2446.  
  2447.  
  2448.  
  2449.  
  2450. HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2451. connecting with varied error messages, messages coming through my console
  2452. ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2453. Here's an example of console messages coming through during the reboot:
  2454. HiPer enabling networks on rfaces....
  2455.  
  2456. Configuring Networrvices.....
  2457.  
  2458. Starting the CLI......
  2459. Please Waor Prompt...
  2460.  
  2461. Running;
  2462. ARC 4.1.72
  2463. NMC 5.5.5
  2464. DSP 1.2.5
  2465. Has my ARC gone bad, or is there something else I can try that may correct
  2466. this?
  2467.  
  2468. Thanks,
  2469. A frustrated Kirk
  2470.  
  2471.  
  2472.  
  2473. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  2474. Keystone Connect                http://www.keyconn.net
  2475. Altoona, PA   814-941-5000         We Unlock the World
  2476.  
  2477.  
  2478. -
  2479.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2480.  with "unsubscribe usr-tc" in the body of the message.
  2481.  For information on digests or retrieving files and old messages send
  2482.  "help" to the same address.  Do not use quotes in your message.
  2483.  
  2484.  
  2485.  
  2486.  
  2487.  
  2488.  
  2489.  
  2490.  
  2491. -
  2492.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2493.  with "unsubscribe usr-tc" in the body of the message.
  2494.  For information on digests or retrieving files and old messages send
  2495.  "help" to the same address.  Do not use quotes in your message.
  2496.  
  2497.  
  2498. -------------------------------------------------------------------------------
  2499.  
  2500. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  2501. Subject: Re: (usr-tc) HiPer gone wacko!
  2502. Date: 05 Apr 1999 17:10:52 -0500
  2503.  
  2504.  
  2505.  
  2506.      Resetting a card by using Dip switch number 5 is usually a good idea, but
  2507. unfortunately the Hyper ARC does not have a Dip # 5.
  2508.  
  2509.      Re-flashing with current code via either the Total Control Manager, or
  2510. Z-modem transfer from the Console are the preferred methods.  TFTP will also
  2511. work, bu then you must expand the file (rename the file to netserve.dmf and then
  2512. reboot).
  2513.  
  2514.      If all else fails, you can always call us in tech support (800) 231-8770.
  2515.  
  2516.                Todd ;-}
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Paul Farber <farber@admin.f-tech.net> on 04/05/99 04:48:31 PM
  2523.  
  2524. Please respond to usr-tc@lists.xmission.com
  2525.  
  2526. cc:    (Todd Keister/MW/US/3Com)
  2527.  
  2528.  
  2529.  
  2530.  
  2531. Try restoring the firmware from the factory default? I think it's sw 5 to
  2532. on, then reboot.  Maybe replace the SIMM module?  Or send it back for
  2533. warranty repair?
  2534.  
  2535. Paul D. Farber II
  2536. Farber Technology
  2537. Ph. 570-628-5303
  2538. Fax 570-628-5545
  2539. farber@admin.f-tech.net
  2540.  
  2541. On Mon, 5 Apr 1999, K Mitchell wrote:
  2542.  
  2543. > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2544. > connecting with varied error messages, messages coming through my console
  2545. > ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2546. > Here's an example of console messages coming through during the reboot:
  2547. > HiPer enabling networks on rfaces....
  2548. >
  2549. > Configuring Networrvices.....
  2550. >
  2551. > Starting the CLI......
  2552. > Please Waor Prompt...
  2553. >
  2554. > Running;
  2555. > ARC 4.1.72
  2556. > NMC 5.5.5
  2557. > DSP 1.2.5
  2558. > Has my ARC gone bad, or is there something else I can try that may correct
  2559. > this?
  2560. >
  2561. > Thanks,
  2562. > A frustrated Kirk
  2563. >
  2564. >
  2565. >
  2566. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  2567. > Keystone Connect                http://www.keyconn.net
  2568. > Altoona, PA   814-941-5000         We Unlock the World
  2569. >
  2570. >
  2571. > -
  2572. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2573. >  with "unsubscribe usr-tc" in the body of the message.
  2574. >  For information on digests or retrieving files and old messages send
  2575. >  "help" to the same address.  Do not use quotes in your message.
  2576. >
  2577.  
  2578.  
  2579. -
  2580.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2581.  with "unsubscribe usr-tc" in the body of the message.
  2582.  For information on digests or retrieving files and old messages send
  2583.  "help" to the same address.  Do not use quotes in your message.
  2584.  
  2585.  
  2586.  
  2587.  
  2588.  
  2589.  
  2590.  
  2591.  
  2592. -
  2593.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2594.  with "unsubscribe usr-tc" in the body of the message.
  2595.  For information on digests or retrieving files and old messages send
  2596.  "help" to the same address.  Do not use quotes in your message.
  2597.  
  2598.  
  2599. -------------------------------------------------------------------------------
  2600.  
  2601. From: Mike Andrews <mandrews@termfrost.org>
  2602. Subject: Re: (usr-tc) PRI on AMI encoding
  2603. Date: 05 Apr 1999 18:21:14 -0400 (EDT)
  2604.  
  2605. It's just not gonna work.  PRI requires ESF/B8ZS, period.  I'm kinda
  2606. surprised the telco didn't know that...
  2607.  
  2608.  
  2609. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  2610. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  2611. Microsoft operating system is like a dog without a brick tied to its head."
  2612.  
  2613. On Fri, 2 Apr 1999, Chris wrote:
  2614.  
  2615. > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest
  2616. > versions of the code on both. Setting this up for PRI, phone company
  2617. > has a DMS100 and the are running D4 and AMI on the line at 56k. Has
  2618. > anyone had any luck setting a PRI up on D4 and AMI or is this just not
  2619. > gonna work? I've spent hours on the phone with the telco and have
  2620. > talked to 3com and have had mixed answers from them as to whether it
  2621. > will work, they start off telling me it will work and then whittle it
  2622. > down to it won't work. Seems like every question I ask they say, "Yeah
  2623. > it'll do that just fine" and then I call back when I'm having trouble
  2624. > and they try some things and then after a while decide that its not
  2625. > gonna work. Any one out there have any input on whether or not this
  2626. > will work. The telco is leasing the fiber from another telco so it is
  2627. > going to be a pain to get it switched over to ESF and B8ZS.
  2628.  
  2629.  
  2630. -
  2631.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2632.  with "unsubscribe usr-tc" in the body of the message.
  2633.  For information on digests or retrieving files and old messages send
  2634.  "help" to the same address.  Do not use quotes in your message.
  2635.  
  2636.  
  2637. -------------------------------------------------------------------------------
  2638.  
  2639. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  2640. Subject: RE: (usr-tc) HiPer gone wacko!
  2641. Date: 05 Apr 1999 17:28:08 -0500
  2642.  
  2643.  
  2644.  
  2645. |-----Original Message-----
  2646. |From: owner-usr-tc@lists.xmission.com
  2647. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister
  2648. |Sent: Monday, April 05, 1999 5:11 PM
  2649. |To: usr-tc@lists.xmission.com
  2650. |Subject: Re: (usr-tc) HiPer gone wacko!
  2651. |
  2652. |
  2653. |
  2654. |
  2655. |     Resetting a card by using Dip switch number 5 is usually a good idea, but
  2656. |unfortunately the Hyper ARC does not have a Dip # 5.
  2657. It has one. It just doesnt have anything to do with clearing the flash. You do
  2658. get a boot menu on console before the code image loads. An option exists there to
  2659. clear the configs.
  2660.  
  2661.  
  2662. If your going to do that, and you are not running the latest code. You might as
  2663. well do the zmodem transfer and
  2664. format the flash in the process.
  2665.  
  2666. From the console. After the Boot ROM version prompt there is a delay. During that
  2667. delay you can type
  2668. "AT{ZF}"  this is case sensative. Then begin the zmodem transfer of the code.
  2669.  
  2670. -M
  2671.  
  2672.  
  2673.  
  2674. -
  2675.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2676.  with "unsubscribe usr-tc" in the body of the message.
  2677.  For information on digests or retrieving files and old messages send
  2678.  "help" to the same address.  Do not use quotes in your message.
  2679.  
  2680.  
  2681. -------------------------------------------------------------------------------
  2682.  
  2683. From: Paul Farber <farber@admin.f-tech.net>
  2684. Subject: Re: (usr-tc) HiPer gone wacko!
  2685. Date: 05 Apr 1999 18:36:07 -0400 (EDT)
  2686.  
  2687. That was a cure for the NMC card I had go bad once.... since it has been
  2688. about 8 months since any hardware went bad, I may be FUBAR.
  2689.  
  2690. I never really liked that console flash idea.  Every new NMC seems to go
  2691. out empty, and if you run a Linix shop.. finding a windows machine to
  2692. flash a card is a minor pain in the rear. 
  2693.  
  2694. If you'all (3Com) released the code I'm sure an enterprising individual
  2695. would port it for you.  
  2696.  
  2697. Paul D. Farber II
  2698. Farber Technology
  2699. Ph. 570-628-5303
  2700. Fax 570-628-5545
  2701. farber@admin.f-tech.net
  2702.  
  2703. On Mon, 5 Apr 1999, Todd Keister wrote:
  2704.  
  2705. > 
  2706. > 
  2707. >      Resetting a card by using Dip switch number 5 is usually a good idea, but
  2708. > unfortunately the Hyper ARC does not have a Dip # 5.
  2709. > 
  2710. >      Re-flashing with current code via either the Total Control Manager, or
  2711. > Z-modem transfer from the Console are the preferred methods.  TFTP will also
  2712. > work, bu then you must expand the file (rename the file to netserve.dmf and then
  2713. > reboot).
  2714. > 
  2715. >      If all else fails, you can always call us in tech support (800) 231-8770.
  2716. > 
  2717. >                Todd ;-}
  2718. > 
  2719. > 
  2720. > 
  2721. > 
  2722. > 
  2723. > Paul Farber <farber@admin.f-tech.net> on 04/05/99 04:48:31 PM
  2724. > 
  2725. > Please respond to usr-tc@lists.xmission.com
  2726. > 
  2727. > To:   usr-tc@lists.xmission.com
  2728. > cc:    (Todd Keister/MW/US/3Com)
  2729. > Subject:  Re: (usr-tc) HiPer gone wacko!
  2730. > 
  2731. > 
  2732. > 
  2733. > 
  2734. > Try restoring the firmware from the factory default? I think it's sw 5 to
  2735. > on, then reboot.  Maybe replace the SIMM module?  Or send it back for
  2736. > warranty repair?
  2737. > 
  2738. > Paul D. Farber II
  2739. > Farber Technology
  2740. > Ph. 570-628-5303
  2741. > Fax 570-628-5545
  2742. > farber@admin.f-tech.net
  2743. > 
  2744. > On Mon, 5 Apr 1999, K Mitchell wrote:
  2745. > 
  2746. > > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2747. > > connecting with varied error messages, messages coming through my console
  2748. > > ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2749. > > Here's an example of console messages coming through during the reboot:
  2750. > > HiPer enabling networks on rfaces....
  2751. > >
  2752. > > Configuring Networrvices.....
  2753. > >
  2754. > > Starting the CLI......
  2755. > > Please Waor Prompt...
  2756. > >
  2757. > > Running;
  2758. > > ARC 4.1.72
  2759. > > NMC 5.5.5
  2760. > > DSP 1.2.5
  2761. > > Has my ARC gone bad, or is there something else I can try that may correct
  2762. > > this?
  2763. > >
  2764. > > Thanks,
  2765. > > A frustrated Kirk
  2766. > >
  2767. > >
  2768. > >
  2769. > > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  2770. > > Keystone Connect                http://www.keyconn.net
  2771. > > Altoona, PA   814-941-5000         We Unlock the World
  2772. > >
  2773. > >
  2774. > > -
  2775. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2776. > >  with "unsubscribe usr-tc" in the body of the message.
  2777. > >  For information on digests or retrieving files and old messages send
  2778. > >  "help" to the same address.  Do not use quotes in your message.
  2779. > >
  2780. > 
  2781. > 
  2782. > -
  2783. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2784. >  with "unsubscribe usr-tc" in the body of the message.
  2785. >  For information on digests or retrieving files and old messages send
  2786. >  "help" to the same address.  Do not use quotes in your message.
  2787. > 
  2788. > 
  2789. > 
  2790. > 
  2791. > 
  2792. > 
  2793. > 
  2794. > 
  2795. > -
  2796. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2797. >  with "unsubscribe usr-tc" in the body of the message.
  2798. >  For information on digests or retrieving files and old messages send
  2799. >  "help" to the same address.  Do not use quotes in your message.
  2800. > 
  2801.  
  2802.  
  2803. -
  2804.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2805.  with "unsubscribe usr-tc" in the body of the message.
  2806.  For information on digests or retrieving files and old messages send
  2807.  "help" to the same address.  Do not use quotes in your message.
  2808.  
  2809.  
  2810. -------------------------------------------------------------------------------
  2811.  
  2812. From: Paul Farber <farber@admin.f-tech.net>
  2813. Subject: Re: (usr-tc) HiPer gone wacko!
  2814. Date: 05 Apr 1999 18:36:07 -0400 (EDT)
  2815.  
  2816. That was a cure for the NMC card I had go bad once.... since it has been
  2817. about 8 months since any hardware went bad, I may be FUBAR.
  2818.  
  2819. I never really liked that console flash idea.  Every new NMC seems to go
  2820. out empty, and if you run a Linix shop.. finding a windows machine to
  2821. flash a card is a minor pain in the rear. 
  2822.  
  2823. If you'all (3Com) released the code I'm sure an enterprising individual
  2824. would port it for you.  
  2825.  
  2826. Paul D. Farber II
  2827. Farber Technology
  2828. Ph. 570-628-5303
  2829. Fax 570-628-5545
  2830. farber@admin.f-tech.net
  2831.  
  2832. On Mon, 5 Apr 1999, Todd Keister wrote:
  2833.  
  2834. > 
  2835. > 
  2836. >      Resetting a card by using Dip switch number 5 is usually a good idea, but
  2837. > unfortunately the Hyper ARC does not have a Dip # 5.
  2838. > 
  2839. >      Re-flashing with current code via either the Total Control Manager, or
  2840. > Z-modem transfer from the Console are the preferred methods.  TFTP will also
  2841. > work, bu then you must expand the file (rename the file to netserve.dmf and then
  2842. > reboot).
  2843. > 
  2844. >      If all else fails, you can always call us in tech support (800) 231-8770.
  2845. > 
  2846. >                Todd ;-}
  2847. > 
  2848. > 
  2849. > 
  2850. > 
  2851. > 
  2852. > Paul Farber <farber@admin.f-tech.net> on 04/05/99 04:48:31 PM
  2853. > 
  2854. > Please respond to usr-tc@lists.xmission.com
  2855. > 
  2856. > To:   usr-tc@lists.xmission.com
  2857. > cc:    (Todd Keister/MW/US/3Com)
  2858. > Subject:  Re: (usr-tc) HiPer gone wacko!
  2859. > 
  2860. > 
  2861. > 
  2862. > 
  2863. > Try restoring the firmware from the factory default? I think it's sw 5 to
  2864. > on, then reboot.  Maybe replace the SIMM module?  Or send it back for
  2865. > warranty repair?
  2866. > 
  2867. > Paul D. Farber II
  2868. > Farber Technology
  2869. > Ph. 570-628-5303
  2870. > Fax 570-628-5545
  2871. > farber@admin.f-tech.net
  2872. > 
  2873. > On Mon, 5 Apr 1999, K Mitchell wrote:
  2874. > 
  2875. > > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  2876. > > connecting with varied error messages, messages coming through my console
  2877. > > ARC connection are misspelled or missing letters. Reboot hasn't helped.
  2878. > > Here's an example of console messages coming through during the reboot:
  2879. > > HiPer enabling networks on rfaces....
  2880. > >
  2881. > > Configuring Networrvices.....
  2882. > >
  2883. > > Starting the CLI......
  2884. > > Please Waor Prompt...
  2885. > >
  2886. > > Running;
  2887. > > ARC 4.1.72
  2888. > > NMC 5.5.5
  2889. > > DSP 1.2.5
  2890. > > Has my ARC gone bad, or is there something else I can try that may correct
  2891. > > this?
  2892. > >
  2893. > > Thanks,
  2894. > > A frustrated Kirk
  2895. > >
  2896. > >
  2897. > >
  2898. > > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  2899. > > Keystone Connect                http://www.keyconn.net
  2900. > > Altoona, PA   814-941-5000         We Unlock the World
  2901. > >
  2902. > >
  2903. > > -
  2904. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2905. > >  with "unsubscribe usr-tc" in the body of the message.
  2906. > >  For information on digests or retrieving files and old messages send
  2907. > >  "help" to the same address.  Do not use quotes in your message.
  2908. > >
  2909. > 
  2910. > 
  2911. > -
  2912. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2913. >  with "unsubscribe usr-tc" in the body of the message.
  2914. >  For information on digests or retrieving files and old messages send
  2915. >  "help" to the same address.  Do not use quotes in your message.
  2916. > 
  2917. > 
  2918. > 
  2919. > 
  2920. > 
  2921. > 
  2922. > 
  2923. > 
  2924. > -
  2925. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2926. >  with "unsubscribe usr-tc" in the body of the message.
  2927. >  For information on digests or retrieving files and old messages send
  2928. >  "help" to the same address.  Do not use quotes in your message.
  2929. > 
  2930.  
  2931.  
  2932. -
  2933.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2934.  with "unsubscribe usr-tc" in the body of the message.
  2935.  For information on digests or retrieving files and old messages send
  2936.  "help" to the same address.  Do not use quotes in your message.
  2937.  
  2938.  
  2939. -------------------------------------------------------------------------------
  2940.  
  2941. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  2942. Subject: RE: (usr-tc) HiPer gone wacko!
  2943. Date: 05 Apr 1999 17:28:08 -0500
  2944.  
  2945.  
  2946.  
  2947. |-----Original Message-----
  2948. |From: owner-usr-tc@lists.xmission.com
  2949. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister
  2950. |Sent: Monday, April 05, 1999 5:11 PM
  2951. |To: usr-tc@lists.xmission.com
  2952. |Subject: Re: (usr-tc) HiPer gone wacko!
  2953. |
  2954. |
  2955. |
  2956. |
  2957. |     Resetting a card by using Dip switch number 5 is usually a good idea, but
  2958. |unfortunately the Hyper ARC does not have a Dip # 5.
  2959. It has one. It just doesnt have anything to do with clearing the flash. You do
  2960. get a boot menu on console before the code image loads. An option exists there to
  2961. clear the configs.
  2962.  
  2963.  
  2964. If your going to do that, and you are not running the latest code. You might as
  2965. well do the zmodem transfer and
  2966. format the flash in the process.
  2967.  
  2968. From the console. After the Boot ROM version prompt there is a delay. During that
  2969. delay you can type
  2970. "AT{ZF}"  this is case sensative. Then begin the zmodem transfer of the code.
  2971.  
  2972. -M
  2973.  
  2974.  
  2975.  
  2976. -
  2977.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2978.  with "unsubscribe usr-tc" in the body of the message.
  2979.  For information on digests or retrieving files and old messages send
  2980.  "help" to the same address.  Do not use quotes in your message.
  2981.  
  2982.  
  2983. -------------------------------------------------------------------------------
  2984.  
  2985. From: Ricky Beam <jfbeam@beaker.interpath.net>
  2986. Subject: Re: (usr-tc) HiPer gone wacko!
  2987. Date: 05 Apr 1999 20:00:51 -0400 (EDT)
  2988.  
  2989. On Mon, 5 Apr 1999, Paul Farber wrote:
  2990. >I never really liked that console flash idea.  Every new NMC seems to go
  2991. >out empty, and if you run a Linix shop.. finding a windows machine to
  2992. >flash a card is a minor pain in the rear. 
  2993.  
  2994. Not really... the flash process is just some fancy SNMP-ness.  Has anyone
  2995. tried running TCM via WINE?  (I'll have to reboot to windows to install
  2996. it before I can test...)
  2997.  
  2998. --Ricky
  2999.  
  3000.  
  3001.  
  3002. -
  3003.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3004.  with "unsubscribe usr-tc" in the body of the message.
  3005.  For information on digests or retrieving files and old messages send
  3006.  "help" to the same address.  Do not use quotes in your message.
  3007.  
  3008.  
  3009. -------------------------------------------------------------------------------
  3010.  
  3011. From: Mike Andrews <mandrews@termfrost.org>
  3012. Subject: Re: (usr-tc) PRI on AMI encoding
  3013. Date: 05 Apr 1999 18:21:14 -0400 (EDT)
  3014.  
  3015. It's just not gonna work.  PRI requires ESF/B8ZS, period.  I'm kinda
  3016. surprised the telco didn't know that...
  3017.  
  3018.  
  3019. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  3020. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  3021. Microsoft operating system is like a dog without a brick tied to its head."
  3022.  
  3023. On Fri, 2 Apr 1999, Chris wrote:
  3024.  
  3025. > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest
  3026. > versions of the code on both. Setting this up for PRI, phone company
  3027. > has a DMS100 and the are running D4 and AMI on the line at 56k. Has
  3028. > anyone had any luck setting a PRI up on D4 and AMI or is this just not
  3029. > gonna work? I've spent hours on the phone with the telco and have
  3030. > talked to 3com and have had mixed answers from them as to whether it
  3031. > will work, they start off telling me it will work and then whittle it
  3032. > down to it won't work. Seems like every question I ask they say, "Yeah
  3033. > it'll do that just fine" and then I call back when I'm having trouble
  3034. > and they try some things and then after a while decide that its not
  3035. > gonna work. Any one out there have any input on whether or not this
  3036. > will work. The telco is leasing the fiber from another telco so it is
  3037. > going to be a pain to get it switched over to ESF and B8ZS.
  3038.  
  3039.  
  3040. -
  3041.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3042.  with "unsubscribe usr-tc" in the body of the message.
  3043.  For information on digests or retrieving files and old messages send
  3044.  "help" to the same address.  Do not use quotes in your message.
  3045.  
  3046.  
  3047. -------------------------------------------------------------------------------
  3048.  
  3049. From: Ricky Beam <jfbeam@beaker.interpath.net>
  3050. Subject: Re: (usr-tc) HiPer gone wacko!
  3051. Date: 05 Apr 1999 20:12:22 -0400 (EDT)
  3052.  
  3053. On Mon, 5 Apr 1999, Paul Farber wrote:
  3054. >If you'all (3Com) released the code I'm sure an enterprising individual
  3055. >would port it for you.  
  3056.  
  3057. I've offered to do it for two years... all I ever managed to get was the
  3058. RADIUS server source (well, there were real reasons for that tho' -- we had
  3059. to have UNIX crypt()ed password support and USR wouldn't spent 5 minutes to
  3060. add it to the scripting language; something so damned simple and they refused
  3061. to do it.  Over a year later (after I did it for them) they finally released
  3062. SA6 with crypt() password capability -- "unsupported" tho'.)
  3063.  
  3064. --Ricky
  3065.  
  3066. PS: I will add, their build environment even two years ago had support for
  3067.     building linux targets.
  3068.  
  3069. PPS: Something tells me TCM-UNIX is headed to look much more like TCM-WIN
  3070.      in the same fashion as HARM. (A serious error in my opinion.  I've
  3071.      never liked seeing windows programs shoe-spooned as UNIX programs.)
  3072.  
  3073.  
  3074.  
  3075.  
  3076. -
  3077.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3078.  with "unsubscribe usr-tc" in the body of the message.
  3079.  For information on digests or retrieving files and old messages send
  3080.  "help" to the same address.  Do not use quotes in your message.
  3081.  
  3082.  
  3083. -------------------------------------------------------------------------------
  3084.  
  3085. From: David Bolen <db3l@ans.net>
  3086. Subject: Re: (usr-tc) HiPer gone wacko!
  3087. Date: 05 Apr 1999 20:36:46 EDT
  3088.  
  3089. Ricky Beam <jfbeam@beaker.interpath.net> writes:
  3090.  
  3091. > Not really... the flash process is just some fancy SNMP-ness.
  3092.  
  3093. Not the SDL-1 (non-Hiper) console flash process - that's a separate
  3094. protocol.  So if you've got an NMC without code, you have to perform
  3095. the console process using PCSDL for which the only officially
  3096. supported platform at this point is DOS/Windows.
  3097.  
  3098. -- David
  3099.  
  3100. /-----------------------------------------------------------------------\
  3101.  \               David Bolen              \  Internet: db3l@ans.net    /
  3102.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  3103.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  3104. \-----------------------------------------------------------------------/
  3105.  
  3106. -
  3107.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3108.  with "unsubscribe usr-tc" in the body of the message.
  3109.  For information on digests or retrieving files and old messages send
  3110.  "help" to the same address.  Do not use quotes in your message.
  3111.  
  3112.  
  3113. -------------------------------------------------------------------------------
  3114.  
  3115. From: Jeff Mcadams <jeffm@iglou.com>
  3116. Subject: Re: (usr-tc) HiPer gone wacko!
  3117. Date: 05 Apr 1999 20:39:33 -0400 (EDT)
  3118.  
  3119. Thus spake Ricky Beam
  3120. >On Mon, 5 Apr 1999, Paul Farber wrote:
  3121. >>I never really liked that console flash idea.  Every new NMC seems to go
  3122. >>out empty, and if you run a Linix shop.. finding a windows machine to
  3123. >>flash a card is a minor pain in the rear. 
  3124.  
  3125. >Not really... the flash process is just some fancy SNMP-ness.  Has anyone
  3126. >tried running TCM via WINE?  (I'll have to reboot to windows to install
  3127. >it before I can test...)
  3128.  
  3129. Have never bothered downloading it to my home box...I think I'll give it
  3130. a shot and see what happens...I'll let ya know.
  3131. -- 
  3132. Jeff McAdams                            Email: jeffm@iglou.com
  3133. Head Network Administrator              Voice: (502) 966-3848
  3134. IgLou Internet Services                        (800) 436-4456
  3135.  
  3136. -
  3137.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3138.  with "unsubscribe usr-tc" in the body of the message.
  3139.  For information on digests or retrieving files and old messages send
  3140.  "help" to the same address.  Do not use quotes in your message.
  3141.  
  3142.  
  3143. -------------------------------------------------------------------------------
  3144.  
  3145. From: Brian <signal@shreve.net>
  3146. Subject: Re: (usr-tc) PRI on AMI encoding
  3147. Date: 05 Apr 1999 19:52:26 -0500 (CDT)
  3148.  
  3149. On Fri, 2 Apr 1999, Chris wrote:
  3150.  
  3151. > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest
  3152. > versions of the code on both. Setting this up for PRI, phone company
  3153. > has a DMS100 and the are running D4 and AMI on the line at 56k. Has
  3154. > anyone had any luck setting a PRI up on D4 and AMI or is this just not
  3155. > gonna work? I've spent hours on the phone with the telco and have
  3156.  
  3157. Everything we run is b8zs/ESF.  I have also seen lines run up in AMI/ESF.
  3158.  
  3159. > talked to 3com and have had mixed answers from them as to whether it
  3160. > will work, they start off telling me it will work and then whittle it
  3161. > down to it won't work. Seems like every question I ask they say, "Yeah
  3162. > it'll do that just fine" and then I call back when I'm having trouble
  3163. > and they try some things and then after a while decide that its not
  3164. > gonna work. Any one out there have any input on whether or not this
  3165. > will work. The telco is leasing the fiber from another telco so it is
  3166. > going to be a pain to get it switched over to ESF and B8ZS.
  3167. > 
  3168.  
  3169. any reason the telco insists on d4/ami?
  3170.  
  3171. > -
  3172. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3173. >  with "unsubscribe usr-tc" in the body of the message.
  3174. >  For information on digests or retrieving files and old messages send
  3175. >  "help" to the same address.  Do not use quotes in your message.
  3176. > 
  3177.  
  3178. Brian Feeny (BF304)     signal@shreve.net   
  3179. 318-222-2638 x 109    http://www.shreve.net/~signal      
  3180. Network Administrator   ShreveNet Inc. (ASN 11881)           
  3181.  
  3182.  
  3183. -
  3184.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3185.  with "unsubscribe usr-tc" in the body of the message.
  3186.  For information on digests or retrieving files and old messages send
  3187.  "help" to the same address.  Do not use quotes in your message.
  3188.  
  3189.  
  3190. -------------------------------------------------------------------------------
  3191.  
  3192. From: Jeff Mcadams <jeffm@iglou.com>
  3193. Subject: Re: (usr-tc) HiPer gone wacko!
  3194. Date: 05 Apr 1999 20:56:52 -0400 (EDT)
  3195.  
  3196. Thus spake Ricky Beam
  3197. >On Mon, 5 Apr 1999, Paul Farber wrote:
  3198. >>I never really liked that console flash idea.  Every new NMC seems to go
  3199. >>out empty, and if you run a Linix shop.. finding a windows machine to
  3200. >>flash a card is a minor pain in the rear. 
  3201.  
  3202. >Not really... the flash process is just some fancy SNMP-ness.  Has anyone
  3203. >tried running TCM via WINE?  (I'll have to reboot to windows to install
  3204. >it before I can test...)
  3205.  
  3206. For what its worth...I didn't try very hard, but it wouldn't run the
  3207. installation...puked out looking for _ISRES.DLL and _SETUP.DLL (with
  3208. that same case even) even though they were in the same directory (with
  3209. the same case...all caps)...
  3210.  
  3211. Anyway...I haven't mucked with wine too much, but I don't have a great
  3212. need for TCM, so its not a big deal for me.  :)
  3213. -- 
  3214. Jeff McAdams                            Email: jeffm@iglou.com
  3215. Head Network Administrator              Voice: (502) 966-3848
  3216. IgLou Internet Services                        (800) 436-4456
  3217.  
  3218. -
  3219.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3220.  with "unsubscribe usr-tc" in the body of the message.
  3221.  For information on digests or retrieving files and old messages send
  3222.  "help" to the same address.  Do not use quotes in your message.
  3223.  
  3224.  
  3225. -------------------------------------------------------------------------------
  3226.  
  3227. From: Ricky Beam <jfbeam@beaker.interpath.net>
  3228. Subject: Re: (usr-tc) HiPer gone wacko!
  3229. Date: 05 Apr 1999 21:14:35 -0400 (EDT)
  3230.  
  3231. On Mon, 5 Apr 1999, David Bolen wrote:
  3232. >Not the SDL-1 (non-Hiper) console flash process - that's a separate
  3233. >protocol.  So if you've got an NMC without code, you have to perform
  3234. >the console process using PCSDL for which the only officially
  3235. >supported platform at this point is DOS/Windows.
  3236.  
  3237. Dead NMC... oh, well, that's different then.  And no, DOSEMU doesn't work
  3238. either -- PCSDL wants hardware access to the serial port.
  3239.  
  3240. Then again, if the NMC is hosed, you really are screwed :-(  I will also note,
  3241. you cannot plug the broken NMC into another chassis to SNMP flash it as NMC
  3242. cards don't work too well outside of slot 17.  (In fact, two functional NMCs
  3243. in one chassis will lock both cards up.)
  3244.  
  3245. --Ricky
  3246.  
  3247.  
  3248.  
  3249. -
  3250.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3251.  with "unsubscribe usr-tc" in the body of the message.
  3252.  For information on digests or retrieving files and old messages send
  3253.  "help" to the same address.  Do not use quotes in your message.
  3254.  
  3255.  
  3256. -------------------------------------------------------------------------------
  3257.  
  3258. From: Ricky Beam <jfbeam@beaker.interpath.net>
  3259. Subject: Re: (usr-tc) HiPer gone wacko!
  3260. Date: 05 Apr 1999 21:18:04 -0400 (EDT)
  3261.  
  3262. On Mon, 5 Apr 1999, Jeff Mcadams wrote:
  3263. >>Not really... the flash process is just some fancy SNMP-ness.  Has anyone
  3264. >>tried running TCM via WINE?  (I'll have to reboot to windows to install
  3265. >>it before I can test...)
  3266. >
  3267. >For what its worth...I didn't try very hard, but it wouldn't run the
  3268. >installation...puked out looking for _ISRES.DLL and _SETUP.DLL (with
  3269. >that same case even) even though they were in the same directory (with
  3270. >the same case...all caps)...
  3271.  
  3272. As I said, I'd have to run windows to INSTALL it.  It needs some windows
  3273. fancy loopback file/directory thing (samba has trouble with this too.)  Once
  3274. it's installed, it might actually "work" -- winzip95 ran with some slight
  3275. problems (the file open dialog box had not backing or border... funny to
  3276. see buttons just floating on the screen.)
  3277.  
  3278. --Ricky
  3279.  
  3280.  
  3281.  
  3282. -
  3283.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3284.  with "unsubscribe usr-tc" in the body of the message.
  3285.  For information on digests or retrieving files and old messages send
  3286.  "help" to the same address.  Do not use quotes in your message.
  3287.  
  3288.  
  3289. -------------------------------------------------------------------------------
  3290.  
  3291. From: "Ray Whelan" <Ray_Whelan@eur.3com.com>
  3292. Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased line
  3293. Date: 06 Apr 1999 10:31:13 +0100
  3294.  
  3295.  
  3296.  
  3297. Hi ,
  3298.  
  3299. Below is the configuration on the setup which I tested, the Quad code in still
  3300. in Beta (tcs3.5),
  3301.  
  3302. Quad to HiPer ARC  - 2 Wire Leased Line setup
  3303.  
  3304.  Total Control QUAD Analog/Digital
  3305.  Total Control HiPer ARC
  3306.  Courier V.Everything
  3307.  Quad  Code: <: 6.0.4 DS>
  3308.  Courier Code: <;3.0.13>
  3309.  Hiper ARC Code: < 4.1.59>
  3310.  
  3311.  
  3312.  The following is how to configure the Courier modem to connect to the Quad
  3313. modem and get login prompt from the ARC
  3314.  
  3315. Configuration for Courier is as follows:
  3316. Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on
  3317. courier set to on,
  3318. at&L1 &b1&n14&w also set the baud rate of the DTE to 115200
  3319.  
  3320. Configuration of the ARC
  3321. Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes
  3322.  
  3323. Configuration of the Quad analog/digital
  3324. at&L1&B1&N14
  3325. ats47.5=1
  3326. ats56.6=0
  3327. ats0=0
  3328.  
  3329. DIP 5 off
  3330.  
  3331. Regards
  3332. Ray Whelan
  3333.  
  3334.  
  3335.  
  3336.  
  3337. Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52
  3338.  
  3339. Please respond to usr-tc@lists.xmission.com
  3340.  
  3341. cc:    (Ray Whelan/IE/3Com)
  3342.  
  3343.  
  3344.  
  3345.  
  3346. Hi folks,
  3347.  
  3348. I wonder if someone of you can tell me how can I setup an TC chassis for
  3349. leased line operation.
  3350. I want that the phone line to be plugged in an Analog Quad Modem and the
  3351. modem "to be connected" in a speciffic interface from the HiperArc. The
  3352. ARC will be configured to make ppp over that line, with no
  3353. authentication, and give the same IP address every time. Of course that
  3354. modem will not be available for the dual E1 card.
  3355.  
  3356.  
  3357. Thank you,
  3358.  
  3359. Stefanita Vilcu, Network Administrator - Dynamic Network Technologies,
  3360. Bucharest, Romania
  3361. vsv@dnt.ro
  3362.  
  3363.  
  3364. -
  3365.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3366.  with "unsubscribe usr-tc" in the body of the message.
  3367.  For information on digests or retrieving files and old messages send
  3368.  "help" to the same address.  Do not use quotes in your message.
  3369.  
  3370.  
  3371.  
  3372.  
  3373.  
  3374.  
  3375.  
  3376.  
  3377.  
  3378. -
  3379.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3380.  with "unsubscribe usr-tc" in the body of the message.
  3381.  For information on digests or retrieving files and old messages send
  3382.  "help" to the same address.  Do not use quotes in your message.
  3383.  
  3384.  
  3385. -------------------------------------------------------------------------------
  3386.  
  3387. From: jeff.binkley@asacomp.com (Jeff Binkley)
  3388. Subject: (usr-tc) RE: (USR-TC) PRI ON AMI E
  3389. Date: 06 Apr 1999 08:29:00 -0500
  3390.  
  3391.  
  3392.  
  3393.  
  3394. To get a 64kbs you must run B8ZS, otherwise the D channel runs at 56kbs.  
  3395. As for ESF, it isn't technically required to run PRIs but generally 
  3396. telcos provision it that way as a general course of business.  The 
  3397. biggest advantage is troubleshooting.
  3398.  
  3399. Jeff Binkley
  3400. ASA Network Computing
  3401.  
  3402.  
  3403. U>On Fri, 2 Apr 1999, Chris wrote:
  3404.  
  3405. U>> I am setting up a chassis with an ARC and 2 HiperDSP's. Latest
  3406. U>> versions of the code on both. Setting this up for PRI, phone company
  3407. U>> has a DMS100 and the are running D4 and AMI on the line at 56k. Has
  3408. U>> anyone had any luck setting a PRI up on D4 and AMI or is this just
  3409. U>> not gonna work? I've spent hours on the phone with the telco and
  3410. U>> have
  3411.  
  3412. U>Everything we run is b8zs/ESF.  I have also seen lines run up in
  3413. U>AMI/ESF.
  3414.  
  3415. U>> talked to 3com and have had mixed answers from them as to whether it
  3416. U>> will work, they start off telling me it will work and then whittle
  3417. U>> it down to it won't work. Seems like every question I ask they say,
  3418. U>> "Yeah it'll do that just fine" and then I call back when I'm having
  3419. U>> trouble and they try some things and then after a while decide that
  3420. U>> its not gonna work. Any one out there have any input on whether or
  3421. U>> not this will work. The telco is leasing the fiber from another
  3422. U>> telco so it is going to be a pain to get it switched over to ESF and
  3423. U>> B8ZS. 
  3424.  
  3425.  
  3426. U>any reason the telco insists on d4/ami?
  3427.  
  3428. U>> -
  3429. U>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3430. U>>  with "unsubscribe usr-tc" in the body of the message.
  3431. U>>  For information on digests or retrieving files and old messages
  3432. U>>  send "help" to the same address.  Do not use quotes in your
  3433. U>> message. 
  3434.  
  3435.  
  3436. U>-----------------------------------------------------
  3437. U>Brian Feeny (BF304)     signal@shreve.net   
  3438. U>318-222-2638 x 109 http://www.shreve.net/~signal      
  3439. U>Network Administrator   ShreveNet Inc. (ASN 11881)        
  3440.  
  3441.  
  3442. U>-
  3443. U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3444. U> with "unsubscribe usr-tc" in the body of the message.
  3445. U> For information on digests or retrieving files and old messages send
  3446. U> "help" to the same address.  Do not use quotes in your message.
  3447.  
  3448. U>                                                      
  3449.  
  3450. CMPQwk 1.42 9999
  3451.  
  3452.  
  3453. -
  3454.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3455.  with "unsubscribe usr-tc" in the body of the message.
  3456.  For information on digests or retrieving files and old messages send
  3457.  "help" to the same address.  Do not use quotes in your message.
  3458.  
  3459.  
  3460. -------------------------------------------------------------------------------
  3461.  
  3462. From: K Mitchell <mitch@keyconn.net>
  3463. Subject: Re: (usr-tc) HiPer operator gone wacko!
  3464. Date: 06 Apr 1999 09:39:33 -0400
  3465.  
  3466. At 05:01 PM 4/5/99 -0500, you wrote:
  3467. >
  3468. >     You will probably want to upgrade to latest code.  Current code is now
  3469. >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90
  3470. >connectivity.   This combination seems to be very stable.  As for this exact
  3471. >issue that you are experiencing, if the reboot does not fix it, it is usually
  3472. >time to re-flash the code.  Since you are in need of an upgrade this is a
  3473. good
  3474. >time to do this.
  3475. >     If you don't have this code, please send me a email, I will forward
  3476. it to
  3477. >you.
  3478.  
  3479.   I appreciate all of the helpful replies. Fortunately the problem turned
  3480. out to be somewhat less serious than the replies anticipated. Being on my
  3481. way out the door to a "You can't be late under any circumstances"
  3482. appointment, I failed to complete a thorough besic check before panicing.
  3483. The problem turned out to be the console cable slipping out of the
  3484. null-modem adaptor. Reaffixing it firmly has everything showing up fine
  3485. again, apparently the user connection problems were an unrelated concidence
  3486. that were all solved by routine configuration reviews.
  3487.   This does bring up another question though. Has anybody been running the
  3488. combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not it
  3489. is worth upgrading to? I know there had been reported problems with the
  3490. 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working fairly
  3491. well, so I've been hesitant to change it.
  3492.  
  3493. Thanks again,
  3494. Kirk
  3495.  
  3496.  
  3497.  
  3498. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  3499. Keystone Connect                http://www.keyconn.net
  3500. Altoona, PA   814-941-5000         We Unlock the World
  3501.  
  3502.  
  3503. -
  3504.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3505.  with "unsubscribe usr-tc" in the body of the message.
  3506.  For information on digests or retrieving files and old messages send
  3507.  "help" to the same address.  Do not use quotes in your message.
  3508.  
  3509.  
  3510. -------------------------------------------------------------------------------
  3511.  
  3512. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  3513. Subject: Re: (usr-tc) HiPer gone wacko!
  3514. Date: 06 Apr 1999 09:49:37 -0500 (CDT)
  3515.  
  3516. On Mon, 5 Apr 1999, Ricky Beam wrote:
  3517.  
  3518. > On Mon, 5 Apr 1999, David Bolen wrote:
  3519. > >Not the SDL-1 (non-Hiper) console flash process - that's a separate
  3520. > >protocol.  So if you've got an NMC without code, you have to perform
  3521. > >the console process using PCSDL for which the only officially
  3522. > >supported platform at this point is DOS/Windows.
  3523. > 
  3524. > Dead NMC... oh, well, that's different then.  And no, DOSEMU doesn't work
  3525. > either -- PCSDL wants hardware access to the serial port.
  3526. > 
  3527. > Then again, if the NMC is hosed, you really are screwed :-(  I will also note,
  3528. > you cannot plug the broken NMC into another chassis to SNMP flash it as NMC
  3529. > cards don't work too well outside of slot 17.  (In fact, two functional NMCs
  3530. > in one chassis will lock both cards up.)
  3531.  
  3532.  
  3533. Do you have a unix machine around there - where you can set it up with a 
  3534. console to the nmc?
  3535.  
  3536. krish
  3537.  
  3538. > 
  3539. > --Ricky
  3540. > 
  3541. > 
  3542. > 
  3543. > -
  3544. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3545. >  with "unsubscribe usr-tc" in the body of the message.
  3546. >  For information on digests or retrieving files and old messages send
  3547. >  "help" to the same address.  Do not use quotes in your message.
  3548. > 
  3549.  
  3550. -
  3551.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3552.  with "unsubscribe usr-tc" in the body of the message.
  3553.  For information on digests or retrieving files and old messages send
  3554.  "help" to the same address.  Do not use quotes in your message.
  3555.  
  3556.  
  3557. -------------------------------------------------------------------------------
  3558.  
  3559. From: Brian <signal@shreve.net>
  3560. Subject: (usr-tc) HiperNMC
  3561. Date: 06 Apr 1999 10:19:56 -0500 (CDT)
  3562.  
  3563.  
  3564. I am sure this has been asked here before, but I don't
  3565. recall.........so.........what is the Aux I/O connector on the back of the
  3566. HiperNMC supposed to be used for?
  3567.  
  3568. I tried hooking my stereo up to it, but I am unable to get the HDM's to do
  3569. an equalization display (<-- just a joke, but it would be cool :) ).
  3570.  
  3571. Brian
  3572.  
  3573.  
  3574. Brian Feeny (BF304)     signal@shreve.net   
  3575. 318-222-2638 x 109    http://www.shreve.net/~signal      
  3576. Network Administrator   ShreveNet Inc. (ASN 11881)           
  3577.  
  3578.  
  3579. -
  3580.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3581.  with "unsubscribe usr-tc" in the body of the message.
  3582.  For information on digests or retrieving files and old messages send
  3583.  "help" to the same address.  Do not use quotes in your message.
  3584.  
  3585.  
  3586. -------------------------------------------------------------------------------
  3587.  
  3588. From: Mike Andrews <mandrews@termfrost.org>
  3589. Subject: Re: (usr-tc) HiPer operator gone wacko!
  3590. Date: 06 Apr 1999 11:18:58 -0400 (EDT)
  3591.  
  3592. DSP 1.2.59 was worse than 1.2.60 for us, but 1.2.43 seems much better than
  3593. either.
  3594.  
  3595. The only problem with ARC 4.1.59-6 I've seen is FreePPP on MacOS can't
  3596. reliably negotiate PPP for some reason (even with all the listed
  3597. workarounds)...
  3598.  
  3599.  
  3600. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  3601. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  3602. Microsoft operating system is like a dog without a brick tied to its head."
  3603.  
  3604. On Tue, 6 Apr 1999, K Mitchell wrote:
  3605.  
  3606. > At 05:01 PM 4/5/99 -0500, you wrote:
  3607. > >
  3608. > >     You will probably want to upgrade to latest code.  Current code is now
  3609. > >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90
  3610. > >connectivity.   This combination seems to be very stable.  As for this exact
  3611. > >issue that you are experiencing, if the reboot does not fix it, it is usually
  3612. > >time to re-flash the code.  Since you are in need of an upgrade this is a
  3613. > good
  3614. > >time to do this.
  3615. > >     If you don't have this code, please send me a email, I will forward
  3616. > it to
  3617. > >you.
  3618. > 
  3619. >   I appreciate all of the helpful replies. Fortunately the problem turned
  3620. > out to be somewhat less serious than the replies anticipated. Being on my
  3621. > way out the door to a "You can't be late under any circumstances"
  3622. > appointment, I failed to complete a thorough besic check before panicing.
  3623. > The problem turned out to be the console cable slipping out of the
  3624. > null-modem adaptor. Reaffixing it firmly has everything showing up fine
  3625. > again, apparently the user connection problems were an unrelated concidence
  3626. > that were all solved by routine configuration reviews.
  3627. >   This does bring up another question though. Has anybody been running the
  3628. > combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not it
  3629. > is worth upgrading to? I know there had been reported problems with the
  3630. > 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working fairly
  3631. > well, so I've been hesitant to change it.
  3632. > 
  3633. > Thanks again,
  3634. > Kirk
  3635. > 
  3636. > 
  3637. > 
  3638. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  3639. > Keystone Connect                http://www.keyconn.net
  3640. > Altoona, PA   814-941-5000         We Unlock the World
  3641. > 
  3642. > 
  3643. > -
  3644. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3645. >  with "unsubscribe usr-tc" in the body of the message.
  3646. >  For information on digests or retrieving files and old messages send
  3647. >  "help" to the same address.  Do not use quotes in your message.
  3648. > 
  3649.  
  3650.  
  3651. -
  3652.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3653.  with "unsubscribe usr-tc" in the body of the message.
  3654.  For information on digests or retrieving files and old messages send
  3655.  "help" to the same address.  Do not use quotes in your message.
  3656.  
  3657.  
  3658. -------------------------------------------------------------------------------
  3659.  
  3660. From: Mike Andrews <mandrews@termfrost.org>
  3661. Subject: (usr-tc) frequency probe data on DSP's
  3662. Date: 06 Apr 1999 11:27:04 -0400 (EDT)
  3663.  
  3664. Quick question:
  3665.  
  3666. Can someone tell me if any current DSP betas or ERs have fixed the
  3667. frequency probe reporting?  This is one of the big Quad features that's
  3668. still missing from DSP's.
  3669.  
  3670. Currently on Quads, you can get the ATY11 frequency probe information (on
  3671. v.34 connects) via SNMP...  on DSP's, all the numbers come up as zero.
  3672. ATY11 works on DSP's, but that doesn't really help you when the user is
  3673. online...
  3674.  
  3675. This, plus a LOT of off-by-one problems with logging, traps, and SNMP, is
  3676. largely what's stopping us from trading out all our Quads for DSP's.  
  3677. (That and the Quads still seem a bit better at dealing with some
  3678. Winmodems.)
  3679.  
  3680.  
  3681. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  3682. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  3683. Microsoft operating system is like a dog without a brick tied to its head."
  3684.  
  3685.  
  3686. -
  3687.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3688.  with "unsubscribe usr-tc" in the body of the message.
  3689.  For information on digests or retrieving files and old messages send
  3690.  "help" to the same address.  Do not use quotes in your message.
  3691.  
  3692.  
  3693. -------------------------------------------------------------------------------
  3694.  
  3695. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  3696. Subject: Re: (usr-tc) HiPer operator gone wacko!
  3697. Date: 06 Apr 1999 11:07:02 -0500
  3698.  
  3699.  
  3700.  
  3701.      Yes, there are a number of people who are running 4.1.59-6 and 1.2.43.
  3702. This combination seems stable, and to resolve most V.90 issues.  This is BIG
  3703. improvement in connectivity, and the 4.1.59-6 addressed some 200 issues with
  3704. 4.1.72-7 code you are running.   The release notes on the web site list most of
  3705. the fixes in this upgrade.
  3706.      In tech support we are asking all customers to go to this code combination.
  3707. It seems very stable, and fixes a whole slew of issues, and finally puts to bed
  3708. most of the V.90 issues.  There are still a few modems that won't cooperate, but
  3709. as long as the End Users (your customers) upgrade to current firmware, the
  3710. should connect fine.
  3711.      If you have any questions, were always here (24x7x365)**
  3712.  
  3713.           Todd           ;-}
  3714.  
  3715.  
  3716.  
  3717.  
  3718.  
  3719.  
  3720. **   of course you do need a premium contract after 8pm central or on weekends /
  3721. holidays.....
  3722.  
  3723.  
  3724.  
  3725.  
  3726.  
  3727. K Mitchell <mitch@keyconn.net> on 04/06/99 08:39:33 AM
  3728.  
  3729. Please respond to usr-tc@lists.xmission.com
  3730.  
  3731. cc:    (Todd Keister/MW/US/3Com)
  3732.  
  3733.  
  3734.  
  3735.  
  3736. At 05:01 PM 4/5/99 -0500, you wrote:
  3737. >
  3738. >     You will probably want to upgrade to latest code.  Current code is now
  3739. >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90
  3740. >connectivity.   This combination seems to be very stable.  As for this exact
  3741. >issue that you are experiencing, if the reboot does not fix it, it is usually
  3742. >time to re-flash the code.  Since you are in need of an upgrade this is a
  3743. good
  3744. >time to do this.
  3745. >     If you don't have this code, please send me a email, I will forward
  3746. it to
  3747. >you.
  3748.  
  3749.   I appreciate all of the helpful replies. Fortunately the problem turned
  3750. out to be somewhat less serious than the replies anticipated. Being on my
  3751. way out the door to a "You can't be late under any circumstances"
  3752. appointment, I failed to complete a thorough besic check before panicing.
  3753. The problem turned out to be the console cable slipping out of the
  3754. null-modem adaptor. Reaffixing it firmly has everything showing up fine
  3755. again, apparently the user connection problems were an unrelated concidence
  3756. that were all solved by routine configuration reviews.
  3757.   This does bring up another question though. Has anybody been running the
  3758. combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not it
  3759. is worth upgrading to? I know there had been reported problems with the
  3760. 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working fairly
  3761. well, so I've been hesitant to change it.
  3762.  
  3763. Thanks again,
  3764. Kirk
  3765.  
  3766.  
  3767.  
  3768. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  3769. Keystone Connect                http://www.keyconn.net
  3770. Altoona, PA   814-941-5000         We Unlock the World
  3771.  
  3772.  
  3773. -
  3774.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3775.  with "unsubscribe usr-tc" in the body of the message.
  3776.  For information on digests or retrieving files and old messages send
  3777.  "help" to the same address.  Do not use quotes in your message.
  3778.  
  3779.  
  3780.  
  3781.  
  3782.  
  3783.  
  3784.  
  3785.  
  3786. -
  3787.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3788.  with "unsubscribe usr-tc" in the body of the message.
  3789.  For information on digests or retrieving files and old messages send
  3790.  "help" to the same address.  Do not use quotes in your message.
  3791.  
  3792.  
  3793. -------------------------------------------------------------------------------
  3794.  
  3795. From: Robert von Bismarck <rvb@petrel.ch>
  3796. Subject: RE: (usr-tc) HiPer operator gone wacko!
  3797. Date: 06 Apr 1999 18:22:12 +0200 
  3798.  
  3799. Is it just me or is 1.2.43 only for T1 ?
  3800.  
  3801. Thanks for any pointers/URL's if it's available for E1-PRI.
  3802.  
  3803.  
  3804. Robert
  3805.  
  3806. > -----Original Message-----
  3807. > From:    Todd Keister [SMTP:Todd_Keister@mw.3com.com]
  3808. > Sent:    mardi, 6. avril 1999 18:07
  3809. > To:    usr-tc@lists.xmission.com
  3810. > Subject:    Re: (usr-tc) HiPer operator gone wacko!
  3811. > 
  3812. > 
  3813. > 
  3814. >      Yes, there are a number of people who are running 4.1.59-6 and
  3815. > 1.2.43.
  3816. > This combination seems stable, and to resolve most V.90 issues.  This is
  3817. > BIG
  3818. > improvement in connectivity, and the 4.1.59-6 addressed some 200 issues
  3819. > with
  3820. > 4.1.72-7 code you are running.   The release notes on the web site list
  3821. > most of
  3822. > the fixes in this upgrade.
  3823. >      In tech support we are asking all customers to go to this code
  3824. > combination.
  3825. > It seems very stable, and fixes a whole slew of issues, and finally puts
  3826. > to bed
  3827. > most of the V.90 issues.  There are still a few modems that won't
  3828. > cooperate, but
  3829. > as long as the End Users (your customers) upgrade to current firmware, the
  3830. > should connect fine.
  3831. >      If you have any questions, were always here (24x7x365)**
  3832. > 
  3833. >           Todd           ;-}
  3834. > 
  3835. > 
  3836. > 
  3837. > 
  3838. > 
  3839. > 
  3840. > **   of course you do need a premium contract after 8pm central or on
  3841. > weekends /
  3842. > holidays.....
  3843. > 
  3844. > 
  3845. > 
  3846. > 
  3847. > 
  3848. > K Mitchell <mitch@keyconn.net> on 04/06/99 08:39:33 AM
  3849. > 
  3850. > Please respond to usr-tc@lists.xmission.com
  3851. > 
  3852. > To:   usr-tc@lists.xmission.com
  3853. > cc:    (Todd Keister/MW/US/3Com)
  3854. > Subject:  Re: (usr-tc) HiPer operator gone wacko!
  3855. > 
  3856. > 
  3857. > 
  3858. > 
  3859. > At 05:01 PM 4/5/99 -0500, you wrote:
  3860. > >
  3861. > >     You will probably want to upgrade to latest code.  Current code is
  3862. > now
  3863. > >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90
  3864. > >connectivity.   This combination seems to be very stable.  As for this
  3865. > exact
  3866. > >issue that you are experiencing, if the reboot does not fix it, it is
  3867. > usually
  3868. > >time to re-flash the code.  Since you are in need of an upgrade this is a
  3869. > good
  3870. > >time to do this.
  3871. > >     If you don't have this code, please send me a email, I will forward
  3872. > it to
  3873. > >you.
  3874. > 
  3875. >   I appreciate all of the helpful replies. Fortunately the problem turned
  3876. > out to be somewhat less serious than the replies anticipated. Being on my
  3877. > way out the door to a "You can't be late under any circumstances"
  3878. > appointment, I failed to complete a thorough besic check before panicing.
  3879. > The problem turned out to be the console cable slipping out of the
  3880. > null-modem adaptor. Reaffixing it firmly has everything showing up fine
  3881. > again, apparently the user connection problems were an unrelated
  3882. > concidence
  3883. > that were all solved by routine configuration reviews.
  3884. >   This does bring up another question though. Has anybody been running the
  3885. > combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not
  3886. > it
  3887. > is worth upgrading to? I know there had been reported problems with the
  3888. > 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working
  3889. > fairly
  3890. > well, so I've been hesitant to change it.
  3891. > 
  3892. > Thanks again,
  3893. > Kirk
  3894. > 
  3895. > 
  3896. > 
  3897. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  3898. > Keystone Connect                http://www.keyconn.net
  3899. > Altoona, PA   814-941-5000         We Unlock the World
  3900. > 
  3901. > 
  3902. > -
  3903. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3904. >  with "unsubscribe usr-tc" in the body of the message.
  3905. >  For information on digests or retrieving files and old messages send
  3906. >  "help" to the same address.  Do not use quotes in your message.
  3907. > 
  3908. > 
  3909. > 
  3910. > 
  3911. > 
  3912. > 
  3913. > 
  3914. > 
  3915. > -
  3916. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3917. >  with "unsubscribe usr-tc" in the body of the message.
  3918. >  For information on digests or retrieving files and old messages send
  3919. >  "help" to the same address.  Do not use quotes in your message.
  3920.  
  3921. -
  3922.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3923.  with "unsubscribe usr-tc" in the body of the message.
  3924.  For information on digests or retrieving files and old messages send
  3925.  "help" to the same address.  Do not use quotes in your message.
  3926.  
  3927.  
  3928. -------------------------------------------------------------------------------
  3929.  
  3930. From: Florin_Neamtu@3com.com
  3931. Subject: RE: (usr-tc) HiPer operator gone wacko!
  3932. Date: 06 Apr 1999 12:36:42 -0400
  3933.  
  3934.  
  3935.  
  3936. That's correct. 1.2.43 is only for T1/PRI.
  3937. The latest code for E1 is 1.2.59, available for download free of charge through
  3938. the end of April from Totalservice site.
  3939.  
  3940. Regards,
  3941. Florin N.
  3942.  
  3943.  
  3944.  
  3945. -
  3946.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3947.  with "unsubscribe usr-tc" in the body of the message.
  3948.  For information on digests or retrieving files and old messages send
  3949.  "help" to the same address.  Do not use quotes in your message.
  3950.  
  3951.  
  3952. -------------------------------------------------------------------------------
  3953.  
  3954. From: Brian <signal@shreve.net>
  3955. Subject: (usr-tc) Alarm server sought
  3956. Date: 06 Apr 1999 12:39:54 -0500 (CDT)
  3957.  
  3958. Can anyone recommend a good alarm server/system for Unix to use with the
  3959. Total Controls?  I want to capture a mutlitude of traps from the chassis.
  3960.  
  3961. The only one I am aware of is trapd(?) which is part of the cmu and/or ucd
  3962. snmp packages.  It would be a big plus if it could log/update a database,
  3963. but even if it can't I can always grok the data from flat file and put it
  3964. into a database.
  3965.  
  3966. Brian
  3967.  
  3968.  
  3969. Brian Feeny (BF304)     signal@shreve.net   
  3970. 318-222-2638 x 109    http://www.shreve.net/~signal      
  3971. Network Administrator   ShreveNet Inc. (ASN 11881)           
  3972.  
  3973.  
  3974. -
  3975.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3976.  with "unsubscribe usr-tc" in the body of the message.
  3977.  For information on digests or retrieving files and old messages send
  3978.  "help" to the same address.  Do not use quotes in your message.
  3979.  
  3980.  
  3981. -------------------------------------------------------------------------------
  3982.  
  3983. From: K Mitchell <mitch@keyconn.net>
  3984. Subject: Re: (usr-tc) HiPer operator gone wacko!
  3985. Date: 06 Apr 1999 13:16:29 -0400
  3986.  
  3987. At 11:07 AM 4/6/99 -0500, "Todd Keister" <Todd_Keister@mw.3com.com> wrote:
  3988. >
  3989. >     Yes, there are a number of people who are running 4.1.59-6 and 1.2.43.
  3990. >This combination seems stable, and to resolve most V.90 issues.  This is BIG
  3991. >improvement in connectivity, and the 4.1.59-6 addressed some 200 issues with
  3992. >4.1.72-7 code you are running.   The release notes on the web site list most 
  3993.  
  3994.   Nothing personal Todd, but I've been bitten by code upgrades before, that
  3995. have been praised by 3Com as the fix to many problems. A number of these
  3996. upgrades have resulted in more problems than they've fixed. The performance
  3997. of these upgrades doesn't have the direct impact on day-to-day business for
  3998. 3Com that it does for ISPs. Being small, I've learned to wait a couple of
  3999. weeks and hear from bigger ISPs that are using an upgrade in production
  4000. before I jump into an upgrade myself.
  4001.  
  4002. Kirk
  4003.  
  4004.  
  4005.  
  4006.  
  4007. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  4008. Keystone Connect                http://www.keyconn.net
  4009. Altoona, PA   814-941-5000         We Unlock the World
  4010.  
  4011.  
  4012. -
  4013.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4014.  with "unsubscribe usr-tc" in the body of the message.
  4015.  For information on digests or retrieving files and old messages send
  4016.  "help" to the same address.  Do not use quotes in your message.
  4017.  
  4018.  
  4019. -------------------------------------------------------------------------------
  4020.  
  4021. From: Brian <signal@shreve.net>
  4022. Subject: (usr-tc) Total Control Parameter Reference
  4023. Date: 06 Apr 1999 12:49:43 -0500 (CDT)
  4024.  
  4025.  
  4026. Where can one get the latest Parameter Reference?  The last one I have is
  4027. 4.3, back from the days when 3Com would actually ship you a printed
  4028. version with every purchase.  I plan to print the latest and spiral bound
  4029. it.
  4030.  
  4031. Do I really need to look at doing queries to the HiperARC btw?  I am use
  4032. to the days when you could get most of diagnostic info (errors, alarms,
  4033. etc) from the nmc.  If I need to look at the HiperARC as well, where is
  4034. the document that documents all its MIB(s) like the parameter reference
  4035. does for the NMC?
  4036.  
  4037. Also, has anyone made a list of traps or mibs to monitor that is a pretty
  4038. good mix for diagnostics/early detection of problems?  I am thinking
  4039. things like LBE's for all the spans, loss of d channels, out of service
  4040. conditions, BPV's on the spans etc.  It would also be helpful to do
  4041. graphs/stats on things like:
  4042.  
  4043. min/max/average connect speed per modem/span/chassis
  4044.  
  4045. etc
  4046.  
  4047. Brian
  4048.  
  4049.  
  4050. Brian Feeny (BF304)     signal@shreve.net   
  4051. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4052. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4053.  
  4054.  
  4055. -
  4056.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4057.  with "unsubscribe usr-tc" in the body of the message.
  4058.  For information on digests or retrieving files and old messages send
  4059.  "help" to the same address.  Do not use quotes in your message.
  4060.  
  4061.  
  4062. -------------------------------------------------------------------------------
  4063.  
  4064. From: Jeff Mcadams <jeffm@iglou.com>
  4065. Subject: Re: (usr-tc) HiPer operator gone wacko!
  4066. Date: 06 Apr 1999 14:04:48 -0400 (EDT)
  4067.  
  4068. Thus spake K Mitchell
  4069. >At 11:07 AM 4/6/99 -0500, "Todd Keister" <Todd_Keister@mw.3com.com>
  4070. >wrote:
  4071. >>Yes, there are a number of people who are running 4.1.59-6 and 1.2.43.
  4072. >>This combination seems stable, and to resolve most V.90 issues.  This
  4073. >>is BIG improvement in connectivity, and the 4.1.59-6 addressed some
  4074. >>200 issues with 4.1.72-7 code you are running.   The release notes on
  4075. >>the web site list most 
  4076.  
  4077. >  Nothing personal Todd, but I've been bitten by code upgrades before,
  4078. >  that have been praised by 3Com as the fix to many problems. 
  4079.  
  4080. I'm so glad to hear someone else say this, not just me.  :)
  4081. -- 
  4082. Jeff McAdams                            Email: jeffm@iglou.com
  4083. Head Network Administrator              Voice: (502) 966-3848
  4084. IgLou Internet Services                        (800) 436-4456
  4085.  
  4086. -
  4087.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4088.  with "unsubscribe usr-tc" in the body of the message.
  4089.  For information on digests or retrieving files and old messages send
  4090.  "help" to the same address.  Do not use quotes in your message.
  4091.  
  4092.  
  4093. -------------------------------------------------------------------------------
  4094.  
  4095. From: "Jim Curran" <Jim_Curran@mw.3com.com>
  4096. Subject: Re: (usr-tc) Total Control Parameter Reference
  4097. Date: 06 Apr 1999 13:19:24 -0500
  4098.  
  4099.  
  4100.  
  4101.  
  4102. Brian,
  4103.  
  4104. As to your first question, I will defer to my colleague who wrote the Parameter
  4105. Reference.
  4106.  
  4107. But about the traps & MIB objects to monitor, we have an ISP Network Management
  4108. Guide available at this URL that aims to answer your questions:
  4109.  
  4110. ftp://totalservice.usr.com/pub/.docs/ispmgt.pdf
  4111.  
  4112. Please let me know if it is helpful to you.
  4113.  
  4114. Jim Curran
  4115. jim_curran@mw.3com.com
  4116.  
  4117.  
  4118.  
  4119.  
  4120. Please respond to usr-tc@lists.xmission.com
  4121.  
  4122. cc:    (Jim Curran/MW/US/3Com)
  4123.  
  4124.  
  4125.  
  4126.  
  4127.  
  4128. Where can one get the latest Parameter Reference?  The last one I have is
  4129. 4.3, back from the days when 3Com would actually ship you a printed
  4130. version with every purchase.  I plan to print the latest and spiral bound
  4131. it.
  4132.  
  4133. Do I really need to look at doing queries to the HiperARC btw?  I am use
  4134. to the days when you could get most of diagnostic info (errors, alarms,
  4135. etc) from the nmc.  If I need to look at the HiperARC as well, where is
  4136. the document that documents all its MIB(s) like the parameter reference
  4137. does for the NMC?
  4138.  
  4139. Also, has anyone made a list of traps or mibs to monitor that is a pretty
  4140. good mix for diagnostics/early detection of problems?  I am thinking
  4141. things like LBE's for all the spans, loss of d channels, out of service
  4142. conditions, BPV's on the spans etc.  It would also be helpful to do
  4143. graphs/stats on things like:
  4144.  
  4145. min/max/average connect speed per modem/span/chassis
  4146.  
  4147. etc
  4148.  
  4149. Brian
  4150.  
  4151.  
  4152.  
  4153.  
  4154.  
  4155.  
  4156.  
  4157. -
  4158.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4159.  with "unsubscribe usr-tc" in the body of the message.
  4160.  For information on digests or retrieving files and old messages send
  4161.  "help" to the same address.  Do not use quotes in your message.
  4162.  
  4163.  
  4164. -------------------------------------------------------------------------------
  4165.  
  4166. From: Mark Lemmert <cto@athenet.net>
  4167. Subject: Re: (usr-tc) Comment from 3COM on latest DSP code please...
  4168. Date: 06 Apr 1999 17:52:47 -0500
  4169.  
  4170. At 12:07 AM 3/19/99 +0000, you wrote:
  4171. >
  4172. >
  4173. >Hi Curt,
  4174. >
  4175. >Below are the two major issues resolved from 1.2.59 to 1.2.43.
  4176. >
  4177. >Hope this helps.
  4178. >
  4179. >Regards,
  4180. >David
  4181. >
  4182. >MR 2021 Improved V.42 compatibility with slower Win-modem clients.
  4183. >MR 2029 Issue : Failure to connect rates were too high and back channel
  4184. >speeds were too low.  Resolution : The answer tone level was hard-coded
  4185. and too
  4186. >loud
  4187. >to trigger the network echo cancellers in some environments.
  4188.  
  4189. David,
  4190.  
  4191. Regarding MR 2029, what was the actual problem symptom that this caused?
  4192. Thanks.
  4193.  
  4194.  
  4195. -Mark
  4196.  
  4197.  
  4198. Mark Lemmert                    AthEnet Data Exchange
  4199. Chief Technical Officer                888-919-8700
  4200.  
  4201. -
  4202.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4203.  with "unsubscribe usr-tc" in the body of the message.
  4204.  For information on digests or retrieving files and old messages send
  4205.  "help" to the same address.  Do not use quotes in your message.
  4206.  
  4207.  
  4208. -------------------------------------------------------------------------------
  4209.  
  4210. From: "Randy McMillan" <randy@pacinfo.com>
  4211. Subject: (usr-tc) Converting to digital T1's give slower v.34 connections
  4212. Date: 06 Apr 1999 12:13:58 -0700
  4213.  
  4214. We are converting our modem pool to all digital lines with TC chassis with
  4215. quad modems and hiper ARC cards.  Some people are connecting slower on the
  4216. new lines than they did on the analog lines.  One customer who got 33.6 or
  4217. 31.2 speeds is now getting 28.8 or 26.4 speeds (with a zoom 2919 with
  4218. current zoom firmware).  He doesn't seem to be able to do v.90 protocol. The
  4219. T1 lines seem to be clean as I can connect at 50k+ using v.90.  If I disable
  4220. v.90 on my sportster, I get 28.8 downstream and 33.6 upstream, but not 33.6
  4221. down.  Of course customers only see the downstream connect speed.
  4222. Does anybody know of any reasons why the v.34 speeds would be slower when
  4223. terminated here on a T1 as opposed to a pots line on the same chassis?  Or
  4224. in regard to my sportster, is there anything in disabling v.90 that would
  4225. disable the 31.2 & 33.6 speeds?  Any info on this would be appreciated..
  4226.  
  4227. Randy McMillan
  4228. PacInfo
  4229.  
  4230.  
  4231. -
  4232.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4233.  with "unsubscribe usr-tc" in the body of the message.
  4234.  For information on digests or retrieving files and old messages send
  4235.  "help" to the same address.  Do not use quotes in your message.
  4236.  
  4237.  
  4238. -------------------------------------------------------------------------------
  4239.  
  4240. From: David Bolen <db3l@ans.net>
  4241. Subject: Re: (usr-tc) HiPer operator gone wacko!
  4242. Date: 06 Apr 1999 14:52:27 EDT
  4243.  
  4244. Jeff Mcadams <jeffm@iglou.com> writes:
  4245.  
  4246. > I'm so glad to hear someone else say this, not just me.  :)
  4247.  
  4248. :-)
  4249.  
  4250. I'll chime in too in agreement.  But I think that, for better or
  4251. worse, this is a general statement on most code for just about any
  4252. hardware in our industry (or even computer hardware in general - how
  4253. quickly does anyone install the latest Windows patches?)
  4254.  
  4255. For our part, personal experience is always going to win out over
  4256. vendor testing.  So any new code gets lab time for specific testing,
  4257. followed by burn-in testing at selected production sites for a
  4258. reasonable period of time (generally 2 weeks for any proposed large
  4259. scale deployment to catch any cyclical behavior) and reasonable call
  4260. load before being accepted for general use.
  4261.  
  4262. In that respect, I don't really care as much whether a code base is
  4263. totally bug free (well, that's not true, I do care, but at times I
  4264. have to be a realist) as much as whether or not there are any bugs
  4265. that happen to get tickled in our specific environment.  There's also
  4266. the consideration that code with problems may still be acceptable in
  4267. the absence of another choice if even with the problems, it's behaving
  4268. better than the existing production code.
  4269.  
  4270. But that holds for others as well, I expect.  So even if some of the
  4271. "larger" ISPs say something good or bad about a code, I'd still want
  4272. to do my own testing, since their environment may not be totally
  4273. representative of my own.
  4274.  
  4275. -- David
  4276.  
  4277. /-----------------------------------------------------------------------\
  4278.  \               David Bolen              \  Internet: db3l@ans.net    /
  4279.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  4280.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  4281. \-----------------------------------------------------------------------/
  4282.  
  4283. -
  4284.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4285.  with "unsubscribe usr-tc" in the body of the message.
  4286.  For information on digests or retrieving files and old messages send
  4287.  "help" to the same address.  Do not use quotes in your message.
  4288.  
  4289.  
  4290. -------------------------------------------------------------------------------
  4291.  
  4292. From: Ronald Kushner <ron@glis.net>
  4293. Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
  4294. Date: 06 Apr 1999 21:17:25 -0400
  4295.  
  4296.  
  4297.  
  4298. Randy McMillan wrote:
  4299. > 
  4300. > We are converting our modem pool to all digital lines with TC chassis with
  4301. > quad modems and hiper ARC cards.  Some people are connecting slower on the
  4302. > new lines than they did on the analog lines.  One customer who got 33.6 or
  4303. > 31.2 speeds is now getting 28.8 or 26.4 speeds (with a zoom 2919 with
  4304. > current zoom firmware).  He doesn't seem to be able to do v.90 protocol. The
  4305. > T1 lines seem to be clean as I can connect at 50k+ using v.90.  If I disable
  4306. > v.90 on my sportster, I get 28.8 downstream and 33.6 upstream, but not 33.6
  4307. > down.  Of course customers only see the downstream connect speed.
  4308. > Does anybody know of any reasons why the v.34 speeds would be slower when
  4309. > terminated here on a T1 as opposed to a pots line on the same chassis?  Or
  4310. > in regard to my sportster, is there anything in disabling v.90 that would
  4311. > disable the 31.2 & 33.6 speeds?  Any info on this would be appreciated..
  4312.  
  4313. There could be two issues at work. The first one is that the call is taking a
  4314. different path now that it is coming in on a CH DS-1. The second is that if calls are
  4315. not originating on the same switch you are terminating on, and the PSTN is not 64k
  4316. clear channel, there is a possibility of added noise in the phone call because of
  4317. Robed Bit Signaling(RBS) - every time the call hops between switches, usually the
  4318. switch picks a new bit to rob from the phone call. If you have your DS-1's provisioned
  4319. with AMI/SF signaling, you might have two different bits robbed if the call is
  4320. originating on a neighboring switch, where before when things were analog there might
  4321. have only been one bit robbed. If you're on the same switch as the caller, you might
  4322. have one robbed bit now where you never had one in the past (the switch operated 64k
  4323. clear internally). These robed bits should not stop a customer from getting a V.90
  4324. connection, unless the customer loop is of poor quality to begin with. But you will
  4325. see reduced connect speeds because of the added noise.
  4326.  
  4327. The best way to boot connect speeds is to go ISDN PRI, but that is generally more
  4328. expensive than CH DS-1s and you pay a penalty of loosing one modem per span. But you
  4329. get back to 64k clear channel with no conversions and usually no padding. I saw a
  4330. boost when a telco I am connected to switched me from AMI/D4 to B8ZS/D5, and another
  4331. boost when I switched my circuits to ISDN PRI. Unfortunatly most rural service areas
  4332. do not offer ISDN PRI service. You defiantly should have your CH DS-1's provisioned as
  4333. B8ZS/ESF if the switch is capable of it.
  4334.  
  4335. There is also a possibility that they have a digital pad misconfigured on your CH
  4336. DS-1, but trying to convince a telco to change the pad type or eliminate the pad can
  4337. be next to impossible. 
  4338.  
  4339. -Ron
  4340. GLISnet, Inc.
  4341. +1 810/939.9885
  4342.  
  4343. -
  4344.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4345.  with "unsubscribe usr-tc" in the body of the message.
  4346.  For information on digests or retrieving files and old messages send
  4347.  "help" to the same address.  Do not use quotes in your message.
  4348.  
  4349.  
  4350. -------------------------------------------------------------------------------
  4351.  
  4352. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  4353. Subject: Re: (usr-tc) HiPer operator gone wacko!
  4354. Date: 06 Apr 1999 16:16:28 -0500
  4355.  
  4356.  
  4357.  
  4358.      Kirk:
  4359.  
  4360.      Since we have to take the calls, we very generally conservative about
  4361. recommending upgrades.  The reason I recommend it is the resolution of the V.90
  4362. issue, and an increase in stability over 4.1.72-7.   This does NOT however imply
  4363. you should ever implement an upgrade without testing.   Networks are far more
  4364. individualized than Snowflakes.   What works on one network may have an issue on
  4365. your network due some specific configuration, or unique grouping of devices with
  4366. a specific configuration.   The upshot:    ALWAYS TEST NEW CODE!!    PLEASE  (
  4367. pretty please with sugar on top)    We do NOT want to cause an issue on your
  4368. production units.
  4369.      The other point you raise is equally valid.  Do you have a valid business
  4370. reason for this upgrade?   If not, then don't upgrade.   The reason I
  4371. recommended this upgrade is most TC owners do want V.90 connectivity (I'm on the
  4372. ISP Support team so this has been one of our most pressing issues).   However,
  4373. if you are a corporate user, and you have good connectivity, and no current
  4374. issues, then you may not want to upgrade at this time.   When in doubt, read the
  4375. release notes, and see if there are any issues that affect you, or may affect
  4376. you in the future.   If so, then consider an upgrade, but only  after your own
  4377. reliability testing.  We can test new code endlessly, and still not have tested
  4378. the code in your environment.
  4379.      With all of this said, I still recommend you upgrade to the 4.1.59-6
  4380. combined with the 1.2.43 code.  This code has been out since March 18th for the
  4381. DSP code, and 4.1.59-6 was released on March 4th.   After an upgrade to this
  4382. code combination, every customer that I have spoken with reported an increase in
  4383. connectivity, a reduction of V.90 complaints, and an increase in general system
  4384. stability.    But of course,  "Your Milage May Vary."
  4385.  
  4386.      Please do note that we did release 4.1.59-1 in early February, and this
  4387. code is different from the 4.1.59-6 that was released on March 4th.   To
  4388. determine exactly which code you have on a Harc type:   _show ver   and it gives
  4389. the exact revision.    Users of the 4.1.59-1 should upgrade to the 4.1.59-6 to
  4390. resolve an issue with ISDN connectivity.
  4391.  
  4392.  
  4393.      Hope this answers your questions.
  4394.  
  4395.  
  4396.                Todd      ;-}
  4397.  
  4398.  
  4399.  
  4400.  
  4401.  
  4402.  
  4403. K Mitchell <mitch@keyconn.net> on 04/06/99 12:16:29 PM
  4404.  
  4405. Please respond to usr-tc@lists.xmission.com
  4406.  
  4407. cc:    (Todd Keister/MW/US/3Com)
  4408.  
  4409.  
  4410.  
  4411.  
  4412. At 11:07 AM 4/6/99 -0500, "Todd Keister" <Todd_Keister@mw.3com.com> wrote:
  4413. >
  4414. >     Yes, there are a number of people who are running 4.1.59-6 and 1.2.43.
  4415. >This combination seems stable, and to resolve most V.90 issues.  This is BIG
  4416. >improvement in connectivity, and the 4.1.59-6 addressed some 200 issues with
  4417. >4.1.72-7 code you are running.   The release notes on the web site list most
  4418.  
  4419.   Nothing personal Todd, but I've been bitten by code upgrades before, that
  4420. have been praised by 3Com as the fix to many problems. A number of these
  4421. upgrades have resulted in more problems than they've fixed. The performance
  4422. of these upgrades doesn't have the direct impact on day-to-day business for
  4423. 3Com that it does for ISPs. Being small, I've learned to wait a couple of
  4424. weeks and hear from bigger ISPs that are using an upgrade in production
  4425. before I jump into an upgrade myself.
  4426.  
  4427. Kirk
  4428.  
  4429.  
  4430.  
  4431.  
  4432. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  4433. Keystone Connect                http://www.keyconn.net
  4434. Altoona, PA   814-941-5000         We Unlock the World
  4435.  
  4436.  
  4437. -
  4438.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4439.  with "unsubscribe usr-tc" in the body of the message.
  4440.  For information on digests or retrieving files and old messages send
  4441.  "help" to the same address.  Do not use quotes in your message.
  4442.  
  4443.  
  4444.  
  4445.  
  4446.  
  4447.  
  4448.  
  4449.  
  4450. -
  4451.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4452.  with "unsubscribe usr-tc" in the body of the message.
  4453.  For information on digests or retrieving files and old messages send
  4454.  "help" to the same address.  Do not use quotes in your message.
  4455.  
  4456.  
  4457. -------------------------------------------------------------------------------
  4458.  
  4459. From: Brian <signal@shreve.net>
  4460. Subject: Re: (usr-tc) Total Control Parameter Reference
  4461. Date: 06 Apr 1999 14:12:53 -0500 (CDT)
  4462.  
  4463. On Tue, 6 Apr 1999, Jim Curran wrote:
  4464.  
  4465. > 
  4466. > 
  4467. > 
  4468. > Brian,
  4469. > 
  4470. > As to your first question, I will defer to my colleague who wrote the Parameter
  4471. > Reference.
  4472. > 
  4473. > But about the traps & MIB objects to monitor, we have an ISP Network Management
  4474. > Guide available at this URL that aims to answer your questions:
  4475. > 
  4476. > ftp://totalservice.usr.com/pub/.docs/ispmgt.pdf
  4477. > 
  4478. > Please let me know if it is helpful to you.
  4479. > 
  4480. > Jim Curran
  4481. > jim_curran@mw.3com.com
  4482.  
  4483.  
  4484. It is :)  I have downloaded that from the first time you posted it, and it
  4485. is a nice peice of work.  Hopefully 3Com will put even more energies into
  4486. usefull documentation such as that, which I feel are very important.
  4487.  
  4488. Brian
  4489.  
  4490.  
  4491. > 
  4492. > 
  4493. > 
  4494. > 
  4495. > Please respond to usr-tc@lists.xmission.com
  4496. > 
  4497. > To:   USRobotics TC Mailing List <usr-tc@xmission.com>
  4498. > cc:    (Jim Curran/MW/US/3Com)
  4499. > Subject:  (usr-tc) Total Control Parameter Reference
  4500. > 
  4501. > 
  4502. > 
  4503. > 
  4504. > 
  4505. > Where can one get the latest Parameter Reference?  The last one I have is
  4506. > 4.3, back from the days when 3Com would actually ship you a printed
  4507. > version with every purchase.  I plan to print the latest and spiral bound
  4508. > it.
  4509. > 
  4510. > Do I really need to look at doing queries to the HiperARC btw?  I am use
  4511. > to the days when you could get most of diagnostic info (errors, alarms,
  4512. > etc) from the nmc.  If I need to look at the HiperARC as well, where is
  4513. > the document that documents all its MIB(s) like the parameter reference
  4514. > does for the NMC?
  4515. > 
  4516. > Also, has anyone made a list of traps or mibs to monitor that is a pretty
  4517. > good mix for diagnostics/early detection of problems?  I am thinking
  4518. > things like LBE's for all the spans, loss of d channels, out of service
  4519. > conditions, BPV's on the spans etc.  It would also be helpful to do
  4520. > graphs/stats on things like:
  4521. > 
  4522. > min/max/average connect speed per modem/span/chassis
  4523. > 
  4524. > etc
  4525. > 
  4526. > Brian
  4527. > 
  4528. > 
  4529. > 
  4530. > 
  4531. > 
  4532. > 
  4533. > 
  4534. > -
  4535. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4536. >  with "unsubscribe usr-tc" in the body of the message.
  4537. >  For information on digests or retrieving files and old messages send
  4538. >  "help" to the same address.  Do not use quotes in your message.
  4539. > 
  4540.  
  4541. Brian Feeny (BF304)     signal@shreve.net   
  4542. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4543. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4544.  
  4545.  
  4546. -
  4547.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4548.  with "unsubscribe usr-tc" in the body of the message.
  4549.  For information on digests or retrieving files and old messages send
  4550.  "help" to the same address.  Do not use quotes in your message.
  4551.  
  4552.  
  4553. -------------------------------------------------------------------------------
  4554.  
  4555. From: <vito@aracnet.net>
  4556. Subject: (usr-tc) Telnet password
  4557. Date: 06 Apr 1999 22:21:13 -0400 (EDT)
  4558.  
  4559. If you for get the telnet password to a USR terminal is there away to
  4560. reset the password so you can telnet into it again.
  4561.  
  4562. Thanks
  4563.  
  4564. Vito
  4565.  
  4566.  
  4567. -
  4568.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4569.  with "unsubscribe usr-tc" in the body of the message.
  4570.  For information on digests or retrieving files and old messages send
  4571.  "help" to the same address.  Do not use quotes in your message.
  4572.  
  4573.  
  4574. -------------------------------------------------------------------------------
  4575.  
  4576. From: K Mitchell <mitch@keyconn.net>
  4577. Subject: Re: (usr-tc) HiPer operator gone wacko!
  4578. Date: 06 Apr 1999 22:13:28 -0400
  4579.  
  4580. At 04:16 PM 4/6/99 -0500, Todd Keister wrote:
  4581. >
  4582. >
  4583. >     Kirk:
  4584. >
  4585. >     Since we have to take the calls, we very generally conservative about
  4586. >recommending upgrades.  The reason I recommend it is the resolution of the
  4587. V.90
  4588. >issue, and an increase in stability over 4.1.72-7.   This does NOT however
  4589. imply
  4590. >you should ever implement an upgrade without testing.   Networks are far more
  4591. >individualized than Snowflakes.   What works on one network may have an
  4592. issue on
  4593. >your network due some specific configuration, or unique grouping of
  4594. devices with
  4595. >a specific configuration.   The upshot:    ALWAYS TEST NEW CODE!!
  4596. PLEASE  (
  4597. >pretty please with sugar on top)    We do NOT want to cause an issue on your
  4598. >production units.
  4599.  
  4600. My problem is that I have only 2 DSPs in service, and an average of 40-44
  4601. modems in use during peak evening times. As much as I'd like to be able to
  4602. test new code myself before putting it in front-line service, I just don't
  4603. have the extra equipment to test it on. I am forced to use other ISPs
  4604. experience as my testing ground because I simply can't afford to have half
  4605. of my modems acting buggy.
  4606.  
  4607. >     The other point you raise is equally valid.  Do you have a valid
  4608. business
  4609. >reason for this upgrade?   If not, then don't upgrade.   The reason I
  4610. >recommended this upgrade is most TC owners do want V.90 connectivity (I'm
  4611. on the
  4612. >ISP Support team so this has been one of our most pressing issues).
  4613. However,
  4614. >if you are a corporate user, and you have good connectivity, and no current
  4615. >issues, then you may not want to upgrade at this time.   When in doubt,
  4616. read the
  4617. >release notes, and see if there are any issues that affect you, or may affect
  4618. >you in the future.
  4619.  
  4620. V90 is an issue for me, but not at the cost of decreased reliability
  4621. elsewhere. Having had no RAS experience prior to my HiPer purchase a year
  4622. ago, I'm not as well-versed as many on this list as to exactly what
  4623. everything does, or all of the ways in which different aspects interact.
  4624. There are times when an issue is mentioned in the release notes and I have
  4625. no clue as to whether it would affect me or not. I'm busting my @$$b to
  4626. learn, but I have to run a business in the meantime, and keep my customers
  4627. happy. This list, and the comments of other users, have been my best guide
  4628. as to whether or not a particular upgrade is likely to help or hurt my
  4629. performance.
  4630.  
  4631. >   If so, then consider an upgrade, but only  after your own
  4632. >reliability testing.  We can test new code endlessly, and still not have
  4633. tested
  4634. >the code in your environment.
  4635. >     With all of this said, I still recommend you upgrade to the 4.1.59-6
  4636. >combined with the 1.2.43 code.  This code has been out since March 18th
  4637. for the
  4638. >DSP code, and 4.1.59-6 was released on March 4th.   After an upgrade to this
  4639. >code combination, every customer that I have spoken with reported an
  4640. increase in
  4641. >connectivity, a reduction of V.90 complaints, and an increase in general
  4642. system
  4643. >stability.    But of course,  "Your Milage May Vary."
  4644.  
  4645. Along this line(did I mention I'm still learning?), how do I "busy-out" a
  4646. DSP in order to force all calls to go to the other one so that I can
  4647. upgrade them with minimal disruption to users online? One of the things I
  4648. have been disappointed in is that all of the HiPer documentation I've seen
  4649. assumes that the reader is well-versed in RAS equipment and terminology.
  4650. I'm not stupid, and have learned a great deal on my own, but for my $12k or
  4651. so would it be too much to ask for a printed document that doesn't assume
  4652. that I've got 3 years of NetServer experience under my belt? Not an
  4653. "Idiot's Guide", but something that at least told me what the hell effect
  4654. things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system.
  4655.  
  4656. >     Please do note that we did release 4.1.59-1 in early February, and this
  4657. >code is different from the 4.1.59-6 that was released on March 4th.   To
  4658. >determine exactly which code you have on a Harc type:   _show ver   and it
  4659. gives
  4660. >the exact revision.    Users of the 4.1.59-1 should upgrade to the
  4661. 4.1.59-6 to
  4662. >resolve an issue with ISDN connectivity.
  4663. >
  4664. >
  4665. >     Hope this answers your questions.
  4666.  
  4667. It clears a few things up. I do appreciate the feedback.
  4668.  
  4669. Kirk
  4670.  
  4671.  
  4672.  
  4673.  
  4674. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  4675. Keystone Connect                http://www.keyconn.net
  4676. Altoona, PA   814-941-5000         We Unlock the World
  4677.  
  4678.  
  4679. -
  4680.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4681.  with "unsubscribe usr-tc" in the body of the message.
  4682.  For information on digests or retrieving files and old messages send
  4683.  "help" to the same address.  Do not use quotes in your message.
  4684.  
  4685.  
  4686. -------------------------------------------------------------------------------
  4687.  
  4688. From: Jim Johnson <jim@perigee.net>
  4689. Subject: (usr-tc) Web Ramp
  4690. Date: 06 Apr 1999 17:28:34 -0400
  4691.  
  4692.  
  4693.  
  4694. One of our customers is having a problem connecting the second channel
  4695. of an ISDN Webramp to our TC HUB.  I believe we have the MLPPP setup
  4696. correctly and use one ARC as the MLPPP server.  This setup seems to work
  4697. for NT and other non-webramp customers.  
  4698.  
  4699. They emailed a PPP dump generated by the webramp which according to
  4700. webramp support indicated that our hub was requesting a
  4701. reconfiguration.  I don't know anything about webramps so I can't tell
  4702. if this is a web ramp problem or if there is something we need do to
  4703. help them from our side.
  4704.  
  4705. Our config
  4706. -------------
  4707. ARCs are using 4.1.59-6
  4708. HDMS are using 1.2.43
  4709. PPP Offloading is enabled
  4710. CCP compression is set to ALL
  4711.  
  4712. PPP DUMP from webramp
  4713. ---------------------
  4714. PPP LCP Successful on channel:B2
  4715. PPP LCP Negotiated Parameters on B2: R_MRU:1524
  4716.   R_MRRU:1600 R_AUTH:PAP S_MRU:1514 S_MRRU:1514 S_AUTH:PAP
  4717. PPP Authentication started on:B2 type:PAP
  4718. PPP Authentication Succeeded on:B2 for
  4719.   user: mac
  4720. PPP IPCP WARNING: 2nd chan fails: Invalid IPCP Config Req from Remote
  4721. PPP Disconnect sent to remote, cause #16:
  4722.   Normal Call Clearing
  4723. PPP Disconnect complete on channel B2
  4724. PPP Initiating a call to remote: 1230140
  4725. PPP Connected on channel B2 to:1230140
  4726. PPP LCP Started on channel:B2
  4727. PPP LCP Successful on channel:B2
  4728. PPP LCP Negotiated Parameters on B2: R_MRU:1524
  4729.   R_MRRU:1600 R_AUTH:PAP S_MRU:1514 S_MRRU:1514 S_AUTH:PAP
  4730. PPP Authentication started on:B2 type:PAP
  4731. PPP Authentication Succeeded on:B2 for
  4732.   user: mac
  4733.  
  4734. -
  4735.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4736.  with "unsubscribe usr-tc" in the body of the message.
  4737.  For information on digests or retrieving files and old messages send
  4738.  "help" to the same address.  Do not use quotes in your message.
  4739.  
  4740.  
  4741. -------------------------------------------------------------------------------
  4742.  
  4743. From: Paul Farber <farber@admin.f-tech.net>
  4744. Subject: Re: (usr-tc) HiPer operator gone wacko!
  4745. Date: 06 Apr 1999 22:54:38 -0400 (EDT)
  4746.  
  4747. Ditto to this.  Having a PRI laying around for testing, plus a chassis is
  4748. a rather tall order.  
  4749.  
  4750. Maybe 3Com could post some data from thier lab as a general expectation
  4751. for others.  I know the reps would LOVE to have me order a unit just for
  4752. testing.. but that ain't gonna happen.  I have 5 DSP's in service and
  4753. although I did get another chassis, the only reason was that
  4754. 2 DSP's are $8500, the entire new rack with support for a year was
  4755. $10,000.   
  4756.  
  4757. I know that every phone system is different.  But the release notes ALWAYS
  4758. have v.90 compatibilaty issues as a resolved issue.. and also as an
  4759. open one?!?!?!?
  4760.  
  4761. BTW.. I am hovering around a 10% call failure rate with the my current
  4762. installed code.  Will put in 1.2.43 in a day or so to see if I can settle
  4763. down the failure rates.
  4764.  
  4765. That said.. I still think US Robotics is doing all right.... and that we
  4766. should collectivly firebomb those damned generic modem factories.
  4767.  
  4768. Paul D. Farber II
  4769. Farber Technology
  4770. Ph. 570-628-5303
  4771. Fax 570-628-5545
  4772. farber@admin.f-tech.net
  4773.  
  4774. On Tue, 6 Apr 1999, K Mitchell wrote:
  4775.  
  4776. > At 04:16 PM 4/6/99 -0500, Todd Keister wrote:
  4777. > >
  4778. > >
  4779. > >     Kirk:
  4780. > >
  4781. > >     Since we have to take the calls, we very generally conservative about
  4782. > >recommending upgrades.  The reason I recommend it is the resolution of the
  4783. > V.90
  4784. > >issue, and an increase in stability over 4.1.72-7.   This does NOT however
  4785. > imply
  4786. > >you should ever implement an upgrade without testing.   Networks are far more
  4787. > >individualized than Snowflakes.   What works on one network may have an
  4788. > issue on
  4789. > >your network due some specific configuration, or unique grouping of
  4790. > devices with
  4791. > >a specific configuration.   The upshot:    ALWAYS TEST NEW CODE!!
  4792. > PLEASE  (
  4793. > >pretty please with sugar on top)    We do NOT want to cause an issue on your
  4794. > >production units.
  4795. > 
  4796. > My problem is that I have only 2 DSPs in service, and an average of 40-44
  4797. > modems in use during peak evening times. As much as I'd like to be able to
  4798. > test new code myself before putting it in front-line service, I just don't
  4799. > have the extra equipment to test it on. I am forced to use other ISPs
  4800. > experience as my testing ground because I simply can't afford to have half
  4801. > of my modems acting buggy.
  4802. > 
  4803. > >     The other point you raise is equally valid.  Do you have a valid
  4804. > business
  4805. > >reason for this upgrade?   If not, then don't upgrade.   The reason I
  4806. > >recommended this upgrade is most TC owners do want V.90 connectivity (I'm
  4807. > on the
  4808. > >ISP Support team so this has been one of our most pressing issues).
  4809. > However,
  4810. > >if you are a corporate user, and you have good connectivity, and no current
  4811. > >issues, then you may not want to upgrade at this time.   When in doubt,
  4812. > read the
  4813. > >release notes, and see if there are any issues that affect you, or may affect
  4814. > >you in the future.
  4815. > 
  4816. > V90 is an issue for me, but not at the cost of decreased reliability
  4817. > elsewhere. Having had no RAS experience prior to my HiPer purchase a year
  4818. > ago, I'm not as well-versed as many on this list as to exactly what
  4819. > everything does, or all of the ways in which different aspects interact.
  4820. > There are times when an issue is mentioned in the release notes and I have
  4821. > no clue as to whether it would affect me or not. I'm busting my @$$b to
  4822. > learn, but I have to run a business in the meantime, and keep my customers
  4823. > happy. This list, and the comments of other users, have been my best guide
  4824. > as to whether or not a particular upgrade is likely to help or hurt my
  4825. > performance.
  4826. > 
  4827. > >   If so, then consider an upgrade, but only  after your own
  4828. > >reliability testing.  We can test new code endlessly, and still not have
  4829. > tested
  4830. > >the code in your environment.
  4831. > >     With all of this said, I still recommend you upgrade to the 4.1.59-6
  4832. > >combined with the 1.2.43 code.  This code has been out since March 18th
  4833. > for the
  4834. > >DSP code, and 4.1.59-6 was released on March 4th.   After an upgrade to this
  4835. > >code combination, every customer that I have spoken with reported an
  4836. > increase in
  4837. > >connectivity, a reduction of V.90 complaints, and an increase in general
  4838. > system
  4839. > >stability.    But of course,  "Your Milage May Vary."
  4840. > 
  4841. > Along this line(did I mention I'm still learning?), how do I "busy-out" a
  4842. > DSP in order to force all calls to go to the other one so that I can
  4843. > upgrade them with minimal disruption to users online? One of the things I
  4844. > have been disappointed in is that all of the HiPer documentation I've seen
  4845. > assumes that the reader is well-versed in RAS equipment and terminology.
  4846. > I'm not stupid, and have learned a great deal on my own, but for my $12k or
  4847. > so would it be too much to ask for a printed document that doesn't assume
  4848. > that I've got 3 years of NetServer experience under my belt? Not an
  4849. > "Idiot's Guide", but something that at least told me what the hell effect
  4850. > things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system.
  4851. > 
  4852. > >     Please do note that we did release 4.1.59-1 in early February, and this
  4853. > >code is different from the 4.1.59-6 that was released on March 4th.   To
  4854. > >determine exactly which code you have on a Harc type:   _show ver   and it
  4855. > gives
  4856. > >the exact revision.    Users of the 4.1.59-1 should upgrade to the
  4857. > 4.1.59-6 to
  4858. > >resolve an issue with ISDN connectivity.
  4859. > >
  4860. > >
  4861. > >     Hope this answers your questions.
  4862. > 
  4863. > It clears a few things up. I do appreciate the feedback.
  4864. > 
  4865. > Kirk
  4866. > 
  4867. > 
  4868. > 
  4869. > 
  4870. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  4871. > Keystone Connect                http://www.keyconn.net
  4872. > Altoona, PA   814-941-5000         We Unlock the World
  4873. > 
  4874. > 
  4875. > -
  4876. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4877. >  with "unsubscribe usr-tc" in the body of the message.
  4878. >  For information on digests or retrieving files and old messages send
  4879. >  "help" to the same address.  Do not use quotes in your message.
  4880. > 
  4881.  
  4882.  
  4883. -
  4884.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4885.  with "unsubscribe usr-tc" in the body of the message.
  4886.  For information on digests or retrieving files and old messages send
  4887.  "help" to the same address.  Do not use quotes in your message.
  4888.  
  4889.  
  4890. -------------------------------------------------------------------------------
  4891.  
  4892. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  4893. Subject: Re: (usr-tc) HiPer operator gone wacko!
  4894. Date: 07 Apr 1999 09:24:51 -0500
  4895.  
  4896.  
  4897.  
  4898.  
  4899.      Kirk:
  4900.  
  4901.  
  4902.      This thread was too long so I've killed most of it.
  4903.  
  4904.      If you want to know how to busy modems on a DSP card, without disconnecting
  4905. users currently connected you need to SOFT BUSY the modems.  Rather than answer
  4906. your question here in this forum, I wish to send you to the 3KB knowledgebase
  4907. for this solution.  I know this solution works (I wrote it ;-}).  The URL for
  4908. 3KB is:   http://knowledgebase.3com.com  When you get to the question window
  4909. just type "how to soft busy modems" and you will find the answer has detailed
  4910. step by step instructions for soft busy, and to restore.
  4911.  
  4912.      We are urging everyone to try the 3KB first for most questions.  We have
  4913. over 1,000 solutions and are publishing more every day.  Another very useful
  4914. search is: netserver cli    This gives an almost full listing of all the command
  4915. line interface commands for the Netserver card.
  4916.  
  4917.      If there is ever a solution that you need, and we don't have it in 3KB,
  4918. just tell the technician you speak with that this solution is NOT in 3KB, and we
  4919. can then be sure to put this answer into the database.
  4920.  
  4921.      If any of you power users out there wish to have your solutions put into
  4922. the database, send me a private email, and I will forward it to the proper place
  4923. for review and publishing.
  4924.  
  4925.  
  4926.      Hope this helps.              Todd       ;-}
  4927.  
  4928.  
  4929.  
  4930.  
  4931.  
  4932.  
  4933.  
  4934.  
  4935. K Mitchell <mitch@keyconn.net> on 04/06/99 09:13:28 PM
  4936. >Along this line(did I mention I'm still learning?), how do I "busy-out" a
  4937. >DSP in order to force all calls to go to the other one so that I can
  4938. >upgrade them with minimal disruption to users online? One of the things I
  4939. >have been disappointed in is that all of the HiPer documentation I've seen
  4940. >assumes that the reader is well-versed in RAS equipment and terminology.
  4941. >I'm not stupid, and have learned a great deal on my own, but for my $12k or
  4942. >so would it be too much to ask for a printed document that doesn't assume
  4943. >that I've got 3 years of NetServer experience under my belt? Not an
  4944. >"Idiot's Guide", but something that at least told me what the hell effect
  4945. >things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system.
  4946.  
  4947. >It clears a few things up. I do appreciate the feedback.
  4948.  
  4949. >Kirk
  4950.  
  4951.  
  4952.  
  4953.  
  4954. >Kirk Mitchell-General Manager     sysadmin@keyconn.net
  4955. >Keystone Connect                http://www.keyconn.net
  4956. >Altoona, PA   814-941-5000         We Unlock the World
  4957.  
  4958.  
  4959.  
  4960.  
  4961.  
  4962.  
  4963. -
  4964.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4965.  with "unsubscribe usr-tc" in the body of the message.
  4966.  For information on digests or retrieving files and old messages send
  4967.  "help" to the same address.  Do not use quotes in your message.
  4968.  
  4969.  
  4970. -------------------------------------------------------------------------------
  4971.  
  4972. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  4973. Subject: Re: (usr-tc) Telnet password
  4974. Date: 07 Apr 1999 09:44:13 -0500 (CDT)
  4975.  
  4976.  
  4977. On Tue, 6 Apr 1999 vito@aracnet.net wrote:
  4978.  
  4979. > If you for get the telnet password to a USR terminal is there away to
  4980. > reset the password so you can telnet into it again.
  4981. > 
  4982.  
  4983. If its a NETServer then you have no other option but to put dip switch 5 
  4984. on and reboot the card - thus erase all the config.
  4985.  
  4986. If its a HiPer arc and if you have radius configured then you can add a 
  4987. admin user 
  4988.  
  4989. user  Password = password
  4990.       User_service_type = Administrative-User
  4991.        
  4992.  
  4993. and then you can use this user to login as admin to the hiper arc card
  4994.  
  4995. krish
  4996.  
  4997.  
  4998. > Thanks
  4999. > 
  5000. > Vito
  5001. > 
  5002. > 
  5003. > -
  5004. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5005. >  with "unsubscribe usr-tc" in the body of the message.
  5006. >  For information on digests or retrieving files and old messages send
  5007. >  "help" to the same address.  Do not use quotes in your message.
  5008. > 
  5009.  
  5010. -
  5011.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5012.  with "unsubscribe usr-tc" in the body of the message.
  5013.  For information on digests or retrieving files and old messages send
  5014.  "help" to the same address.  Do not use quotes in your message.
  5015.  
  5016.  
  5017. -------------------------------------------------------------------------------
  5018.  
  5019. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  5020. Subject: Re: (usr-tc) HiPer operator gone wacko!
  5021. Date: 07 Apr 1999 09:41:55 -0500
  5022.  
  5023.  
  5024.  
  5025.  
  5026.      Paul:
  5027.  
  5028.      The testing I recommend can be as simple as putting new code on only 1 card
  5029. if all you have is 2 cards.   Sure, some of the larger ISPs have a seperate
  5030. chassis just for reliability testing, and this is ideal.   But many of our
  5031. customers can't afford that luxury.   On the other hand, I have had to pick up
  5032. the pieces when a customer upgraded his Hyper Arc, all 30 of his DSPs on 4
  5033. chassis, all of his NMCs and the Netserver card on the chassis with Quads, all
  5034. in 1 day.   With many things upgraded it was not fun trying to guess which item
  5035. was the "culprit"     A little planing and foresight can go a long way in making
  5036. an upgrade happen without headaches or difficulties.   If  you have multiple
  5037. upgrades to undertake, upgrade 1 item and see if it works for 2-3 days first.
  5038. Then try the next upgrade.  This way we can see if one specific item will not
  5039. play nice on your network.
  5040.  
  5041.           I hope this helps to clarify my prior statements.
  5042.  
  5043.           Thanks for using 3Com equipment.
  5044.  
  5045.                Todd      ;-}
  5046.  
  5047.  
  5048.  
  5049.  
  5050.  
  5051.  
  5052.  
  5053.  
  5054. Paul Farber <farber@admin.f-tech.net> on 04/06/99 09:54:38 PM
  5055.  
  5056. Please respond to usr-tc@lists.xmission.com
  5057.  
  5058. cc:    (Todd Keister/MW/US/3Com)
  5059.  
  5060.  
  5061.  
  5062.  
  5063. Ditto to this.  Having a PRI laying around for testing, plus a chassis is
  5064. a rather tall order.
  5065.  
  5066. Maybe 3Com could post some data from thier lab as a general expectation
  5067. for others.  I know the reps would LOVE to have me order a unit just for
  5068. testing.. but that ain't gonna happen.  I have 5 DSP's in service and
  5069. although I did get another chassis, the only reason was that
  5070. 2 DSP's are $8500, the entire new rack with support for a year was
  5071. $10,000.
  5072.  
  5073. I know that every phone system is different.  But the release notes ALWAYS
  5074. have v.90 compatibilaty issues as a resolved issue.. and also as an
  5075. open one?!?!?!?
  5076.  
  5077. BTW.. I am hovering around a 10% call failure rate with the my current
  5078. installed code.  Will put in 1.2.43 in a day or so to see if I can settle
  5079. down the failure rates.
  5080.  
  5081. That said.. I still think US Robotics is doing all right.... and that we
  5082. should collectivly firebomb those damned generic modem factories.
  5083.  
  5084. Paul D. Farber II
  5085. Farber Technology
  5086. Ph. 570-628-5303
  5087. Fax 570-628-5545
  5088. farber@admin.f-tech.net
  5089.  
  5090. On Tue, 6 Apr 1999, K Mitchell wrote:
  5091.  
  5092. > At 04:16 PM 4/6/99 -0500, Todd Keister wrote:
  5093. > >
  5094. > >
  5095. > >     Kirk:
  5096. > >
  5097. > >     Since we have to take the calls, we very generally conservative about
  5098. > >recommending upgrades.  The reason I recommend it is the resolution of the
  5099. > V.90
  5100. > >issue, and an increase in stability over 4.1.72-7.   This does NOT however
  5101. > imply
  5102. > >you should ever implement an upgrade without testing.   Networks are far more
  5103. > >individualized than Snowflakes.   What works on one network may have an
  5104. > issue on
  5105. > >your network due some specific configuration, or unique grouping of
  5106. > devices with
  5107. > >a specific configuration.   The upshot:    ALWAYS TEST NEW CODE!!
  5108. > PLEASE  (
  5109. > >pretty please with sugar on top)    We do NOT want to cause an issue on your
  5110. > >production units.
  5111. >
  5112. > My problem is that I have only 2 DSPs in service, and an average of 40-44
  5113. > modems in use during peak evening times. As much as I'd like to be able to
  5114. > test new code myself before putting it in front-line service, I just don't
  5115. > have the extra equipment to test it on. I am forced to use other ISPs
  5116. > experience as my testing ground because I simply can't afford to have half
  5117. > of my modems acting buggy.
  5118. >
  5119. > >     The other point you raise is equally valid.  Do you have a valid
  5120. > business
  5121. > >reason for this upgrade?   If not, then don't upgrade.   The reason I
  5122. > >recommended this upgrade is most TC owners do want V.90 connectivity (I'm
  5123. > on the
  5124. > >ISP Support team so this has been one of our most pressing issues).
  5125. > However,
  5126. > >if you are a corporate user, and you have good connectivity, and no current
  5127. > >issues, then you may not want to upgrade at this time.   When in doubt,
  5128. > read the
  5129. > >release notes, and see if there are any issues that affect you, or may affect
  5130. > >you in the future.
  5131. >
  5132. > V90 is an issue for me, but not at the cost of decreased reliability
  5133. > elsewhere. Having had no RAS experience prior to my HiPer purchase a year
  5134. > ago, I'm not as well-versed as many on this list as to exactly what
  5135. > everything does, or all of the ways in which different aspects interact.
  5136. > There are times when an issue is mentioned in the release notes and I have
  5137. > no clue as to whether it would affect me or not. I'm busting my @$$b to
  5138. > learn, but I have to run a business in the meantime, and keep my customers
  5139. > happy. This list, and the comments of other users, have been my best guide
  5140. > as to whether or not a particular upgrade is likely to help or hurt my
  5141. > performance.
  5142. >
  5143. > >   If so, then consider an upgrade, but only  after your own
  5144. > >reliability testing.  We can test new code endlessly, and still not have
  5145. > tested
  5146. > >the code in your environment.
  5147. > >     With all of this said, I still recommend you upgrade to the 4.1.59-6
  5148. > >combined with the 1.2.43 code.  This code has been out since March 18th
  5149. > for the
  5150. > >DSP code, and 4.1.59-6 was released on March 4th.   After an upgrade to this
  5151. > >code combination, every customer that I have spoken with reported an
  5152. > increase in
  5153. > >connectivity, a reduction of V.90 complaints, and an increase in general
  5154. > system
  5155. > >stability.    But of course,  "Your Milage May Vary."
  5156. >
  5157. > Along this line(did I mention I'm still learning?), how do I "busy-out" a
  5158. > DSP in order to force all calls to go to the other one so that I can
  5159. > upgrade them with minimal disruption to users online? One of the things I
  5160. > have been disappointed in is that all of the HiPer documentation I've seen
  5161. > assumes that the reader is well-versed in RAS equipment and terminology.
  5162. > I'm not stupid, and have learned a great deal on my own, but for my $12k or
  5163. > so would it be too much to ask for a printed document that doesn't assume
  5164. > that I've got 3 years of NetServer experience under my belt? Not an
  5165. > "Idiot's Guide", but something that at least told me what the hell effect
  5166. > things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system.
  5167. >
  5168. > >     Please do note that we did release 4.1.59-1 in early February, and this
  5169. > >code is different from the 4.1.59-6 that was released on March 4th.   To
  5170. > >determine exactly which code you have on a Harc type:   _show ver   and it
  5171. > gives
  5172. > >the exact revision.    Users of the 4.1.59-1 should upgrade to the
  5173. > 4.1.59-6 to
  5174. > >resolve an issue with ISDN connectivity.
  5175. > >
  5176. > >
  5177. > >     Hope this answers your questions.
  5178. >
  5179. > It clears a few things up. I do appreciate the feedback.
  5180. >
  5181. > Kirk
  5182. >
  5183. >
  5184. >
  5185. >
  5186. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  5187. > Keystone Connect                http://www.keyconn.net
  5188. > Altoona, PA   814-941-5000         We Unlock the World
  5189. >
  5190. >
  5191. > -
  5192. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5193. >  with "unsubscribe usr-tc" in the body of the message.
  5194. >  For information on digests or retrieving files and old messages send
  5195. >  "help" to the same address.  Do not use quotes in your message.
  5196. >
  5197.  
  5198.  
  5199. -
  5200.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5201.  with "unsubscribe usr-tc" in the body of the message.
  5202.  For information on digests or retrieving files and old messages send
  5203.  "help" to the same address.  Do not use quotes in your message.
  5204.  
  5205.  
  5206.  
  5207.  
  5208.  
  5209.  
  5210.  
  5211.  
  5212. -
  5213.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5214.  with "unsubscribe usr-tc" in the body of the message.
  5215.  For information on digests or retrieving files and old messages send
  5216.  "help" to the same address.  Do not use quotes in your message.
  5217.  
  5218.  
  5219. -------------------------------------------------------------------------------
  5220.  
  5221. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  5222. Subject: (usr-tc) Totalservice BETA reforms
  5223. Date: 07 Apr 1999 10:44:53 -0500
  5224.  
  5225. We have revised the beta process and now have all beta working through
  5226. totalservice. If you visit the beta section
  5227. you will see a list of active and upcoming beta projects.  You will have to sign
  5228. up for each beta. Once accepted you will gain access to the code on totalservice.
  5229.  
  5230. Incase you were not aware, OSPF is in BETA now. If your interested and not in the
  5231. BETA, please sign up. Drop me a
  5232. note if you do so I can expedite your acceptance into the program. OSPF is part
  5233. of the TCS 3.6 Beta.
  5234.  
  5235.  
  5236. Mike Wronski (mike@coredump.ae.usr.com)
  5237. Rogue 3Com Network Systems Engineer / BETA Engineer
  5238. PGP:http://coredump.ae.usr.com/pgp iCQ:15796141
  5239. "If at first you do succeed, try not to look astonished."
  5240.  
  5241.  
  5242. -
  5243.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5244.  with "unsubscribe usr-tc" in the body of the message.
  5245.  For information on digests or retrieving files and old messages send
  5246.  "help" to the same address.  Do not use quotes in your message.
  5247.  
  5248.  
  5249. -------------------------------------------------------------------------------
  5250.  
  5251. From: "Jamie Orzechowski" <mhz@ripnet.com>
  5252. Subject: Re: (usr-tc) Totalservice BETA reforms
  5253. Date: 07 Apr 1999 12:11:29 -0400
  5254.  
  5255. I try an signup for the TCS 3.6 Beta and I get the following
  5256.  
  5257.  
  5258. Error Occurred While Processing Request
  5259. Error Diagnostic Information
  5260. Parameter 3 of function DateDiff which is now "" must be a date/time value
  5261.  
  5262. The error occurred while evaluating the expression:
  5263.  
  5264.  
  5265.  Expiration = DateDiff("d", "#Date#","#ExpireDate.sti_finishdate#")
  5266.  
  5267.  
  5268.  
  5269.  
  5270. The error occurred while processing an element with a general identifier of
  5271. (CFSET), occupying document position (193:4) to (193:77).
  5272.  
  5273.  
  5274. Date/Time: 04/07/99 11:08:21
  5275. Browser: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98;
  5276. CNETHomeBuild03171999)
  5277. Remote Address: 206.47.98.69
  5278. HTTP Referer: http://tsoweb.nsd.usr.com/beta/
  5279. Template: D:\InetPub\wwwroot\beta\logged_in.cfm
  5280.  
  5281.  
  5282.  
  5283.  
  5284.  
  5285.  
  5286. ----- Original Message -----
  5287. Sent: Wednesday, April 07, 1999 11:44 AM
  5288.  
  5289.  
  5290. > We have revised the beta process and now have all beta working through
  5291. > totalservice. If you visit the beta section
  5292. > you will see a list of active and upcoming beta projects.  You will have
  5293. to sign
  5294. > up for each beta. Once accepted you will gain access to the code on
  5295. totalservice.
  5296. >
  5297. > Incase you were not aware, OSPF is in BETA now. If your interested and not
  5298. in the
  5299. > BETA, please sign up. Drop me a
  5300. > note if you do so I can expedite your acceptance into the program. OSPF is
  5301. part
  5302. > of the TCS 3.6 Beta.
  5303. >
  5304. >
  5305. > ---------------------------------------------------------
  5306. > Mike Wronski (mike@coredump.ae.usr.com)
  5307. > Rogue 3Com Network Systems Engineer / BETA Engineer
  5308. > PGP:http://coredump.ae.usr.com/pgp iCQ:15796141
  5309. > "If at first you do succeed, try not to look astonished."
  5310. >
  5311. >
  5312. > -
  5313. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5314. >  with "unsubscribe usr-tc" in the body of the message.
  5315. >  For information on digests or retrieving files and old messages send
  5316. >  "help" to the same address.  Do not use quotes in your message.
  5317. >
  5318. >
  5319.  
  5320.  
  5321. -
  5322.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5323.  with "unsubscribe usr-tc" in the body of the message.
  5324.  For information on digests or retrieving files and old messages send
  5325.  "help" to the same address.  Do not use quotes in your message.
  5326.  
  5327.  
  5328. -------------------------------------------------------------------------------
  5329.  
  5330. From: "David Bachta" <David_Bachta@mw.3com.com>
  5331. Subject: Re: (usr-tc) Comment from 3COM on latest DSP code please...
  5332. Date: 07 Apr 1999 13:01:16 -0500
  5333.  
  5334.  
  5335.  
  5336. Hi Mark,
  5337.  
  5338. I'm not sure if I understand your question.  The problem from MR2029 was that in
  5339. certain environments echo cancellers were not being completely disabled.  This
  5340. caused low back channel speeds and increased failure to connect rates.  After
  5341. investigation we discovered that our answer tone levels (the answer tone
  5342. sequence includes a tone to shut off network echo cancellers) were a bit too hot
  5343. for a specific manufacturer's echo canceller.  The resolution was to add a
  5344. configurable parameter to modify the answer tone level, S39.  The default is
  5345. -11db.  We found that by decreasing the tone a few db the problem was resolved.
  5346. Also note, that this usually only applies to long distance calls.  Most carriers
  5347. do not use echo cancellers on local calls.
  5348.  
  5349. Hope this answers your question.  If not, let me know.
  5350.  
  5351. Regards,
  5352. David
  5353.  
  5354.  
  5355.  
  5356.  
  5357. Mark Lemmert <cto@athenet.net> on 04/06/99 05:52:47 PM
  5358.  
  5359. Please respond to usr-tc@lists.xmission.com
  5360.  
  5361. cc:    (David Bachta/MW/US/3Com)
  5362.  
  5363.  
  5364.  
  5365.  
  5366. At 12:07 AM 3/19/99 +0000, you wrote:
  5367. >
  5368. >
  5369. >Hi Curt,
  5370. >
  5371. >Below are the two major issues resolved from 1.2.59 to 1.2.43.
  5372. >
  5373. >Hope this helps.
  5374. >
  5375. >Regards,
  5376. >David
  5377. >
  5378. >MR 2021 Improved V.42 compatibility with slower Win-modem clients.
  5379. >MR 2029 Issue : Failure to connect rates were too high and back channel
  5380. >speeds were too low.  Resolution : The answer tone level was hard-coded
  5381. and too
  5382. >loud
  5383. >to trigger the network echo cancellers in some environments.
  5384.  
  5385. David,
  5386.  
  5387. Regarding MR 2029, what was the actual problem symptom that this caused?
  5388. Thanks.
  5389.  
  5390.  
  5391. -Mark
  5392.  
  5393.  
  5394. Mark Lemmert                       AthEnet Data Exchange
  5395. Chief Technical Officer                  888-919-8700
  5396.  
  5397. -
  5398.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5399.  with "unsubscribe usr-tc" in the body of the message.
  5400.  For information on digests or retrieving files and old messages send
  5401.  "help" to the same address.  Do not use quotes in your message.
  5402.  
  5403.  
  5404.  
  5405.  
  5406.  
  5407.  
  5408.  
  5409.  
  5410. -
  5411.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5412.  with "unsubscribe usr-tc" in the body of the message.
  5413.  For information on digests or retrieving files and old messages send
  5414.  "help" to the same address.  Do not use quotes in your message.
  5415.  
  5416.  
  5417. -------------------------------------------------------------------------------
  5418.  
  5419. From: Paul Farber <farber@admin.f-tech.net>
  5420. Subject: Re: (usr-tc) HiPer operator gone wacko!
  5421. Date: 07 Apr 1999 14:13:16 -0400 (EDT)
  5422.  
  5423. I did that with the 1.2.43 DSP code... but I have not effective way to
  5424. measure the reults.  I will try the 3KB site you previously mentioned.
  5425.  
  5426. Te manual should have a chaper labeled "monitoring" or "Quality
  5427. Assurance".
  5428.  
  5429. Paul D. Farber II
  5430. Farber Technology
  5431. Ph. 570-628-5303
  5432. Fax 570-628-5545
  5433. farber@admin.f-tech.net
  5434.  
  5435. On Wed, 7 Apr 1999, Todd Keister wrote:
  5436.  
  5437. > 
  5438. > 
  5439. > 
  5440. >      Paul:
  5441. > 
  5442. >      The testing I recommend can be as simple as putting new code on only 1 card
  5443. > if all you have is 2 cards.   Sure, some of the larger ISPs have a seperate
  5444. > chassis just for reliability testing, and this is ideal.   But many of our
  5445. > customers can't afford that luxury.   On the other hand, I have had to pick up
  5446. > the pieces when a customer upgraded his Hyper Arc, all 30 of his DSPs on 4
  5447. > chassis, all of his NMCs and the Netserver card on the chassis with Quads, all
  5448. > in 1 day.   With many things upgraded it was not fun trying to guess which item
  5449. > was the "culprit"     A little planing and foresight can go a long way in making
  5450. > an upgrade happen without headaches or difficulties.   If  you have multiple
  5451. > upgrades to undertake, upgrade 1 item and see if it works for 2-3 days first.
  5452. > Then try the next upgrade.  This way we can see if one specific item will not
  5453. > play nice on your network.
  5454. > 
  5455. >           I hope this helps to clarify my prior statements.
  5456. > 
  5457. >           Thanks for using 3Com equipment.
  5458. > 
  5459. >                Todd      ;-}
  5460. > 
  5461. > 
  5462. > 
  5463. > 
  5464. > 
  5465. > 
  5466. > 
  5467. > 
  5468. > Paul Farber <farber@admin.f-tech.net> on 04/06/99 09:54:38 PM
  5469. > 
  5470. > Please respond to usr-tc@lists.xmission.com
  5471. > 
  5472. > To:   usr-tc@lists.xmission.com
  5473. > cc:    (Todd Keister/MW/US/3Com)
  5474. > Subject:  Re: (usr-tc) HiPer operator gone wacko!
  5475. > 
  5476. > 
  5477. > 
  5478. > 
  5479. > Ditto to this.  Having a PRI laying around for testing, plus a chassis is
  5480. > a rather tall order.
  5481. > 
  5482. > Maybe 3Com could post some data from thier lab as a general expectation
  5483. > for others.  I know the reps would LOVE to have me order a unit just for
  5484. > testing.. but that ain't gonna happen.  I have 5 DSP's in service and
  5485. > although I did get another chassis, the only reason was that
  5486. > 2 DSP's are $8500, the entire new rack with support for a year was
  5487. > $10,000.
  5488. > 
  5489. > I know that every phone system is different.  But the release notes ALWAYS
  5490. > have v.90 compatibilaty issues as a resolved issue.. and also as an
  5491. > open one?!?!?!?
  5492. > 
  5493. > BTW.. I am hovering around a 10% call failure rate with the my current
  5494. > installed code.  Will put in 1.2.43 in a day or so to see if I can settle
  5495. > down the failure rates.
  5496. > 
  5497. > That said.. I still think US Robotics is doing all right.... and that we
  5498. > should collectivly firebomb those damned generic modem factories.
  5499. > 
  5500. > Paul D. Farber II
  5501. > Farber Technology
  5502. > Ph. 570-628-5303
  5503. > Fax 570-628-5545
  5504. > farber@admin.f-tech.net
  5505. > 
  5506. > On Tue, 6 Apr 1999, K Mitchell wrote:
  5507. > 
  5508. > > At 04:16 PM 4/6/99 -0500, Todd Keister wrote:
  5509. > > >
  5510. > > >
  5511. > > >     Kirk:
  5512. > > >
  5513. > > >     Since we have to take the calls, we very generally conservative about
  5514. > > >recommending upgrades.  The reason I recommend it is the resolution of the
  5515. > > V.90
  5516. > > >issue, and an increase in stability over 4.1.72-7.   This does NOT however
  5517. > > imply
  5518. > > >you should ever implement an upgrade without testing.   Networks are far more
  5519. > > >individualized than Snowflakes.   What works on one network may have an
  5520. > > issue on
  5521. > > >your network due some specific configuration, or unique grouping of
  5522. > > devices with
  5523. > > >a specific configuration.   The upshot:    ALWAYS TEST NEW CODE!!
  5524. > > PLEASE  (
  5525. > > >pretty please with sugar on top)    We do NOT want to cause an issue on your
  5526. > > >production units.
  5527. > >
  5528. > > My problem is that I have only 2 DSPs in service, and an average of 40-44
  5529. > > modems in use during peak evening times. As much as I'd like to be able to
  5530. > > test new code myself before putting it in front-line service, I just don't
  5531. > > have the extra equipment to test it on. I am forced to use other ISPs
  5532. > > experience as my testing ground because I simply can't afford to have half
  5533. > > of my modems acting buggy.
  5534. > >
  5535. > > >     The other point you raise is equally valid.  Do you have a valid
  5536. > > business
  5537. > > >reason for this upgrade?   If not, then don't upgrade.   The reason I
  5538. > > >recommended this upgrade is most TC owners do want V.90 connectivity (I'm
  5539. > > on the
  5540. > > >ISP Support team so this has been one of our most pressing issues).
  5541. > > However,
  5542. > > >if you are a corporate user, and you have good connectivity, and no current
  5543. > > >issues, then you may not want to upgrade at this time.   When in doubt,
  5544. > > read the
  5545. > > >release notes, and see if there are any issues that affect you, or may affect
  5546. > > >you in the future.
  5547. > >
  5548. > > V90 is an issue for me, but not at the cost of decreased reliability
  5549. > > elsewhere. Having had no RAS experience prior to my HiPer purchase a year
  5550. > > ago, I'm not as well-versed as many on this list as to exactly what
  5551. > > everything does, or all of the ways in which different aspects interact.
  5552. > > There are times when an issue is mentioned in the release notes and I have
  5553. > > no clue as to whether it would affect me or not. I'm busting my @$$b to
  5554. > > learn, but I have to run a business in the meantime, and keep my customers
  5555. > > happy. This list, and the comments of other users, have been my best guide
  5556. > > as to whether or not a particular upgrade is likely to help or hurt my
  5557. > > performance.
  5558. > >
  5559. > > >   If so, then consider an upgrade, but only  after your own
  5560. > > >reliability testing.  We can test new code endlessly, and still not have
  5561. > > tested
  5562. > > >the code in your environment.
  5563. > > >     With all of this said, I still recommend you upgrade to the 4.1.59-6
  5564. > > >combined with the 1.2.43 code.  This code has been out since March 18th
  5565. > > for the
  5566. > > >DSP code, and 4.1.59-6 was released on March 4th.   After an upgrade to this
  5567. > > >code combination, every customer that I have spoken with reported an
  5568. > > increase in
  5569. > > >connectivity, a reduction of V.90 complaints, and an increase in general
  5570. > > system
  5571. > > >stability.    But of course,  "Your Milage May Vary."
  5572. > >
  5573. > > Along this line(did I mention I'm still learning?), how do I "busy-out" a
  5574. > > DSP in order to force all calls to go to the other one so that I can
  5575. > > upgrade them with minimal disruption to users online? One of the things I
  5576. > > have been disappointed in is that all of the HiPer documentation I've seen
  5577. > > assumes that the reader is well-versed in RAS equipment and terminology.
  5578. > > I'm not stupid, and have learned a great deal on my own, but for my $12k or
  5579. > > so would it be too much to ask for a printed document that doesn't assume
  5580. > > that I've got 3 years of NetServer experience under my belt? Not an
  5581. > > "Idiot's Guide", but something that at least told me what the hell effect
  5582. > > things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system.
  5583. > >
  5584. > > >     Please do note that we did release 4.1.59-1 in early February, and this
  5585. > > >code is different from the 4.1.59-6 that was released on March 4th.   To
  5586. > > >determine exactly which code you have on a Harc type:   _show ver   and it
  5587. > > gives
  5588. > > >the exact revision.    Users of the 4.1.59-1 should upgrade to the
  5589. > > 4.1.59-6 to
  5590. > > >resolve an issue with ISDN connectivity.
  5591. > > >
  5592. > > >
  5593. > > >     Hope this answers your questions.
  5594. > >
  5595. > > It clears a few things up. I do appreciate the feedback.
  5596. > >
  5597. > > Kirk
  5598. > >
  5599. > >
  5600. > >
  5601. > >
  5602. > > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  5603. > > Keystone Connect                http://www.keyconn.net
  5604. > > Altoona, PA   814-941-5000         We Unlock the World
  5605. > >
  5606. > >
  5607. > > -
  5608. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5609. > >  with "unsubscribe usr-tc" in the body of the message.
  5610. > >  For information on digests or retrieving files and old messages send
  5611. > >  "help" to the same address.  Do not use quotes in your message.
  5612. > >
  5613. > 
  5614. > 
  5615. > -
  5616. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5617. >  with "unsubscribe usr-tc" in the body of the message.
  5618. >  For information on digests or retrieving files and old messages send
  5619. >  "help" to the same address.  Do not use quotes in your message.
  5620. > 
  5621. > 
  5622. > 
  5623. > 
  5624. > 
  5625. > 
  5626. > 
  5627. > 
  5628. > -
  5629. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5630. >  with "unsubscribe usr-tc" in the body of the message.
  5631. >  For information on digests or retrieving files and old messages send
  5632. >  "help" to the same address.  Do not use quotes in your message.
  5633. > 
  5634.  
  5635.  
  5636. -
  5637.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5638.  with "unsubscribe usr-tc" in the body of the message.
  5639.  For information on digests or retrieving files and old messages send
  5640.  "help" to the same address.  Do not use quotes in your message.
  5641.  
  5642.  
  5643. -------------------------------------------------------------------------------
  5644.  
  5645. From: K Mitchell <mitch@keyconn.net>
  5646. Subject: Re: (usr-tc) HiPer operator gone wacko!
  5647. Date: 07 Apr 1999 15:21:12 -0400
  5648.  
  5649. At 09:24 AM 4/7/99 -0500, Todd Keister wrote:
  5650. >
  5651. >     If you want to know how to busy modems on a DSP card, without
  5652. disconnecting
  5653. >users currently connected you need to SOFT BUSY the modems.  Rather than
  5654. answer
  5655. >your question here in this forum, I wish to send you to the 3KB knowledgebase
  5656. >for this solution.
  5657.  
  5658. What's the alternative for PRI?
  5659.  
  5660.  
  5661.  
  5662.  
  5663. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  5664. Keystone Connect                http://www.keyconn.net
  5665. Altoona, PA   814-941-5000         We Unlock the World
  5666.  
  5667.  
  5668. -
  5669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5670.  with "unsubscribe usr-tc" in the body of the message.
  5671.  For information on digests or retrieving files and old messages send
  5672.  "help" to the same address.  Do not use quotes in your message.
  5673.  
  5674.  
  5675. -------------------------------------------------------------------------------
  5676.  
  5677. From: Jeff Mcadams <jeffm@iglou.com>
  5678. Subject: Re: (usr-tc) HiPer operator gone wacko!
  5679. Date: 07 Apr 1999 15:59:19 -0400 (EDT)
  5680.  
  5681. Thus spake K Mitchell
  5682. >At 09:24 AM 4/7/99 -0500, Todd Keister wrote:
  5683. >>     If you want to know how to busy modems on a DSP card, without
  5684. >>disconnecting users currently connected you need to SOFT BUSY the
  5685. >>modems.  Rather than answer your question here in this forum, I wish
  5686. >>to send you to the 3KB knowledgebase for this solution.
  5687.  
  5688. >What's the alternative for PRI?
  5689.  
  5690. If you're got a translation type that supports service messages (note,
  5691. NI-2 *doesn't*) its "localoutofservice".
  5692. -- 
  5693. Jeff McAdams                            Email: jeffm@iglou.com
  5694. Head Network Administrator              Voice: (502) 966-3848
  5695. IgLou Internet Services                        (800) 436-4456
  5696.  
  5697. -
  5698.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5699.  with "unsubscribe usr-tc" in the body of the message.
  5700.  For information on digests or retrieving files and old messages send
  5701.  "help" to the same address.  Do not use quotes in your message.
  5702.  
  5703.  
  5704. -------------------------------------------------------------------------------
  5705.  
  5706. From: "Randy McMillan" <randy@pacinfo.com>
  5707. Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
  5708. Date: 07 Apr 1999 13:25:29 -0700
  5709.  
  5710. The T1's are provisioned b8zs/esf.  The analog calls originate and terminate
  5711. in the same switch.  The T1 calls terminate in a different switch, but I
  5712. have been told that it is using 64k clear channel between them.
  5713. So, if that is true, does robbed bit signaling affect v.34 more than v.90?
  5714. Where does the digital pad get introduced, in one of the switches or on the
  5715. T1 line?  Thanks again for the info.
  5716.  
  5717. Randy McMillan
  5718.  
  5719. >
  5720. >
  5721. > Randy McMillan wrote:
  5722. > >
  5723. > > We are converting our modem pool to all digital lines with TC chassis
  5724. with
  5725. > > quad modems and hiper ARC cards.  Some people are connecting slower on
  5726. the
  5727. > > new lines than they did on the analog lines.  One customer who got 33.6
  5728. or
  5729. > > 31.2 speeds is now getting 28.8 or 26.4 speeds (with a zoom 2919 with
  5730. > > current zoom firmware).  He doesn't seem to be able to do v.90 protocol.
  5731. The
  5732. > > T1 lines seem to be clean as I can connect at 50k+ using v.90.  If I
  5733. disable
  5734. > > v.90 on my sportster, I get 28.8 downstream and 33.6 upstream, but not
  5735. 33.6
  5736. > > down.  Of course customers only see the downstream connect speed.
  5737. > > Does anybody know of any reasons why the v.34 speeds would be slower
  5738. when
  5739. > > terminated here on a T1 as opposed to a pots line on the same chassis?
  5740. Or
  5741. > > in regard to my sportster, is there anything in disabling v.90 that
  5742. would
  5743. > > disable the 31.2 & 33.6 speeds?  Any info on this would be appreciated..
  5744. >
  5745. > There could be two issues at work. The first one is that the call is
  5746. taking a
  5747. > different path now that it is coming in on a CH DS-1. The second is that
  5748. if calls are
  5749. > not originating on the same switch you are terminating on, and the PSTN is
  5750. not 64k
  5751. > clear channel, there is a possibility of added noise in the phone call
  5752. because of
  5753. > Robed Bit Signaling(RBS) - every time the call hops between switches,
  5754. usually the
  5755. > switch picks a new bit to rob from the phone call. If you have your DS-1's
  5756. provisioned
  5757. > with AMI/SF signaling, you might have two different bits robbed if the
  5758. call is
  5759. > originating on a neighboring switch, where before when things were analog
  5760. there might
  5761. > have only been one bit robbed. If you're on the same switch as the caller,
  5762. you might
  5763. > have one robbed bit now where you never had one in the past (the switch
  5764. operated 64k
  5765. > clear internally). These robed bits should not stop a customer from
  5766. getting a V.90
  5767. > connection, unless the customer loop is of poor quality to begin with. But
  5768. you will
  5769. > see reduced connect speeds because of the added noise.
  5770. >
  5771. > The best way to boot connect speeds is to go ISDN PRI, but that is
  5772. generally more
  5773. > expensive than CH DS-1s and you pay a penalty of loosing one modem per
  5774. span. But you
  5775. > get back to 64k clear channel with no conversions and usually no padding.
  5776. I saw a
  5777. > boost when a telco I am connected to switched me from AMI/D4 to B8ZS/D5,
  5778. and another
  5779. > boost when I switched my circuits to ISDN PRI. Unfortunatly most rural
  5780. service areas
  5781. > do not offer ISDN PRI service. You defiantly should have your CH DS-1's
  5782. provisioned as
  5783. > B8ZS/ESF if the switch is capable of it.
  5784. >
  5785. > There is also a possibility that they have a digital pad misconfigured on
  5786. your CH
  5787. > DS-1, but trying to convince a telco to change the pad type or eliminate
  5788. the pad can
  5789. > be next to impossible.
  5790. >
  5791. > -Ron
  5792. > GLISnet, Inc.
  5793. > +1 810/939.9885
  5794. >
  5795. > -
  5796. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5797. >  with "unsubscribe usr-tc" in the body of the message.
  5798. >  For information on digests or retrieving files and old messages send
  5799. >  "help" to the same address.  Do not use quotes in your message.
  5800. >
  5801. >
  5802.  
  5803.  
  5804. -
  5805.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5806.  with "unsubscribe usr-tc" in the body of the message.
  5807.  For information on digests or retrieving files and old messages send
  5808.  "help" to the same address.  Do not use quotes in your message.
  5809.  
  5810.  
  5811. -------------------------------------------------------------------------------
  5812.  
  5813. From: GTI x2 Tech <x2@apollo.gti.net>
  5814. Subject: (usr-tc) ISDN router probs. since Hiper Upgrade
  5815. Date: 07 Apr 1999 16:52:56 -0400 (EDT)
  5816.  
  5817.  
  5818.  
  5819. I have 2 customers with:
  5820.  
  5821. Cisco 766 ISDN router
  5822. Ascend Pipeline 75
  5823.  
  5824.  
  5825. Who connected fine before I upgraded now cannot connect at all.  
  5826.  
  5827. My PPP settings are:
  5828.  
  5829. PPP AUTHENTICATION
  5830. DIAL_IN Users Authenticate:               ANY              
  5831. PPP Authentication Preference:            PAP
  5832. System Transmit Authentication Name:      HiPer
  5833.  
  5834. PPP offloading:                           ENABLED  
  5835.  
  5836. CCP will be attempted for call type(s):   DIGITAL
  5837.                                           UNCOMPRESSED_ANALOG    
  5838.  
  5839.  
  5840.  
  5841.  
  5842. I told them to set auth to PAP and it doesnt work.  Ive tried to debug
  5843. with no success.
  5844.  
  5845. Is there any way to see debug output like it was on the NetServer card?
  5846. (i.e. set debug 0x51).  Ive tried PPP monitor and Radius monitor and it
  5847. doesnt tell me anything (access-reject).
  5848.  
  5849. I am going to loose these customers unless I can figure out whats wrong.
  5850.  
  5851. Thanks,
  5852.  
  5853. John
  5854.  
  5855.  
  5856.  
  5857. Addl debug info follows:
  5858.  
  5859.  
  5860.    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  5861.   199.171.x.x     1645     199.171.x.x      1645    4 Access-Request
  5862.  
  5863.                      User-Name : gbareppp
  5864.                  User-Password : xxxxxxxxxx
  5865.                 NAS-IP-Address : 199.171.x.x
  5866.                       NAS-Port : 3329
  5867.                Acct-Session-Id : 218119937
  5868.                Interface-Index : 4585
  5869.                   Service-Type : 2
  5870.                Framed-Protocol : PPP
  5871.      Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38
  5872.               Chasis-Call-Slot : 14
  5873.               Chasis-Call-Span : 1
  5874.            Chasis-Call-Channel : 1
  5875.             Calling-Station-Id : 9086040517
  5876.              Called-Station-Id : 6052881
  5877.                  NAS-Port-Type : 2
  5878.  
  5879.    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  5880.     199.171.x.x     1645   199.171.x.x      1645    4 Access-Accept
  5881.  
  5882.                   Service-Type : 2
  5883.                Framed-Protocol : PPP
  5884.              Framed-IP-Address : 208.216.x.x
  5885.              Framed-IP-Netmask : 255.255.255.240
  5886.                   Framed-Route : 208.216.x.x/28 208.216.x.x 1
  5887.             Framed-Compression : 0
  5888.                   Idle-Timeout : 1200
  5889.                Session-Timeout : 18000
  5890.                     Port-Limit : 2
  5891.                     Framed-MTU : 1500
  5892.  
  5893.    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  5894.   199.171.x.x     1645     199.171.x.x      1645    5 Access-Request
  5895.  
  5896.                      User-Name : gbareppp
  5897.                  User-Password : xxxxxxxxxx
  5898.                 NAS-IP-Address : 199.171.x.x
  5899.                       NAS-Port : 3329
  5900.                Acct-Session-Id : 218119937
  5901.                Interface-Index : 4585
  5902.                   Service-Type : 2
  5903.                Framed-Protocol : PPP
  5904.      Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38
  5905.               Chasis-Call-Slot : 14
  5906.               Chasis-Call-Span : 1
  5907.            Chasis-Call-Channel : 1
  5908.             Calling-Station-Id : 9086040517
  5909.              Called-Station-Id : 6052881
  5910.                  NAS-Port-Type : 2
  5911.  
  5912.    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  5913.     199.171.x.x     1645   199.171.x.x      1645    5 Access-Reject
  5914.  
  5915.  
  5916.  
  5917. -
  5918.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5919.  with "unsubscribe usr-tc" in the body of the message.
  5920.  For information on digests or retrieving files and old messages send
  5921.  "help" to the same address.  Do not use quotes in your message.
  5922.  
  5923.  
  5924. -------------------------------------------------------------------------------
  5925.  
  5926. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  5927. Subject: Re: (usr-tc) HiPer operator gone wacko!
  5928. Date: 07 Apr 1999 15:57:29 -0500
  5929.  
  5930.  
  5931.  
  5932.      Kirk:
  5933.  
  5934.  
  5935.      Actually the same procedure works for either T1 or PRI.   The reviewer for
  5936. my team believed that this process would not work for a DSP connected to a PRI
  5937. span, but they were mistaken.  I have just confirmed that this process works by
  5938. testing this on a DSP card connected to a PRI span.  I also got the explanation,
  5939. from one of our Network Engineers.  This process works because the DSP card
  5940. places a "go busy" command into the modems command que to be performed when the
  5941. current task completes.  This process is therefore independent of the span type
  5942. (either T1 or PRI**).
  5943.  
  5944.      The solution in 3KB has updated to reflect this information.
  5945.  
  5946.  
  5947.           Todd      ;-}
  5948.  
  5949.  
  5950.  
  5951.  
  5952.  
  5953.           **    I don't work with the Eurpean E1 spans - so I don't know how
  5954. these work.
  5955.  
  5956.  
  5957.  
  5958.  
  5959.  
  5960.  
  5961.  
  5962. K Mitchell <mitch@keyconn.net> on 04/07/99 02:21:12 PM
  5963.  
  5964. Please respond to usr-tc@lists.xmission.com
  5965.  
  5966. cc:    (Todd Keister/MW/US/3Com)
  5967.  
  5968.  
  5969.  
  5970.  
  5971. At 09:24 AM 4/7/99 -0500, Todd Keister wrote:
  5972. >
  5973. >     If you want to know how to busy modems on a DSP card, without
  5974. disconnecting
  5975. >users currently connected you need to SOFT BUSY the modems.  Rather than
  5976. answer
  5977. >your question here in this forum, I wish to send you to the 3KB knowledgebase
  5978. >for this solution.
  5979.  
  5980. What's the alternative for PRI?
  5981.  
  5982.  
  5983.  
  5984.  
  5985. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  5986. Keystone Connect                http://www.keyconn.net
  5987. Altoona, PA   814-941-5000         We Unlock the World
  5988.  
  5989.  
  5990. -
  5991.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5992.  with "unsubscribe usr-tc" in the body of the message.
  5993.  For information on digests or retrieving files and old messages send
  5994.  "help" to the same address.  Do not use quotes in your message.
  5995.  
  5996.  
  5997.  
  5998.  
  5999.  
  6000.  
  6001.  
  6002.  
  6003. -
  6004.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6005.  with "unsubscribe usr-tc" in the body of the message.
  6006.  For information on digests or retrieving files and old messages send
  6007.  "help" to the same address.  Do not use quotes in your message.
  6008.  
  6009.  
  6010. -------------------------------------------------------------------------------
  6011.  
  6012. From: David Bolen <db3l@ans.net>
  6013. Subject: Re: (usr-tc) HiPer operator gone wacko!
  6014. Date: 07 Apr 1999 17:01:32 EDT
  6015.  
  6016. "Todd Keister" <Todd_Keister@mw.3com.com> writes:
  6017.  
  6018. >      Actually the same procedure works for either T1 or PRI.  The
  6019. > reviewer for my team believed that this process would not work for a
  6020. > DSP connected to a PRI span, but they were mistaken.
  6021.  
  6022. Well, only as long as the PRI span supports service messages.  If it
  6023. doesn't (e.g., NI-2 mode[*] or a custom switch type without service
  6024. messages enabled on the telco end), then you can't do this.  I mean,
  6025. the function will be accepted and the card will try to take the
  6026. channel out of service, but the remote end will ignore that and you'll
  6027. end up losing calls that try to use that channel anyway.
  6028.  
  6029. Note that even channelized T1 configurations can have problems taking
  6030. a channel out of service in some configurations (for example, ground
  6031. start into older channel banks).  But that's much less common.
  6032.  
  6033. Oh, and just for clarity - it isn't the "modems" that are being busied
  6034. out or removed from service - it's the DS0 channels (or B channels for
  6035. PRI spans).  True, in most default configurations there is a one to
  6036. one fixed mapping, but the actual busy/service operation is taking
  6037. place on the span side of things, not on the modem.  The command to
  6038. request an out of service/busy operation is made to the DS0 entity.
  6039. In fact, unlike the quad cards, you can't ask a HiperDSP modem to busy
  6040. out or go out of service (an "offHook" command to a quad modem).
  6041.  
  6042. >           **    I don't work with the Eurpean E1 spans - so I don't know how
  6043. > these work.
  6044.  
  6045. They don't, as far as this goes, at least not E1-PRI.  I'm not aware
  6046. of any European switch types that support the equivalent to the
  6047. service messages of domestic switch types at this time.
  6048.  
  6049. -- David
  6050.  
  6051. [*] Recently I think we've found some 5ESS switches with late enough
  6052. software that are willing to deal with service messages even in NI-2
  6053. mode.
  6054.  
  6055. /-----------------------------------------------------------------------\
  6056.  \               David Bolen              \  Internet: db3l@ans.net    /
  6057.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  6058.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  6059. \-----------------------------------------------------------------------/
  6060.  
  6061. -
  6062.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6063.  with "unsubscribe usr-tc" in the body of the message.
  6064.  For information on digests or retrieving files and old messages send
  6065.  "help" to the same address.  Do not use quotes in your message.
  6066.  
  6067.  
  6068. -------------------------------------------------------------------------------
  6069.  
  6070. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  6071. Subject: Re: (usr-tc) HiPer operator gone wacko!
  6072. Date: 07 Apr 1999 16:15:42 -0500
  6073.  
  6074.  
  6075.  
  6076.      Thank you for the further clarification David.
  6077.  
  6078.  
  6079.           Todd ;-}
  6080.  
  6081.  
  6082.  
  6083.  
  6084.  
  6085.  
  6086.  
  6087. David Bolen <db3l@ans.net> on 04/07/99 04:01:32 PM
  6088.  
  6089. Please respond to usr-tc@lists.xmission.com
  6090.  
  6091. cc:    (Todd Keister/MW/US/3Com)
  6092.  
  6093.  
  6094.  
  6095.  
  6096. "Todd Keister" <Todd_Keister@mw.3com.com> writes:
  6097.  
  6098. >      Actually the same procedure works for either T1 or PRI.  The
  6099. > reviewer for my team believed that this process would not work for a
  6100. > DSP connected to a PRI span, but they were mistaken.
  6101.  
  6102. Well, only as long as the PRI span supports service messages.  If it
  6103. doesn't (e.g., NI-2 mode[*] or a custom switch type without service
  6104. messages enabled on the telco end), then you can't do this.  I mean,
  6105. the function will be accepted and the card will try to take the
  6106. channel out of service, but the remote end will ignore that and you'll
  6107. end up losing calls that try to use that channel anyway.
  6108.  
  6109. Note that even channelized T1 configurations can have problems taking
  6110. a channel out of service in some configurations (for example, ground
  6111. start into older channel banks).  But that's much less common.
  6112.  
  6113. Oh, and just for clarity - it isn't the "modems" that are being busied
  6114. out or removed from service - it's the DS0 channels (or B channels for
  6115. PRI spans).  True, in most default configurations there is a one to
  6116. one fixed mapping, but the actual busy/service operation is taking
  6117. place on the span side of things, not on the modem.  The command to
  6118. request an out of service/busy operation is made to the DS0 entity.
  6119. In fact, unlike the quad cards, you can't ask a HiperDSP modem to busy
  6120. out or go out of service (an "offHook" command to a quad modem).
  6121.  
  6122. >           **    I don't work with the Eurpean E1 spans - so I don't know how
  6123. > these work.
  6124.  
  6125. They don't, as far as this goes, at least not E1-PRI.  I'm not aware
  6126. of any European switch types that support the equivalent to the
  6127. service messages of domestic switch types at this time.
  6128.  
  6129. -- David
  6130.  
  6131. [*] Recently I think we've found some 5ESS switches with late enough
  6132. software that are willing to deal with service messages even in NI-2
  6133. mode.
  6134.  
  6135. /-----------------------------------------------------------------------\
  6136.  \               David Bolen              \  Internet: db3l@ans.net    /
  6137.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  6138.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  6139. \-----------------------------------------------------------------------/
  6140.  
  6141. -
  6142.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6143.  with "unsubscribe usr-tc" in the body of the message.
  6144.  For information on digests or retrieving files and old messages send
  6145.  "help" to the same address.  Do not use quotes in your message.
  6146.  
  6147.  
  6148.  
  6149.  
  6150.  
  6151.  
  6152.  
  6153.  
  6154. -
  6155.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6156.  with "unsubscribe usr-tc" in the body of the message.
  6157.  For information on digests or retrieving files and old messages send
  6158.  "help" to the same address.  Do not use quotes in your message.
  6159.  
  6160.  
  6161. -------------------------------------------------------------------------------
  6162.  
  6163. From: K Mitchell <mitch@keyconn.net>
  6164. Subject: Re: (usr-tc) HiPer operator gone wacko!
  6165. Date: 07 Apr 1999 17:17:52 -0400
  6166.  
  6167. At 05:01 PM 4/7/99 EDT, you wrote:
  6168. >"Todd Keister" <Todd_Keister@mw.3com.com> writes:
  6169. >
  6170. >>      Actually the same procedure works for either T1 or PRI.  The
  6171. >> reviewer for my team believed that this process would not work for a
  6172. >> DSP connected to a PRI span, but they were mistaken.
  6173. >
  6174. >Well, only as long as the PRI span supports service messages.  If it
  6175. >doesn't (e.g., NI-2 mode[*] or a custom switch type without service
  6176. >messages enabled on the telco end), then you can't do this.  I mean,
  6177. >the function will be accepted and the card will try to take the
  6178. >channel out of service, but the remote end will ignore that and you'll
  6179. >end up losing calls that try to use that channel anyway.
  6180.  
  6181. Ok, next stupid question...How do I find out if my PRI span supports
  6182. service messages? This is the exact question I entered in 3KB and got no
  6183. useful answer.
  6184.  
  6185. Thanks again,
  6186. Kirk
  6187.  
  6188.  
  6189.  
  6190. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  6191. Keystone Connect                http://www.keyconn.net
  6192. Altoona, PA   814-941-5000         We Unlock the World
  6193.  
  6194.  
  6195. -
  6196.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6197.  with "unsubscribe usr-tc" in the body of the message.
  6198.  For information on digests or retrieving files and old messages send
  6199.  "help" to the same address.  Do not use quotes in your message.
  6200.  
  6201.  
  6202. -------------------------------------------------------------------------------
  6203.  
  6204. From: David Bolen <db3l@ans.net>
  6205. Subject: Re: (usr-tc) HiPer operator gone wacko!
  6206. Date: 07 Apr 1999 17:40:25 EDT
  6207.  
  6208. K Mitchell <mitch@keyconn.net> writes:
  6209.  
  6210. > Ok, next stupid question...How do I find out if my PRI span supports
  6211. > service messages? This is the exact question I entered in 3KB and got no
  6212. > useful answer.
  6213.  
  6214. One approach is just to verify it with your circuit provider.  :-)
  6215.  
  6216. Another approach if you have more than one span in a hunt group is to
  6217. take an entire span out of service and see if calls flow to the next
  6218. span (or if a random/round robin distribution, do repeated test calls
  6219. not show any busy or problem delivering the call), and idling the span
  6220. lets calls flow back onto it.
  6221.  
  6222. A less intrusive (except for a moment) approach that we use requires
  6223. counters in the HiperDSP code to track service messages sent and
  6224. received.  I'll include below a small procedure we use, but I can't
  6225. remember if the counters in the below procedure were added just to an
  6226. ANS-specific build or if they made the mainline.  If they are present
  6227. on your display output, you can use them.  The gist of it is you
  6228. attempt to take something in and out of service and ensure that the
  6229. requests were ack'd by the remote end of he circuit.
  6230.  
  6231.       - - - - - - - - - - - - - - - - - - - - - - - - -
  6232.  
  6233. (...)
  6234.  
  6235. Unlike the Dual-PRI card, testing service messages does not require
  6236. changing this behavior and then observing how a channel reacts to an
  6237. attempted service change.  Instead, the HDM card keeps a continuous
  6238. count of service messages sent and received, and all you need to do is
  6239. take a baseline of those values, perform the service operations, and
  6240. then verify that both the sent and received messages remained in
  6241. sync. 
  6242.  
  6243. One thing in common with the Dual-PRI card is that this additional
  6244. service message information is only available from the console, as
  6245. part of the span statistics.  So, getting on the console you can:
  6246.  
  6247.    > chdev span
  6248.    span1> display spnstats
  6249.       Span1 Near Time Elapsed is:               87 seconds
  6250.       Span1 Near Valid Intervals is:            96
  6251.       Span1 Line Status is:
  6252.      NO ALARM          = TRUE
  6253.      RCV FAR END LOF   = FALSE
  6254.  
  6255.       (rest of normal stats)
  6256.  
  6257.   ==> Span1 Service Messages Sent:               0 
  6258.   ==> Span1 Service Ack Messages Received:       0 
  6259.  
  6260.  
  6261. Although in theory if the span is working properly these values will
  6262. either be in sync or out of sync, I think it is best that you first
  6263. get current values from the card, and then always base the results of
  6264. the test on an offset from those values.
  6265.  
  6266. For example, in the above case, this card hasn't issued any service
  6267. messages yet.  However, if I know take a single channel locally out of
  6268. service and then place it back in service (and this can be done via
  6269. any normal operation such as through the NMC card with usr), I now
  6270. have at the bottom of the above screen:
  6271.  
  6272.       Span1 Service Messages Sent:               2 
  6273.       Span1 Service Ack Messages Received:       2 
  6274.  
  6275. This tells us that I sent two messages (one to take it out of service,
  6276. and one to put it back in), and that two acknowledgements were
  6277. received.  This indicates that service messages are functioning on
  6278. that span.  If they weren't functioning properly, you would see 2
  6279. messages sent, but 0 acks (or 2 and 0 respectively on top of whatever
  6280. values were previously in those counters).
  6281.  
  6282. The counters cannot be cleared but start counting from the time the
  6283. card has booted.
  6284.       - - - - - - - - - - - - - - - - - - - - - - - - -
  6285.  
  6286. -- David
  6287.  
  6288. /-----------------------------------------------------------------------\
  6289.  \               David Bolen              \  Internet: db3l@ans.net    /
  6290.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  6291.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  6292. \-----------------------------------------------------------------------/
  6293.  
  6294. -
  6295.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6296.  with "unsubscribe usr-tc" in the body of the message.
  6297.  For information on digests or retrieving files and old messages send
  6298.  "help" to the same address.  Do not use quotes in your message.
  6299.  
  6300.  
  6301. -------------------------------------------------------------------------------
  6302.  
  6303. From: "David Bachta" <David_Bachta@mw.3com.com>
  6304. Subject: Re: (usr-tc) HiPer operator gone wacko!
  6305. Date: 07 Apr 1999 17:28:00 -0500
  6306.  
  6307.  
  6308.  
  6309. Hi David, Hi Kirk,
  6310.  
  6311. The service message counters David described below will be available in the
  6312. 2.0.x GA Hiper DSP code.  They are not available in the current 1.2.x GA code.
  6313.  
  6314. Hope this helps.
  6315.  
  6316. Regards,
  6317. David
  6318.  
  6319. >A less intrusive (except for a moment) approach that we use requires
  6320. >counters in the HiperDSP code to track service messages sent and
  6321. >received.  I'll include below a small procedure we use, but I can't
  6322. >remember if the counters in the below procedure were added just to an
  6323. >ANS-specific build or if they made the mainline.  If they are present
  6324. >on your display output, you can use them.  The gist of it is you
  6325. >attempt to take something in and out of service and ensure that the
  6326. >requests were ack'd by the remote end of he circuit.
  6327.  
  6328. snip
  6329.  
  6330. >   > chdev span
  6331. >   span1> display spnstats
  6332. >      Span1 Near Time Elapsed is:               87 seconds
  6333. >      Span1 Near Valid Intervals is:            96
  6334. >      Span1 Line Status is:
  6335. >     NO ALARM          = TRUE
  6336. >     RCV FAR END LOF   = FALSE
  6337. >
  6338. >      (rest of normal stats)
  6339. >
  6340. >  ==> Span1 Service Messages Sent:               0
  6341. >  ==> Span1 Service Ack Messages Received:       0
  6342. >
  6343.  
  6344. snip
  6345.  
  6346.  
  6347.  
  6348.  
  6349.  
  6350. -
  6351.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6352.  with "unsubscribe usr-tc" in the body of the message.
  6353.  For information on digests or retrieving files and old messages send
  6354.  "help" to the same address.  Do not use quotes in your message.
  6355.  
  6356.  
  6357. -------------------------------------------------------------------------------
  6358.  
  6359. From: Brian <signal@shreve.net>
  6360. Subject: Re: (usr-tc) ISDN router probs. since Hiper Upgrade
  6361. Date: 07 Apr 1999 19:02:28 -0500 (CDT)
  6362.  
  6363. On Wed, 7 Apr 1999, GTI x2 Tech wrote:
  6364.  
  6365. > 
  6366. > 
  6367. > I have 2 customers with:
  6368. > 
  6369. > Cisco 766 ISDN router
  6370. > Ascend Pipeline 75
  6371.  
  6372. Is stack enabled on the customers equipment?  did you try to disable?
  6373.  
  6374.  
  6375. > 
  6376. > 
  6377. > Who connected fine before I upgraded now cannot connect at all.  
  6378. > 
  6379. > My PPP settings are:
  6380. > 
  6381. > PPP AUTHENTICATION
  6382. > DIAL_IN Users Authenticate:               ANY              
  6383. > PPP Authentication Preference:            PAP
  6384. > System Transmit Authentication Name:      HiPer
  6385. > 
  6386. > PPP offloading:                           ENABLED  
  6387. > 
  6388. > CCP will be attempted for call type(s):   DIGITAL
  6389. >                                           UNCOMPRESSED_ANALOG    
  6390. > 
  6391. > 
  6392. > 
  6393. > 
  6394. > I told them to set auth to PAP and it doesnt work.  Ive tried to debug
  6395. > with no success.
  6396. > 
  6397. > Is there any way to see debug output like it was on the NetServer card?
  6398. > (i.e. set debug 0x51).  Ive tried PPP monitor and Radius monitor and it
  6399. > doesnt tell me anything (access-reject).
  6400. > 
  6401. > I am going to loose these customers unless I can figure out whats wrong.
  6402. > 
  6403. > Thanks,
  6404. > 
  6405. > John
  6406. > 
  6407. > 
  6408. > 
  6409. > Addl debug info follows:
  6410. > 
  6411. > 
  6412. > ---------------------------------------------------------------------
  6413. >    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  6414. > ---------------------------------------------------------------------
  6415. >   199.171.x.x     1645     199.171.x.x      1645    4 Access-Request
  6416. > ---------------------------------------------------------------------
  6417. > 
  6418. >                      User-Name : gbareppp
  6419. >                  User-Password : xxxxxxxxxx
  6420. >                 NAS-IP-Address : 199.171.x.x
  6421. >                       NAS-Port : 3329
  6422. >                Acct-Session-Id : 218119937
  6423. >                Interface-Index : 4585
  6424. >                   Service-Type : 2
  6425. >                Framed-Protocol : PPP
  6426. >      Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38
  6427. >               Chasis-Call-Slot : 14
  6428. >               Chasis-Call-Span : 1
  6429. >            Chasis-Call-Channel : 1
  6430. >             Calling-Station-Id : 9086040517
  6431. >              Called-Station-Id : 6052881
  6432. >                  NAS-Port-Type : 2
  6433. > 
  6434. > ---------------------------------------------------------------------
  6435. >    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  6436. > ---------------------------------------------------------------------
  6437. >     199.171.x.x     1645   199.171.x.x      1645    4 Access-Accept
  6438. > ---------------------------------------------------------------------
  6439. > 
  6440. >                   Service-Type : 2
  6441. >                Framed-Protocol : PPP
  6442. >              Framed-IP-Address : 208.216.x.x
  6443. >              Framed-IP-Netmask : 255.255.255.240
  6444. >                   Framed-Route : 208.216.x.x/28 208.216.x.x 1
  6445. >             Framed-Compression : 0
  6446. >                   Idle-Timeout : 1200
  6447. >                Session-Timeout : 18000
  6448. >                     Port-Limit : 2
  6449. >                     Framed-MTU : 1500
  6450. > 
  6451. > ---------------------------------------------------------------------
  6452. >    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  6453. > ---------------------------------------------------------------------
  6454. >   199.171.x.x     1645     199.171.x.x      1645    5 Access-Request
  6455. > ---------------------------------------------------------------------
  6456. > 
  6457. >                      User-Name : gbareppp
  6458. >                  User-Password : xxxxxxxxxx
  6459. >                 NAS-IP-Address : 199.171.x.x
  6460. >                       NAS-Port : 3329
  6461. >                Acct-Session-Id : 218119937
  6462. >                Interface-Index : 4585
  6463. >                   Service-Type : 2
  6464. >                Framed-Protocol : PPP
  6465. >      Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38
  6466. >               Chasis-Call-Slot : 14
  6467. >               Chasis-Call-Span : 1
  6468. >            Chasis-Call-Channel : 1
  6469. >             Calling-Station-Id : 9086040517
  6470. >              Called-Station-Id : 6052881
  6471. >                  NAS-Port-Type : 2
  6472. > 
  6473. > ---------------------------------------------------------------------
  6474. >    Source-IP         Src-Port Destination-IP Dest-Port Id Packet-Type
  6475. > ---------------------------------------------------------------------
  6476. >     199.171.x.x     1645   199.171.x.x      1645    5 Access-Reject
  6477. > ---------------------------------------------------------------------
  6478. > 
  6479. > 
  6480. > 
  6481. > -
  6482. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6483. >  with "unsubscribe usr-tc" in the body of the message.
  6484. >  For information on digests or retrieving files and old messages send
  6485. >  "help" to the same address.  Do not use quotes in your message.
  6486. > 
  6487.  
  6488. Brian Feeny (BF304)     signal@shreve.net   
  6489. 318-222-2638 x 109    http://www.shreve.net/~signal      
  6490. Network Administrator   ShreveNet Inc. (ASN 11881)           
  6491.  
  6492.  
  6493. -
  6494.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6495.  with "unsubscribe usr-tc" in the body of the message.
  6496.  For information on digests or retrieving files and old messages send
  6497.  "help" to the same address.  Do not use quotes in your message.
  6498.  
  6499.  
  6500. -------------------------------------------------------------------------------
  6501.  
  6502. From: Corneliu Rudeanu <rudy@dntis.ro>
  6503. Subject: (usr-tc) Slot ownerwhip
  6504. Date: 08 Apr 1999 03:50:13 +0300 (EEST)
  6505.  
  6506.  
  6507.  
  6508. I am facing the following problem:
  6509.  
  6510. HiPer>> list chassis
  6511. Slot    Owner        Description                      Ports   Type
  6512. 1       NO           Primary Rate T1 NAC              0       DYNAMIC
  6513. 2       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6514. 3       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6515. 4       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6516. 5       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6517. 6       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6518. 7       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6519. 8       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6520. 9       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6521. 10      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6522. 11      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6523. 12      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6524. 13      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6525. 14      NO           Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6526. 15      NO           Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6527. 16      NO           HiPer Access Router NAC          0       DYNAMIC
  6528. HiPer>>
  6529.  
  6530. In the User Manual for HiperArc it says that under special circumstances
  6531. (multiple HARCs) you can _statically_ assign the modems for load
  6532. balancing. I guess (read "hope") that this way (using set chassis slot) I
  6533. can take the ownership for slots 14 and 15. 
  6534.  
  6535. Yet, by default, the NMC should assign this ownership and that should work
  6536. by all means.
  6537.  
  6538. Am I missing something? Is there any way I can find 'who owns' those
  6539. slots?
  6540.  
  6541. Any advice appreciated.
  6542.  
  6543. Corneliu Rudeanu
  6544.  
  6545.  
  6546. -
  6547.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6548.  with "unsubscribe usr-tc" in the body of the message.
  6549.  For information on digests or retrieving files and old messages send
  6550.  "help" to the same address.  Do not use quotes in your message.
  6551.  
  6552.  
  6553. -------------------------------------------------------------------------------
  6554.  
  6555. From: Ronald Kushner <ron@glis.net>
  6556. Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
  6557. Date: 07 Apr 1999 20:57:11 -0400
  6558.  
  6559.  
  6560.  
  6561. Randy McMillan wrote:
  6562. > 
  6563. > The T1's are provisioned b8zs/esf.  The analog calls originate and terminate
  6564. > in the same switch.  The T1 calls terminate in a different switch, but I
  6565. > have been told that it is using 64k clear channel between them.
  6566. > So, if that is true, does robbed bit signaling affect v.34 more than v.90?
  6567. > Where does the digital pad get introduced, in one of the switches or on the
  6568. > T1 line?  Thanks again for the info.
  6569.  
  6570. Sounds like it might be a misconfigured digital pad then, is this through a CLEC?
  6571.  
  6572. If it's all SS7 B8ZS/D5, the signaling is via an X25 network and does not affect call
  6573. quality. There should be no robbed bits.
  6574.  
  6575. I ran into problems with digital pads and gain problems with CLECs. That might be the
  6576. first place to look. I have seen 54666  and 56000 connections with 33,600 on the
  6577. backchannel since they fixed all my padding issues. (I thought these things were speed
  6578. limited to 53kbps!). We tried it without a digital pad, but that was worse than having
  6579. the wrong digital pad on the line. Your milage may vary. There may be digital pads on
  6580. each DS-1 circuit and on your DS-1 circuit, and all should be set the same. It's the
  6581. conversion of a pad mismatch that causes noise (it was explained to me that the pad
  6582. eliminates bits or stuffs bits, depending on the setting)
  6583.  
  6584. As to line problems affecting V.34 more than V.90, it appears to affect both about the
  6585. same - nobody expects to see a 54,666 V.90 connection and are happy with the 49,333
  6586. connect rate.
  6587.  
  6588. -Ron
  6589. GLISnet, Inc.
  6590. +1 810/939.9885
  6591.  
  6592. -
  6593.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6594.  with "unsubscribe usr-tc" in the body of the message.
  6595.  For information on digests or retrieving files and old messages send
  6596.  "help" to the same address.  Do not use quotes in your message.
  6597.  
  6598.  
  6599. -------------------------------------------------------------------------------
  6600.  
  6601. From: Brian <signal@shreve.net>
  6602. Subject: Re: (usr-tc) Slot ownerwhip
  6603. Date: 07 Apr 1999 21:46:49 -0500 (CDT)
  6604.  
  6605. On Thu, 8 Apr 1999, Corneliu Rudeanu wrote:
  6606.  
  6607. > 
  6608. > 
  6609. > I am facing the following problem:
  6610. > 
  6611. > HiPer>> list chassis
  6612. > Slot    Owner        Description                      Ports   Type
  6613. > 1       NO           Primary Rate T1 NAC              0       DYNAMIC
  6614. > 2       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6615. > 3       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6616. > 4       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6617. > 5       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6618. > 6       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6619. > 7       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6620. > 8       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6621. > 9       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6622. > 10      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6623. > 11      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6624. > 12      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6625. > 13      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6626. > 14      NO           Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6627. > 15      NO           Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6628. > 16      NO           HiPer Access Router NAC          0       DYNAMIC
  6629. > HiPer>>
  6630. > 
  6631. > In the User Manual for HiperArc it says that under special circumstances
  6632. > (multiple HARCs) you can _statically_ assign the modems for load
  6633. > balancing. I guess (read "hope") that this way (using set chassis slot) I
  6634. > can take the ownership for slots 14 and 15. 
  6635. > 
  6636. > Yet, by default, the NMC should assign this ownership and that should work
  6637. > by all means.
  6638. > 
  6639. > Am I missing something? Is there any way I can find 'who owns' those
  6640. > slots?
  6641. > 
  6642. > Any advice appreciated.
  6643. > 
  6644.  
  6645.  
  6646. I do not trust nmc chassis awareness.  The first command in all my configs
  6647. is "disable nmc chassis_awareness".
  6648.  
  6649. I statically assign all cards to their appropriate hiper arcs.
  6650.  
  6651. Brian
  6652.  
  6653.  
  6654. > Corneliu Rudeanu
  6655. > 
  6656. > 
  6657. > -
  6658. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6659. >  with "unsubscribe usr-tc" in the body of the message.
  6660. >  For information on digests or retrieving files and old messages send
  6661. >  "help" to the same address.  Do not use quotes in your message.
  6662. > 
  6663.  
  6664. Brian Feeny (BF304)     signal@shreve.net   
  6665. 318-222-2638 x 109    http://www.shreve.net/~signal      
  6666. Network Administrator   ShreveNet Inc. (ASN 11881)           
  6667.  
  6668.  
  6669. -
  6670.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6671.  with "unsubscribe usr-tc" in the body of the message.
  6672.  For information on digests or retrieving files and old messages send
  6673.  "help" to the same address.  Do not use quotes in your message.
  6674.  
  6675.  
  6676. -------------------------------------------------------------------------------
  6677.  
  6678. From: Randy McMillan <randy@cheetah.pacinfo.com>
  6679. Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
  6680. Date: 07 Apr 1999 22:26:15 -0700 (PDT)
  6681.  
  6682. Yes it is a CLEC with SS7 between switches and b8zf/esf on the T1.  I
  6683. asked about digital padding, and they said their switch doesn't do
  6684. padding, so there may not be any padding???  He called our T1 from his
  6685. switch to our equipment as a "nailed up T1" using HDSL that didn't go
  6686. through any switching, etc.  How did you find out about who was padding 
  6687. it and where it was padded, and how did you get it resolved?  Thanks
  6688. again.
  6689.  
  6690. Randy McMillan 
  6691.  
  6692. On Wed, 7 Apr 1999, Ronald Kushner wrote:
  6693.  
  6694. > 
  6695. > 
  6696. > Randy McMillan wrote:
  6697. > > 
  6698. > > The T1's are provisioned b8zs/esf.  The analog calls originate and terminate
  6699. > > in the same switch.  The T1 calls terminate in a different switch, but I
  6700. > > have been told that it is using 64k clear channel between them.
  6701. > > So, if that is true, does robbed bit signaling affect v.34 more than v.90?
  6702. > > Where does the digital pad get introduced, in one of the switches or on the
  6703. > > T1 line?  Thanks again for the info.
  6704. > 
  6705. > Sounds like it might be a misconfigured digital pad then, is this through a CLEC?
  6706. > 
  6707. > If it's all SS7 B8ZS/D5, the signaling is via an X25 network and does not affect call
  6708. > quality. There should be no robbed bits.
  6709. > 
  6710. > I ran into problems with digital pads and gain problems with CLECs. That might be the
  6711. > first place to look. I have seen 54666  and 56000 connections with 33,600 on the
  6712. > backchannel since they fixed all my padding issues. (I thought these things were speed
  6713. > limited to 53kbps!). We tried it without a digital pad, but that was worse than having
  6714. > the wrong digital pad on the line. Your milage may vary. There may be digital pads on
  6715. > each DS-1 circuit and on your DS-1 circuit, and all should be set the same. It's the
  6716. > conversion of a pad mismatch that causes noise (it was explained to me that the pad
  6717. > eliminates bits or stuffs bits, depending on the setting)
  6718. > 
  6719. > As to line problems affecting V.34 more than V.90, it appears to affect both about the
  6720. > same - nobody expects to see a 54,666 V.90 connection and are happy with the 49,333
  6721. > connect rate.
  6722. > 
  6723. > -Ron
  6724. > GLISnet, Inc.
  6725. > +1 810/939.9885
  6726. > 
  6727. > -
  6728. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6729. >  with "unsubscribe usr-tc" in the body of the message.
  6730. >  For information on digests or retrieving files and old messages send
  6731. >  "help" to the same address.  Do not use quotes in your message.
  6732. > 
  6733.  
  6734.  
  6735. -
  6736.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6737.  with "unsubscribe usr-tc" in the body of the message.
  6738.  For information on digests or retrieving files and old messages send
  6739.  "help" to the same address.  Do not use quotes in your message.
  6740.  
  6741.  
  6742. -------------------------------------------------------------------------------
  6743.  
  6744. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  6745. Subject: Re: (usr-tc) Slot ownerwhip
  6746. Date: 08 Apr 1999 07:53:40 -0500 (CDT)
  6747.  
  6748. On Thu, 8 Apr 1999, Corneliu Rudeanu wrote:
  6749. > 
  6750. > 
  6751. > I am facing the following problem:
  6752. > 
  6753. > HiPer>> list chassis
  6754. > Slot    Owner        Description                      Ports   Type
  6755. > 1       NO           Primary Rate T1 NAC              0       DYNAMIC
  6756. > 2       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6757. > 3       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6758. > 4       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6759. > 5       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6760. > 6       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6761. > 7       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6762. > 8       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6763. > 9       YES          Quad Digital V.34 Modem          4       DYNAMIC
  6764. > 10      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6765. > 11      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6766. > 12      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6767. > 13      YES          Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6768. > 14      NO           Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6769. > 15      NO           Quad Anal-Digi V.34 Modem        4       DYNAMIC
  6770. > 16      NO           HiPer Access Router NAC          0       DYNAMIC
  6771. > HiPer>>
  6772. > 
  6773. > In the User Manual for HiperArc it says that under special circumstances
  6774. > (multiple HARCs) you can _statically_ assign the modems for load
  6775. > balancing. I guess (read "hope") that this way (using set chassis slot) I
  6776. > can take the ownership for slots 14 and 15. 
  6777. > 
  6778. > Yet, by default, the NMC should assign this ownership and that should work
  6779. > by all means.
  6780.  
  6781. Every card upon bootup sends its info to NMC - Info regarding card type, 
  6782. status etc, based on that information NMC sends out chassis awarness 
  6783. information.  The HiPer arc uses this info to activate the cards.  In 
  6784. here it looks like either the NMC has not set that info or the HiPer arc 
  6785. has ignore that info.  You could either reboot either of the cards or the 
  6786. NMC, or you could set it manually.
  6787. In any case - I would suspect that these two cards were not on the packet 
  6788. or removed from the same manually once thus the hiper arc is not taking 
  6789. it back.
  6790.  
  6791. krish
  6792.  
  6793.  
  6794.  
  6795. > 
  6796. > Am I missing something? Is there any way I can find 'who owns' those
  6797. > slots?
  6798. > 
  6799. > Any advice appreciated.
  6800. > 
  6801. > Corneliu Rudeanu
  6802. > 
  6803. > 
  6804. > -
  6805. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6806. >  with "unsubscribe usr-tc" in the body of the message.
  6807. >  For information on digests or retrieving files and old messages send
  6808. >  "help" to the same address.  Do not use quotes in your message.
  6809. > 
  6810.  
  6811. -
  6812.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6813.  with "unsubscribe usr-tc" in the body of the message.
  6814.  For information on digests or retrieving files and old messages send
  6815.  "help" to the same address.  Do not use quotes in your message.
  6816.  
  6817.  
  6818. -------------------------------------------------------------------------------
  6819.  
  6820. From: Paul Farber <farber@admin.f-tech.net>
  6821. Subject: (usr-tc) Traps & Config
  6822. Date: 08 Apr 1999 09:36:19 -0400 (EDT)
  6823.  
  6824. hello all
  6825.  
  6826. Two questions, went to the 3Kb and got the info for "Capturing the
  6827. configuration through the CLI".  Telenetted in and did "sho config", I
  6828. don't thing I could rebuild a chassis from the information it listed.  I'm
  6829. looking for more like the actual commands, or to tftp the config down to a
  6830. hdd for safe keeping.
  6831.  
  6832. Also, can I set up traps via the CLI?  The 3KB says fire up TCM... any way
  6833. to replicate the process with the good ol cmd line?
  6834.  
  6835. Thanks!
  6836.  
  6837. Paul D. Farber II
  6838. Farber Technology
  6839. Ph. 570-628-5303
  6840. Fax 570-628-5545
  6841. farber@admin.f-tech.net
  6842.  
  6843.  
  6844. -
  6845.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6846.  with "unsubscribe usr-tc" in the body of the message.
  6847.  For information on digests or retrieving files and old messages send
  6848.  "help" to the same address.  Do not use quotes in your message.
  6849.  
  6850.  
  6851. -------------------------------------------------------------------------------
  6852.  
  6853. From: "Tony Loosle" <tony@tcsourceone.com>
  6854. Subject: (usr-tc) WTB Netserver 8 or 16 I +  (still looking)
  6855. Date: 08 Apr 1999 10:14:17 -0600
  6856.  
  6857. Still looking for used netserver 8I+ and 16I+
  6858.  
  6859. tony
  6860. 435-753-5455
  6861.  
  6862.  
  6863.  
  6864.  
  6865. -
  6866.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6867.  with "unsubscribe usr-tc" in the body of the message.
  6868.  For information on digests or retrieving files and old messages send
  6869.  "help" to the same address.  Do not use quotes in your message.
  6870.  
  6871.  
  6872. -------------------------------------------------------------------------------
  6873.  
  6874. From: "Eric Billeter" <ebilleter@cableone.net>
  6875. Subject: RE: (usr-tc) WTB Netserver 8 or 16 I +  (still looking)
  6876. Date: 08 Apr 1999 11:17:27 -0700
  6877.  
  6878. How many do you want and what do you want to pay for them..
  6879.  
  6880. I have 16 of em (8 never used)
  6881.  
  6882.  
  6883. Eric T. Billeter                   Cable One
  6884. Internet Engineer                  1314 North 3rd Street
  6885. ebilleter@cableone.net             Phoenix, AZ 85004           
  6886.  
  6887. -----Original Message-----
  6888. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tony Loosle
  6889. Sent: Thursday, April 08, 1999 9:14 AM
  6890.  
  6891.  
  6892. Still looking for used netserver 8I+ and 16I+
  6893.  
  6894. tony
  6895. 435-753-5455
  6896.  
  6897.  
  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. -
  6910.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6911.  with "unsubscribe usr-tc" in the body of the message.
  6912.  For information on digests or retrieving files and old messages send
  6913.  "help" to the same address.  Do not use quotes in your message.
  6914.  
  6915.  
  6916. -------------------------------------------------------------------------------
  6917.  
  6918. From: Blake Fithen <fithen@NetworksPlus.com>
  6919. Subject: (usr-tc) ISDN connect failures
  6920. Date: 08 Apr 1999 15:26:41 -0500 
  6921.  
  6922. hello, we're having a trouble with ISDN customers not being
  6923. able to connect for extended periods of time.  The caller will
  6924. be online for any amount of time, then the connection is
  6925. dropped.  After that they repeatedly try to connect without 
  6926. success.  This is happening to several makes/models of 
  6927. ISDN router.  I can see them hitting the modem but the call
  6928. never completes. No radius dialog, no ppp dialog using
  6929. "mon radius" and "mon ppp".  TCM shows "RingRcvd" and
  6930. then "Link negotiation" in the "Operational Status of a
  6931. modem" column.  About 10 seconds later the call drops and 
  6932. the "Reason for call failure" column shows
  6933. "normaUserCallClear(73)" then the cycle continues.  But
  6934. without intervention or any resetting on the hubs they
  6935. eventually connect anywhere from 10 minutes to several
  6936. hours later.  I'm running 1.2.43 and 4.1.59-6. PPP offloading
  6937. is enabled and PPP BACP and BAP are disabled.  We
  6938. have a totally different ARC chassis running the same code
  6939. revisions but the problem remains with that chassis.  The
  6940. chassis has 6 DSP's, one ARC and one 70 AMP PSU.  
  6941.  
  6942. Any thoughts would be greatly appreciated.
  6943. blake
  6944.  
  6945. syslog output:
  6946.  
  6947. x.x.x.x:     Thu Apr  8 12:08:09:     <38>At 11:11:48, Facility "Auth
  6948. Facility", Level "COMMON":: The connection for call id 218235631, on if
  6949. slot:14/mod:3 was dropped for user UNKNOWN
  6950. x.x.x.x:     Thu Apr  8 12:08:16:     <38>At 11:11:55, Facility "Auth
  6951. Facility", Level "VERBOSE":: A call, call id = 218235632, has arrived on
  6952. interface slot:14/mod:3
  6953. x.x.x.x:     Thu Apr  8 12:08:47:     <38>At 11:12:25, Facility "Auth
  6954. Facility", Level "VERBOSE":: A call, call id = 218235633, has arrived on
  6955. interface slot:14/mod:3
  6956. x.x.x.x:     Thu Apr  8 12:09:07:     <38>At 11:12:46, Facility "Auth
  6957. Facility", Level "COMMON":: A call is established, call id 218235633, on
  6958. interface slot:14/mod:3
  6959. x.x.x.x:     Thu Apr  8 12:09:10:     <38>At 11:12:49, Facility "Auth
  6960. Facility", Level "COMMON":: The connection for call id 218235633, on if
  6961. slot:14/mod:3 was dropped for user UNKNOWN
  6962. x.x.x.x:     Thu Apr  8 12:09:17:     <38>At 11:12:55, Facility "Auth
  6963. Facility", Level "VERBOSE":: A call, call id = 218235634, has arrived on
  6964. interface slot:14/mod:3
  6965. x.x.x.x:     Thu Apr  8 12:09:47:     <38>At 11:13:25, Facility "Auth
  6966. Facility", Level "VERBOSE":: A call, call id = 218235635, has arrived on
  6967. interface slot:14/mod:3
  6968. x.x.x.x:     Thu Apr  8 12:10:07:     <38>At 11:13:46, Facility "Auth
  6969. Facility", Level "COMMON":: A call is established, call id 218235635, on
  6970. interface slot:14/mod:3
  6971. x.x.x.x:     Thu Apr  8 12:10:10:     <38>At 11:13:49, Facility "Auth
  6972. Facility", Level "COMMON":: The connection for call id 218235635, on if
  6973. slot:14/mod:3 was dropped for user UNKNOWN
  6974. x.x.x.x:     Thu Apr  8 12:10:17:     <38>At 11:13:56, Facility "Auth
  6975. Facility", Level "VERBOSE":: A call, call id = 218235636, has arrived on
  6976. interface slot:14/mod:3
  6977. x.x.x.x:     Thu Apr  8 12:10:32:     <38>At 11:14:11, Facility "Auth
  6978. Facility", Level "COMMON":: A call is established, call id 218235636, on
  6979. interface slot:14/mod:3
  6980. x.x.x.x:     Thu Apr  8 12:10:41:     <38>At 11:14:19, Facility "Auth
  6981. Facility", Level "COMMON":: The connection for call id 218235636, on if
  6982. slot:14/mod:3 was dropped for user UNKNOWN
  6983.  
  6984. -
  6985.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6986.  with "unsubscribe usr-tc" in the body of the message.
  6987.  For information on digests or retrieving files and old messages send
  6988.  "help" to the same address.  Do not use quotes in your message.
  6989.  
  6990.  
  6991. -------------------------------------------------------------------------------
  6992.  
  6993. From: Jim Johnson <jim@perigee.net>
  6994. Subject: (usr-tc) ISDN Connect Problem
  6995. Date: 08 Apr 1999 16:43:48 -0400
  6996.  
  6997.  
  6998.  
  6999. We are having another connect problem with an ISDN customer.  
  7000.  
  7001. He has an Adtran Express 3000.  When the call is made it gets to the
  7002. username and password and then drops him, occasionally it will get
  7003. through that and we can monitor him through mon ppp.  Most of those
  7004. times, he gets dropped during an IPCP Config Request.   Occasionally, he
  7005. will get connected and stay connected.
  7006.  
  7007. I had a customer on Tues. who reported a similar problem.  The IPCP
  7008. Config Request from the TC chassis was consider invalid and the call was
  7009. terminated.  In both cases, the "Reason for call failure" column shows
  7010. "normaUserCallClear(73)".
  7011.  
  7012. We are using ARCs w/4.1.59-6 and HDMS w/1.2.43
  7013.  
  7014. Regards,
  7015.  
  7016. Jim Johnson
  7017.  
  7018. -
  7019.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7020.  with "unsubscribe usr-tc" in the body of the message.
  7021.  For information on digests or retrieving files and old messages send
  7022.  "help" to the same address.  Do not use quotes in your message.
  7023.  
  7024.  
  7025. -------------------------------------------------------------------------------
  7026.  
  7027. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  7028. Subject: Re: (usr-tc) ISDN connect failures
  7029. Date: 08 Apr 1999 16:10:07 -0500 (CDT)
  7030.  
  7031. On Thu, 8 Apr 1999, Blake Fithen wrote:
  7032.  
  7033. > hello, we're having a trouble with ISDN customers not being
  7034. > able to connect for extended periods of time.  The caller will
  7035. > be online for any amount of time, then the connection is
  7036. > dropped.  After that they repeatedly try to connect without 
  7037. > success.  This is happening to several makes/models of 
  7038. > ISDN router.  I can see them hitting the modem but the call
  7039. > never completes. No radius dialog, no ppp dialog using
  7040. > "mon radius" and "mon ppp".  TCM shows "RingRcvd" and
  7041. > then "Link negotiation" in the "Operational Status of a
  7042. > modem" column.  About 10 seconds later the call drops and 
  7043. > the "Reason for call failure" column shows
  7044. > "normaUserCallClear(73)" then the cycle continues.  But
  7045. > without intervention or any resetting on the hubs they
  7046. > eventually connect anywhere from 10 minutes to several
  7047. > hours later.  I'm running 1.2.43 and 4.1.59-6. PPP offloading
  7048. > is enabled and PPP BACP and BAP are disabled.  We
  7049. > have a totally different ARC chassis running the same code
  7050. > revisions but the problem remains with that chassis.  The
  7051. > chassis has 6 DSP's, one ARC and one 70 AMP PSU.  
  7052.  
  7053. Need to find out what is happening when the call is being presented.  
  7054. From the information above it looks like the call is never completed.  We 
  7055. would need enable tap on the hiper arc and see if the modem is presenting 
  7056. the call or not to the hiper arc.  Would recommend that you open a ticket 
  7057. for a tech to collect info.
  7058.  
  7059. regards
  7060.  
  7061. krish
  7062.  
  7063. > 
  7064. > Any thoughts would be greatly appreciated.
  7065. > blake
  7066. > 
  7067. > syslog output:
  7068. > 
  7069. > x.x.x.x:     Thu Apr  8 12:08:09:     <38>At 11:11:48, Facility "Auth
  7070. > Facility", Level "COMMON":: The connection for call id 218235631, on if
  7071. > slot:14/mod:3 was dropped for user UNKNOWN
  7072. > x.x.x.x:     Thu Apr  8 12:08:16:     <38>At 11:11:55, Facility "Auth
  7073. > Facility", Level "VERBOSE":: A call, call id = 218235632, has arrived on
  7074. > interface slot:14/mod:3
  7075. > x.x.x.x:     Thu Apr  8 12:08:47:     <38>At 11:12:25, Facility "Auth
  7076. > Facility", Level "VERBOSE":: A call, call id = 218235633, has arrived on
  7077. > interface slot:14/mod:3
  7078. > x.x.x.x:     Thu Apr  8 12:09:07:     <38>At 11:12:46, Facility "Auth
  7079. > Facility", Level "COMMON":: A call is established, call id 218235633, on
  7080. > interface slot:14/mod:3
  7081. > x.x.x.x:     Thu Apr  8 12:09:10:     <38>At 11:12:49, Facility "Auth
  7082. > Facility", Level "COMMON":: The connection for call id 218235633, on if
  7083. > slot:14/mod:3 was dropped for user UNKNOWN
  7084. > x.x.x.x:     Thu Apr  8 12:09:17:     <38>At 11:12:55, Facility "Auth
  7085. > Facility", Level "VERBOSE":: A call, call id = 218235634, has arrived on
  7086. > interface slot:14/mod:3
  7087. > x.x.x.x:     Thu Apr  8 12:09:47:     <38>At 11:13:25, Facility "Auth
  7088. > Facility", Level "VERBOSE":: A call, call id = 218235635, has arrived on
  7089. > interface slot:14/mod:3
  7090. > x.x.x.x:     Thu Apr  8 12:10:07:     <38>At 11:13:46, Facility "Auth
  7091. > Facility", Level "COMMON":: A call is established, call id 218235635, on
  7092. > interface slot:14/mod:3
  7093. > x.x.x.x:     Thu Apr  8 12:10:10:     <38>At 11:13:49, Facility "Auth
  7094. > Facility", Level "COMMON":: The connection for call id 218235635, on if
  7095. > slot:14/mod:3 was dropped for user UNKNOWN
  7096. > x.x.x.x:     Thu Apr  8 12:10:17:     <38>At 11:13:56, Facility "Auth
  7097. > Facility", Level "VERBOSE":: A call, call id = 218235636, has arrived on
  7098. > interface slot:14/mod:3
  7099. > x.x.x.x:     Thu Apr  8 12:10:32:     <38>At 11:14:11, Facility "Auth
  7100. > Facility", Level "COMMON":: A call is established, call id 218235636, on
  7101. > interface slot:14/mod:3
  7102. > x.x.x.x:     Thu Apr  8 12:10:41:     <38>At 11:14:19, Facility "Auth
  7103. > Facility", Level "COMMON":: The connection for call id 218235636, on if
  7104. > slot:14/mod:3 was dropped for user UNKNOWN
  7105. > 
  7106. > -
  7107. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7108. >  with "unsubscribe usr-tc" in the body of the message.
  7109. >  For information on digests or retrieving files and old messages send
  7110. >  "help" to the same address.  Do not use quotes in your message.
  7111. > 
  7112.  
  7113. -
  7114.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7115.  with "unsubscribe usr-tc" in the body of the message.
  7116.  For information on digests or retrieving files and old messages send
  7117.  "help" to the same address.  Do not use quotes in your message.
  7118.  
  7119.  
  7120. -------------------------------------------------------------------------------
  7121.  
  7122. From: Blake Fithen <fithen@NetworksPlus.com>
  7123. Subject: RE: (usr-tc) ISDN Connect Problem
  7124. Date: 08 Apr 1999 15:56:09 -0500 
  7125.  
  7126. We had the same problem with a customer who had a Adtran
  7127. Express XRT.  Try this from Adtrans FAQ page.  I'm not=20
  7128. sure if it will help the 3000 but our symptoms were the=20
  7129. same as yours and it helped him right away.
  7130.  
  7131. http://www.adtran.com/support/faqs/xr_xrt/listing.html
  7132.  
  7133. The second channel is not being properly authenticated because Linux is =
  7134. not
  7135. able to respond to a CHAP password challenge on the second channel. Set
  7136. Linux to use PAP (Password Authentication Protocol) instead of CHAP and =
  7137. set
  7138. register S118=3D32 on the ADTRAN Express XR=AE/XRT=AE. This setting =
  7139. causes the
  7140. ADTRAN Express XR=AE/XRT=AE to "spoof" the CHAP authentication on the
  7141. second channel.
  7142.  
  7143. > -----Original Message-----
  7144. > From: Jim Johnson [mailto:jim@perigee.net]
  7145. > Sent: Thursday, April 08, 1999 3:44 PM
  7146. > To: usr-tc Mailing List
  7147. > Subject: (usr-tc) ISDN Connect Problem
  7148. >=20
  7149. >=20
  7150. >=20
  7151. >=20
  7152. > We are having another connect problem with an ISDN customer. =20
  7153. >=20
  7154. > He has an Adtran Express 3000.  When the call is made it gets to the
  7155. > username and password and then drops him, occasionally it will get
  7156. > through that and we can monitor him through mon ppp.  Most of those
  7157. > times, he gets dropped during an IPCP Config Request.  =20
  7158. > Occasionally, he
  7159. > will get connected and stay connected.
  7160. >=20
  7161. > I had a customer on Tues. who reported a similar problem.  The IPCP
  7162. > Config Request from the TC chassis was consider invalid and=20
  7163. > the call was
  7164. > terminated.  In both cases, the "Reason for call failure" column =
  7165. shows
  7166. > "normaUserCallClear(73)".
  7167. >=20
  7168. > We are using ARCs w/4.1.59-6 and HDMS w/1.2.43
  7169. >=20
  7170. > Regards,
  7171. >=20
  7172. > Jim Johnson
  7173. >=20
  7174. > -
  7175. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7176. >  with "unsubscribe usr-tc" in the body of the message.
  7177. >  For information on digests or retrieving files and old messages send
  7178. >  "help" to the same address.  Do not use quotes in your message.
  7179. >=20
  7180.  
  7181. -
  7182.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7183.  with "unsubscribe usr-tc" in the body of the message.
  7184.  For information on digests or retrieving files and old messages send
  7185.  "help" to the same address.  Do not use quotes in your message.
  7186.  
  7187.  
  7188. -------------------------------------------------------------------------------
  7189.  
  7190. From: Blake Fithen <fithen@NetworksPlus.com>
  7191. Subject: RE: (usr-tc) ISDN connect failures
  7192. Date: 08 Apr 1999 16:22:02 -0500 
  7193.  
  7194. OK - not to be a jerk or anything but I'd rather not try to open
  7195. a case just yet - with an exception of a few individuals at 3com 
  7196. tech support, I am thoroughly frustrated with the QOS I pay for 
  7197. and it's too much of a pain to tell whoever picks up the case to
  7198. go find the competent ones. But that's a different problem.
  7199.  
  7200. I Did a "add tap user blakehome screen" waited for about 10
  7201. minutes with no tap traffic output even though I was getting
  7202. same dialog as before in Performance monitor with my SPID in the
  7203. appropriate column.  Then, all of the sudden the TAP traffic
  7204. started and my ISDN device got logged in.  Some TAP output with
  7205. lots of "IN:" and "OUT:" from the top was lost.  So what does
  7206. this tell me?
  7207.  
  7208. TAP USER blakehome on slot:14/mod:3  IN:   11: ....<abcdefghijk
  7209. TAP USER blakehome on slot:14/mod:3  IN:   11: lmnopqrstuvwxyza
  7210. TAP USER blakehome on slot:14/mod:3  IN:   11: bcdef
  7211. TAP USER blakehome on slot:14/mod:3  IN:   12: ...=....!E..4F..
  7212. TAP USER blakehome on slot:14/mod:3  IN:   12: .@.0............
  7213. TAP USER blakehome on slot:14/mod:3  IN:   12: .. s............
  7214. TAP USER blakehome on slot:14/mod:3  IN:   12: .............
  7215. TAP USER blakehome on slot:14/mod:3  IN:   13: ...=....!E..4F..
  7216. TAP USER blakehome on slot:14/mod:3  IN:   13: .@.0............
  7217. TAP USER blakehome on slot:14/mod:3  IN:   13: .. s............
  7218. TAP USER blakehome on slot:14/mod:3  IN:   13: .............
  7219. TAP USER blakehome on slot:14/mod:3  IN:   14: ...=....!E..4F..
  7220. TAP USER blakehome on slot:14/mod:3  IN:   14: .@.0............
  7221. TAP USER blakehome on slot:14/mod:3  IN:   14: .. s............
  7222. TAP USER blakehome on slot:14/mod:3  IN:   14: .............
  7223. TAP USER blakehome on slot:14/mod:3  IN:   15: ...=....!E..4F..
  7224. TAP USER blakehome on slot:14/mod:3  IN:   15: .@.0............
  7225. TAP USER blakehome on slot:14/mod:3  IN:   15: .. s............
  7226. TAP USER blakehome on slot:14/mod:3  IN:   15: .............
  7227. TAP USER blakehome on slot:14/mod:3 OUT:   16: ...!E..<u+..~...
  7228. TAP USER blakehome on slot:14/mod:3 OUT:   16: ...............<
  7229. TAP USER blakehome on slot:14/mod:3 OUT:   16: abcdefghijklmnop
  7230. TAP USER blakehome on slot:14/mod:3 OUT:   16: qrstuvwxyzabcdef
  7231. TAP USER blakehome on slot:14/mod:3  IN:   17: ...=....!E..<F..
  7232. TAP USER blakehome on slot:14/mod:3  IN:   17: ...s............
  7233. TAP USER blakehome on slot:14/mod:3  IN:   17: ....<abcdefghijk
  7234. TAP USER blakehome on slot:14/mod:3  IN:   17: lmnopqrstuvwxyza
  7235. TAP USER blakehome on slot:14/mod:3  IN:   17: bcdef
  7236. TAP USER blakehome on slot:14/mod:3  IN:   18: ...=....!E..4F..
  7237. TAP USER blakehome on slot:14/mod:3  IN:   18: .@./............
  7238. TAP USER blakehome on slot:14/mod:3  IN:   18: .. s............
  7239. TAP USER blakehome on slot:14/mod:3  IN:   18: .............          
  7240.  
  7241.  
  7242.  
  7243. > -----Original Message-----
  7244. > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com]
  7245. > Sent: Thursday, April 08, 1999 4:10 PM
  7246. > To: Blake Fithen
  7247. > Cc: usr-tc@lists.xmission.com
  7248. > Subject: Re: (usr-tc) ISDN connect failures
  7249. > 
  7250. > 
  7251. > On Thu, 8 Apr 1999, Blake Fithen wrote:
  7252. > 
  7253. > > hello, we're having a trouble with ISDN customers not being
  7254. > > able to connect for extended periods of time.  The caller will
  7255. > > be online for any amount of time, then the connection is
  7256. > > dropped.  After that they repeatedly try to connect without 
  7257. > > success.  This is happening to several makes/models of 
  7258. > > ISDN router.  I can see them hitting the modem but the call
  7259. > > never completes. No radius dialog, no ppp dialog using
  7260. > > "mon radius" and "mon ppp".  TCM shows "RingRcvd" and
  7261. > > then "Link negotiation" in the "Operational Status of a
  7262. > > modem" column.  About 10 seconds later the call drops and 
  7263. > > the "Reason for call failure" column shows
  7264. > > "normaUserCallClear(73)" then the cycle continues.  But
  7265. > > without intervention or any resetting on the hubs they
  7266. > > eventually connect anywhere from 10 minutes to several
  7267. > > hours later.  I'm running 1.2.43 and 4.1.59-6. PPP offloading
  7268. > > is enabled and PPP BACP and BAP are disabled.  We
  7269. > > have a totally different ARC chassis running the same code
  7270. > > revisions but the problem remains with that chassis.  The
  7271. > > chassis has 6 DSP's, one ARC and one 70 AMP PSU.  
  7272. > 
  7273. > Need to find out what is happening when the call is being presented.  
  7274. > From the information above it looks like the call is never 
  7275. > completed.  We 
  7276. > would need enable tap on the hiper arc and see if the modem 
  7277. > is presenting 
  7278. > the call or not to the hiper arc.  Would recommend that you 
  7279. > open a ticket 
  7280. > for a tech to collect info.
  7281. > 
  7282. > regards
  7283. > 
  7284. > krish
  7285. > 
  7286. > > 
  7287. > > Any thoughts would be greatly appreciated.
  7288. > > blake
  7289. > > 
  7290. > > syslog output:
  7291. > > 
  7292. > > x.x.x.x:     Thu Apr  8 12:08:09:     <38>At 11:11:48, 
  7293. > Facility "Auth
  7294. > > Facility", Level "COMMON":: The connection for call id 
  7295. > 218235631, on if
  7296. > > slot:14/mod:3 was dropped for user UNKNOWN
  7297. > > x.x.x.x:     Thu Apr  8 12:08:16:     <38>At 11:11:55, 
  7298. > Facility "Auth
  7299. > > Facility", Level "VERBOSE":: A call, call id = 218235632, 
  7300. > has arrived on
  7301. > > interface slot:14/mod:3
  7302. > > x.x.x.x:     Thu Apr  8 12:08:47:     <38>At 11:12:25, 
  7303. > Facility "Auth
  7304. > > Facility", Level "VERBOSE":: A call, call id = 218235633, 
  7305. > has arrived on
  7306. > > interface slot:14/mod:3
  7307. > > x.x.x.x:     Thu Apr  8 12:09:07:     <38>At 11:12:46, 
  7308. > Facility "Auth
  7309. > > Facility", Level "COMMON":: A call is established, call id 
  7310. > 218235633, on
  7311. > > interface slot:14/mod:3
  7312. > > x.x.x.x:     Thu Apr  8 12:09:10:     <38>At 11:12:49, 
  7313. > Facility "Auth
  7314. > > Facility", Level "COMMON":: The connection for call id 
  7315. > 218235633, on if
  7316. > > slot:14/mod:3 was dropped for user UNKNOWN
  7317. > > x.x.x.x:     Thu Apr  8 12:09:17:     <38>At 11:12:55, 
  7318. > Facility "Auth
  7319. > > Facility", Level "VERBOSE":: A call, call id = 218235634, 
  7320. > has arrived on
  7321. > > interface slot:14/mod:3
  7322. > > x.x.x.x:     Thu Apr  8 12:09:47:     <38>At 11:13:25, 
  7323. > Facility "Auth
  7324. > > Facility", Level "VERBOSE":: A call, call id = 218235635, 
  7325. > has arrived on
  7326. > > interface slot:14/mod:3
  7327. > > x.x.x.x:     Thu Apr  8 12:10:07:     <38>At 11:13:46, 
  7328. > Facility "Auth
  7329. > > Facility", Level "COMMON":: A call is established, call id 
  7330. > 218235635, on
  7331. > > interface slot:14/mod:3
  7332. > > x.x.x.x:     Thu Apr  8 12:10:10:     <38>At 11:13:49, 
  7333. > Facility "Auth
  7334. > > Facility", Level "COMMON":: The connection for call id 
  7335. > 218235635, on if
  7336. > > slot:14/mod:3 was dropped for user UNKNOWN
  7337. > > x.x.x.x:     Thu Apr  8 12:10:17:     <38>At 11:13:56, 
  7338. > Facility "Auth
  7339. > > Facility", Level "VERBOSE":: A call, call id = 218235636, 
  7340. > has arrived on
  7341. > > interface slot:14/mod:3
  7342. > > x.x.x.x:     Thu Apr  8 12:10:32:     <38>At 11:14:11, 
  7343. > Facility "Auth
  7344. > > Facility", Level "COMMON":: A call is established, call id 
  7345. > 218235636, on
  7346. > > interface slot:14/mod:3
  7347. > > x.x.x.x:     Thu Apr  8 12:10:41:     <38>At 11:14:19, 
  7348. > Facility "Auth
  7349. > > Facility", Level "COMMON":: The connection for call id 
  7350. > 218235636, on if
  7351. > > slot:14/mod:3 was dropped for user UNKNOWN
  7352. > > 
  7353. > > -
  7354. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7355. > >  with "unsubscribe usr-tc" in the body of the message.
  7356. > >  For information on digests or retrieving files and old 
  7357. > messages send
  7358. > >  "help" to the same address.  Do not use quotes in your message.
  7359. > > 
  7360. > 
  7361. > -
  7362. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7363. >  with "unsubscribe usr-tc" in the body of the message.
  7364. >  For information on digests or retrieving files and old messages send
  7365. >  "help" to the same address.  Do not use quotes in your message.
  7366. > 
  7367.  
  7368. -
  7369.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7370.  with "unsubscribe usr-tc" in the body of the message.
  7371.  For information on digests or retrieving files and old messages send
  7372.  "help" to the same address.  Do not use quotes in your message.
  7373.  
  7374.  
  7375. -------------------------------------------------------------------------------
  7376.  
  7377. From: d baud <dbaud@iname.com>
  7378. Subject: (usr-tc) CRC error on boot configuration
  7379. Date: 08 Apr 1999 13:53:50 -0400
  7380.  
  7381. I just received a HiperCard that I installed on the chassis:
  7382. I plugged the console cable to perform the quicksetup routine and I
  7383. noticed that it gave me the following error as soon as it did a Save
  7384. All.
  7385. The error message is the following:
  7386. WARNING: CRC error on boot configuration. Defaulting it
  7387. (repeating for about 15 lines)
  7388.  
  7389. At first I suspected the code used was faulty, so I reseated the card
  7390. and issued the regular AT{Z} command to send the current ne040159-6.dmf
  7391. code.  Once finished, I try a "save all" and still nothing happens.
  7392.  
  7393. I then decided to do a: AT{ZF} command with the same code.
  7394. Unfortunately still the same error message
  7395.  
  7396. I then called the tech people at USR, and the lady said that this might
  7397. be a debug and unharmful code.  So she issued some command to remove
  7398. those messages and refused to tell me what it was because it was "too
  7399. dificult to understand" 
  7400. Well now I don't get the error message when I "save all" but the
  7401. following error apears at boot time:
  7402. Error writing configuration to EEPROM
  7403. WARNING: CRC error on boot configuration. Defaulting it
  7404.  
  7405. Anyone had this issue before ?
  7406.  
  7407. Donald Baud
  7408.  
  7409. -
  7410.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7411.  with "unsubscribe usr-tc" in the body of the message.
  7412.  For information on digests or retrieving files and old messages send
  7413.  "help" to the same address.  Do not use quotes in your message.
  7414.  
  7415.  
  7416. -------------------------------------------------------------------------------
  7417.  
  7418. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  7419. Subject: Re: (usr-tc) HiPer gone wacko!
  7420. Date: 06 Apr 1999 09:57:40 -0500 (CDT)
  7421.  
  7422. If you have access to the console - as soon as you reboot the card you 
  7423. will get a menu - one of the options in the menu is to erase router 
  7424. config.  Trying erasing the router config, and see if that fixes the 
  7425. card.  If that does not work then get the 4.1.59 -6  code from 
  7426. http://totalservice.usr.com
  7427.  
  7428.  
  7429. Reboot the hiper arc card and as soon as you see the word "boot"
  7430. using zmodem down loas the 4.1.59-6 code
  7431.  
  7432. regards
  7433.  
  7434. krish
  7435.  
  7436.         \    T.S.V. Krishnan  \
  7437.          \      Network System Engineer \ ( : - : )
  7438.           \     3Com ............   \
  7439.         ----------------------------------------------/
  7440. tkrishna@bubba.ae.usr.com  
  7441. ----------------------------/ http://interproc.ae.usr.com ----/
  7442. The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
  7443.     Any Sufficiently advanced bug is indistinguishable for a feature.
  7444.                         - Rick Kulawiec
  7445.  
  7446. On Mon, 5 Apr 1999, K Mitchell wrote:
  7447.  
  7448. > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems
  7449. > connecting with varied error messages, messages coming through my console
  7450. > ARC connection are misspelled or missing letters. Reboot hasn't helped.
  7451. > Here's an example of console messages coming through during the reboot:
  7452. > HiPer enabling networks on rfaces....
  7453. > 
  7454. > Configuring Networrvices.....
  7455. > 
  7456. > Starting the CLI......
  7457. > Please Waor Prompt...
  7458. > 
  7459. > Running;
  7460. > ARC 4.1.72
  7461. > NMC 5.5.5
  7462. > DSP 1.2.5
  7463. > Has my ARC gone bad, or is there something else I can try that may correct
  7464. > this?
  7465. > 
  7466. > Thanks,
  7467. > A frustrated Kirk
  7468. > 
  7469. > 
  7470. > 
  7471. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  7472. > Keystone Connect                http://www.keyconn.net
  7473. > Altoona, PA   814-941-5000         We Unlock the World
  7474. > 
  7475. > 
  7476. > -
  7477. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7478. >  with "unsubscribe usr-tc" in the body of the message.
  7479. >  For information on digests or retrieving files and old messages send
  7480. >  "help" to the same address.  Do not use quotes in your message.
  7481. > 
  7482.  
  7483. -
  7484.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7485.  with "unsubscribe usr-tc" in the body of the message.
  7486.  For information on digests or retrieving files and old messages send
  7487.  "help" to the same address.  Do not use quotes in your message.
  7488.  
  7489.  
  7490. -------------------------------------------------------------------------------
  7491.  
  7492. From: Pete Ashdown <pashdown@xmission.com>
  7493. Subject: Re: (usr-tc) RIP updates on assigned pool
  7494. Date: 08 Apr 1999 16:34:45 -0600 (MDT)
  7495.  
  7496. Brian Elfert said once upon a time:
  7497. >
  7498. >For some reason, some of my Netservers (All running 3.7.24) won't
  7499. >broadcast any IPs in their assigned pool via RIP (v1).  They will
  7500. >broadcast static IPs not in the assigned pool.
  7501. >
  7502. >Any ideas?  On the Cisco, I can see updates coming in, but none from any
  7503. >of the IP pools on some of the Netservers.
  7504.  
  7505. There was a bug that had this effect a long time ago.  Unfortunately, I
  7506. can't remember the details of it.  If you search back through the archives
  7507. you'll probably find me bitching about it.  I seem to remember the solution
  7508. was a code-update, so I don't know why you're suffering from it.
  7509.  
  7510. -
  7511.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7512.  with "unsubscribe usr-tc" in the body of the message.
  7513.  For information on digests or retrieving files and old messages send
  7514.  "help" to the same address.  Do not use quotes in your message.
  7515.  
  7516.  
  7517. -------------------------------------------------------------------------------
  7518.  
  7519. From: Pete Ashdown <pashdown@xmission.com>
  7520. Subject: (usr-tc) multicasting over ARC's?
  7521. Date: 08 Apr 1999 16:35:52 -0600 (MDT)
  7522.  
  7523. Is anyone doing multicasting over their ARC's?  Did you need to do anything
  7524. to get it to run?
  7525.  
  7526. -
  7527.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7528.  with "unsubscribe usr-tc" in the body of the message.
  7529.  For information on digests or retrieving files and old messages send
  7530.  "help" to the same address.  Do not use quotes in your message.
  7531.  
  7532.  
  7533. -------------------------------------------------------------------------------
  7534.  
  7535. From: Brian <signal@shreve.net>
  7536. Subject: (usr-tc) TCM vs. TFTP
  7537. Date: 09 Apr 1999 00:31:22 -0500 (CDT)
  7538.  
  7539.  
  7540. Why is TCM so slow?  I started a transfer of 4.1.59-6 from TCM into 2
  7541. ARC's via Software Download.
  7542.  
  7543. During the time of the download I was able to upgrade 6 other arc's by
  7544. just using UNIX tftp.  When I was finished, SDL via TCM still had a
  7545. another few minutes to go!  Each tftp via UNIX took just 43 seconds.
  7546.  
  7547. Brian
  7548.  
  7549.  
  7550. Brian Feeny (BF304)     signal@shreve.net   
  7551. 318-222-2638 x 109    http://www.shreve.net/~signal      
  7552. Network Administrator   ShreveNet Inc. (ASN 11881)           
  7553.  
  7554.  
  7555. -
  7556.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7557.  with "unsubscribe usr-tc" in the body of the message.
  7558.  For information on digests or retrieving files and old messages send
  7559.  "help" to the same address.  Do not use quotes in your message.
  7560.  
  7561.  
  7562. -------------------------------------------------------------------------------
  7563.  
  7564. From: David Bolen <db3l@ans.net>
  7565. Subject: Re: (usr-tc) TCM vs. TFTP
  7566. Date: 09 Apr 1999 2:09:40 EDT
  7567.  
  7568. Brian <signal@shreve.net> writes:
  7569.  
  7570. > During the time of the download I was able to upgrade 6 other arc's by
  7571. > just using UNIX tftp.  When I was finished, SDL via TCM still had a
  7572. > another few minutes to go!  Each tftp via UNIX took just 43 seconds.
  7573.  
  7574. Hmm, It's hard to say for your specific test, but one possibility is
  7575. to be careful to time the entire process.  Unlike SDL-1 cards (like
  7576. the quads), with SDL-2 (the HiPer cards) the NMC can accept a code
  7577. image faster than it can actually transmit it to the appropriate
  7578. cards, so there can be a lag from completion of tftp to all the code
  7579. getting to the cards.
  7580. cards.
  7581.  
  7582. So while your tftp may have completed, if you check the command table
  7583. for the slots involved, you may find that they aren't indicated as
  7584. being done yet, since the NMC is still transmitting the code
  7585. internally in the chassis.
  7586.  
  7587. My guess is that TCM is monitoring the command table for completion
  7588. before it actually declares the process done.
  7589.  
  7590. The other thing to check is if you're comparing HiperNMCs with older
  7591. 486 NMCs.  The "wire speed" at which the NMC can receive the new code
  7592. is far faster on the HiperNMC than the 486 NMC.
  7593.  
  7594. Although to be honest, even in a HiperNMC case, I don't think I've
  7595. seen it that fast.
  7596.  
  7597. Unless you're referring to tftp'ing the file directly to the ARC
  7598. itself, in which case there's a big difference between dumping it to
  7599. the flash filesystem that way versus going through the NMC's
  7600. management bus interface (which is much lower bandwidth and smaller
  7601. packet chunks).  Comparing an NMC download versus a tftp right to the
  7602. ARC could certainly appear far slower.
  7603.  
  7604. -- David
  7605.  
  7606. -
  7607.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7608.  with "unsubscribe usr-tc" in the body of the message.
  7609.  For information on digests or retrieving files and old messages send
  7610.  "help" to the same address.  Do not use quotes in your message.
  7611.  
  7612.  
  7613. -------------------------------------------------------------------------------
  7614.  
  7615. From: Mike Andrews <mandrews@termfrost.org>
  7616. Subject: Re: (usr-tc) TCM vs. TFTP
  7617. Date: 09 Apr 1999 02:14:52 -0400 (EDT)
  7618.  
  7619. Just curious -- When you did the Unix tftp, did you tftp it directly to
  7620. the ARC, or to the NMC?  TCM sends it to the NMC.  The Perl script I wrote
  7621. for flashing cards also sends it to the NMC (using Unix tftp), and it's
  7622. exactly as slow as TCM -- pretty much the same transfer time you're
  7623. seeing.  I think the last one I did said about 11 Kbits/sec.  My Sprint
  7624. PCS phone transmits data faster than that :)  So if you're doing ARCs,
  7625. tftping directly to the ARC is probably the way to go (I've never tried
  7626. it), but it's kinda hard to do that with DSP's, Quads, NETservers, or
  7627. whatever else...
  7628.  
  7629.  
  7630. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  7631. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  7632. Microsoft operating system is like a dog without a brick tied to its head."
  7633.  
  7634. On Fri, 9 Apr 1999, Brian wrote:
  7635.  
  7636. > 
  7637. > Why is TCM so slow?  I started a transfer of 4.1.59-6 from TCM into 2
  7638. > ARC's via Software Download.
  7639. > 
  7640. > During the time of the download I was able to upgrade 6 other arc's by
  7641. > just using UNIX tftp.  When I was finished, SDL via TCM still had a
  7642. > another few minutes to go!  Each tftp via UNIX took just 43 seconds.
  7643. > 
  7644. > Brian
  7645. > 
  7646. > 
  7647. > -----------------------------------------------------
  7648. > Brian Feeny (BF304)     signal@shreve.net   
  7649. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  7650. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  7651. > 
  7652. > 
  7653. > -
  7654. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7655. >  with "unsubscribe usr-tc" in the body of the message.
  7656. >  For information on digests or retrieving files and old messages send
  7657. >  "help" to the same address.  Do not use quotes in your message.
  7658. > 
  7659.  
  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.  
  7670. From: Mike Andrews <mandrews@termfrost.org>
  7671. Subject: Re: (usr-tc) TCM vs. TFTP
  7672. Date: 09 Apr 1999 02:14:52 -0400 (EDT)
  7673.  
  7674. Just curious -- When you did the Unix tftp, did you tftp it directly to
  7675. the ARC, or to the NMC?  TCM sends it to the NMC.  The Perl script I wrote
  7676. for flashing cards also sends it to the NMC (using Unix tftp), and it's
  7677. exactly as slow as TCM -- pretty much the same transfer time you're
  7678. seeing.  I think the last one I did said about 11 Kbits/sec.  My Sprint
  7679. PCS phone transmits data faster than that :)  So if you're doing ARCs,
  7680. tftping directly to the ARC is probably the way to go (I've never tried
  7681. it), but it's kinda hard to do that with DSP's, Quads, NETservers, or
  7682. whatever else...
  7683.  
  7684.  
  7685. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  7686. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  7687. Microsoft operating system is like a dog without a brick tied to its head."
  7688.  
  7689. On Fri, 9 Apr 1999, Brian wrote:
  7690.  
  7691. > 
  7692. > Why is TCM so slow?  I started a transfer of 4.1.59-6 from TCM into 2
  7693. > ARC's via Software Download.
  7694. > 
  7695. > During the time of the download I was able to upgrade 6 other arc's by
  7696. > just using UNIX tftp.  When I was finished, SDL via TCM still had a
  7697. > another few minutes to go!  Each tftp via UNIX took just 43 seconds.
  7698. > 
  7699. > Brian
  7700. > 
  7701. > 
  7702. > -----------------------------------------------------
  7703. > Brian Feeny (BF304)     signal@shreve.net   
  7704. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  7705. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  7706. > 
  7707. > 
  7708. > -
  7709. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7710. >  with "unsubscribe usr-tc" in the body of the message.
  7711. >  For information on digests or retrieving files and old messages send
  7712. >  "help" to the same address.  Do not use quotes in your message.
  7713. > 
  7714.  
  7715.  
  7716. -
  7717.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7718.  with "unsubscribe usr-tc" in the body of the message.
  7719.  For information on digests or retrieving files and old messages send
  7720.  "help" to the same address.  Do not use quotes in your message.
  7721.  
  7722.  
  7723. -------------------------------------------------------------------------------
  7724.  
  7725. From: Mike Andrews <mandrews@termfrost.org>
  7726. Subject: Re: (usr-tc) TCM vs. TFTP
  7727. Date: 09 Apr 1999 02:18:24 -0400 (EDT)
  7728.  
  7729. On Fri, 9 Apr 1999, David Bolen wrote:
  7730.  
  7731. > The other thing to check is if you're comparing HiperNMCs with older
  7732. > 486 NMCs.  The "wire speed" at which the NMC can receive the new code
  7733. > is far faster on the HiperNMC than the 486 NMC.
  7734.  
  7735. Now here's something I've been meaning to ask about..  I've heard *very*
  7736. little about this "HiPer NMC", other than it seems to be Pentium based
  7737. (what speed?) rather than 486 based.  What else is different about it
  7738. exactly?  Are there any applications yet that require a Pentium one
  7739. instead of a 486(SX)?
  7740.  
  7741.  
  7742. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  7743. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  7744. Microsoft operating system is like a dog without a brick tied to its head."
  7745.  
  7746.  
  7747. -
  7748.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7749.  with "unsubscribe usr-tc" in the body of the message.
  7750.  For information on digests or retrieving files and old messages send
  7751.  "help" to the same address.  Do not use quotes in your message.
  7752.  
  7753.  
  7754. -------------------------------------------------------------------------------
  7755.  
  7756. From: Brian <signal@shreve.net>
  7757. Subject: Re: (usr-tc) TCM vs. TFTP
  7758. Date: 09 Apr 1999 01:39:14 -0500 (CDT)
  7759.  
  7760.  
  7761. > 
  7762. > Unless you're referring to tftp'ing the file directly to the ARC
  7763. > itself, in which case there's a big difference between dumping it to
  7764. > the flash filesystem that way versus going through the NMC's
  7765. > management bus interface (which is much lower bandwidth and smaller
  7766. > packet chunks).  Comparing an NMC download versus a tftp right to the
  7767. > ARC could certainly appear far slower.
  7768. > 
  7769. > -- David
  7770.  
  7771. Yes, that's what I was comparing.  I thought TCM would have tftp'ed it to
  7772. the ARC directly, I didn't realize it still used the NMC for ARC code
  7773. transfers.
  7774.  
  7775.  
  7776. > 
  7777. > -
  7778. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7779. >  with "unsubscribe usr-tc" in the body of the message.
  7780. >  For information on digests or retrieving files and old messages send
  7781. >  "help" to the same address.  Do not use quotes in your message.
  7782. > 
  7783.  
  7784. Brian Feeny (BF304)     signal@shreve.net   
  7785. 318-222-2638 x 109    http://www.shreve.net/~signal      
  7786. Network Administrator   ShreveNet Inc. (ASN 11881)           
  7787.  
  7788.  
  7789. -
  7790.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7791.  with "unsubscribe usr-tc" in the body of the message.
  7792.  For information on digests or retrieving files and old messages send
  7793.  "help" to the same address.  Do not use quotes in your message.
  7794.  
  7795.  
  7796. -------------------------------------------------------------------------------
  7797.  
  7798. From: Brian <signal@shreve.net>
  7799. Subject: (usr-tc) Tftp'ing to the ARC
  7800. Date: 09 Apr 1999 01:43:27 -0500 (CDT)
  7801.  
  7802.  
  7803. Does anyone have any suggestions about what to do when your tftp to an ARC
  7804. fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  7805. worked fine in all my other ARC's.  
  7806.  
  7807. I know I can probably erase the config and start afresh, but I am hoping
  7808. someone has a more recoverable solution.
  7809.  
  7810. Brian
  7811.  
  7812.  
  7813. Brian Feeny (BF304)     signal@shreve.net   
  7814. 318-222-2638 x 109    http://www.shreve.net/~signal      
  7815. Network Administrator   ShreveNet Inc. (ASN 11881)           
  7816.  
  7817.  
  7818. -
  7819.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7820.  with "unsubscribe usr-tc" in the body of the message.
  7821.  For information on digests or retrieving files and old messages send
  7822.  "help" to the same address.  Do not use quotes in your message.
  7823.  
  7824.  
  7825. -------------------------------------------------------------------------------
  7826.  
  7827. From: Corneliu Rudeanu <rudy@dntis.ro>
  7828. Subject: (usr-tc) Configuring a "silent" TC
  7829. Date: 09 Apr 1999 17:43:19 +0300 (EEST)
  7830.  
  7831.  
  7832. Ok I have a TC with the following cards: HiperNMC 3.0/5.6.2, HiperArc
  7833. 19.0.0/4.1.11, 14 QuadModemV34 and a E1 PRI which I upgraded to CAS 1.2.09
  7834. for compatibility with local PTT.
  7835.  
  7836. I configured the modems' source to priTdm, I made the DS0<-> Modem
  7837. configuration and set Modem Call Routing method to fixedAssignement.
  7838.  
  7839. When I try to make a dialup connection (from a client, via E1 phone
  7840. numbers) I hear nothing (no rings). While enabling Call Control debugs
  7841. from the CAS Debug (pressing ^D ; btw: this keyboard shortcut is not
  7842. documented, as far as I read; are there any more?) I get the following
  7843. debug lines:
  7844.  
  7845. Menu Selection: (1-18):ds0_res_call_type: dsl: 0, intid: 0, ds0: 1, bct: 73, err: 0 verdict: 1
  7846. get_fixed_mdm: span=0, ds0=2, mdm_id=4, err=0
  7847. release_ds0: span=0, ds0=2
  7848. sfn:ucc_null,evt:20-SETUP_IND,tcid:3328,ucid:0000000C
  7849. ERR:ucc_gen_error,ucc_setup_in_call,uccidm_allow_mdm_calls,fail,drop_call:,err:0
  7850. Note: releasing uccb,  DE-ALLOC tcid:3328, ucid: 0000000C
  7851. release_ds0: span=0, ds0=2
  7852. uccu_release_bchs > DE-ALLOC ucid: c
  7853. release_ds0: span=0, ds0=2
  7854.  
  7855.  
  7856. Again, displaying 'Call Control General Error Counters' I get:
  7857.  
  7858. Menu Selection: (1-18):13
  7859. Print Call Control General Error Count
  7860. Call Control General Error Counters:
  7861. Din Drop Call no Free MDM:                    0
  7862. Din Drop Call MDMs not allowed:               15
  7863. Din Drop Call MDM(s) reject call:             0
  7864. Din Drop Call MDM(s) setup to:                0
  7865. Din Drop Call no TDM TS avail:                0
  7866.  
  7867. Yet, I'd note that configuring the modems for NIC source, everything
  7868. worked OK.
  7869.  
  7870. Any hints?
  7871.  
  7872.  
  7873. Corneliu Rudeanu
  7874. DNT Romania
  7875.  
  7876.  
  7877.  
  7878. -
  7879.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7880.  with "unsubscribe usr-tc" in the body of the message.
  7881.  For information on digests or retrieving files and old messages send
  7882.  "help" to the same address.  Do not use quotes in your message.
  7883.  
  7884.  
  7885. -------------------------------------------------------------------------------
  7886.  
  7887. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  7888. Subject: RE: (usr-tc) ISDN connect failures
  7889. Date: 09 Apr 1999 10:21:43 -0500 (CDT)
  7890.  
  7891. On Thu, 8 Apr 1999, Blake Fithen wrote:
  7892.  
  7893. > OK - not to be a jerk or anything but I'd rather not try to open
  7894. > a case just yet - with an exception of a few individuals at 3com 
  7895. > tech support, I am thoroughly frustrated with the QOS I pay for 
  7896. > and it's too much of a pain to tell whoever picks up the case to
  7897. > go find the competent ones. But that's a different problem.
  7898. > 
  7899.  
  7900. Well we need to access your chassis and debug the DSP and the hiper arc.  
  7901. For this we need to get someone in support to work with you.  And this 
  7902. requires a ticket.  Open a support ticket and send me an email with the 
  7903. ticket number - I will talk with the tech and get help him analyze the 
  7904. problem.
  7905.  
  7906. > I Did a "add tap user blakehome screen" waited for about 10
  7907. > minutes with no tap traffic output even though I was getting
  7908. > same dialog as before in Performance monitor with my SPID in the
  7909. > appropriate column.  Then, all of the sudden the TAP traffic
  7910. > started and my ISDN device got logged in.  Some TAP output with
  7911. > lots of "IN:" and "OUT:" from the top was lost.  So what does
  7912. > this tell me?
  7913. > 
  7914. This does not tell me much either - we need ascii and hex dump to see 
  7915. what is happening.
  7916.  
  7917. regards
  7918.  
  7919. krish
  7920.  
  7921.  
  7922. > TAP USER blakehome on slot:14/mod:3  IN:   11: ....<abcdefghijk
  7923. > TAP USER blakehome on slot:14/mod:3  IN:   11: lmnopqrstuvwxyza
  7924. > TAP USER blakehome on slot:14/mod:3  IN:   11: bcdef
  7925. > TAP USER blakehome on slot:14/mod:3  IN:   12: ...=....!E..4F..
  7926. > TAP USER blakehome on slot:14/mod:3  IN:   12: .@.0............
  7927. > TAP USER blakehome on slot:14/mod:3  IN:   12: .. s............
  7928. > TAP USER blakehome on slot:14/mod:3  IN:   12: .............
  7929. > TAP USER blakehome on slot:14/mod:3  IN:   13: ...=....!E..4F..
  7930. > TAP USER blakehome on slot:14/mod:3  IN:   13: .@.0............
  7931. > TAP USER blakehome on slot:14/mod:3  IN:   13: .. s............
  7932. > TAP USER blakehome on slot:14/mod:3  IN:   13: .............
  7933. > TAP USER blakehome on slot:14/mod:3  IN:   14: ...=....!E..4F..
  7934. > TAP USER blakehome on slot:14/mod:3  IN:   14: .@.0............
  7935. > TAP USER blakehome on slot:14/mod:3  IN:   14: .. s............
  7936. > TAP USER blakehome on slot:14/mod:3  IN:   14: .............
  7937. > TAP USER blakehome on slot:14/mod:3  IN:   15: ...=....!E..4F..
  7938. > TAP USER blakehome on slot:14/mod:3  IN:   15: .@.0............
  7939. > TAP USER blakehome on slot:14/mod:3  IN:   15: .. s............
  7940. > TAP USER blakehome on slot:14/mod:3  IN:   15: .............
  7941. > TAP USER blakehome on slot:14/mod:3 OUT:   16: ...!E..<u+..~...
  7942. > TAP USER blakehome on slot:14/mod:3 OUT:   16: ...............<
  7943. > TAP USER blakehome on slot:14/mod:3 OUT:   16: abcdefghijklmnop
  7944. > TAP USER blakehome on slot:14/mod:3 OUT:   16: qrstuvwxyzabcdef
  7945. > TAP USER blakehome on slot:14/mod:3  IN:   17: ...=....!E..<F..
  7946. > TAP USER blakehome on slot:14/mod:3  IN:   17: ...s............
  7947. > TAP USER blakehome on slot:14/mod:3  IN:   17: ....<abcdefghijk
  7948. > TAP USER blakehome on slot:14/mod:3  IN:   17: lmnopqrstuvwxyza
  7949. > TAP USER blakehome on slot:14/mod:3  IN:   17: bcdef
  7950. > TAP USER blakehome on slot:14/mod:3  IN:   18: ...=....!E..4F..
  7951. > TAP USER blakehome on slot:14/mod:3  IN:   18: .@./............
  7952. > TAP USER blakehome on slot:14/mod:3  IN:   18: .. s............
  7953. > TAP USER blakehome on slot:14/mod:3  IN:   18: .............          
  7954. > 
  7955. > 
  7956. > 
  7957. > > -----Original Message-----
  7958. > > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com]
  7959. > > Sent: Thursday, April 08, 1999 4:10 PM
  7960. > > To: Blake Fithen
  7961. > > Cc: usr-tc@lists.xmission.com
  7962. > > Subject: Re: (usr-tc) ISDN connect failures
  7963. > > 
  7964. > > 
  7965. > > On Thu, 8 Apr 1999, Blake Fithen wrote:
  7966. > > 
  7967. > > > hello, we're having a trouble with ISDN customers not being
  7968. > > > able to connect for extended periods of time.  The caller will
  7969. > > > be online for any amount of time, then the connection is
  7970. > > > dropped.  After that they repeatedly try to connect without 
  7971. > > > success.  This is happening to several makes/models of 
  7972. > > > ISDN router.  I can see them hitting the modem but the call
  7973. > > > never completes. No radius dialog, no ppp dialog using
  7974. > > > "mon radius" and "mon ppp".  TCM shows "RingRcvd" and
  7975. > > > then "Link negotiation" in the "Operational Status of a
  7976. > > > modem" column.  About 10 seconds later the call drops and 
  7977. > > > the "Reason for call failure" column shows
  7978. > > > "normaUserCallClear(73)" then the cycle continues.  But
  7979. > > > without intervention or any resetting on the hubs they
  7980. > > > eventually connect anywhere from 10 minutes to several
  7981. > > > hours later.  I'm running 1.2.43 and 4.1.59-6. PPP offloading
  7982. > > > is enabled and PPP BACP and BAP are disabled.  We
  7983. > > > have a totally different ARC chassis running the same code
  7984. > > > revisions but the problem remains with that chassis.  The
  7985. > > > chassis has 6 DSP's, one ARC and one 70 AMP PSU.  
  7986. > > 
  7987. > > Need to find out what is happening when the call is being presented.  
  7988. > > From the information above it looks like the call is never 
  7989. > > completed.  We 
  7990. > > would need enable tap on the hiper arc and see if the modem 
  7991. > > is presenting 
  7992. > > the call or not to the hiper arc.  Would recommend that you 
  7993. > > open a ticket 
  7994. > > for a tech to collect info.
  7995. > > 
  7996. > > regards
  7997. > > 
  7998. > > krish
  7999. > > 
  8000. > > > 
  8001. > > > Any thoughts would be greatly appreciated.
  8002. > > > blake
  8003. > > > 
  8004. > > > syslog output:
  8005. > > > 
  8006. > > > x.x.x.x:     Thu Apr  8 12:08:09:     <38>At 11:11:48, 
  8007. > > Facility "Auth
  8008. > > > Facility", Level "COMMON":: The connection for call id 
  8009. > > 218235631, on if
  8010. > > > slot:14/mod:3 was dropped for user UNKNOWN
  8011. > > > x.x.x.x:     Thu Apr  8 12:08:16:     <38>At 11:11:55, 
  8012. > > Facility "Auth
  8013. > > > Facility", Level "VERBOSE":: A call, call id = 218235632, 
  8014. > > has arrived on
  8015. > > > interface slot:14/mod:3
  8016. > > > x.x.x.x:     Thu Apr  8 12:08:47:     <38>At 11:12:25, 
  8017. > > Facility "Auth
  8018. > > > Facility", Level "VERBOSE":: A call, call id = 218235633, 
  8019. > > has arrived on
  8020. > > > interface slot:14/mod:3
  8021. > > > x.x.x.x:     Thu Apr  8 12:09:07:     <38>At 11:12:46, 
  8022. > > Facility "Auth
  8023. > > > Facility", Level "COMMON":: A call is established, call id 
  8024. > > 218235633, on
  8025. > > > interface slot:14/mod:3
  8026. > > > x.x.x.x:     Thu Apr  8 12:09:10:     <38>At 11:12:49, 
  8027. > > Facility "Auth
  8028. > > > Facility", Level "COMMON":: The connection for call id 
  8029. > > 218235633, on if
  8030. > > > slot:14/mod:3 was dropped for user UNKNOWN
  8031. > > > x.x.x.x:     Thu Apr  8 12:09:17:     <38>At 11:12:55, 
  8032. > > Facility "Auth
  8033. > > > Facility", Level "VERBOSE":: A call, call id = 218235634, 
  8034. > > has arrived on
  8035. > > > interface slot:14/mod:3
  8036. > > > x.x.x.x:     Thu Apr  8 12:09:47:     <38>At 11:13:25, 
  8037. > > Facility "Auth
  8038. > > > Facility", Level "VERBOSE":: A call, call id = 218235635, 
  8039. > > has arrived on
  8040. > > > interface slot:14/mod:3
  8041. > > > x.x.x.x:     Thu Apr  8 12:10:07:     <38>At 11:13:46, 
  8042. > > Facility "Auth
  8043. > > > Facility", Level "COMMON":: A call is established, call id 
  8044. > > 218235635, on
  8045. > > > interface slot:14/mod:3
  8046. > > > x.x.x.x:     Thu Apr  8 12:10:10:     <38>At 11:13:49, 
  8047. > > Facility "Auth
  8048. > > > Facility", Level "COMMON":: The connection for call id 
  8049. > > 218235635, on if
  8050. > > > slot:14/mod:3 was dropped for user UNKNOWN
  8051. > > > x.x.x.x:     Thu Apr  8 12:10:17:     <38>At 11:13:56, 
  8052. > > Facility "Auth
  8053. > > > Facility", Level "VERBOSE":: A call, call id = 218235636, 
  8054. > > has arrived on
  8055. > > > interface slot:14/mod:3
  8056. > > > x.x.x.x:     Thu Apr  8 12:10:32:     <38>At 11:14:11, 
  8057. > > Facility "Auth
  8058. > > > Facility", Level "COMMON":: A call is established, call id 
  8059. > > 218235636, on
  8060. > > > interface slot:14/mod:3
  8061. > > > x.x.x.x:     Thu Apr  8 12:10:41:     <38>At 11:14:19, 
  8062. > > Facility "Auth
  8063. > > > Facility", Level "COMMON":: The connection for call id 
  8064. > > 218235636, on if
  8065. > > > slot:14/mod:3 was dropped for user UNKNOWN
  8066. > > > 
  8067. > > > -
  8068. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8069. > > >  with "unsubscribe usr-tc" in the body of the message.
  8070. > > >  For information on digests or retrieving files and old 
  8071. > > messages send
  8072. > > >  "help" to the same address.  Do not use quotes in your message.
  8073. > > > 
  8074. > > 
  8075. > > -
  8076. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8077. > >  with "unsubscribe usr-tc" in the body of the message.
  8078. > >  For information on digests or retrieving files and old messages send
  8079. > >  "help" to the same address.  Do not use quotes in your message.
  8080. > > 
  8081. > 
  8082. > -
  8083. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8084. >  with "unsubscribe usr-tc" in the body of the message.
  8085. >  For information on digests or retrieving files and old messages send
  8086. >  "help" to the same address.  Do not use quotes in your message.
  8087. > 
  8088.  
  8089. -
  8090.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8091.  with "unsubscribe usr-tc" in the body of the message.
  8092.  For information on digests or retrieving files and old messages send
  8093.  "help" to the same address.  Do not use quotes in your message.
  8094.  
  8095.  
  8096. -------------------------------------------------------------------------------
  8097.  
  8098. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  8099. Subject: Re: (usr-tc) CRC error on boot configuration
  8100. Date: 09 Apr 1999 10:26:23 -0500 (CDT)
  8101.  
  8102. On Thu, 8 Apr 1999, d baud wrote:
  8103.  
  8104. > I just received a HiperCard that I installed on the chassis:
  8105. > I plugged the console cable to perform the quicksetup routine and I
  8106. > noticed that it gave me the following error as soon as it did a Save
  8107. > All.
  8108. > The error message is the following:
  8109. > WARNING: CRC error on boot configuration. Defaulting it
  8110. > (repeating for about 15 lines)
  8111. > 
  8112. > At first I suspected the code used was faulty, so I reseated the card
  8113. > and issued the regular AT{Z} command to send the current ne040159-6.dmf
  8114. > code.  Once finished, I try a "save all" and still nothing happens.
  8115. > 
  8116. > I then decided to do a: AT{ZF} command with the same code.
  8117. > Unfortunately still the same error message
  8118. > 
  8119. > I then called the tech people at USR, and the lady said that this might
  8120. > be a debug and unharmful code.  So she issued some command to remove
  8121. > those messages and refused to tell me what it was because it was "too
  8122. > dificult to understand" 
  8123. > Well now I don't get the error message when I "save all" but the
  8124. > following error apears at boot time:
  8125. > Error writing configuration to EEPROM
  8126. > WARNING: CRC error on boot configuration. Defaulting it
  8127. EEPROM ... Downloading code does not write to the EEPROM.  This looks 
  8128. like that for some reason the EEPROM has been erased.  What is the ticket 
  8129. number?  that way can get access to your card and see what is being 
  8130. done.  As far as I know there is no debug code etc.  Get me the ticket 
  8131. number will talk to the lady.
  8132.  
  8133. krish
  8134.  
  8135.  
  8136. > 
  8137. > Anyone had this issue before ?
  8138. > 
  8139. > Donald Baud
  8140. > 
  8141. > -
  8142. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8143. >  with "unsubscribe usr-tc" in the body of the message.
  8144. >  For information on digests or retrieving files and old messages send
  8145. >  "help" to the same address.  Do not use quotes in your message.
  8146. > 
  8147.  
  8148. -
  8149.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8150.  with "unsubscribe usr-tc" in the body of the message.
  8151.  For information on digests or retrieving files and old messages send
  8152.  "help" to the same address.  Do not use quotes in your message.
  8153.  
  8154.  
  8155. -------------------------------------------------------------------------------
  8156.  
  8157. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  8158. Subject: Re: (usr-tc) TCM vs. TFTP
  8159. Date: 09 Apr 1999 10:28:16 -0500 (CDT)
  8160.  
  8161. On Fri, 9 Apr 1999, Brian wrote:
  8162.  
  8163. > 
  8164. > Why is TCM so slow?  I started a transfer of 4.1.59-6 from TCM into 2
  8165. > ARC's via Software Download.
  8166. > 
  8167. > During the time of the download I was able to upgrade 6 other arc's by
  8168. > just using UNIX tftp.  When I was finished, SDL via TCM still had a
  8169. > another few minutes to go!  Each tftp via UNIX took just 43 seconds.
  8170.  
  8171. Using TCM you are sending the code to the nmc which is then sending the 
  8172. file via management bus to the hiper arc - which is slow.
  8173.  
  8174. krish
  8175.  
  8176. > 
  8177. > Brian
  8178. > 
  8179. > 
  8180. > -----------------------------------------------------
  8181. > Brian Feeny (BF304)     signal@shreve.net   
  8182. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  8183. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  8184. > 
  8185. > 
  8186. > -
  8187. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8188. >  with "unsubscribe usr-tc" in the body of the message.
  8189. >  For information on digests or retrieving files and old messages send
  8190. >  "help" to the same address.  Do not use quotes in your message.
  8191. > 
  8192.  
  8193. -
  8194.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8195.  with "unsubscribe usr-tc" in the body of the message.
  8196.  For information on digests or retrieving files and old messages send
  8197.  "help" to the same address.  Do not use quotes in your message.
  8198.  
  8199.  
  8200. -------------------------------------------------------------------------------
  8201.  
  8202. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  8203. Subject: Re: (usr-tc) Tftp'ing to the ARC
  8204. Date: 09 Apr 1999 10:29:38 -0500 (CDT)
  8205.  
  8206. On Fri, 9 Apr 1999, Brian wrote:
  8207.  
  8208. > 
  8209. > Does anyone have any suggestions about what to do when your tftp to an ARC
  8210. > fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  8211. > worked fine in all my other ARC's.  
  8212. > 
  8213. > I know I can probably erase the config and start afresh, but I am hoping
  8214. > someone has a more recoverable solution.
  8215.  
  8216. You can program the hiper arc to get the file on boot up from a tftp 
  8217. server.  
  8218. do a set bootr ip ?
  8219. you will see the command necessary
  8220.  
  8221. krish
  8222.  
  8223. > 
  8224. > Brian
  8225. > 
  8226. > 
  8227. > -----------------------------------------------------
  8228. > Brian Feeny (BF304)     signal@shreve.net   
  8229. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  8230. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  8231. > 
  8232. > 
  8233. > -
  8234. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8235. >  with "unsubscribe usr-tc" in the body of the message.
  8236. >  For information on digests or retrieving files and old messages send
  8237. >  "help" to the same address.  Do not use quotes in your message.
  8238. > 
  8239.  
  8240. -
  8241.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8242.  with "unsubscribe usr-tc" in the body of the message.
  8243.  For information on digests or retrieving files and old messages send
  8244.  "help" to the same address.  Do not use quotes in your message.
  8245.  
  8246.  
  8247. -------------------------------------------------------------------------------
  8248.  
  8249. From: matthews <matthews@brunnet.net>
  8250. Subject: RE: (usr-tc) ISDN connect failures
  8251. Date: 09 Apr 1999 12:17:51 -0300
  8252.  
  8253. On Friday, April 09, 1999 12:22 PM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote:
  8254. > Well we need to access your chassis and debug the DSP and the hiper arc.  
  8255. > For this we need to get someone in support to work with you.  And this 
  8256. > requires a ticket.  Open a support ticket and send me an email with the 
  8257. > ticket number - I will talk with the tech and get help him analyze the 
  8258. > problem.
  8259. >
  8260.  
  8261. Is it possible to open a ticket without a support contract?
  8262.  
  8263.  
  8264. -
  8265.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8266.  with "unsubscribe usr-tc" in the body of the message.
  8267.  For information on digests or retrieving files and old messages send
  8268.  "help" to the same address.  Do not use quotes in your message.
  8269.  
  8270.  
  8271. -------------------------------------------------------------------------------
  8272.  
  8273. From: Brian Elfert <brian@citilink.com>
  8274. Subject: Re: (usr-tc) RIP updates on assigned pool
  8275. Date: 09 Apr 1999 10:27:32 -0500 (CDT)
  8276.  
  8277.  
  8278.  
  8279. On Thu, 8 Apr 1999, Pete Ashdown wrote:
  8280.  
  8281. > >Any ideas?  On the Cisco, I can see updates coming in, but none from any
  8282. > >of the IP pools on some of the Netservers.
  8283. > 
  8284. > There was a bug that had this effect a long time ago.  Unfortunately, I
  8285. > can't remember the details of it.  If you search back through the archives
  8286. > you'll probably find me bitching about it.  I seem to remember the solution
  8287. > was a code-update, so I don't know why you're suffering from it.
  8288.  
  8289. David Bolen helped me fix this.  RIPv1 is classful.  It was just
  8290. broadcasting the route for the /24 since the /32s are in that /24.
  8291.  
  8292. Adding the dialup /24s to the netmask table with a netmask of
  8293. 255.255.255.255 fixed things right up.
  8294.  
  8295. Now, I'm thinking of switching to RIPv2.  Anybody have any tips on doing
  8296. that?  Is it worth it?
  8297.  
  8298. Brian
  8299.  
  8300.  
  8301. -
  8302.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8303.  with "unsubscribe usr-tc" in the body of the message.
  8304.  For information on digests or retrieving files and old messages send
  8305.  "help" to the same address.  Do not use quotes in your message.
  8306.  
  8307.  
  8308. -------------------------------------------------------------------------------
  8309.  
  8310. From: Jeff Mcadams <jeffm@iglou.com>
  8311. Subject: Re: (usr-tc) RIP updates on assigned pool
  8312. Date: 09 Apr 1999 12:20:06 -0400 (EDT)
  8313.  
  8314. Thus spake Brian Elfert
  8315. >Now, I'm thinking of switching to RIPv2.  Anybody have any tips on doing
  8316. >that?  Is it worth it?
  8317.  
  8318. RIPv2 is pretty much backward compatible with RIPv2, so just switch your
  8319. stuff to start using RIPv2 and it'll pretty much just work.  I'd start
  8320. with your cisco router to begin with, and then switch everything else.
  8321.  
  8322. Yes, its most definitely worth it.  Things just work better when you
  8323. have a routing protocol that has an understanding of netmasks.  :)
  8324. -- 
  8325. Jeff McAdams                            Email: jeffm@iglou.com
  8326. Head Network Administrator              Voice: (502) 966-3848
  8327. IgLou Internet Services                        (800) 436-4456
  8328.  
  8329. -
  8330.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8331.  with "unsubscribe usr-tc" in the body of the message.
  8332.  For information on digests or retrieving files and old messages send
  8333.  "help" to the same address.  Do not use quotes in your message.
  8334.  
  8335.  
  8336. -------------------------------------------------------------------------------
  8337.  
  8338. From: David Bolen <db3l@ans.net>
  8339. Subject: Re: (usr-tc) TCM vs. TFTP
  8340. Date: 09 Apr 1999 14:09:35 EDT
  8341.  
  8342. Brian <signal@shreve.net> writes:
  8343.  
  8344. > Yes, that's what I was comparing.  I thought TCM would have tftp'ed it to
  8345. > the ARC directly, I didn't realize it still used the NMC for ARC code
  8346. > transfers.
  8347.  
  8348. If you think about it, it makes sense.  TCM only knows the IP address
  8349. (and community strings and such) for your NMC.  Everything it does is
  8350. via the NMC, downloads included.
  8351.  
  8352. To directly do the ARC, it would have to know all the individual IP
  8353. addresses and maintain separate connections to them, not to mention
  8354. having to do distinct tftps rather than a single one via the NMC.  Not
  8355. to mention handling the ARC completely separately from any other card.
  8356.  
  8357. It's a bit slower, but it's more standardized to stick with NMC
  8358. approach, which is what we also do with our tools.  An ARC download
  8359. may take 10-12 minutes or so (although it doesn't grow linearly with
  8360. multiple cards) but it's handled just as another component compared to
  8361. all other cards, which I consider a big advantage.
  8362.  
  8363. -- David
  8364.  
  8365. /-----------------------------------------------------------------------\
  8366.  \               David Bolen              \  Internet: db3l@ans.net    /
  8367.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  8368.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  8369. \-----------------------------------------------------------------------/
  8370.  
  8371. -
  8372.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8373.  with "unsubscribe usr-tc" in the body of the message.
  8374.  For information on digests or retrieving files and old messages send
  8375.  "help" to the same address.  Do not use quotes in your message.
  8376.  
  8377.  
  8378. -------------------------------------------------------------------------------
  8379.  
  8380. From: David Bolen <db3l@ans.net>
  8381. Subject: Re: (usr-tc) RIP updates on assigned pool
  8382. Date: 09 Apr 1999 14:13:12 EDT
  8383.  
  8384. Brian Elfert <brian@citilink.com> writes:
  8385.  
  8386. > Now, I'm thinking of switching to RIPv2.  Anybody have any tips on doing
  8387. > that?  Is it worth it?
  8388.  
  8389. To my mind it depends on your configuration, and what you do with
  8390. those routes after they leave the NETServer.  When it comes down to
  8391. it, all RIPv2 is going to buy you is the ability to announce an
  8392. arbitrary prefix size.
  8393.  
  8394. In our case, the routes never do anything more than get installed on a
  8395. local Cisco (propagation beyond that point is not from RIP
  8396. redistribution), so we've never bothered to switch beyond RIPv1.  It
  8397. does the job of getting that last "next hop" right just fine.
  8398.  
  8399. However, if you're automatically redistributing such routes into other
  8400. IGPs such as OSPF or IBGP then RIPv2 may permit you to avoid injecting
  8401. host routes and instead use more appropriate prefix sizes.
  8402.  
  8403. -- David
  8404.  
  8405. /-----------------------------------------------------------------------\
  8406.  \               David Bolen              \  Internet: db3l@ans.net    /
  8407.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  8408.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  8409. \-----------------------------------------------------------------------/
  8410.  
  8411. -
  8412.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8413.  with "unsubscribe usr-tc" in the body of the message.
  8414.  For information on digests or retrieving files and old messages send
  8415.  "help" to the same address.  Do not use quotes in your message.
  8416.  
  8417.  
  8418. -------------------------------------------------------------------------------
  8419.  
  8420. From: Jeff Mcadams <jeffm@iglou.com>
  8421. Subject: Re: (usr-tc) TCM vs. TFTP
  8422. Date: 09 Apr 1999 14:23:37 -0400 (EDT)
  8423.  
  8424. Thus spake David Bolen
  8425. >Brian <signal@shreve.net> writes:
  8426. >> Yes, that's what I was comparing.  I thought TCM would have tftp'ed
  8427. >> it to the ARC directly, I didn't realize it still used the NMC for
  8428. >> ARC code transfers.
  8429.  
  8430. >If you think about it, it makes sense.  TCM only knows the IP address
  8431. >(and community strings and such) for your NMC.  Everything it does is
  8432. >via the NMC, downloads included.
  8433.  
  8434. >To directly do the ARC, it would have to know all the individual IP
  8435. >addresses and maintain separate connections to them, not to mention
  8436. >having to do distinct tftps rather than a single one via the NMC.  Not
  8437. >to mention handling the ARC completely separately from any other card.
  8438.  
  8439. Very true in all cases...however one minor nit here.  :)
  8440.  
  8441. It is conceivable that TCM could come up with the IP addresses of the
  8442. Arcs...it would just have to hit the NMC's SNMP agent to get them.
  8443. Keeping in mind that the NMC can get the IP address for the Arc via the
  8444. management bus.
  8445.  
  8446. Yes, this is extremely convoluted and pointless, but it *could* be done.
  8447. :)
  8448. -- 
  8449. Jeff McAdams                            Email: jeffm@iglou.com
  8450. Head Network Administrator              Voice: (502) 966-3848
  8451. IgLou Internet Services                        (800) 436-4456
  8452.  
  8453. -
  8454.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8455.  with "unsubscribe usr-tc" in the body of the message.
  8456.  For information on digests or retrieving files and old messages send
  8457.  "help" to the same address.  Do not use quotes in your message.
  8458.  
  8459.  
  8460. -------------------------------------------------------------------------------
  8461.  
  8462. From: "Tony Loosle" <tony@tcsourceone.com>
  8463. Subject: (usr-tc) For sale USR Netserver 8I
  8464. Date: 09 Apr 1999 13:35:22 -0600
  8465.  
  8466. For sale, USR Netserver 8I box.  has v.90 installed.
  8467.  
  8468. tony
  8469.  
  8470.  
  8471.  
  8472. -
  8473.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8474.  with "unsubscribe usr-tc" in the body of the message.
  8475.  For information on digests or retrieving files and old messages send
  8476.  "help" to the same address.  Do not use quotes in your message.
  8477.  
  8478.  
  8479. -------------------------------------------------------------------------------
  8480.  
  8481. From: Brian <signal@shreve.net>
  8482. Subject: (usr-tc) netopia
  8483. Date: 09 Apr 1999 18:53:43 -0500 (CDT)
  8484.  
  8485.  
  8486. Any issues known between Netopia ISDN routers and 1.2.43/4.1.59-6?
  8487.  
  8488. Brian
  8489.  
  8490.  
  8491. Brian Feeny (BF304)     signal@shreve.net   
  8492. 318-222-2638 x 109    http://www.shreve.net/~signal      
  8493. Network Administrator   ShreveNet Inc. (ASN 11881)           
  8494.  
  8495.  
  8496. -
  8497.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8498.  with "unsubscribe usr-tc" in the body of the message.
  8499.  For information on digests or retrieving files and old messages send
  8500.  "help" to the same address.  Do not use quotes in your message.
  8501.  
  8502.  
  8503. -------------------------------------------------------------------------------
  8504.  
  8505. From: Brian <signal@shreve.net>
  8506. Subject: Re: (usr-tc) Tftp'ing to the ARC
  8507. Date: 09 Apr 1999 21:04:14 -0500 (CDT)
  8508.  
  8509. On Fri, 9 Apr 1999, Tatai SV Krishnan wrote:
  8510.  
  8511. > On Fri, 9 Apr 1999, Brian wrote:
  8512. > 
  8513. > > 
  8514. > > Does anyone have any suggestions about what to do when your tftp to an ARC
  8515. > > fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  8516. > > worked fine in all my other ARC's.  
  8517. > > 
  8518. > > I know I can probably erase the config and start afresh, but I am hoping
  8519. > > someone has a more recoverable solution.
  8520. > 
  8521. > You can program the hiper arc to get the file on boot up from a tftp 
  8522. > server.  
  8523. > do a set bootr ip ?
  8524. > you will see the command necessary
  8525.  
  8526. But aren't the odds that if I was unable to tftp the netserve.dmf into the
  8527. ARC, that the arc won't be able to tftp the file into itself upon bootup
  8528. either?  I mean, woudln't I still probably need to erase the config?
  8529.  
  8530.  
  8531. > 
  8532. > krish
  8533. > 
  8534. > > 
  8535. > > Brian
  8536. > > 
  8537. > > 
  8538. > > -----------------------------------------------------
  8539. > > Brian Feeny (BF304)     signal@shreve.net   
  8540. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  8541. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  8542. > > 
  8543. > > 
  8544. > > -
  8545. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8546. > >  with "unsubscribe usr-tc" in the body of the message.
  8547. > >  For information on digests or retrieving files and old messages send
  8548. > >  "help" to the same address.  Do not use quotes in your message.
  8549. > > 
  8550. > 
  8551. > -
  8552. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8553. >  with "unsubscribe usr-tc" in the body of the message.
  8554. >  For information on digests or retrieving files and old messages send
  8555. >  "help" to the same address.  Do not use quotes in your message.
  8556. > 
  8557.  
  8558. Brian Feeny (BF304)     signal@shreve.net   
  8559. 318-222-2638 x 109    http://www.shreve.net/~signal      
  8560. Network Administrator   ShreveNet Inc. (ASN 11881)           
  8561.  
  8562.  
  8563. -
  8564.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8565.  with "unsubscribe usr-tc" in the body of the message.
  8566.  For information on digests or retrieving files and old messages send
  8567.  "help" to the same address.  Do not use quotes in your message.
  8568.  
  8569.  
  8570. -------------------------------------------------------------------------------
  8571.  
  8572. From: Brian <signal@shreve.net>
  8573. Subject: Re: (usr-tc) Tftp'ing to the ARC
  8574. Date: 09 Apr 1999 21:04:14 -0500 (CDT)
  8575.  
  8576. On Fri, 9 Apr 1999, Tatai SV Krishnan wrote:
  8577.  
  8578. > On Fri, 9 Apr 1999, Brian wrote:
  8579. > 
  8580. > > 
  8581. > > Does anyone have any suggestions about what to do when your tftp to an ARC
  8582. > > fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  8583. > > worked fine in all my other ARC's.  
  8584. > > 
  8585. > > I know I can probably erase the config and start afresh, but I am hoping
  8586. > > someone has a more recoverable solution.
  8587. > 
  8588. > You can program the hiper arc to get the file on boot up from a tftp 
  8589. > server.  
  8590. > do a set bootr ip ?
  8591. > you will see the command necessary
  8592.  
  8593. But aren't the odds that if I was unable to tftp the netserve.dmf into the
  8594. ARC, that the arc won't be able to tftp the file into itself upon bootup
  8595. either?  I mean, woudln't I still probably need to erase the config?
  8596.  
  8597.  
  8598. > 
  8599. > krish
  8600. > 
  8601. > > 
  8602. > > Brian
  8603. > > 
  8604. > > 
  8605. > > -----------------------------------------------------
  8606. > > Brian Feeny (BF304)     signal@shreve.net   
  8607. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  8608. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  8609. > > 
  8610. > > 
  8611. > > -
  8612. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8613. > >  with "unsubscribe usr-tc" in the body of the message.
  8614. > >  For information on digests or retrieving files and old messages send
  8615. > >  "help" to the same address.  Do not use quotes in your message.
  8616. > > 
  8617. > 
  8618. > -
  8619. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8620. >  with "unsubscribe usr-tc" in the body of the message.
  8621. >  For information on digests or retrieving files and old messages send
  8622. >  "help" to the same address.  Do not use quotes in your message.
  8623. > 
  8624.  
  8625. Brian Feeny (BF304)     signal@shreve.net   
  8626. 318-222-2638 x 109    http://www.shreve.net/~signal      
  8627. Network Administrator   ShreveNet Inc. (ASN 11881)           
  8628.  
  8629.  
  8630. -
  8631.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8632.  with "unsubscribe usr-tc" in the body of the message.
  8633.  For information on digests or retrieving files and old messages send
  8634.  "help" to the same address.  Do not use quotes in your message.
  8635.  
  8636.  
  8637. -------------------------------------------------------------------------------
  8638.  
  8639. From: Jeff Lynch <jeff@mercury.jorsm.com>
  8640. Subject: (usr-tc) USR S&A
  8641. Date: 10 Apr 1999 00:37:20 -0500 (CDT)
  8642.  
  8643. We purchased a small ISP and need to extract their RADIUS user auth db 
  8644. from USR S&A, text delimited would be fine. Does anyone know how to do
  8645. this? 
  8646.  
  8647. --jeff
  8648.  
  8649. ============================================================================ 
  8650. Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
  8651. email: jeff@jorsm.com        | 7 Area Codes in Chicagoland and NW Indiana
  8652. Voice: (219)322-2180        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
  8653. Autoresponse: info@jorsm.com    | Quality Service, Affordable Prices
  8654. http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995
  8655.  
  8656.  
  8657.  
  8658. -
  8659.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8660.  with "unsubscribe usr-tc" in the body of the message.
  8661.  For information on digests or retrieving files and old messages send
  8662.  "help" to the same address.  Do not use quotes in your message.
  8663.  
  8664.  
  8665. -------------------------------------------------------------------------------
  8666.  
  8667. From: Ricky Beam <jfbeam@beaker.interpath.net>
  8668. Subject: Re: (usr-tc) USR S&A
  8669. Date: 10 Apr 1999 01:48:40 -0400 (EDT)
  8670.  
  8671. On Sat, 10 Apr 1999, Jeff Lynch wrote:
  8672. >We purchased a small ISP and need to extract their RADIUS user auth db 
  8673. >from USR S&A, text delimited would be fine. Does anyone know how to do
  8674. >this? 
  8675.  
  8676. Is it an Access database, postgres database, or text file?
  8677.  
  8678. As for the later two, the answer is yes.  For a small fee, I can generate
  8679. almost whatever format you want and even remove the USR password
  8680. encryption :-)
  8681.  
  8682. --Ricky
  8683.  
  8684.  
  8685. -
  8686.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8687.  with "unsubscribe usr-tc" in the body of the message.
  8688.  For information on digests or retrieving files and old messages send
  8689.  "help" to the same address.  Do not use quotes in your message.
  8690.  
  8691.  
  8692. -------------------------------------------------------------------------------
  8693.  
  8694. From: Jeff Lynch <jeff@mercury.jorsm.com>
  8695. Subject: Re: (usr-tc) USR S&A
  8696. Date: 10 Apr 1999 09:03:48 -0500 (CDT)
  8697.  
  8698. On Sat, 10 Apr 1999, Ricky Beam wrote:
  8699.  
  8700. > On Sat, 10 Apr 1999, Jeff Lynch wrote:
  8701. > >We purchased a small ISP and need to extract their RADIUS user auth db 
  8702. > >from USR S&A, text delimited would be fine. Does anyone know how to do
  8703. > >this? 
  8704. > 
  8705. > Is it an Access database, postgres database, or text file?
  8706.  
  8707. Access. Since this was the first time laying hands on USR S&A I
  8708. couldn't find the clicks to get a view of the user table to
  8709. save as text delim.
  8710.  
  8711. > 
  8712. > As for the later two, the answer is yes.  For a small fee, I can generate
  8713. > almost whatever format you want and even remove the USR password
  8714. > encryption :-)
  8715. > 
  8716.  
  8717. Hmm, no way to export the user table from the Access version?
  8718.  
  8719. We just bought a small ISP that's being shut down on Monday. Yeah, it's a
  8720. kind of fire sale, but there's not that many, so we decided to give it a
  8721. shot. One of our urgent problems is that neither of us use any realm
  8722. designations for logins which rules out most proxy solutions. We have
  8723. paper signup forms with handwritten passwords so we could muttle through
  8724. with manual data entry.
  8725.  
  8726. ============================================================================ 
  8727. Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
  8728. email: jeff@jorsm.com        | 7 Area Codes in Chicagoland and NW Indiana
  8729. Voice: (219)322-2180        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
  8730. Autoresponse: info@jorsm.com    | Quality Service, Affordable Prices
  8731. http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995
  8732.  
  8733.  
  8734.  
  8735. -
  8736.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8737.  with "unsubscribe usr-tc" in the body of the message.
  8738.  For information on digests or retrieving files and old messages send
  8739.  "help" to the same address.  Do not use quotes in your message.
  8740.  
  8741.  
  8742. -------------------------------------------------------------------------------
  8743.  
  8744. From: Brian <signal@shreve.net>
  8745. Subject: Re: (usr-tc) USR S&A
  8746. Date: 10 Apr 1999 11:07:01 -0500 (CDT)
  8747.  
  8748. On Sat, 10 Apr 1999, Ricky Beam wrote:
  8749.  
  8750. > On Sat, 10 Apr 1999, Jeff Lynch wrote:
  8751. > >We purchased a small ISP and need to extract their RADIUS user auth db 
  8752. > >from USR S&A, text delimited would be fine. Does anyone know how to do
  8753. > >this? 
  8754. > 
  8755. > Is it an Access database, postgres database, or text file?
  8756. > 
  8757. > As for the later two, the answer is yes.  For a small fee, I can generate
  8758. > almost whatever format you want and even remove the USR password
  8759. > encryption :-)
  8760. > 
  8761.  
  8762. USR S&A works with Postgres?
  8763.  
  8764. > --Ricky
  8765. > 
  8766. > 
  8767. > -
  8768. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8769. >  with "unsubscribe usr-tc" in the body of the message.
  8770. >  For information on digests or retrieving files and old messages send
  8771. >  "help" to the same address.  Do not use quotes in your message.
  8772. > 
  8773.  
  8774. Brian Feeny (BF304)     signal@shreve.net   
  8775. 318-222-2638 x 109    http://www.shreve.net/~signal      
  8776. Network Administrator   ShreveNet Inc. (ASN 11881)           
  8777.  
  8778.  
  8779. -
  8780.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8781.  with "unsubscribe usr-tc" in the body of the message.
  8782.  For information on digests or retrieving files and old messages send
  8783.  "help" to the same address.  Do not use quotes in your message.
  8784.  
  8785.  
  8786. -------------------------------------------------------------------------------
  8787.  
  8788. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  8789. Subject: RE: (usr-tc) USR S&A
  8790. Date: 10 Apr 1999 11:56:48 -0500
  8791.  
  8792.  
  8793.  
  8794. |-----Original Message-----
  8795. |From: owner-usr-tc@lists.xmission.com
  8796. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  8797. |Sent: Saturday, April 10, 1999 11:07 AM
  8798. |To: usr-tc@lists.xmission.com
  8799. |Subject: Re: (usr-tc) USR S&A
  8800. |
  8801. |
  8802. |On Sat, 10 Apr 1999, Ricky Beam wrote:
  8803. |
  8804. |> On Sat, 10 Apr 1999, Jeff Lynch wrote:
  8805. |> >We purchased a small ISP and need to extract their RADIUS user auth db 
  8806. |> >from USR S&A, text delimited would be fine. Does anyone know how to do
  8807. |> >this? 
  8808. |> 
  8809. |> Is it an Access database, postgres database, or text file?
  8810. |> 
  8811. |> As for the later two, the answer is yes.  For a small fee, I can generate
  8812. |> almost whatever format you want and even remove the USR password
  8813. |> encryption :-)
  8814. |> 
  8815. |
  8816. |USR S&A works with Postgres?
  8817. |
  8818.  
  8819. UNIX version does.
  8820.  
  8821. -M
  8822.  
  8823.  
  8824. -
  8825.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8826.  with "unsubscribe usr-tc" in the body of the message.
  8827.  For information on digests or retrieving files and old messages send
  8828.  "help" to the same address.  Do not use quotes in your message.
  8829.  
  8830.  
  8831. -------------------------------------------------------------------------------
  8832.  
  8833. From: Jeff Lynch <jeff@mercury.jorsm.com>
  8834. Subject: RE: (usr-tc) USR S&A
  8835. Date: 10 Apr 1999 12:55:42 -0500 (CDT)
  8836.  
  8837. USR folks, we need to export a user table from the windows/access
  8838. version.
  8839.  
  8840. --jeff
  8841.  
  8842. ============================================================================ 
  8843. Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
  8844. email: jeff@jorsm.com        | 7 Area Codes in Chicagoland and NW Indiana
  8845. Voice: (219)322-2180        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
  8846. Autoresponse: info@jorsm.com    | Quality Service, Affordable Prices
  8847. http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995
  8848.  
  8849. On Sat, 10 Apr 1999, Mike Wronski wrote:
  8850.  
  8851. > 
  8852. > 
  8853. > |-----Original Message-----
  8854. > |From: owner-usr-tc@lists.xmission.com
  8855. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  8856. > |Sent: Saturday, April 10, 1999 11:07 AM
  8857. > |To: usr-tc@lists.xmission.com
  8858. > |Subject: Re: (usr-tc) USR S&A
  8859. > |
  8860. > |
  8861. > |On Sat, 10 Apr 1999, Ricky Beam wrote:
  8862. > |
  8863. > |> On Sat, 10 Apr 1999, Jeff Lynch wrote:
  8864. > |> >We purchased a small ISP and need to extract their RADIUS user auth db 
  8865. > |> >from USR S&A, text delimited would be fine. Does anyone know how to do
  8866. > |> >this? 
  8867. > |> 
  8868. > |> Is it an Access database, postgres database, or text file?
  8869. > |> 
  8870. > |> As for the later two, the answer is yes.  For a small fee, I can generate
  8871. > |> almost whatever format you want and even remove the USR password
  8872. > |> encryption :-)
  8873. > |> 
  8874. > |
  8875. > |USR S&A works with Postgres?
  8876. > |
  8877. > 
  8878. > UNIX version does.
  8879. > 
  8880. > -M
  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. Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
  8892. email: jeff@jorsm.com        | 7 Area Codes in Chicagoland and NW Indiana
  8893. Voice: (219)322-2180        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
  8894. Autoresponse: info@jorsm.com    | Quality Service, Affordable Prices
  8895. http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995
  8896.  
  8897.  
  8898. -
  8899.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8900.  with "unsubscribe usr-tc" in the body of the message.
  8901.  For information on digests or retrieving files and old messages send
  8902.  "help" to the same address.  Do not use quotes in your message.
  8903.  
  8904.  
  8905. -------------------------------------------------------------------------------
  8906.  
  8907. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  8908. Subject: Re: (usr-tc) USR S&A
  8909. Date: 10 Apr 1999 17:34:19 -0500 (CDT)
  8910.  
  8911. On Sat, 10 Apr 1999, Jeff Lynch wrote:
  8912.  
  8913. > We purchased a small ISP and need to extract their RADIUS user auth db 
  8914. > from USR S&A, text delimited would be fine. Does anyone know how to do
  8915. > this? 
  8916.  
  8917. You can get the users info into a access database and then export it to 
  8918. text format.
  8919.  
  8920. krish
  8921.  
  8922. > 
  8923. > --jeff
  8924. > 
  8925. > ============================================================================ 
  8926. > Jeffrey A. Lynch        | JORSM Internet, Regional Internet Services
  8927. > email: jeff@jorsm.com        | 7 Area Codes in Chicagoland and NW Indiana
  8928. > Voice: (219)322-2180        | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN
  8929. > Autoresponse: info@jorsm.com    | Quality Service, Affordable Prices
  8930. > http://www.jorsm.com        | Serving Gov, Biz, Indivds Since 1995
  8931. > 
  8932. > 
  8933. > 
  8934. > -
  8935. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8936. >  with "unsubscribe usr-tc" in the body of the message.
  8937. >  For information on digests or retrieving files and old messages send
  8938. >  "help" to the same address.  Do not use quotes in your message.
  8939. > 
  8940.  
  8941. -
  8942.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8943.  with "unsubscribe usr-tc" in the body of the message.
  8944.  For information on digests or retrieving files and old messages send
  8945.  "help" to the same address.  Do not use quotes in your message.
  8946.  
  8947.  
  8948. -------------------------------------------------------------------------------
  8949.  
  8950. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  8951. Subject: Re: (usr-tc) Tftp'ing to the ARC
  8952. Date: 10 Apr 1999 17:32:08 -0500 (CDT)
  8953.  
  8954. On Fri, 9 Apr 1999, Brian wrote:
  8955.  
  8956. > On Fri, 9 Apr 1999, Tatai SV Krishnan wrote:
  8957. > 
  8958. > > On Fri, 9 Apr 1999, Brian wrote:
  8959. > > 
  8960. > > > 
  8961. > > > Does anyone have any suggestions about what to do when your tftp to an ARC
  8962. > > > fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  8963. > > > worked fine in all my other ARC's.  
  8964. > > > 
  8965. > > > I know I can probably erase the config and start afresh, but I am hoping
  8966. > > > someone has a more recoverable solution.
  8967. > > 
  8968. > > You can program the hiper arc to get the file on boot up from a tftp 
  8969. > > server.  
  8970. > > do a set bootr ip ?
  8971. > > you will see the command necessary
  8972. > 
  8973. > But aren't the odds that if I was unable to tftp the netserve.dmf into the
  8974. > ARC, that the arc won't be able to tftp the file into itself upon bootup
  8975. > either?  I mean, woudln't I still probably need to erase the config?
  8976. > 
  8977.  
  8978. No - the boot process is completely separate process and it copies the 
  8979. new code to flash diffently then a regular tftp process.  This process 
  8980. generally works - if this fails there your flash format is required.
  8981.  
  8982. krish
  8983.  
  8984. > 
  8985. > > 
  8986. > > krish
  8987. > > 
  8988. > > > 
  8989. > > > Brian
  8990. > > > 
  8991. > > > 
  8992. > > > -----------------------------------------------------
  8993. > > > Brian Feeny (BF304)     signal@shreve.net   
  8994. > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  8995. > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  8996. > > > 
  8997. > > > 
  8998. > > > -
  8999. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9000. > > >  with "unsubscribe usr-tc" in the body of the message.
  9001. > > >  For information on digests or retrieving files and old messages send
  9002. > > >  "help" to the same address.  Do not use quotes in your message.
  9003. > > > 
  9004. > > 
  9005. > > -
  9006. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9007. > >  with "unsubscribe usr-tc" in the body of the message.
  9008. > >  For information on digests or retrieving files and old messages send
  9009. > >  "help" to the same address.  Do not use quotes in your message.
  9010. > > 
  9011. > 
  9012. > -----------------------------------------------------
  9013. > Brian Feeny (BF304)     signal@shreve.net   
  9014. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  9015. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  9016. > 
  9017. > 
  9018. > -
  9019. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9020. >  with "unsubscribe usr-tc" in the body of the message.
  9021. >  For information on digests or retrieving files and old messages send
  9022. >  "help" to the same address.  Do not use quotes in your message.
  9023. > 
  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. From: Aaron Nabil <nabil@spiritone.com>
  9035. Subject: (usr-tc) Passwords getting corrupted
  9036. Date: 11 Apr 1999 14:46:55 -0700 (PDT)
  9037.  
  9038.  
  9039. Our radius server (radiator) can log the cleartext passwords sent by
  9040. the client.  I've noticed an interesting pattern, failed attempts followed 
  9041. by succesfull one, with only the last character of the password changed.  It
  9042. has been happening hundreds of times per day.
  9043.  
  9044. An example would be a failed attempt with the password "cooki^X" 
  9045. followed by an succesfull attempt of "cookie".  The transformation isn't
  9046. fixed, if the same user fails again, it might be "cookiZ" he tries before
  9047. "cookie".
  9048.  
  9049. We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  9050.  
  9051. I haven't noticed any correlation between modem speeds, x2/v.90, or
  9052. anything other that it only appears to be happening on our USR chassis.
  9053.  
  9054. -- 
  9055. Aaron Nabil
  9056.  
  9057. -
  9058.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9059.  with "unsubscribe usr-tc" in the body of the message.
  9060.  For information on digests or retrieving files and old messages send
  9061.  "help" to the same address.  Do not use quotes in your message.
  9062.  
  9063.  
  9064. -------------------------------------------------------------------------------
  9065.  
  9066. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  9067. Subject: Re: (usr-tc) Passwords getting corrupted
  9068. Date: 11 Apr 1999 20:24:40 -0500 (CDT)
  9069.  
  9070. On Sun, 11 Apr 1999, Aaron Nabil wrote:
  9071.  
  9072. > 
  9073. > Our radius server (radiator) can log the cleartext passwords sent by
  9074. > the client.  I've noticed an interesting pattern, failed attempts followed 
  9075. > by succesfull one, with only the last character of the password changed.  It
  9076. > has been happening hundreds of times per day.
  9077. > 
  9078. > An example would be a failed attempt with the password "cooki^X" 
  9079. > followed by an succesfull attempt of "cookie".  The transformation isn't
  9080. > fixed, if the same user fails again, it might be "cookiZ" he tries before
  9081. > "cookie".
  9082.  
  9083. Is it possible for you to use the tap feature to capture this info?
  9084. I have heard reports of this but I have not been able to get any one to 
  9085. work with me on this.  If you can either run tap to syslog and capture 
  9086. the data or if this is reproduceble on demand then it would be easy for 
  9087. us to identify the problem.
  9088.  
  9089. If running tap is a problem then you can try disabling ppp offloading and 
  9090. see if this problem exits.  That would give us somegood info.
  9091.  
  9092. regards
  9093. krish
  9094.  
  9095. > 
  9096. > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  9097. > 
  9098. > I haven't noticed any correlation between modem speeds, x2/v.90, or
  9099. > anything other that it only appears to be happening on our USR chassis.
  9100. > 
  9101. > -- 
  9102. > Aaron Nabil
  9103. > 
  9104. > -
  9105. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9106. >  with "unsubscribe usr-tc" in the body of the message.
  9107. >  For information on digests or retrieving files and old messages send
  9108. >  "help" to the same address.  Do not use quotes in your message.
  9109. > 
  9110.  
  9111. -
  9112.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9113.  with "unsubscribe usr-tc" in the body of the message.
  9114.  For information on digests or retrieving files and old messages send
  9115.  "help" to the same address.  Do not use quotes in your message.
  9116.  
  9117.  
  9118. -------------------------------------------------------------------------------
  9119.  
  9120. From: Aaron Nabil <nabil@spiritone.com>
  9121. Subject: Re: (usr-tc) Passwords getting corrupted
  9122. Date: 11 Apr 1999 20:12:45 -0700 (PDT)
  9123.  
  9124. Tatai SV Krishnan writes...
  9125. >On Sun, 11 Apr 1999, Aaron Nabil wrote:
  9126. >> Our radius server (radiator) can log the cleartext passwords sent by
  9127. >> the client.  I've noticed an interesting pattern, failed attempts followed 
  9128. >> by succesfull one, with only the last character of the password changed.  It
  9129. >> has been happening hundreds of times per day.
  9130. >> 
  9131. >Is it possible for you to use the tap feature to capture this info?
  9132. >I have heard reports of this but I have not been able to get any one to 
  9133. >work with me on this.  If you can either run tap to syslog and capture 
  9134. >the data or if this is reproduceble on demand then it would be easy for 
  9135. >us to identify the problem.
  9136.  
  9137. It seems to be associated with particular users, I've sent mail to one
  9138. to see if he can call in while I'm capturing.
  9139.  
  9140. >If running tap is a problem then you can try disabling ppp offloading and 
  9141. >see if this problem exits.  That would give us somegood info.
  9142.  
  9143. It's possible I could disable ppp offloading on one card and track
  9144. to see if the problem doesn't exist there.
  9145.  
  9146. What is the performance hit of disabling offloading?  I'm running 3 DSP's
  9147. per ARC.
  9148.  
  9149. -- 
  9150. Aaron Nabil
  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: Brian <signal@shreve.net>
  9162. Subject: Re: (usr-tc) Passwords getting corrupted
  9163. Date: 11 Apr 1999 22:32:05 -0500 (CDT)
  9164.  
  9165. On Sun, 11 Apr 1999, Tatai SV Krishnan wrote:
  9166.  
  9167. > On Sun, 11 Apr 1999, Aaron Nabil wrote:
  9168. >=20
  9169. > >=20
  9170. > > Our radius server (radiator) can log the cleartext passwords sent by
  9171. > > the client.  I've noticed an interesting pattern, failed attempts follo=
  9172. wed=20
  9173. > > by succesfull one, with only the last character of the password changed=
  9174. =2E  It
  9175. > > has been happening hundreds of times per day.
  9176. > >=20
  9177. > > An example would be a failed attempt with the password "cooki^X"=20
  9178. > > followed by an succesfull attempt of "cookie".  The transformation isn'=
  9179. t
  9180. > > fixed, if the same user fails again, it might be "cookiZ" he tries befo=
  9181. re
  9182. > > "cookie".
  9183. >=20
  9184. > Is it possible for you to use the tap feature to capture this info?
  9185. > I have heard reports of this but I have not been able to get any one to=
  9186. =20
  9187. > work with me on this.  If you can either run tap to syslog and capture=20
  9188. > the data or if this is reproduceble on demand then it would be easy for=
  9189. =20
  9190. > us to identify the problem.
  9191. >=20
  9192. > If running tap is a problem then you can try disabling ppp offloading and=
  9193. =20
  9194. > see if this problem exits.  That would give us somegood info.
  9195.  
  9196.  
  9197. Ugh, not good.
  9198.  
  9199. [signal@norad radacct]$ tail -500 password.log |grep juicy
  9200. Sun Apr 11 22:11:44 1999:923886704:juicy:d00ms:ENCRYPTED:PASS
  9201. Sun Apr 11 22:12:53 1999:923886773:juicy:d00mI:ENCRYPTED:FAIL
  9202. Sun Apr 11 22:13:12 1999:923886792:juicy:d00ms:ENCRYPTED:PASS
  9203.  
  9204. [signal@norad radacct]$ tail -500 password.log |grep thunder
  9205. Sun Apr 11 22:15:17 1999:923886917:thunder:tbon=EC:ENCRYPTED:FAIL
  9206. Sun Apr 11 22:15:29 1999:923886929:thunder:tbone:ENCRYPTED:PASS
  9207. Sun Apr 11 22:25:31 1999:923887531:thunder:tbone:ENCRYPTED:PASS
  9208.  
  9209. (usernames have been changed to protect the innocent :)  )
  9210.  
  9211. So the short of it, is that I am seeing this too.  Yes I am running ppp
  9212. offloading as per the release notes.  I would say their is a problem.
  9213. Hopefully this will be a quick one, and a fix will be released soon.
  9214.  
  9215. Perhaps others can do a check of their RADIUS password logs and look for
  9216. this type of activity.
  9217.  >=20
  9218. > regards
  9219. > krish
  9220. >=20
  9221. > >=20
  9222. > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSP=
  9223. s.
  9224. > >=20
  9225. > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  9226. > > anything other that it only appears to be happening on our USR chassis.
  9227. > >=20
  9228. > > --=20
  9229. > > Aaron Nabil
  9230. > >=20
  9231. > > -
  9232. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9233. > >  with "unsubscribe usr-tc" in the body of the message.
  9234. > >  For information on digests or retrieving files and old messages send
  9235. > >  "help" to the same address.  Do not use quotes in your message.
  9236. > >=20
  9237. >=20
  9238. > -
  9239. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9240. >  with "unsubscribe usr-tc" in the body of the message.
  9241. >  For information on digests or retrieving files and old messages send
  9242. >  "help" to the same address.  Do not use quotes in your message.
  9243. >=20
  9244.  
  9245. Brian Feeny (BF304)     signal@shreve.net  =20
  9246. 318-222-2638 x 109=09http://www.shreve.net/~signal     =20
  9247. Network Administrator   ShreveNet Inc. (ASN 11881) =09     =20
  9248.  
  9249.  
  9250. -
  9251.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9252.  with "unsubscribe usr-tc" in the body of the message.
  9253.  For information on digests or retrieving files and old messages send
  9254.  "help" to the same address.  Do not use quotes in your message.
  9255.  
  9256.  
  9257. -------------------------------------------------------------------------------
  9258.  
  9259. From: "Customer Support" <webster@yore.net>
  9260. Subject: (usr-tc) No handshake..
  9261. Date: 11 Apr 1999 22:53:37 -0500
  9262.  
  9263. This is a multi-part message in MIME format.
  9264.  
  9265. ------=_NextPart_000_0058_01BE846E.22867A20
  9266. Content-Type: text/plain;
  9267.     charset="iso-8859-1"
  9268. Content-Transfer-Encoding: quoted-printable
  9269.  
  9270. At about 4 this afternoon the TC's DSP's stopped moving data. One of the =
  9271. clients that were online at the time said they got a "illegal =
  9272. instruction" fault and where disconnected. I first tried to dial into =
  9273. the box and found that, although the DSP would pick-up the line, there =
  9274. was no handshake. Everything looked normal as far as the status =
  9275. indicators go on the front of the TC cards.
  9276.     I cycled the power using the on/off switch and all the tests seemed =
  9277. to go just fine. I tried moving the DSP to another slot. I've checked to =
  9278. make sure that the modems were enabled(using the telnet command "enable =
  9279. modem_group slot:1") and the show command shows all modems as active.
  9280.     I checked with the phone company (SWBell) and they said they checked =
  9281. the PRI and everything was OK.
  9282.      I'm running 1.2.5 on the DSP's and 4.1.72 on the ARC and 5.6.2 on =
  9283. the NMC.
  9284.     Any ideas? I'll be happy to provide any other information.
  9285.  
  9286.          Ray (AKA Webster)
  9287.  
  9288.  
  9289. ------=_NextPart_000_0058_01BE846E.22867A20
  9290. Content-Type: text/html;
  9291.     charset="iso-8859-1"
  9292. Content-Transfer-Encoding: quoted-printable
  9293.  
  9294. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  9295. <HTML>
  9296. <HEAD>
  9297.  
  9298. <META content=3Dtext/html;charset=3Diso-8859-1 =
  9299. http-equiv=3DContent-Type>
  9300. <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
  9301. </HEAD>
  9302. <BODY bgColor=3D#ffffff>
  9303. <DIV><FONT color=3D#000000 size=3D2>At about 4 this afternoon the TC's =
  9304. DSP's stopped=20
  9305. moving data. One of the clients that were online at the time said they =
  9306. got a=20
  9307. "illegal instruction" fault and where disconnected. I first =
  9308. tried to=20
  9309. dial into the box and found that, although the DSP would pick-up the =
  9310. line, there=20
  9311. was no handshake. Everything looked normal as far as the status =
  9312. indicators go on=20
  9313. the front of the TC cards.</FONT></DIV>
  9314. <DIV><FONT color=3D#000000 size=3D2>    I cycled the =
  9315. power using the=20
  9316. on/off switch and all the tests seemed to go just fine. I tried moving =
  9317. the DSP=20
  9318. to another slot. I've checked to make sure that the modems were =
  9319. enabled(using=20
  9320. the telnet command "enable modem_group slot:1") and the show =
  9321. command=20
  9322. shows all modems as active.</FONT></DIV>
  9323. <DIV><FONT color=3D#000000 size=3D2>    I checked with =
  9324. the phone=20
  9325. company (SWBell) and they said they checked the PRI and everything was=20
  9326. OK.</FONT></DIV>
  9327. <DIV><FONT color=3D#000000 size=3D2>     I'm running =
  9328. 1.2.5 on=20
  9329. the DSP's and 4.1.72 on the ARC and 5.6.2 on the NMC.</FONT></DIV>
  9330. <DIV><FONT color=3D#000000 size=3D2>    Any ideas? I'll =
  9331. be happy to=20
  9332. provide any other information.</FONT></DIV>
  9333. <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  9334. <DIV><FONT color=3D#000000 =
  9335. size=3D2>        =20
  9336. Ray (AKA Webster)<BR></FONT></DIV></BODY></HTML>
  9337.  
  9338. ------=_NextPart_000_0058_01BE846E.22867A20--
  9339.  
  9340.  
  9341. -
  9342.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9343.  with "unsubscribe usr-tc" in the body of the message.
  9344.  For information on digests or retrieving files and old messages send
  9345.  "help" to the same address.  Do not use quotes in your message.
  9346.  
  9347.  
  9348. -------------------------------------------------------------------------------
  9349.  
  9350. From: "Steve Lalonde" <steve@enta.net>
  9351. Subject: Re: (usr-tc) Passwords getting corrupted
  9352. Date: 12 Apr 1999 08:26:39 +0100
  9353.  
  9354. Im getting exactly the same here, and it always affects the same users
  9355.  
  9356. 4.1.59-6  on hiperARCs and 1.2.59 on hiperDSPs
  9357.  
  9358. Were in the UK so its E1/PRI versions of code
  9359.  
  9360. Steve Lalonde
  9361. Systems Manager
  9362. ENTANET International Ltd
  9363. Most usefull Unix command :- man man
  9364. Most Dangerous Unix command :- rm -rf /
  9365.  
  9366.  
  9367.  
  9368.  
  9369. ----- Original Message -----
  9370. Cc: Aaron Nabil <nabil@spiritone.com>
  9371. Sent: 12 April 1999 04:32
  9372.  
  9373.  
  9374. > On Sun, 11 Apr 1999, Tatai SV Krishnan wrote:
  9375. >
  9376. > > On Sun, 11 Apr 1999, Aaron Nabil wrote:
  9377. > >
  9378. > > >
  9379. > > > Our radius server (radiator) can log the cleartext passwords sent b=
  9380. y
  9381. > > > the client.  I've noticed an interesting pattern, failed attempts
  9382. followed
  9383. > > > by succesfull one, with only the last character of the password
  9384. changed.  It
  9385. > > > has been happening hundreds of times per day.
  9386. > > >
  9387. > > > An example would be a failed attempt with the password "cooki^X"
  9388. > > > followed by an succesfull attempt of "cookie".  The transformation
  9389. isn't
  9390. > > > fixed, if the same user fails again, it might be "cookiZ" he tries
  9391. before
  9392. > > > "cookie".
  9393. > >
  9394. > > Is it possible for you to use the tap feature to capture this info?
  9395. > > I have heard reports of this but I have not been able to get any one =
  9396. to
  9397. > > work with me on this.  If you can either run tap to syslog and captur=
  9398. e
  9399. > > the data or if this is reproduceble on demand then it would be easy f=
  9400. or
  9401. > > us to identify the problem.
  9402. > >
  9403. > > If running tap is a problem then you can try disabling ppp offloading
  9404. and
  9405. > > see if this problem exits.  That would give us somegood info.
  9406. >
  9407. >
  9408. > Ugh, not good.
  9409. >
  9410. > [signal@norad radacct]$ tail -500 password.log |grep juicy
  9411. > Sun Apr 11 22:11:44 1999:923886704:juicy:d00ms:ENCRYPTED:PASS
  9412. > Sun Apr 11 22:12:53 1999:923886773:juicy:d00mI:ENCRYPTED:FAIL
  9413. > Sun Apr 11 22:13:12 1999:923886792:juicy:d00ms:ENCRYPTED:PASS
  9414. >
  9415. > [signal@norad radacct]$ tail -500 password.log |grep thunder
  9416. > Sun Apr 11 22:15:17 1999:923886917:thunder:tbon=EC:ENCRYPTED:FAIL
  9417. > Sun Apr 11 22:15:29 1999:923886929:thunder:tbone:ENCRYPTED:PASS
  9418. > Sun Apr 11 22:25:31 1999:923887531:thunder:tbone:ENCRYPTED:PASS
  9419. >
  9420. > (usernames have been changed to protect the innocent :)  )
  9421. >
  9422. > So the short of it, is that I am seeing this too.  Yes I am running ppp
  9423. > offloading as per the release notes.  I would say their is a problem.
  9424. > Hopefully this will be a quick one, and a fix will be released soon.
  9425. >
  9426. > Perhaps others can do a check of their RADIUS password logs and look fo=
  9427. r
  9428. > this type of activity.
  9429. >  >
  9430. > > regards
  9431. > > krish
  9432. > >
  9433. > > >
  9434. > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the
  9435. hiperDSPs.
  9436. > > >
  9437. > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  9438. > > > anything other that it only appears to be happening on our USR
  9439. chassis.
  9440. > > >
  9441. > > > --
  9442. > > > Aaron Nabil
  9443. > > >
  9444. > > > -
  9445. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com=
  9446. "
  9447. > > >  with "unsubscribe usr-tc" in the body of the message.
  9448. > > >  For information on digests or retrieving files and old messages se=
  9449. nd
  9450. > > >  "help" to the same address.  Do not use quotes in your message.
  9451. > > >
  9452. > >
  9453. > > -
  9454. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9455. > >  with "unsubscribe usr-tc" in the body of the message.
  9456. > >  For information on digests or retrieving files and old messages send
  9457. > >  "help" to the same address.  Do not use quotes in your message.
  9458. > >
  9459. >
  9460. > -----------------------------------------------------
  9461. > Brian Feeny (BF304)     signal@shreve.net
  9462. > 318-222-2638 x 109 http://www.shreve.net/~signal
  9463. > Network Administrator   ShreveNet Inc. (ASN 11881)
  9464. >
  9465. >
  9466. > -
  9467. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9468. >  with "unsubscribe usr-tc" in the body of the message.
  9469. >  For information on digests or retrieving files and old messages send
  9470. >  "help" to the same address.  Do not use quotes in your message.
  9471. >
  9472.  
  9473.  
  9474. -
  9475.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9476.  with "unsubscribe usr-tc" in the body of the message.
  9477.  For information on digests or retrieving files and old messages send
  9478.  "help" to the same address.  Do not use quotes in your message.
  9479.  
  9480.  
  9481. -------------------------------------------------------------------------------
  9482.  
  9483. From: "Customer Support" <webster@yore.net>
  9484. Subject: Re: (usr-tc) No handshake..
  9485. Date: 12 Apr 1999 03:57:44 -0500
  9486.  
  9487. This is a multi-part message in MIME format.
  9488.  
  9489. ------=_NextPart_000_00B5_01BE8498.9EAAC640
  9490. Content-Type: text/plain;
  9491.     charset="iso-8859-1"
  9492. Content-Transfer-Encoding: quoted-printable
  9493.  
  9494.     -----Original Message-----
  9495.     From: Customer Support <webster@yore.net>
  9496.     To: usr-tc@xmission.com <usr-tc@xmission.com>
  9497.     Date: Sunday, April 11, 1999 10:55 PM
  9498.     Subject: (usr-tc) No handshake..
  9499.    =20
  9500.    =20
  9501.     At about 4 this afternoon the TC's DSP's stopped moving data. One of =
  9502. the clients that were online at the time said they got a "illegal =
  9503. instruction" fault and where disconnected. I first tried to dial into =
  9504. the box and found that, although the DSP would pick-up the line, there =
  9505. was no handshake. Everything looked normal as far as the status =
  9506. indicators go on the front of the TC cards.
  9507.         I cycled the power using the on/off switch and all the tests =
  9508. seemed to go just fine. I tried moving the DSP to another slot. I've =
  9509. checked to make sure that the modems were enabled(using the telnet =
  9510. command "enable modem_group slot:1") and the show command shows all =
  9511. modems as active.
  9512.         I checked with the phone company (SWBell) and they said they =
  9513. checked the PRI and everything was OK.
  9514.          I'm running 1.2.5 on the DSP's and 4.1.72 on the ARC and 5.6.2 =
  9515. on the NMC.
  9516.         Any ideas? I'll be happy to provide any other information.
  9517.     =20
  9518.              Ray (AKA Webster)
  9519.    =20
  9520.             More to add...
  9521.         I've been trying various things to find something suspect and I =
  9522. found that if you begin punching random numbers on the telephone after =
  9523. you dial the trunk number, the handshake will begin. I've checked in =
  9524. again with the phone co. (SWBell) and they say they are checking their =
  9525. tranlations now. It seems to me the problem lies with a switch =
  9526. somewhere.
  9527.         Anyone?
  9528.  
  9529.  
  9530. ------=_NextPart_000_00B5_01BE8498.9EAAC640
  9531. Content-Type: text/html;
  9532.     charset="iso-8859-1"
  9533. Content-Transfer-Encoding: quoted-printable
  9534.  
  9535. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  9536. <HTML>
  9537. <HEAD>
  9538.  
  9539. <META content=3Dtext/html;charset=3Diso-8859-1 =
  9540. http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
  9541. HTML//EN">
  9542. <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
  9543. </HEAD>
  9544. <BODY bgColor=3D#ffffff>
  9545. <BLOCKQUOTE=20
  9546. style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
  9547. 5px">
  9548.     <DIV><FONT face=3DArial size=3D2><B>-----Original =
  9549. Message-----</B><BR><B>From:=20
  9550.     </B>Customer Support <<A=20
  9551.     href=3D"mailto:webster@yore.net">webster@yore.net</A>><BR><B>To: =
  9552. </B><A=20
  9553.     href=3D"mailto:usr-tc@xmission.com">usr-tc@xmission.com</A> <<A=20
  9554.     =
  9555. href=3D"mailto:usr-tc@xmission.com">usr-tc@xmission.com</A>><BR><B>Dat=
  9556. e:=20
  9557.     </B>Sunday, April 11, 1999 10:55 PM<BR><B>Subject: </B>(usr-tc) No=20
  9558.     handshake..<BR><BR></DIV></FONT>
  9559.     <DIV><FONT color=3D#000000 size=3D2>At about 4 this afternoon the =
  9560. TC's DSP's=20
  9561.     stopped moving data. One of the clients that were online at the time =
  9562. said=20
  9563.     they got a "illegal instruction" fault and where =
  9564. disconnected. I=20
  9565.     first tried to dial into the box and found that, although the DSP =
  9566. would=20
  9567.     pick-up the line, there was no handshake. Everything looked normal =
  9568. as far as=20
  9569.     the status indicators go on the front of the TC cards.</FONT></DIV>
  9570.     <DIV><FONT color=3D#000000 size=3D2>    I cycled the =
  9571. power using=20
  9572.     the on/off switch and all the tests seemed to go just fine. I tried =
  9573. moving=20
  9574.     the DSP to another slot. I've checked to make sure that the modems =
  9575. were=20
  9576.     enabled(using the telnet command "enable modem_group =
  9577. slot:1") and=20
  9578.     the show command shows all modems as active.</FONT></DIV>
  9579.     <DIV><FONT color=3D#000000 size=3D2>    I checked =
  9580. with the phone=20
  9581.     company (SWBell) and they said they checked the PRI and everything =
  9582. was=20
  9583.     OK.</FONT></DIV>
  9584.     <DIV><FONT color=3D#000000 size=3D2>     I'm =
  9585. running 1.2.5=20
  9586.     on the DSP's and 4.1.72 on the ARC and 5.6.2 on the =
  9587. NMC.</FONT></DIV>
  9588.     <DIV><FONT color=3D#000000 size=3D2>    Any ideas? =
  9589. I'll be happy=20
  9590.     to provide any other information.</FONT></DIV>
  9591.     <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  9592.     <DIV><FONT color=3D#000000=20
  9593.     size=3D2>         Ray (AKA=20
  9594.     Webster)</FONT></DIV>
  9595.     <DIV><FONT color=3D#000000 size=3D2></FONT><FONT color=3D#000000=20
  9596.     size=3D2></FONT> </DIV>
  9597.     <DIV><FONT color=3D#000000 =
  9598. size=3D2>       =20
  9599.     More to add...</FONT></DIV>
  9600.     <DIV><FONT color=3D#000000 size=3D2>    I've been =
  9601. trying various=20
  9602.     things to find something suspect and I found that if you begin =
  9603. punching=20
  9604.     random numbers on the telephone after you dial the trunk number, the =
  9605.  
  9606.     handshake will begin. I've checked in again with the phone co. =
  9607. (SWBell) and=20
  9608.     they say they are checking their tranlations now. It seems to me the =
  9609. problem=20
  9610.     lies with a switch somewhere.</FONT></DIV>
  9611.     <DIV><FONT color=3D#000000 size=3D2>    =
  9612. Anyone?</FONT></DIV>
  9613.     <DIV><FONT color=3D#000000 =
  9614. size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML>
  9615.  
  9616. ------=_NextPart_000_00B5_01BE8498.9EAAC640--
  9617.  
  9618.  
  9619. -
  9620.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9621.  with "unsubscribe usr-tc" in the body of the message.
  9622.  For information on digests or retrieving files and old messages send
  9623.  "help" to the same address.  Do not use quotes in your message.
  9624.  
  9625.  
  9626. -------------------------------------------------------------------------------
  9627.  
  9628. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  9629. Subject: Re: (usr-tc) Passwords getting corrupted
  9630. Date: 12 Apr 1999 07:55:25 -0500 (CDT)
  9631.  
  9632.  
  9633. > Tatai SV Krishnan writes...
  9634. > >On Sun, 11 Apr 1999, Aaron Nabil wrote:
  9635. > >> Our radius server (radiator) can log the cleartext passwords sent by
  9636. > >> the client.  I've noticed an interesting pattern, failed attempts followed 
  9637. > >> by succesfull one, with only the last character of the password changed.  It
  9638. > >> has been happening hundreds of times per day.
  9639. > >> 
  9640. > >Is it possible for you to use the tap feature to capture this info?
  9641. > >I have heard reports of this but I have not been able to get any one to 
  9642. > >work with me on this.  If you can either run tap to syslog and capture 
  9643. > >the data or if this is reproduceble on demand then it would be easy for 
  9644. > >us to identify the problem.
  9645. > 
  9646. > It seems to be associated with particular users, I've sent mail to one
  9647. > to see if he can call in while I'm capturing.
  9648.  
  9649. Then you can just add tap for these users.  When ever they log in the 
  9650. info will be logged to syslog.
  9651.  
  9652. > 
  9653. > >If running tap is a problem then you can try disabling ppp offloading and 
  9654. > >see if this problem exits.  That would give us somegood info.
  9655. > 
  9656. > It's possible I could disable ppp offloading on one card and track
  9657. > to see if the problem doesn't exist there.
  9658. Unfortunately it is not possible to disable ppp offloading on one card. 
  9659. You have to disable it on all the cards.
  9660. > 
  9661.  
  9662.  
  9663. > What is the performance hit of disabling offloading?  I'm running 3 DSP's
  9664. > per ARC.
  9665. I do not have a specific number or percentage.  When you disable ppp 
  9666. offloading the ppp framing is done by hiper arc software compared to 
  9667. modem which is done in hardware.
  9668.  
  9669. I would say users will not notice the difference.
  9670.  
  9671. krish
  9672.  
  9673. > 
  9674. > -- 
  9675. > Aaron Nabil
  9676. > 
  9677.  
  9678. -
  9679.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9680.  with "unsubscribe usr-tc" in the body of the message.
  9681.  For information on digests or retrieving files and old messages send
  9682.  "help" to the same address.  Do not use quotes in your message.
  9683.  
  9684.  
  9685. -------------------------------------------------------------------------------
  9686.  
  9687. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  9688. Subject: Re: (usr-tc) Passwords getting corrupted
  9689. Date: 12 Apr 1999 08:00:14 -0500 (CDT)
  9690.  
  9691. On Sun, 11 Apr 1999, Brian wrote:
  9692.  
  9693. > On Sun, 11 Apr 1999, Tatai SV Krishnan wrote:
  9694. >=20
  9695. > > On Sun, 11 Apr 1999, Aaron Nabil wrote:
  9696. > >=20
  9697. > > >=20
  9698. > > > Our radius server (radiator) can log the cleartext passwords sent by
  9699. > > > the client.  I've noticed an interesting pattern, failed attempts fol=
  9700. lowed=20
  9701. > > > by succesfull one, with only the last character of the password chang=
  9702. ed.  It
  9703. > > > has been happening hundreds of times per day.
  9704. > > >=20
  9705. > > > An example would be a failed attempt with the password "cooki^X"=20
  9706. > > > followed by an succesfull attempt of "cookie".  The transformation is=
  9707. n't
  9708. > > > fixed, if the same user fails again, it might be "cookiZ" he tries be=
  9709. fore
  9710. > > > "cookie".
  9711. > >=20
  9712. > > Is it possible for you to use the tap feature to capture this info?
  9713. > > I have heard reports of this but I have not been able to get any one to=
  9714. =20
  9715. > > work with me on this.  If you can either run tap to syslog and capture=
  9716. =20
  9717. > > the data or if this is reproduceble on demand then it would be easy for=
  9718. =20
  9719. > > us to identify the problem.
  9720. > >=20
  9721. > > If running tap is a problem then you can try disabling ppp offloading a=
  9722. nd=20
  9723. > > see if this problem exits.  That would give us somegood info.
  9724. >=20
  9725. >=20
  9726. > Ugh, not good.
  9727. >=20
  9728. > [signal@norad radacct]$ tail -500 password.log |grep juicy
  9729. > Sun Apr 11 22:11:44 1999:923886704:juicy:d00ms:ENCRYPTED:PASS
  9730. > Sun Apr 11 22:12:53 1999:923886773:juicy:d00mI:ENCRYPTED:FAIL
  9731. > Sun Apr 11 22:13:12 1999:923886792:juicy:d00ms:ENCRYPTED:PASS
  9732. >=20
  9733. > [signal@norad radacct]$ tail -500 password.log |grep thunder
  9734. > Sun Apr 11 22:15:17 1999:923886917:thunder:tbon=EC:ENCRYPTED:FAIL
  9735. > Sun Apr 11 22:15:29 1999:923886929:thunder:tbone:ENCRYPTED:PASS
  9736. > Sun Apr 11 22:25:31 1999:923887531:thunder:tbone:ENCRYPTED:PASS
  9737. >=20
  9738. > (usernames have been changed to protect the innocent :)  )
  9739.  
  9740. I understand the problem - but need a tap to see what exactly is being=20
  9741. sent to the radius.  Could you enable tap for juicy and tunder?
  9742.  
  9743. krish
  9744.  
  9745. >=20
  9746. > So the short of it, is that I am seeing this too.  Yes I am running ppp
  9747. > offloading as per the release notes.  I would say their is a problem.
  9748. > Hopefully this will be a quick one, and a fix will be released soon.
  9749. >=20
  9750. > Perhaps others can do a check of their RADIUS password logs and look for
  9751. > this type of activity.
  9752. >  >=20
  9753. > > regards
  9754. > > krish
  9755. > >=20
  9756. > > >=20
  9757. > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperD=
  9758. SPs.
  9759. > > >=20
  9760. > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  9761. > > > anything other that it only appears to be happening on our USR chassi=
  9762. s.
  9763. > > >=20
  9764. > > > --=20
  9765. > > > Aaron Nabil
  9766. > > >=20
  9767. > > > -
  9768. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9769. > > >  with "unsubscribe usr-tc" in the body of the message.
  9770. > > >  For information on digests or retrieving files and old messages send
  9771. > > >  "help" to the same address.  Do not use quotes in your message.
  9772. > > >=20
  9773. > >=20
  9774. > > -
  9775. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9776. > >  with "unsubscribe usr-tc" in the body of the message.
  9777. > >  For information on digests or retrieving files and old messages send
  9778. > >  "help" to the same address.  Do not use quotes in your message.
  9779. > >=20
  9780. >=20
  9781. > -----------------------------------------------------
  9782. > Brian Feeny (BF304)     signal@shreve.net  =20
  9783. > 318-222-2638 x 109=09http://www.shreve.net/~signal     =20
  9784. > Network Administrator   ShreveNet Inc. (ASN 11881) =09     =20
  9785. >=20
  9786. >=20
  9787. > -
  9788. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9789. >  with "unsubscribe usr-tc" in the body of the message.
  9790. >  For information on digests or retrieving files and old messages send
  9791. >  "help" to the same address.  Do not use quotes in your message.
  9792. >=20
  9793.  
  9794. -
  9795.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9796.  with "unsubscribe usr-tc" in the body of the message.
  9797.  For information on digests or retrieving files and old messages send
  9798.  "help" to the same address.  Do not use quotes in your message.
  9799.  
  9800.  
  9801. -------------------------------------------------------------------------------
  9802.  
  9803. From: Brian <signal@shreve.net>
  9804. Subject: Re: (usr-tc) Passwords getting corrupted
  9805. Date: 12 Apr 1999 08:22:35 -0500 (CDT)
  9806.  
  9807. > 
  9808. > I understand the problem - but need a tap to see what exactly is being 
  9809. > sent to the radius.  Could you enable tap for juicy and tunder?
  9810. > 
  9811.  
  9812. Can I just enable syslog tap for that user on the ARC?  Or do I have to do
  9813. it via RADIUS (the user is entirley in RADIUS)?  Can you give me an
  9814. example of how to tap the user?  I will get you a file with some info in
  9815. it.
  9816.  
  9817.  
  9818.  
  9819. > krish
  9820. > 
  9821. > > 
  9822. > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  9823. > > offloading as per the release notes.  I would say their is a problem.
  9824. > > Hopefully this will be a quick one, and a fix will be released soon.
  9825. > > 
  9826. > > Perhaps others can do a check of their RADIUS password logs and look for
  9827. > > this type of activity.
  9828. > >  > 
  9829. > > > regards
  9830. > > > krish
  9831. > > > 
  9832. > > > > 
  9833. > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  9834. > > > > 
  9835. > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  9836. > > > > anything other that it only appears to be happening on our USR chassis.
  9837. > > > > 
  9838. > > > > -- 
  9839. > > > > Aaron Nabil
  9840. > > > > 
  9841. > > > > -
  9842. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9843. > > > >  with "unsubscribe usr-tc" in the body of the message.
  9844. > > > >  For information on digests or retrieving files and old messages send
  9845. > > > >  "help" to the same address.  Do not use quotes in your message.
  9846. > > > > 
  9847. > > > 
  9848. > > > -
  9849. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9850. > > >  with "unsubscribe usr-tc" in the body of the message.
  9851. > > >  For information on digests or retrieving files and old messages send
  9852. > > >  "help" to the same address.  Do not use quotes in your message.
  9853. > > > 
  9854. > > 
  9855. > > -----------------------------------------------------
  9856. > > Brian Feeny (BF304)     signal@shreve.net   
  9857. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  9858. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  9859. > > 
  9860. > > 
  9861. > > -
  9862. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9863. > >  with "unsubscribe usr-tc" in the body of the message.
  9864. > >  For information on digests or retrieving files and old messages send
  9865. > >  "help" to the same address.  Do not use quotes in your message.
  9866. > > 
  9867. > 
  9868.  
  9869. Brian Feeny (BF304)     signal@shreve.net   
  9870. 318-222-2638 x 109    http://www.shreve.net/~signal      
  9871. Network Administrator   ShreveNet Inc. (ASN 11881)           
  9872.  
  9873.  
  9874. -
  9875.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9876.  with "unsubscribe usr-tc" in the body of the message.
  9877.  For information on digests or retrieving files and old messages send
  9878.  "help" to the same address.  Do not use quotes in your message.
  9879.  
  9880.  
  9881. -------------------------------------------------------------------------------
  9882.  
  9883. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  9884. Subject: Re: (usr-tc) Passwords getting corrupted
  9885. Date: 12 Apr 1999 08:43:46 -0500 (CDT)
  9886.  
  9887. On Mon, 12 Apr 1999, Brian wrote:
  9888.  
  9889. > > 
  9890. > > I understand the problem - but need a tap to see what exactly is being 
  9891. > > sent to the radius.  Could you enable tap for juicy and tunder?
  9892. > > 
  9893. > 
  9894. > Can I just enable syslog tap for that user on the ARC?  Or do I have to do
  9895. > it via RADIUS (the user is entirley in RADIUS)?  Can you give me an
  9896. > example of how to tap the user?  I will get you a file with some info in
  9897. > it.
  9898. > 
  9899. > 
  9900.  
  9901. You can enable syslog tap for the user.  Add tap user <username> fomrat 
  9902. <ascii/hex> output syslog 
  9903.  
  9904. That is to it.  if you do not have asyslog host specified then in the 
  9905. above tap command you can speficy the syslog host address.
  9906.  
  9907. krish
  9908.  
  9909.  
  9910. > 
  9911. > > krish
  9912. > > 
  9913. > > > 
  9914. > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  9915. > > > offloading as per the release notes.  I would say their is a problem.
  9916. > > > Hopefully this will be a quick one, and a fix will be released soon.
  9917. > > > 
  9918. > > > Perhaps others can do a check of their RADIUS password logs and look for
  9919. > > > this type of activity.
  9920. > > >  > 
  9921. > > > > regards
  9922. > > > > krish
  9923. > > > > 
  9924. > > > > > 
  9925. > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  9926. > > > > > 
  9927. > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  9928. > > > > > anything other that it only appears to be happening on our USR chassis.
  9929. > > > > > 
  9930. > > > > > -- 
  9931. > > > > > Aaron Nabil
  9932. > > > > > 
  9933. > > > > > -
  9934. > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9935. > > > > >  with "unsubscribe usr-tc" in the body of the message.
  9936. > > > > >  For information on digests or retrieving files and old messages send
  9937. > > > > >  "help" to the same address.  Do not use quotes in your message.
  9938. > > > > > 
  9939. > > > > 
  9940. > > > > -
  9941. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9942. > > > >  with "unsubscribe usr-tc" in the body of the message.
  9943. > > > >  For information on digests or retrieving files and old messages send
  9944. > > > >  "help" to the same address.  Do not use quotes in your message.
  9945. > > > > 
  9946. > > > 
  9947. > > > -----------------------------------------------------
  9948. > > > Brian Feeny (BF304)     signal@shreve.net   
  9949. > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  9950. > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  9951. > > > 
  9952. > > > 
  9953. > > > -
  9954. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9955. > > >  with "unsubscribe usr-tc" in the body of the message.
  9956. > > >  For information on digests or retrieving files and old messages send
  9957. > > >  "help" to the same address.  Do not use quotes in your message.
  9958. > > > 
  9959. > > 
  9960. > 
  9961. > -----------------------------------------------------
  9962. > Brian Feeny (BF304)     signal@shreve.net   
  9963. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  9964. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  9965. > 
  9966.  
  9967. -
  9968.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9969.  with "unsubscribe usr-tc" in the body of the message.
  9970.  For information on digests or retrieving files and old messages send
  9971.  "help" to the same address.  Do not use quotes in your message.
  9972.  
  9973.  
  9974. -------------------------------------------------------------------------------
  9975.  
  9976. From: Brian <signal@shreve.net>
  9977. Subject: Re: (usr-tc) Passwords getting corrupted
  9978. Date: 12 Apr 1999 09:33:39 -0500 (CDT)
  9979.  
  9980. On Mon, 12 Apr 1999, Tatai SV Krishnan wrote:
  9981.  
  9982. > On Mon, 12 Apr 1999, Brian wrote:
  9983. > 
  9984. > > > 
  9985. > > > I understand the problem - but need a tap to see what exactly is being 
  9986. > > > sent to the radius.  Could you enable tap for juicy and tunder?
  9987. > > > 
  9988. > > 
  9989. > > Can I just enable syslog tap for that user on the ARC?  Or do I have to do
  9990. > > it via RADIUS (the user is entirley in RADIUS)?  Can you give me an
  9991. > > example of how to tap the user?  I will get you a file with some info in
  9992. > > it.
  9993. > > 
  9994. > > 
  9995. > 
  9996. > You can enable syslog tap for the user.  Add tap user <username> fomrat 
  9997. > <ascii/hex> output syslog 
  9998. > 
  9999. > That is to it.  if you do not have asyslog host specified then in the 
  10000. > above tap command you can speficy the syslog host address.
  10001.  
  10002. Well, I will certainly give this a try.  I will tap maybe 5 users, so I
  10003. can get something fast.  The thing is, is their a way via RADIUS VSA to do
  10004. this?  I say this, because we have alot of chassis (well not alot, but
  10005. over 14 ARC's or so) and I really don't want to have to do this on all 14
  10006. because I don't know where he is going to login at :).
  10007.  
  10008. If a VSA will work , perhaps give me an example, otherwise, I'll just set
  10009. the tap up on all arc's.
  10010.  
  10011. Brian
  10012.  
  10013.  
  10014.  
  10015. > 
  10016. > krish
  10017. > 
  10018. > 
  10019. > > 
  10020. > > > krish
  10021. > > > 
  10022. > > > > 
  10023. > > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  10024. > > > > offloading as per the release notes.  I would say their is a problem.
  10025. > > > > Hopefully this will be a quick one, and a fix will be released soon.
  10026. > > > > 
  10027. > > > > Perhaps others can do a check of their RADIUS password logs and look for
  10028. > > > > this type of activity.
  10029. > > > >  > 
  10030. > > > > > regards
  10031. > > > > > krish
  10032. > > > > > 
  10033. > > > > > > 
  10034. > > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  10035. > > > > > > 
  10036. > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  10037. > > > > > > anything other that it only appears to be happening on our USR chassis.
  10038. > > > > > > 
  10039. > > > > > > -- 
  10040. > > > > > > Aaron Nabil
  10041. > > > > > > 
  10042. > > > > > > -
  10043. > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10044. > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10045. > > > > > >  For information on digests or retrieving files and old messages send
  10046. > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10047. > > > > > > 
  10048. > > > > > 
  10049. > > > > > -
  10050. > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10051. > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10052. > > > > >  For information on digests or retrieving files and old messages send
  10053. > > > > >  "help" to the same address.  Do not use quotes in your message.
  10054. > > > > > 
  10055. > > > > 
  10056. > > > > -----------------------------------------------------
  10057. > > > > Brian Feeny (BF304)     signal@shreve.net   
  10058. > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10059. > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10060. > > > > 
  10061. > > > > 
  10062. > > > > -
  10063. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10064. > > > >  with "unsubscribe usr-tc" in the body of the message.
  10065. > > > >  For information on digests or retrieving files and old messages send
  10066. > > > >  "help" to the same address.  Do not use quotes in your message.
  10067. > > > > 
  10068. > > > 
  10069. > > 
  10070. > > -----------------------------------------------------
  10071. > > Brian Feeny (BF304)     signal@shreve.net   
  10072. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10073. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10074. > > 
  10075. > 
  10076.  
  10077. Brian Feeny (BF304)     signal@shreve.net   
  10078. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10079. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10080.  
  10081.  
  10082. -
  10083.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10084.  with "unsubscribe usr-tc" in the body of the message.
  10085.  For information on digests or retrieving files and old messages send
  10086.  "help" to the same address.  Do not use quotes in your message.
  10087.  
  10088.  
  10089. -------------------------------------------------------------------------------
  10090.  
  10091. From: Ricky Beam <jfbeam@beaker.interpath.net>
  10092. Subject: Re: (usr-tc) Passwords getting corrupted
  10093. Date: 12 Apr 1999 10:51:42 -0400 (EDT)
  10094.  
  10095. On Mon, 12 Apr 1999, Brian wrote:
  10096. >Well, I will certainly give this a try.  I will tap maybe 5 users, so I
  10097. >can get something fast.  The thing is, is their a way via RADIUS VSA to do
  10098. >this?  I say this, because we have alot of chassis (well not alot, but
  10099. >over 14 ARC's or so) and I really don't want to have to do this on all 14
  10100. >because I don't know where he is going to login at :).
  10101. >
  10102. >If a VSA will work , perhaps give me an example, otherwise, I'll just set
  10103. >the tap up on all arc's.
  10104.  
  10105. Think about what you are asking for... the tap has to active before it's
  10106. generated any RADIUS traffic at all.  If you are just looking for a fast way
  10107. to turn the tap on/off on multiple ARC's, I'd look in the SNMP stuff -- the
  10108. ARC is completely SNMP managable :-)
  10109.  
  10110. The answer is "yes."  A syslog tap can be activated via RADDIUS, but they
  10111. would have to be logged in for it to be active which it the whole problem.
  10112.  
  10113. --Ricky
  10114.  
  10115.  
  10116.  
  10117. -
  10118.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10119.  with "unsubscribe usr-tc" in the body of the message.
  10120.  For information on digests or retrieving files and old messages send
  10121.  "help" to the same address.  Do not use quotes in your message.
  10122.  
  10123.  
  10124. -------------------------------------------------------------------------------
  10125.  
  10126. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  10127. Subject: RE: (usr-tc) Passwords getting corrupted
  10128. Date: 12 Apr 1999 10:36:57 -0500
  10129.  
  10130.  
  10131.  
  10132. |-----Original Message-----
  10133. |From: owner-usr-tc@lists.xmission.com
  10134. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  10135. |Sent: Sunday, April 11, 1999 10:13 PM
  10136. |To: Tatai SV Krishnan
  10137. |Cc: usr-tc@lists.xmission.com
  10138. |Subject: Re: (usr-tc) Passwords getting corrupted
  10139. |
  10140. |
  10141. |Tatai SV Krishnan writes...
  10142. |>On Sun, 11 Apr 1999, Aaron Nabil wrote:
  10143. |>> Our radius server (radiator) can log the cleartext passwords sent by
  10144. |>> the client.  I've noticed an interesting pattern, failed attempts followed
  10145. |>> by succesfull one, with only the last character of the password changed.  It
  10146. |>> has been happening hundreds of times per day.
  10147. |>>
  10148. |>Is it possible for you to use the tap feature to capture this info?
  10149. |>I have heard reports of this but I have not been able to get any one to
  10150. |>work with me on this.  If you can either run tap to syslog and capture
  10151. |>the data or if this is reproduceble on demand then it would be easy for
  10152. |>us to identify the problem.
  10153. |
  10154. |It seems to be associated with particular users, I've sent mail to one
  10155. |to see if he can call in while I'm capturing.
  10156.  
  10157. Do these users have >8 char passwords???
  10158.  
  10159.  
  10160. |>If running tap is a problem then you can try disabling ppp offloading and
  10161. |>see if this problem exits.  That would give us somegood info.
  10162. |
  10163. |It's possible I could disable ppp offloading on one card and track
  10164. |to see if the problem doesn't exist there.
  10165. |
  10166. |What is the performance hit of disabling offloading?  I'm running 3 DSP's
  10167. |per ARC.
  10168.  
  10169. Its minimal. You can turn it back after the test.. Its just a good inidictor for
  10170. us as to where the problem may be.
  10171.  
  10172. -M
  10173.  
  10174.  
  10175. -
  10176.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10177.  with "unsubscribe usr-tc" in the body of the message.
  10178.  For information on digests or retrieving files and old messages send
  10179.  "help" to the same address.  Do not use quotes in your message.
  10180.  
  10181.  
  10182. -------------------------------------------------------------------------------
  10183.  
  10184. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  10185. Subject: Re: (usr-tc) Passwords getting corrupted
  10186. Date: 12 Apr 1999 11:11:37 -0500 (CDT)
  10187.  
  10188. On Mon, 12 Apr 1999, Brian wrote:
  10189.  
  10190. > Well, I will certainly give this a try.  I will tap maybe 5 users, so I
  10191. > can get something fast.  The thing is, is their a way via RADIUS VSA to do
  10192. > this?  I say this, because we have alot of chassis (well not alot, but
  10193. > over 14 ARC's or so) and I really don't want to have to do this on all 14
  10194. > because I don't know where he is going to login at :).
  10195. > 
  10196. > If a VSA will work , perhaps give me an example, otherwise, I'll just set
  10197. > the tap up on all arc's.
  10198.  
  10199. VSa will work - but only after authentication.  Thus you may never 
  10200. capture the problem.
  10201.  
  10202. krish
  10203.  
  10204. > 
  10205. > Brian
  10206. > 
  10207. > 
  10208. > 
  10209. > > 
  10210. > > krish
  10211. > > 
  10212. > > 
  10213. > > > 
  10214. > > > > krish
  10215. > > > > 
  10216. > > > > > 
  10217. > > > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  10218. > > > > > offloading as per the release notes.  I would say their is a problem.
  10219. > > > > > Hopefully this will be a quick one, and a fix will be released soon.
  10220. > > > > > 
  10221. > > > > > Perhaps others can do a check of their RADIUS password logs and look for
  10222. > > > > > this type of activity.
  10223. > > > > >  > 
  10224. > > > > > > regards
  10225. > > > > > > krish
  10226. > > > > > > 
  10227. > > > > > > > 
  10228. > > > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  10229. > > > > > > > 
  10230. > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  10231. > > > > > > > anything other that it only appears to be happening on our USR chassis.
  10232. > > > > > > > 
  10233. > > > > > > > -- 
  10234. > > > > > > > Aaron Nabil
  10235. > > > > > > > 
  10236. > > > > > > > -
  10237. > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10238. > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10239. > > > > > > >  For information on digests or retrieving files and old messages send
  10240. > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10241. > > > > > > > 
  10242. > > > > > > 
  10243. > > > > > > -
  10244. > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10245. > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10246. > > > > > >  For information on digests or retrieving files and old messages send
  10247. > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10248. > > > > > > 
  10249. > > > > > 
  10250. > > > > > -----------------------------------------------------
  10251. > > > > > Brian Feeny (BF304)     signal@shreve.net   
  10252. > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10253. > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10254. > > > > > 
  10255. > > > > > 
  10256. > > > > > -
  10257. > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10258. > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10259. > > > > >  For information on digests or retrieving files and old messages send
  10260. > > > > >  "help" to the same address.  Do not use quotes in your message.
  10261. > > > > > 
  10262. > > > > 
  10263. > > > 
  10264. > > > -----------------------------------------------------
  10265. > > > Brian Feeny (BF304)     signal@shreve.net   
  10266. > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10267. > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10268. > > > 
  10269. > > 
  10270. > 
  10271. > -----------------------------------------------------
  10272. > Brian Feeny (BF304)     signal@shreve.net   
  10273. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10274. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10275. > 
  10276.  
  10277. -
  10278.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10279.  with "unsubscribe usr-tc" in the body of the message.
  10280.  For information on digests or retrieving files and old messages send
  10281.  "help" to the same address.  Do not use quotes in your message.
  10282.  
  10283.  
  10284. -------------------------------------------------------------------------------
  10285.  
  10286. From: Brian <signal@shreve.net>
  10287. Subject: Re: (usr-tc) Passwords getting corrupted
  10288. Date: 12 Apr 1999 10:57:12 -0500 (CDT)
  10289.  
  10290. On Mon, 12 Apr 1999, Tatai SV Krishnan wrote:
  10291.  
  10292. > On Mon, 12 Apr 1999, Brian wrote:
  10293. > 
  10294. > > Well, I will certainly give this a try.  I will tap maybe 5 users, so I
  10295. > > can get something fast.  The thing is, is their a way via RADIUS VSA to do
  10296. > > this?  I say this, because we have alot of chassis (well not alot, but
  10297. > > over 14 ARC's or so) and I really don't want to have to do this on all 14
  10298. > > because I don't know where he is going to login at :).
  10299. > > 
  10300. > > If a VSA will work , perhaps give me an example, otherwise, I'll just set
  10301. > > the tap up on all arc's.
  10302. > 
  10303. > VSa will work - but only after authentication.  Thus you may never 
  10304. > capture the problem.
  10305.  
  10306. ahh, good point.  So the TAP goes into effect as soon as it gets a
  10307. username sent to the ARC and BEFORE it gets a password sent?
  10308.  
  10309. Brian
  10310.  
  10311.  
  10312. > 
  10313. > krish
  10314. > 
  10315. > > 
  10316. > > Brian
  10317. > > 
  10318. > > 
  10319. > > 
  10320. > > > 
  10321. > > > krish
  10322. > > > 
  10323. > > > 
  10324. > > > > 
  10325. > > > > > krish
  10326. > > > > > 
  10327. > > > > > > 
  10328. > > > > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  10329. > > > > > > offloading as per the release notes.  I would say their is a problem.
  10330. > > > > > > Hopefully this will be a quick one, and a fix will be released soon.
  10331. > > > > > > 
  10332. > > > > > > Perhaps others can do a check of their RADIUS password logs and look for
  10333. > > > > > > this type of activity.
  10334. > > > > > >  > 
  10335. > > > > > > > regards
  10336. > > > > > > > krish
  10337. > > > > > > > 
  10338. > > > > > > > > 
  10339. > > > > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  10340. > > > > > > > > 
  10341. > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  10342. > > > > > > > > anything other that it only appears to be happening on our USR chassis.
  10343. > > > > > > > > 
  10344. > > > > > > > > -- 
  10345. > > > > > > > > Aaron Nabil
  10346. > > > > > > > > 
  10347. > > > > > > > > -
  10348. > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10349. > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10350. > > > > > > > >  For information on digests or retrieving files and old messages send
  10351. > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10352. > > > > > > > > 
  10353. > > > > > > > 
  10354. > > > > > > > -
  10355. > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10356. > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10357. > > > > > > >  For information on digests or retrieving files and old messages send
  10358. > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10359. > > > > > > > 
  10360. > > > > > > 
  10361. > > > > > > -----------------------------------------------------
  10362. > > > > > > Brian Feeny (BF304)     signal@shreve.net   
  10363. > > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10364. > > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10365. > > > > > > 
  10366. > > > > > > 
  10367. > > > > > > -
  10368. > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10369. > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10370. > > > > > >  For information on digests or retrieving files and old messages send
  10371. > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10372. > > > > > > 
  10373. > > > > > 
  10374. > > > > 
  10375. > > > > -----------------------------------------------------
  10376. > > > > Brian Feeny (BF304)     signal@shreve.net   
  10377. > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10378. > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10379. > > > > 
  10380. > > > 
  10381. > > 
  10382. > > -----------------------------------------------------
  10383. > > Brian Feeny (BF304)     signal@shreve.net   
  10384. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10385. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10386. > > 
  10387. > 
  10388.  
  10389. Brian Feeny (BF304)     signal@shreve.net   
  10390. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10391. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10392.  
  10393.  
  10394. -
  10395.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10396.  with "unsubscribe usr-tc" in the body of the message.
  10397.  For information on digests or retrieving files and old messages send
  10398.  "help" to the same address.  Do not use quotes in your message.
  10399.  
  10400.  
  10401. -------------------------------------------------------------------------------
  10402.  
  10403. From: Brian <signal@shreve.net>
  10404. Subject: RE: (usr-tc) Passwords getting corrupted
  10405. Date: 12 Apr 1999 11:01:18 -0500 (CDT)
  10406.  
  10407. On Mon, 12 Apr 1999, Mike Wronski wrote:
  10408.  
  10409. > 
  10410. > 
  10411. > |-----Original Message-----
  10412. > |From: owner-usr-tc@lists.xmission.com
  10413. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  10414. > |Sent: Sunday, April 11, 1999 10:13 PM
  10415. > |To: Tatai SV Krishnan
  10416. > |Cc: usr-tc@lists.xmission.com
  10417. > |Subject: Re: (usr-tc) Passwords getting corrupted
  10418. > |
  10419. > |
  10420. > |Tatai SV Krishnan writes...
  10421. > |>On Sun, 11 Apr 1999, Aaron Nabil wrote:
  10422. > |>> Our radius server (radiator) can log the cleartext passwords sent by
  10423. > |>> the client.  I've noticed an interesting pattern, failed attempts followed
  10424. > |>> by succesfull one, with only the last character of the password changed.  It
  10425. > |>> has been happening hundreds of times per day.
  10426. > |>>
  10427. > |>Is it possible for you to use the tap feature to capture this info?
  10428. > |>I have heard reports of this but I have not been able to get any one to
  10429. > |>work with me on this.  If you can either run tap to syslog and capture
  10430. > |>the data or if this is reproduceble on demand then it would be easy for
  10431. > |>us to identify the problem.
  10432. > |
  10433. > |It seems to be associated with particular users, I've sent mail to one
  10434. > |to see if he can call in while I'm capturing.
  10435. > 
  10436. > Do these users have >8 char passwords???
  10437.  
  10438.  
  10439. No, they do not, a variety of lengths.
  10440.  
  10441. Brian
  10442.  
  10443.  
  10444. > 
  10445. > 
  10446. > |>If running tap is a problem then you can try disabling ppp offloading and
  10447. > |>see if this problem exits.  That would give us somegood info.
  10448. > |
  10449. > |It's possible I could disable ppp offloading on one card and track
  10450. > |to see if the problem doesn't exist there.
  10451. > |
  10452. > |What is the performance hit of disabling offloading?  I'm running 3 DSP's
  10453. > |per ARC.
  10454. > 
  10455. > Its minimal. You can turn it back after the test.. Its just a good inidictor for
  10456. > us as to where the problem may be.
  10457. > 
  10458. > -M
  10459. > 
  10460. > 
  10461. > -
  10462. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10463. >  with "unsubscribe usr-tc" in the body of the message.
  10464. >  For information on digests or retrieving files and old messages send
  10465. >  "help" to the same address.  Do not use quotes in your message.
  10466. > 
  10467.  
  10468. Brian Feeny (BF304)     signal@shreve.net   
  10469. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10470. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10471.  
  10472.  
  10473. -
  10474.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10475.  with "unsubscribe usr-tc" in the body of the message.
  10476.  For information on digests or retrieving files and old messages send
  10477.  "help" to the same address.  Do not use quotes in your message.
  10478.  
  10479.  
  10480. -------------------------------------------------------------------------------
  10481.  
  10482. From: Aaron Nabil <nabil@spiritone.com>
  10483. Subject: Re: (usr-tc) Passwords getting corrupted
  10484. Date: 12 Apr 1999 09:03:32 -0700 (PDT)
  10485.  
  10486. Mike Wronski writes...
  10487. >|Tatai SV Krishnan writes...
  10488. >|>On Sun, 11 Apr 1999, Aaron Nabil wrote:
  10489. >|>> Our radius server (radiator) can log the cleartext passwords sent by
  10490. >|>> the client.  I've noticed an interesting pattern, failed attempts followed
  10491. >|>> by succesfull one, with only the last character of the password changed.  It
  10492. >|>> has been happening hundreds of times per day.
  10493. >|>>
  10494. >|>Is it possible for you to use the tap feature to capture this info?
  10495. >|>I have heard reports of this but I have not been able to get any one to
  10496. >|>work with me on this.  If you can either run tap to syslog and capture
  10497. >|>the data or if this is reproduceble on demand then it would be easy for
  10498. >|>us to identify the problem.
  10499. >|
  10500. >|It seems to be associated with particular users, I've sent mail to one
  10501. >|to see if he can call in while I'm capturing.
  10502. >
  10503. >Do these users have >8 char passwords???
  10504.  
  10505. No, it happens irrespective of password length.  I've seen it on 4 character
  10506. passwords.
  10507.  
  10508.  
  10509. -- 
  10510. Aaron Nabil
  10511.  
  10512. -
  10513.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10514.  with "unsubscribe usr-tc" in the body of the message.
  10515.  For information on digests or retrieving files and old messages send
  10516.  "help" to the same address.  Do not use quotes in your message.
  10517.  
  10518.  
  10519. -------------------------------------------------------------------------------
  10520.  
  10521. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  10522. Subject: Re: (usr-tc) Passwords getting corrupted
  10523. Date: 12 Apr 1999 11:31:13 -0500 (CDT)
  10524.  
  10525. On Mon, 12 Apr 1999, Brian wrote:
  10526. > 
  10527. > ahh, good point.  So the TAP goes into effect as soon as it gets a
  10528. > username sent to the ARC and BEFORE it gets a password sent?
  10529.  
  10530. The vsa attributes will take effect as soon as the authentication is 
  10531. over.  Both user name and password should first get through then the 
  10532. attributes are sent out.
  10533.  
  10534. krish
  10535.  
  10536. > 
  10537. > Brian
  10538. > 
  10539. > 
  10540. > > 
  10541. > > krish
  10542. > > 
  10543. > > > 
  10544. > > > Brian
  10545. > > > 
  10546. > > > 
  10547. > > > 
  10548. > > > > 
  10549. > > > > krish
  10550. > > > > 
  10551. > > > > 
  10552. > > > > > 
  10553. > > > > > > krish
  10554. > > > > > > 
  10555. > > > > > > > 
  10556. > > > > > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  10557. > > > > > > > offloading as per the release notes.  I would say their is a problem.
  10558. > > > > > > > Hopefully this will be a quick one, and a fix will be released soon.
  10559. > > > > > > > 
  10560. > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for
  10561. > > > > > > > this type of activity.
  10562. > > > > > > >  > 
  10563. > > > > > > > > regards
  10564. > > > > > > > > krish
  10565. > > > > > > > > 
  10566. > > > > > > > > > 
  10567. > > > > > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  10568. > > > > > > > > > 
  10569. > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  10570. > > > > > > > > > anything other that it only appears to be happening on our USR chassis.
  10571. > > > > > > > > > 
  10572. > > > > > > > > > -- 
  10573. > > > > > > > > > Aaron Nabil
  10574. > > > > > > > > > 
  10575. > > > > > > > > > -
  10576. > > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10577. > > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10578. > > > > > > > > >  For information on digests or retrieving files and old messages send
  10579. > > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10580. > > > > > > > > > 
  10581. > > > > > > > > 
  10582. > > > > > > > > -
  10583. > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10584. > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10585. > > > > > > > >  For information on digests or retrieving files and old messages send
  10586. > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10587. > > > > > > > > 
  10588. > > > > > > > 
  10589. > > > > > > > -----------------------------------------------------
  10590. > > > > > > > Brian Feeny (BF304)     signal@shreve.net   
  10591. > > > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10592. > > > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10593. > > > > > > > 
  10594. > > > > > > > 
  10595. > > > > > > > -
  10596. > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10597. > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10598. > > > > > > >  For information on digests or retrieving files and old messages send
  10599. > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10600. > > > > > > > 
  10601. > > > > > > 
  10602. > > > > > 
  10603. > > > > > -----------------------------------------------------
  10604. > > > > > Brian Feeny (BF304)     signal@shreve.net   
  10605. > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10606. > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10607. > > > > > 
  10608. > > > > 
  10609. > > > 
  10610. > > > -----------------------------------------------------
  10611. > > > Brian Feeny (BF304)     signal@shreve.net   
  10612. > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10613. > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10614. > > > 
  10615. > > 
  10616. > 
  10617. > -----------------------------------------------------
  10618. > Brian Feeny (BF304)     signal@shreve.net   
  10619. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10620. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10621. > 
  10622.  
  10623. -
  10624.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10625.  with "unsubscribe usr-tc" in the body of the message.
  10626.  For information on digests or retrieving files and old messages send
  10627.  "help" to the same address.  Do not use quotes in your message.
  10628.  
  10629.  
  10630. -------------------------------------------------------------------------------
  10631.  
  10632. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  10633. Subject: RE: (usr-tc) Passwords getting corrupted
  10634. Date: 12 Apr 1999 11:23:25 -0500
  10635.  
  10636. he can call in while I'm capturing.
  10637. |>
  10638. |>Do these users have >8 char passwords???
  10639. |
  10640. |No, it happens irrespective of password length.  I've seen it on 4 character
  10641. |passwords.
  10642. |
  10643.  
  10644. How about your secret length?? Any special chars (not A-z 0-9).. I am just
  10645. fishing here.
  10646.  
  10647.  
  10648. -M
  10649.  
  10650.  
  10651. -
  10652.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10653.  with "unsubscribe usr-tc" in the body of the message.
  10654.  For information on digests or retrieving files and old messages send
  10655.  "help" to the same address.  Do not use quotes in your message.
  10656.  
  10657.  
  10658. -------------------------------------------------------------------------------
  10659.  
  10660. From: Stefanita Vilcu <vsv@dnt.ro>
  10661. Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased lineoperation
  10662. Date: 12 Apr 1999 19:27:23 +0300
  10663.  
  10664. I have tried the same, but I am not able to get the prompt.
  10665.  
  10666. Best Regards,
  10667.  
  10668. -vsv
  10669.  
  10670.  
  10671. Ray Whelan wrote:
  10672.  
  10673. > Hi ,
  10674. >
  10675. > Below is the configuration on the setup which I tested, the Quad code in still
  10676. > in Beta (tcs3.5),
  10677. >
  10678. > Quad to HiPer ARC  - 2 Wire Leased Line setup
  10679. >
  10680. >  Total Control QUAD Analog/Digital
  10681. >  Total Control HiPer ARC
  10682. >  Courier V.Everything
  10683. >  Quad  Code: <: 6.0.4 DS>
  10684. >  Courier Code: <;3.0.13>
  10685. >  Hiper ARC Code: < 4.1.59>
  10686. >
  10687. >  The following is how to configure the Courier modem to connect to the Quad
  10688. > modem and get login prompt from the ARC
  10689. >
  10690. > Configuration for Courier is as follows:
  10691. > Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on
  10692. > courier set to on,
  10693. > at&L1 &b1&n14&w also set the baud rate of the DTE to 115200
  10694. >
  10695. > Configuration of the ARC
  10696. > Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes
  10697. >
  10698. > Configuration of the Quad analog/digital
  10699. > at&L1&B1&N14
  10700. > ats47.5=1
  10701. > ats56.6=0
  10702. > ats0=0
  10703. >
  10704. > DIP 5 off
  10705. >
  10706. > Regards
  10707. > Ray Whelan
  10708. >
  10709. > Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52
  10710. >
  10711. > Please respond to usr-tc@lists.xmission.com
  10712. >
  10713. > To:   usr-tc@lists.xmission.com
  10714. > cc:    (Ray Whelan/IE/3Com)
  10715. > Subject:  (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation
  10716. >
  10717. > Hi folks,
  10718. >
  10719. > I wonder if someone of you can tell me how can I setup an TC chassis for
  10720. > leased line operation.
  10721. > I want that the phone line to be plugged in an Analog Quad Modem and the
  10722. > modem "to be connected" in a speciffic interface from the HiperArc. The
  10723. > ARC will be configured to make ppp over that line, with no
  10724. > authentication, and give the same IP address every time. Of course that
  10725. > modem will not be available for the dual E1 card.
  10726. >
  10727. > Thank you,
  10728. >
  10729. > Stefanita Vilcu, Network Administrator - Dynamic Network Technologies,
  10730. > Bucharest, Romania
  10731. > vsv@dnt.ro
  10732.  
  10733.  
  10734. -
  10735.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10736.  with "unsubscribe usr-tc" in the body of the message.
  10737.  For information on digests or retrieving files and old messages send
  10738.  "help" to the same address.  Do not use quotes in your message.
  10739.  
  10740.  
  10741. -------------------------------------------------------------------------------
  10742.  
  10743. From: Stefanita Vilcu <vsv@dnt.ro>
  10744. Subject: (usr-tc) multiple questions
  10745. Date: 12 Apr 1999 19:30:51 +0300
  10746.  
  10747.  
  10748.  
  10749.  
  10750. -
  10751.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10752.  with "unsubscribe usr-tc" in the body of the message.
  10753.  For information on digests or retrieving files and old messages send
  10754.  "help" to the same address.  Do not use quotes in your message.
  10755.  
  10756.  
  10757. -------------------------------------------------------------------------------
  10758.  
  10759. From: Stefanita Vilcu <vsv@dnt.ro>
  10760. Subject: (usr-tc) multiple questions
  10761. Date: 12 Apr 1999 19:43:16 +0300
  10762.  
  10763. Hi,
  10764.  
  10765. Sorry for the empty message, here I my issues, maybe sbm. can help me:
  10766.  
  10767. I have an analog-digital modem configured to get the phone signal from
  10768. the nic (not from the E1 card) and to route it in the Hiper ARC. The
  10769. modem is configured as a dial-in modem, but the Init-script associated
  10770. with the line sends at&l1 making from it a leased line one.  My problem
  10771. is that I receive nothing from the HiperARC.  The modems stay connected
  10772. until timed-out but no character is sended (banner or ppp). After
  10773. timeout the quad modem resets and link again in leased mode, and so on,
  10774. the syslog debug shows nothing.
  10775.  
  10776. Is there a way to see if something is sent in the modem, from the
  10777. HiperARC?
  10778. How can I configure a line to make ppp with no authentication and static
  10779. Ip address?
  10780.  
  10781.  
  10782. TIA
  10783.  
  10784. -vsv
  10785.  
  10786.  
  10787. -
  10788.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10789.  with "unsubscribe usr-tc" in the body of the message.
  10790.  For information on digests or retrieving files and old messages send
  10791.  "help" to the same address.  Do not use quotes in your message.
  10792.  
  10793.  
  10794. -------------------------------------------------------------------------------
  10795.  
  10796. From: Brian <signal@shreve.net>
  10797. Subject: Re: (usr-tc) Passwords getting corrupted
  10798. Date: 12 Apr 1999 11:46:53 -0500 (CDT)
  10799.  
  10800. On Mon, 12 Apr 1999, Tatai SV Krishnan wrote:
  10801.  
  10802. > On Mon, 12 Apr 1999, Brian wrote:
  10803. > > 
  10804. > > ahh, good point.  So the TAP goes into effect as soon as it gets a
  10805. > > username sent to the ARC and BEFORE it gets a password sent?
  10806. > 
  10807. > The vsa attributes will take effect as soon as the authentication is 
  10808. > over.  Both user name and password should first get through then the 
  10809. > attributes are sent out.
  10810. > 
  10811. > krish
  10812.  
  10813.  
  10814. Right I understand.  I am asking about a traditional "add tap user foo
  10815. blah blah", does that tap take effect after the username is sent but
  10816. before the password is sent?  Becuase all I did was log into each arc and
  10817. setup a tap for 5 different users.
  10818.  
  10819.  
  10820. > 
  10821. > > 
  10822. > > Brian
  10823. > > 
  10824. > > 
  10825. > > > 
  10826. > > > krish
  10827. > > > 
  10828. > > > > 
  10829. > > > > Brian
  10830. > > > > 
  10831. > > > > 
  10832. > > > > 
  10833. > > > > > 
  10834. > > > > > krish
  10835. > > > > > 
  10836. > > > > > 
  10837. > > > > > > 
  10838. > > > > > > > krish
  10839. > > > > > > > 
  10840. > > > > > > > > 
  10841. > > > > > > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  10842. > > > > > > > > offloading as per the release notes.  I would say their is a problem.
  10843. > > > > > > > > Hopefully this will be a quick one, and a fix will be released soon.
  10844. > > > > > > > > 
  10845. > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for
  10846. > > > > > > > > this type of activity.
  10847. > > > > > > > >  > 
  10848. > > > > > > > > > regards
  10849. > > > > > > > > > krish
  10850. > > > > > > > > > 
  10851. > > > > > > > > > > 
  10852. > > > > > > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  10853. > > > > > > > > > > 
  10854. > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  10855. > > > > > > > > > > anything other that it only appears to be happening on our USR chassis.
  10856. > > > > > > > > > > 
  10857. > > > > > > > > > > -- 
  10858. > > > > > > > > > > Aaron Nabil
  10859. > > > > > > > > > > 
  10860. > > > > > > > > > > -
  10861. > > > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10862. > > > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10863. > > > > > > > > > >  For information on digests or retrieving files and old messages send
  10864. > > > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10865. > > > > > > > > > > 
  10866. > > > > > > > > > 
  10867. > > > > > > > > > -
  10868. > > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10869. > > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10870. > > > > > > > > >  For information on digests or retrieving files and old messages send
  10871. > > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10872. > > > > > > > > > 
  10873. > > > > > > > > 
  10874. > > > > > > > > -----------------------------------------------------
  10875. > > > > > > > > Brian Feeny (BF304)     signal@shreve.net   
  10876. > > > > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10877. > > > > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10878. > > > > > > > > 
  10879. > > > > > > > > 
  10880. > > > > > > > > -
  10881. > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10882. > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  10883. > > > > > > > >  For information on digests or retrieving files and old messages send
  10884. > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  10885. > > > > > > > > 
  10886. > > > > > > > 
  10887. > > > > > > 
  10888. > > > > > > -----------------------------------------------------
  10889. > > > > > > Brian Feeny (BF304)     signal@shreve.net   
  10890. > > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10891. > > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10892. > > > > > > 
  10893. > > > > > 
  10894. > > > > 
  10895. > > > > -----------------------------------------------------
  10896. > > > > Brian Feeny (BF304)     signal@shreve.net   
  10897. > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10898. > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10899. > > > > 
  10900. > > > 
  10901. > > 
  10902. > > -----------------------------------------------------
  10903. > > Brian Feeny (BF304)     signal@shreve.net   
  10904. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  10905. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  10906. > > 
  10907. > 
  10908.  
  10909. Brian Feeny (BF304)     signal@shreve.net   
  10910. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10911. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10912.  
  10913.  
  10914. -
  10915.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10916.  with "unsubscribe usr-tc" in the body of the message.
  10917.  For information on digests or retrieving files and old messages send
  10918.  "help" to the same address.  Do not use quotes in your message.
  10919.  
  10920.  
  10921. -------------------------------------------------------------------------------
  10922.  
  10923. From: Brian <signal@shreve.net>
  10924. Subject: RE: (usr-tc) Passwords getting corrupted
  10925. Date: 12 Apr 1999 11:50:17 -0500 (CDT)
  10926.  
  10927. On Mon, 12 Apr 1999, Mike Wronski wrote:
  10928.  
  10929. > he can call in while I'm capturing.
  10930. > |>
  10931. > |>Do these users have >8 char passwords???
  10932. > |
  10933. > |No, it happens irrespective of password length.  I've seen it on 4 character
  10934. > |passwords.
  10935. > |
  10936. > 
  10937. > How about your secret length?? Any special chars (not A-z 0-9).. I am just
  10938. > fishing here.
  10939.  
  10940. our secret is only alpha, no special characters
  10941.  
  10942. > 
  10943. > 
  10944. > -M
  10945. > 
  10946. > 
  10947. > -
  10948. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10949. >  with "unsubscribe usr-tc" in the body of the message.
  10950. >  For information on digests or retrieving files and old messages send
  10951. >  "help" to the same address.  Do not use quotes in your message.
  10952. > 
  10953.  
  10954. Brian Feeny (BF304)     signal@shreve.net   
  10955. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10956. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10957.  
  10958.  
  10959. -
  10960.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10961.  with "unsubscribe usr-tc" in the body of the message.
  10962.  For information on digests or retrieving files and old messages send
  10963.  "help" to the same address.  Do not use quotes in your message.
  10964.  
  10965.  
  10966. -------------------------------------------------------------------------------
  10967.  
  10968. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  10969. Subject: Re: (usr-tc) Passwords getting corrupted
  10970. Date: 12 Apr 1999 12:10:16 -0500 (CDT)
  10971.  
  10972. On Mon, 12 Apr 1999, Brian wrote:
  10973.  
  10974. > On Mon, 12 Apr 1999, Tatai SV Krishnan wrote:
  10975. > 
  10976. > > On Mon, 12 Apr 1999, Brian wrote:
  10977. > > > 
  10978. > > > ahh, good point.  So the TAP goes into effect as soon as it gets a
  10979. > > > username sent to the ARC and BEFORE it gets a password sent?
  10980. > > 
  10981. > > The vsa attributes will take effect as soon as the authentication is 
  10982. > > over.  Both user name and password should first get through then the 
  10983. > > attributes are sent out.
  10984. > > 
  10985. > > krish
  10986. > 
  10987. > 
  10988. > Right I understand.  I am asking about a traditional "add tap user foo
  10989. > blah blah", does that tap take effect after the username is sent but
  10990. > before the password is sent?  Becuase all I did was log into each arc and
  10991. > setup a tap for 5 different users.
  10992.  
  10993. As soon as the user name is received - it does not wait for the password.
  10994. I will check this out also - just to be sure.
  10995.  
  10996. krish
  10997.  
  10998.  
  10999. > 
  11000. > 
  11001. > > 
  11002. > > > 
  11003. > > > Brian
  11004. > > > 
  11005. > > > 
  11006. > > > > 
  11007. > > > > krish
  11008. > > > > 
  11009. > > > > > 
  11010. > > > > > Brian
  11011. > > > > > 
  11012. > > > > > 
  11013. > > > > > 
  11014. > > > > > > 
  11015. > > > > > > krish
  11016. > > > > > > 
  11017. > > > > > > 
  11018. > > > > > > > 
  11019. > > > > > > > > krish
  11020. > > > > > > > > 
  11021. > > > > > > > > > 
  11022. > > > > > > > > > So the short of it, is that I am seeing this too.  Yes I am running ppp
  11023. > > > > > > > > > offloading as per the release notes.  I would say their is a problem.
  11024. > > > > > > > > > Hopefully this will be a quick one, and a fix will be released soon.
  11025. > > > > > > > > > 
  11026. > > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for
  11027. > > > > > > > > > this type of activity.
  11028. > > > > > > > > >  > 
  11029. > > > > > > > > > > regards
  11030. > > > > > > > > > > krish
  11031. > > > > > > > > > > 
  11032. > > > > > > > > > > > 
  11033. > > > > > > > > > > > We are running V4.1.59 - 6  on our hiperARCs and 1.2.43 on the hiperDSPs.
  11034. > > > > > > > > > > > 
  11035. > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or
  11036. > > > > > > > > > > > anything other that it only appears to be happening on our USR chassis.
  11037. > > > > > > > > > > > 
  11038. > > > > > > > > > > > -- 
  11039. > > > > > > > > > > > Aaron Nabil
  11040. > > > > > > > > > > > 
  11041. > > > > > > > > > > > -
  11042. > > > > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11043. > > > > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  11044. > > > > > > > > > > >  For information on digests or retrieving files and old messages send
  11045. > > > > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  11046. > > > > > > > > > > > 
  11047. > > > > > > > > > > 
  11048. > > > > > > > > > > -
  11049. > > > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11050. > > > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  11051. > > > > > > > > > >  For information on digests or retrieving files and old messages send
  11052. > > > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  11053. > > > > > > > > > > 
  11054. > > > > > > > > > 
  11055. > > > > > > > > > -----------------------------------------------------
  11056. > > > > > > > > > Brian Feeny (BF304)     signal@shreve.net   
  11057. > > > > > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  11058. > > > > > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  11059. > > > > > > > > > 
  11060. > > > > > > > > > 
  11061. > > > > > > > > > -
  11062. > > > > > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11063. > > > > > > > > >  with "unsubscribe usr-tc" in the body of the message.
  11064. > > > > > > > > >  For information on digests or retrieving files and old messages send
  11065. > > > > > > > > >  "help" to the same address.  Do not use quotes in your message.
  11066. > > > > > > > > > 
  11067. > > > > > > > > 
  11068. > > > > > > > 
  11069. > > > > > > > -----------------------------------------------------
  11070. > > > > > > > Brian Feeny (BF304)     signal@shreve.net   
  11071. > > > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  11072. > > > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  11073. > > > > > > > 
  11074. > > > > > > 
  11075. > > > > > 
  11076. > > > > > -----------------------------------------------------
  11077. > > > > > Brian Feeny (BF304)     signal@shreve.net   
  11078. > > > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  11079. > > > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  11080. > > > > > 
  11081. > > > > 
  11082. > > > 
  11083. > > > -----------------------------------------------------
  11084. > > > Brian Feeny (BF304)     signal@shreve.net   
  11085. > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  11086. > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  11087. > > > 
  11088. > > 
  11089. > 
  11090. > -----------------------------------------------------
  11091. > Brian Feeny (BF304)     signal@shreve.net   
  11092. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  11093. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  11094. > 
  11095.  
  11096. -
  11097.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11098.  with "unsubscribe usr-tc" in the body of the message.
  11099.  For information on digests or retrieving files and old messages send
  11100.  "help" to the same address.  Do not use quotes in your message.
  11101.  
  11102.  
  11103. -------------------------------------------------------------------------------
  11104.  
  11105. From: Aaron Nabil <nabil@spiritone.com>
  11106. Subject: Re: (usr-tc) Passwords getting corrupted
  11107. Date: 12 Apr 1999 09:53:21 -0700 (PDT)
  11108.  
  11109. Mike Wronski writes...
  11110. >he can call in while I'm capturing.
  11111. >|>
  11112. >|>Do these users have >8 char passwords???
  11113. >|
  11114. >|No, it happens irrespective of password length.  I've seen it on 4 character
  11115. >|passwords.
  11116. >|
  11117. >
  11118. >How about your secret length?? Any special chars (not A-z 0-9).. I am just
  11119. >fishing here.
  11120.  
  11121. 9 characters long, all within [A-Za-z0-9].
  11122.  
  11123. -- 
  11124. Aaron Nabil
  11125.  
  11126. -
  11127.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11128.  with "unsubscribe usr-tc" in the body of the message.
  11129.  For information on digests or retrieving files and old messages send
  11130.  "help" to the same address.  Do not use quotes in your message.
  11131.  
  11132.  
  11133. -------------------------------------------------------------------------------
  11134.  
  11135. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  11136. Subject: RE: (usr-tc) Passwords getting corrupted
  11137. Date: 12 Apr 1999 12:15:35 -0500 (CDT)
  11138.  
  11139. On Mon, 12 Apr 1999, Brian wrote:
  11140.  
  11141.  
  11142. As soon as the user name is sent the tap starts - Here is a log
  11143.  
  11144.  
  11145. 1}$}%\}3}#} }-G~
  11146. NO CARRIER                           
  11147.  
  11148.  
  11149. TAP USER tkrishna on slot:2/mod:1 OUT:    6: ...!............
  11150. TAP USER tkrishna on slot:2/mod:1 OUT:    6: ......A.........
  11151. TAP USER tkrishna on slot:2/mod:1 OUT:    6: ...
  11152. TAP USER tkrishna on slot:2/mod:1 OUT:    7: ...!............
  11153. TAP USER tkrishna on slot:2/mod:1 OUT:    7: ......A.........
  11154. TAP USER tkrishna on slot:2/mod:1 OUT:    7: ...
  11155. TAP USER tkrishna on slot:2/mod:1 OUT:    8: ...!............
  11156. TAP USER tkrishna on slot:2/mod:1 OUT:    8: ......A.........
  11157. TAP USER tkrishna on slot:2/mod:1 OUT:    8: ...
  11158. TAP USER tkrishna on slot:2/mod:1 OUT:    9: ...!............
  11159. TAP USER tkrishna on slot:2/mod:1 OUT:    9: ......A.........
  11160. TAP USER tkrishna on slot:2/mod:1 OUT:    9: 
  11161.  
  11162.  
  11163.  
  11164.  
  11165. > On Mon, 12 Apr 1999, Mike Wronski wrote:
  11166. > 
  11167. > > he can call in while I'm capturing.
  11168. > > |>
  11169. > > |>Do these users have >8 char passwords???
  11170. > > |
  11171. > > |No, it happens irrespective of password length.  I've seen it on 4 character
  11172. > > |passwords.
  11173. > > |
  11174. > > 
  11175. > > How about your secret length?? Any special chars (not A-z 0-9).. I am just
  11176. > > fishing here.
  11177. > 
  11178. > our secret is only alpha, no special characters
  11179. > 
  11180. > > 
  11181. > > 
  11182. > > -M
  11183. > > 
  11184. > > 
  11185. > > -
  11186. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11187. > >  with "unsubscribe usr-tc" in the body of the message.
  11188. > >  For information on digests or retrieving files and old messages send
  11189. > >  "help" to the same address.  Do not use quotes in your message.
  11190. > > 
  11191. > 
  11192. > -----------------------------------------------------
  11193. > Brian Feeny (BF304)     signal@shreve.net   
  11194. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  11195. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  11196. > 
  11197. > 
  11198. > -
  11199. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11200. >  with "unsubscribe usr-tc" in the body of the message.
  11201. >  For information on digests or retrieving files and old messages send
  11202. >  "help" to the same address.  Do not use quotes in your message.
  11203. > 
  11204.  
  11205. -
  11206.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11207.  with "unsubscribe usr-tc" in the body of the message.
  11208.  For information on digests or retrieving files and old messages send
  11209.  "help" to the same address.  Do not use quotes in your message.
  11210.  
  11211.  
  11212. -------------------------------------------------------------------------------
  11213.  
  11214. From: Stefanita Vilcu <vsv@dnt.ro>
  11215. Subject: (usr-tc) plz. help, I see no way out
  11216. Date: 12 Apr 1999 21:18:07 +0300
  11217.  
  11218. Hi.
  11219.  
  11220. I have a modem configured for "nic" not for "priT1" and the following
  11221. configuration I made in the hiperarc:
  11222. HiPer>> show chassis slot 15
  11223.  
  11224. CHASSIS SLOT 15 SETTINGS
  11225. Owner:                      YES
  11226. Description:                Quad Modem
  11227. Number of Ports:            4
  11228. Type:                       STATIC  Console:                    NO
  11229. HiPer>> add iniT_SCRIPT answer commAND "ata"
  11230. HiPer>> set switchED interfaCE slot:15/mod:2 iniT_SCRIPT answer
  11231.  
  11232. connected with this modem is a courier in which I send "atd" the modems
  11233. connect but I receive nothing from the HiperARC.  Please advise.  I have
  11234. only one ideea, to get drunk! but I don't think it is usefull with the
  11235. hiperarc :-( .
  11236.  
  11237.  
  11238. Thank you
  11239.  
  11240. -vsv
  11241.  
  11242. ---
  11243. Stefanita Vilcu, Network Administrator - Dynamic Network Technologies,
  11244. Bucharest, Romania
  11245. vsv@dnt.ro
  11246.  
  11247.  
  11248. -
  11249.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11250.  with "unsubscribe usr-tc" in the body of the message.
  11251.  For information on digests or retrieving files and old messages send
  11252.  "help" to the same address.  Do not use quotes in your message.
  11253.  
  11254.  
  11255. -------------------------------------------------------------------------------
  11256.  
  11257. From: Blake Fithen <fithen@NetworksPlus.com>
  11258. Subject: (usr-tc) 23in. and 19in. racks
  11259. Date: 12 Apr 1999 13:27:59 -0500
  11260.  
  11261. Hello, we are going to put our USR stuff, 3640, and other 19inch
  11262. stuff into a somewhat "tight" location that requires us to use 23
  11263. inch racks.  Does anyone have recommendations on any type
  11264. of conversion device/anything that will make our 19 inch stuff fit
  11265. nice and snugly into the 23 inch racks??
  11266.  
  11267. thanks for your time, blake
  11268.  
  11269. -
  11270.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11271.  with "unsubscribe usr-tc" in the body of the message.
  11272.  For information on digests or retrieving files and old messages send
  11273.  "help" to the same address.  Do not use quotes in your message.
  11274.  
  11275.  
  11276. -------------------------------------------------------------------------------
  11277.  
  11278. From: Steve Rivera <sales@wrca.net>
  11279. Subject: (usr-tc) fs: USR Network Hardware
  11280. Date: 12 Apr 1999 15:16:04 -0400
  11281.  
  11282. 5- USR TC Chassis dual 45a
  11283. 1- USR TC chassis dual 70a, fan tray
  11284. 28- USR Quad digital NACS
  11285. 1- Netserver PRI
  11286. 1- Dual PRI
  11287. 1- NMC
  11288. 15- USR Quad analog/digital
  11289. 5- AS5100 cards (Cisco 2511)
  11290. 6- Netserver 16I+
  11291. 2- MP16
  11292. 4- Netserver 16 v34
  11293. 2- Netserver 8 v34
  11294.  
  11295.  
  11296. All sold with 30 day warranty
  11297.  
  11298.  
  11299.  
  11300. Steve Rivera  sales@wrca.net 732-833-2111
  11301. Check out product information and inventory.
  11302.        http://www.wrca.net NEW!
  11303. M-F 9:00-6:30 EST / 24HR EMAIL support and sales
  11304. '''''''''''''''''''''''''''''''''''''''''''''''
  11305. De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  11306. '''''''''''''''''''''''''''''''''''''''''''''''
  11307.  
  11308.  
  11309.  
  11310.      
  11311.   
  11312.  
  11313.  
  11314.  
  11315.  
  11316. -
  11317.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11318.  with "unsubscribe usr-tc" in the body of the message.
  11319.  For information on digests or retrieving files and old messages send
  11320.  "help" to the same address.  Do not use quotes in your message.
  11321.  
  11322.  
  11323. -------------------------------------------------------------------------------
  11324.  
  11325. From: "Frank Basso" <frank@got.net>
  11326. Subject: Re: (usr-tc) 23in. and 19in. racks
  11327. Date: 12 Apr 1999 12:38:23 -0700
  11328.  
  11329. Chatsworth products have adapter flanges.
  11330.  
  11331. -Frank
  11332. ----- Original Message ----- 
  11333. Sent: Monday, April 12, 1999 11:27 AM
  11334.  
  11335.  
  11336. > Hello, we are going to put our USR stuff, 3640, and other 19inch
  11337. > stuff into a somewhat "tight" location that requires us to use 23
  11338. > inch racks.  Does anyone have recommendations on any type
  11339. > of conversion device/anything that will make our 19 inch stuff fit
  11340. > nice and snugly into the 23 inch racks??
  11341. > 
  11342. > thanks for your time, blake
  11343. > 
  11344. > -
  11345. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11346. >  with "unsubscribe usr-tc" in the body of the message.
  11347. >  For information on digests or retrieving files and old messages send
  11348. >  "help" to the same address.  Do not use quotes in your message.
  11349. > 
  11350.  
  11351.  
  11352. -
  11353.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11354.  with "unsubscribe usr-tc" in the body of the message.
  11355.  For information on digests or retrieving files and old messages send
  11356.  "help" to the same address.  Do not use quotes in your message.
  11357.  
  11358.  
  11359. -------------------------------------------------------------------------------
  11360.  
  11361. From: "John Verreault" <verreaul@aei.ca>
  11362. Subject: RE: (usr-tc) fs: USR Network Hardware
  11363. Date: 12 Apr 1999 16:12:47 -0400
  11364.  
  11365. Prices required
  11366. John
  11367.  
  11368. > -----Original Message-----
  11369. > From: owner-usr-tc@lists.xmission.com
  11370. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera
  11371. > Sent: Monday, April 12, 1999 3:16 PM
  11372. > To: usr-tc@lists.xmission.com
  11373. > Subject: (usr-tc) fs: USR Network Hardware
  11374. > 
  11375. > 
  11376. > 5- USR TC Chassis dual 45a
  11377. > 1- USR TC chassis dual 70a, fan tray
  11378. > 28- USR Quad digital NACS
  11379. > 1- Netserver PRI
  11380. > 1- Dual PRI
  11381. > 1- NMC
  11382. > 15- USR Quad analog/digital
  11383. > 5- AS5100 cards (Cisco 2511)
  11384. > 6- Netserver 16I+
  11385. > 2- MP16
  11386. > 4- Netserver 16 v34
  11387. > 2- Netserver 8 v34
  11388. > 
  11389. > 
  11390. > All sold with 30 day warranty
  11391. > 
  11392. > 
  11393. > 
  11394. > Steve Rivera  sales@wrca.net 732-833-2111
  11395. > Check out product information and inventory.
  11396. >        http://www.wrca.net NEW!
  11397. > M-F 9:00-6:30 EST / 24HR EMAIL support and sales
  11398. > '''''''''''''''''''''''''''''''''''''''''''''''
  11399. > De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  11400. > '''''''''''''''''''''''''''''''''''''''''''''''
  11401. > 
  11402. > 
  11403. > 
  11404. >      
  11405. >   
  11406. > 
  11407. > 
  11408. > 
  11409. > 
  11410. > -
  11411. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11412. >  with "unsubscribe usr-tc" in the body of the message.
  11413. >  For information on digests or retrieving files and old messages send
  11414. >  "help" to the same address.  Do not use quotes in your message.
  11415. > 
  11416.  
  11417. -
  11418.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11419.  with "unsubscribe usr-tc" in the body of the message.
  11420.  For information on digests or retrieving files and old messages send
  11421.  "help" to the same address.  Do not use quotes in your message.
  11422.  
  11423.  
  11424. -------------------------------------------------------------------------------
  11425.  
  11426. From: Greg Genge <greg@dynavar.com>
  11427. Subject: RE: (usr-tc) fs: USR Network Hardware
  11428. Date: 12 Apr 1999 15:39:57 -0700
  11429.  
  11430. Hi Steve, This is greg@dynavar.com (using Cam's email) I am interested in
  11431. buying all 6 Netserver16I's. What price would you give me for those. I
  11432. actually could use 10. I have a customer I can resell them to if the price
  11433. is right.
  11434.  
  11435. How much for 1 and for 6?
  11436.  
  11437. And How much for the Dual PRI card? Would you take $800.
  11438.  
  11439. Please reply to greg@dynavar.com
  11440.  
  11441. Regards, Greg
  11442.  
  11443. At 04:12 PM 12/04/99 -0400, you wrote:
  11444. >Prices required
  11445. >John
  11446. >
  11447. >> -----Original Message-----
  11448. >> From: owner-usr-tc@lists.xmission.com
  11449. >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera
  11450. >> Sent: Monday, April 12, 1999 3:16 PM
  11451. >> To: usr-tc@lists.xmission.com
  11452. >> Subject: (usr-tc) fs: USR Network Hardware
  11453. >> 
  11454. >> 
  11455. >> 5- USR TC Chassis dual 45a
  11456. >> 1- USR TC chassis dual 70a, fan tray
  11457. >> 28- USR Quad digital NACS
  11458. >> 1- Netserver PRI
  11459. >> 1- Dual PRI
  11460. >> 1- NMC
  11461. >> 15- USR Quad analog/digital
  11462. >> 5- AS5100 cards (Cisco 2511)
  11463. >> 6- Netserver 16I+
  11464. >> 2- MP16
  11465. >> 4- Netserver 16 v34
  11466. >> 2- Netserver 8 v34
  11467. >> 
  11468. >> 
  11469. >> All sold with 30 day warranty
  11470. >> 
  11471. >> 
  11472. >> 
  11473. >> Steve Rivera  sales@wrca.net 732-833-2111
  11474. >> Check out product information and inventory.
  11475. >>        http://www.wrca.net NEW!
  11476. >> M-F 9:00-6:30 EST / 24HR EMAIL support and sales
  11477. >> '''''''''''''''''''''''''''''''''''''''''''''''
  11478. >> De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  11479. >> '''''''''''''''''''''''''''''''''''''''''''''''
  11480. >> 
  11481. >> 
  11482. >> 
  11483. >>      
  11484. >>   
  11485. >> 
  11486. >> 
  11487. >> 
  11488. >> 
  11489. >> -
  11490. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11491. >>  with "unsubscribe usr-tc" in the body of the message.
  11492. >>  For information on digests or retrieving files and old messages send
  11493. >>  "help" to the same address.  Do not use quotes in your message.
  11494. >> 
  11495. >
  11496. >-
  11497. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11498. > with "unsubscribe usr-tc" in the body of the message.
  11499. > For information on digests or retrieving files and old messages send
  11500. > "help" to the same address.  Do not use quotes in your message.
  11501. > 
  11502.  
  11503. -
  11504.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11505.  with "unsubscribe usr-tc" in the body of the message.
  11506.  For information on digests or retrieving files and old messages send
  11507.  "help" to the same address.  Do not use quotes in your message.
  11508.  
  11509.  
  11510. -------------------------------------------------------------------------------
  11511.  
  11512. From: "Kalev Nurklik" <kalev@mail.lbi.ee>
  11513. Subject: Re: (usr-tc) Tftp'ing to the ARC
  11514. Date: 13 Apr 1999 13:44:09 +0300
  11515.  
  11516. > On Fri, 9 Apr 1999, Tatai SV Krishnan wrote:
  11517. > 
  11518. > > On Fri, 9 Apr 1999, Brian wrote:
  11519. > > 
  11520. > > > 
  11521. > > > Does anyone have any suggestions about what to do when your tftp to an ARC
  11522. > > > fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  11523. > > > worked fine in all my other ARC's.  
  11524. > > > 
  11525. > > > I know I can probably erase the config and start afresh, but I am hoping
  11526. > > > someone has a more recoverable solution.
  11527. > > 
  11528. > > You can program the hiper arc to get the file on boot up from a tftp 
  11529. > > server.  
  11530. > > do a set bootr ip ?
  11531. > > you will see the command necessary
  11532. > 
  11533. > But aren't the odds that if I was unable to tftp the netserve.dmf into the
  11534. > ARC, that the arc won't be able to tftp the file into itself upon bootup
  11535. > either?  I mean, woudln't I still probably need to erase the config?
  11536.  
  11537. Maybe but as I mentioned once before the reboot seem to defrag
  11538. flash on the ARC so probably this will work. If rebooting Your ARC
  11539. couple of times isn't very troublesome then do this -
  11540. *before reboot do "list files" on ARC and check what "Deleted
  11541. Sectors" value is.
  11542. After reload check "list files" again. Deletes Sectors should be
  11543. considerably smaller - You have more room for new files.
  11544.  
  11545. > > 
  11546. > > krish
  11547. > > 
  11548. > > > 
  11549. > > > Brian
  11550. > > > 
  11551. > > > 
  11552.  
  11553. __________________________________
  11554. Kalev Nurklik
  11555. MicroLink Online
  11556. Sakala 19, 10141 Tallinn, Estonia
  11557. Tel: +372 6 308 909
  11558. Fax: +372 6 308 901
  11559. E-mail: k.nurklik@online.ee
  11560. http://www.online.ee
  11561.  
  11562. -
  11563.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11564.  with "unsubscribe usr-tc" in the body of the message.
  11565.  For information on digests or retrieving files and old messages send
  11566.  "help" to the same address.  Do not use quotes in your message.
  11567.  
  11568.  
  11569. -------------------------------------------------------------------------------
  11570.  
  11571. From: Marcelo Souza <mpsouza@centroin.com.br>
  11572. Subject: (usr-tc) Problems with Winmodems
  11573. Date: 13 Apr 1999 09:29:55 -0300 (EST)
  11574.  
  11575.  
  11576.  
  11577.     Recently we receive some complains from users of USR V.90
  11578. Winmodems (model 5698) in connecting our Hiper TC.
  11579.     Is there any known problem with these modems?
  11580.  
  11581.     The chassis :
  11582.  
  11583.     DSP :     1.1.91   
  11584.     ARC :    4.0.29
  11585.     NMC :    5.5.1
  11586.  
  11587. - Marcelo
  11588.  
  11589.  
  11590. -
  11591.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11592.  with "unsubscribe usr-tc" in the body of the message.
  11593.  For information on digests or retrieving files and old messages send
  11594.  "help" to the same address.  Do not use quotes in your message.
  11595.  
  11596.  
  11597. -------------------------------------------------------------------------------
  11598.  
  11599. From: Brian <signal@shreve.net>
  11600. Subject: Re: (usr-tc) Problems with Winmodems
  11601. Date: 13 Apr 1999 07:55:48 -0500 (CDT)
  11602.  
  11603. On Tue, 13 Apr 1999, Marcelo Souza wrote:
  11604.  
  11605. > 
  11606. > 
  11607. >     Recently we receive some complains from users of USR V.90
  11608. > Winmodems (model 5698) in connecting our Hiper TC.
  11609. >     Is there any known problem with these modems?
  11610. > 
  11611. >     The chassis :
  11612. > 
  11613. >     DSP :     1.1.91   
  11614. >     ARC :    4.0.29
  11615. >     NMC :    5.5.1
  11616.  
  11617. my opinion would be to upgrade to the latest service release of arc/hdm
  11618. code.  God knows the code you are running has alot of problems, especially
  11619. memory leaks.
  11620.  
  11621. Brian
  11622.  
  11623.  
  11624. > 
  11625. > - Marcelo
  11626. > 
  11627. > 
  11628. > -
  11629. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11630. >  with "unsubscribe usr-tc" in the body of the message.
  11631. >  For information on digests or retrieving files and old messages send
  11632. >  "help" to the same address.  Do not use quotes in your message.
  11633. > 
  11634.  
  11635. Brian Feeny (BF304)     signal@shreve.net   
  11636. 318-222-2638 x 109    http://www.shreve.net/~signal      
  11637. Network Administrator   ShreveNet Inc. (ASN 11881)           
  11638.  
  11639.  
  11640. -
  11641.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11642.  with "unsubscribe usr-tc" in the body of the message.
  11643.  For information on digests or retrieving files and old messages send
  11644.  "help" to the same address.  Do not use quotes in your message.
  11645.  
  11646.  
  11647. -------------------------------------------------------------------------------
  11648.  
  11649. From: Alessandro Alves <aalves@mpcnet.com.br>
  11650. Subject: Re: (usr-tc) Problems with Winmodems
  11651. Date: 13 Apr 1999 09:56:56 -0300
  11652.  
  11653. Marcelo,
  11654.  
  11655.     The version of Hiper DSP/ARC are very old ..... and you will have some
  11656. problems to connect a Winmodem to the TC, after upgrade you'll have more
  11657. success.
  11658.  
  11659.     As vers=F5es que voc=EA est=E1 usando na Hiper DSP e ARC s=E3o muito velhas=
  11660.  .....
  11661. e realmente existem alguns problemas para se conectar o Winmodem ao TC,
  11662. atualizando estas vers=F5es, voc=EA ter=E1 mais sucesso.
  11663.  
  11664. Um abra=E7o
  11665.  
  11666. Alessandro
  11667.  
  11668. Suporte T=E9cnico 3Com/US Robotics
  11669. Network Express
  11670.  
  11671. At 09:29 AM 4/13/99 -0300, you wrote:
  11672. >
  11673. >
  11674. >    Recently we receive some complains from users of USR V.90
  11675. >Winmodems (model 5698) in connecting our Hiper TC.
  11676. >    Is there any known problem with these modems?
  11677. >
  11678. >    The chassis :
  11679. >
  11680. >    DSP :     1.1.91  =20
  11681. >    ARC :    4.0.29
  11682. >    NMC :    5.5.1
  11683. >
  11684. >- Marcelo
  11685. >
  11686. >
  11687. >-
  11688. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11689. > with "unsubscribe usr-tc" in the body of the message.
  11690. > For information on digests or retrieving files and old messages send
  11691. > "help" to the same address.  Do not use quotes in your message.
  11692. >=20
  11693.  
  11694. -
  11695.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11696.  with "unsubscribe usr-tc" in the body of the message.
  11697.  For information on digests or retrieving files and old messages send
  11698.  "help" to the same address.  Do not use quotes in your message.
  11699.  
  11700.  
  11701. -------------------------------------------------------------------------------
  11702.  
  11703. From: K Mitchell <mitch@keyconn.net>
  11704. Subject: Re: (usr-tc) Problems with Winmodems
  11705. Date: 13 Apr 1999 09:00:37 -0400
  11706.  
  11707. At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote:
  11708. >
  11709. >    Recently we receive some complains from users of USR V.90
  11710. >Winmodems (model 5698) in connecting our Hiper TC.
  11711. >    Is there any known problem with these modems?
  11712.  
  11713. Winmodems are notorious for problems, but the latest firmware upgrade has
  11714. been working well here. I believe it's 5.32, check at 
  11715. http://808hi.com/56k/x2-lucent.htm
  11716.   Also, there are ARC and DSP upgrades available that will help with a lot
  11717. of v90 connectivity issues. The most recent are;
  11718. ARC 4.1.59-6
  11719. DSP 1.2.43(PRI/T-1)
  11720. DSP 1.2.59(E-1)
  11721. All are available free on the totalservice website even if you don't have a
  11722. support contract.
  11723.  
  11724. Kirk
  11725.  
  11726.  
  11727.  
  11728. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  11729. Keystone Connect                http://www.keyconn.net
  11730. Altoona, PA   814-941-5000         We Unlock the World
  11731.  
  11732.  
  11733. -
  11734.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11735.  with "unsubscribe usr-tc" in the body of the message.
  11736.  For information on digests or retrieving files and old messages send
  11737.  "help" to the same address.  Do not use quotes in your message.
  11738.  
  11739.  
  11740. -------------------------------------------------------------------------------
  11741.  
  11742. From: Jeff Mcadams <jeffm@iglou.com>
  11743. Subject: Re: (usr-tc) Problems with Winmodems
  11744. Date: 13 Apr 1999 09:45:19 -0400 (EDT)
  11745.  
  11746. Thus spake K Mitchell
  11747. >At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote:
  11748. >>    Recently we receive some complains from users of USR V.90
  11749. >>Winmodems (model 5698) in connecting our Hiper TC.
  11750. >>    Is there any known problem with these modems?
  11751.  
  11752. >Winmodems are notorious for problems, but the latest firmware upgrade has
  11753. >been working well here. I believe it's 5.32, check at 
  11754. >http://808hi.com/56k/x2-lucent.htm
  11755.  
  11756. Whoa, Kirk...he was talking about 3Com/USR winmodems...while they
  11757. function on the same basic principles, the code is very different.  :)
  11758.  
  11759. Yes, 5.32 and later on the Lucent's is good, but 3Com winmodems are a
  11760. different matter entirely.
  11761.  
  11762. >  Also, there are ARC and DSP upgrades available that will help with a lot
  11763. >of v90 connectivity issues. The most recent are;
  11764. >ARC 4.1.59-6
  11765. >DSP 1.2.43(PRI/T-1)
  11766. >DSP 1.2.59(E-1)
  11767. >All are available free on the totalservice website even if you don't have a
  11768. >support contract.
  11769.  
  11770. Yes, upgrading to these versions would be a huge improvement...still not
  11771. perfect (my infamous ticket 58316 has just been reopened...fun joy...its
  11772. now a toddler, had its first birthday a week or so ago), but much
  11773. better.
  11774. -- 
  11775. Jeff McAdams                            Email: jeffm@iglou.com
  11776. Head Network Administrator              Voice: (502) 966-3848
  11777. IgLou Internet Services                        (800) 436-4456
  11778.  
  11779. -
  11780.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11781.  with "unsubscribe usr-tc" in the body of the message.
  11782.  For information on digests or retrieving files and old messages send
  11783.  "help" to the same address.  Do not use quotes in your message.
  11784.  
  11785.  
  11786. -------------------------------------------------------------------------------
  11787.  
  11788. From: Alessandro Alves <aalves@mpcnet.com.br>
  11789. Subject: Re: (usr-tc) Problems with Winmodems
  11790. Date: 13 Apr 1999 10:59:30 -0300
  11791.  
  11792. Hi all,
  11793.  
  11794.     The code 1.2.59(E-1) is for E1-PRI, the custumer uses E1/R2 Brazil, he has
  11795. to use a beta code for E1/R2-Brazil.
  11796.  
  11797. At 09:00 AM 4/13/99 -0400, you wrote:
  11798. >At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote:
  11799. >>
  11800. >>    Recently we receive some complains from users of USR V.90
  11801. >>Winmodems (model 5698) in connecting our Hiper TC.
  11802. >>    Is there any known problem with these modems?
  11803. >
  11804. >Winmodems are notorious for problems, but the latest firmware upgrade has
  11805. >been working well here. I believe it's 5.32, check at 
  11806. >http://808hi.com/56k/x2-lucent.htm
  11807. >  Also, there are ARC and DSP upgrades available that will help with a lot
  11808. >of v90 connectivity issues. The most recent are;
  11809. >ARC 4.1.59-6
  11810. >DSP 1.2.43(PRI/T-1)
  11811. >DSP 1.2.59(E-1)
  11812. >All are available free on the totalservice website even if you don't have a
  11813. >support contract.
  11814. >
  11815. >Kirk
  11816. >
  11817. >
  11818. >
  11819. >Kirk Mitchell-General Manager     sysadmin@keyconn.net
  11820. >Keystone Connect                http://www.keyconn.net
  11821. >Altoona, PA   814-941-5000         We Unlock the World
  11822. >
  11823. >
  11824. >-
  11825. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11826. > with "unsubscribe usr-tc" in the body of the message.
  11827. > For information on digests or retrieving files and old messages send
  11828. > "help" to the same address.  Do not use quotes in your message.
  11829. > 
  11830.  
  11831. -
  11832.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11833.  with "unsubscribe usr-tc" in the body of the message.
  11834.  For information on digests or retrieving files and old messages send
  11835.  "help" to the same address.  Do not use quotes in your message.
  11836.  
  11837.  
  11838. -------------------------------------------------------------------------------
  11839.  
  11840. From: "Mark A. Cooper" <mcooper@fais.net>
  11841. Subject: (usr-tc) DS1 Line Code Violations
  11842. Date: 13 Apr 1999 09:32:23 -0500
  11843.  
  11844. I have been monitoring the current interval statistics on the channelized 
  11845. T1 lines into my Hiper DSP chassis.
  11846. The buildout is D4/B8ZS.  I am seeing a lot of linecode violations but it 
  11847. doesn't seem to be effecting anything.  Is this anything to worry with? 
  11848.  Something to look at in the DS1 or DS0 settings?  Phone company problem?
  11849.  
  11850. Errored Seconds            756
  11851. Severely Errored Seconds        0
  11852. Severely Errored Framing Seconds    0
  11853. Unavailable Seconds            0
  11854. Controlled Slip Seconds            0
  11855. Path Coding Violations            0
  11856. Line Errored Seconds            756
  11857. Bursty Errored Seconds            0
  11858. Degraded Minutes            12
  11859. Line Code Violations            84410
  11860.  
  11861. ***************************
  11862. Mark A. Cooper, Owner
  11863. Technical Support Associates
  11864. Fayette Area Internet Services
  11865. 135 W. Travis
  11866. La Grange, TX  78945
  11867. 409.968.3999
  11868. ***************************
  11869.  
  11870.  
  11871. -
  11872.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11873.  with "unsubscribe usr-tc" in the body of the message.
  11874.  For information on digests or retrieving files and old messages send
  11875.  "help" to the same address.  Do not use quotes in your message.
  11876.  
  11877.  
  11878. -------------------------------------------------------------------------------
  11879.  
  11880. From: Norm_Miller@3com.com
  11881. Subject: Re: (usr-tc) Tftp'ing to the ARC
  11882. Date: 13 Apr 1999 10:51:51 -0400
  11883.  
  11884.  
  11885.  
  11886. Kalev,
  11887. This is also documented in 3KB at http://knowledgebase.3com.com/
  11888.  
  11889. To set up an ARC  to ask for code, BootRom needs to be configured. You can do
  11890. this via the setup menu that is displayed during the boot process or configure
  11891. it via set commands. Below are the commands that need to be set, you can make a
  11892. do file if you want.
  11893.  
  11894. SET BOOTROM BOOT INTERFACE eth:1
  11895. SET BOOTROM  IP INTERFACE eth:1 ADDRESS 199.37.208.112 NETMASK 255.255.255.224
  11896. GATEWAY 199.37.208.161
  11897. SET BOOTROM  IP INTERFACE eth:1 LOADFILE netserve.dmf TFTP_BOOT ONCE  TFTPSERVER
  11898. 199.37.210.23
  11899. SAVE ALL
  11900.  
  11901. To view your BOOTROM sttings use
  11902. SHOW BOOTROM IP INTERFACE eth:1
  11903. SHOW BOOTROM SETTINGS
  11904.  
  11905. When you want an ARC to request a file, place the appropriate file renamed to
  11906. netserve.dmf into the directory on your pc  that you have configured as the
  11907. default download directory for the TFTPServer application. Start the TFTPServer
  11908. application on your pc, telnet to the shelf you want to work with and do a
  11909. SET BOOTROM CONFIG BOOTMODE NETWORK
  11910. reboot
  11911. when the ARC reboots it will do a TFTP GET to the TFTPServer and download the
  11912. file, it will also set the BOOTMODE back to FLASH.  This is substantially faster
  11913. then doing a download via TCM. We have a little TFTP server package that one of
  11914. our guys wrote for folks that  you can pull off of our website at
  11915. http://infodeli.3com.com/software/utilities_for_windows_32_bit.htm
  11916.  
  11917.  
  11918. regards,
  11919. /norm
  11920.  
  11921.  
  11922.  
  11923.  
  11924.  
  11925. "Kalev Nurklik" <kalev@mail.lbi.ee> on 04/13/99 06:44:09 AM
  11926.  
  11927. Please respond to usr-tc@lists.xmission.com
  11928.  
  11929. cc:    (Norm Miller/US/3Com)
  11930.  
  11931.  
  11932.  
  11933.  
  11934. > On Fri, 9 Apr 1999, Tatai SV Krishnan wrote:
  11935. >
  11936. > > On Fri, 9 Apr 1999, Brian wrote:
  11937. > >
  11938. > > >
  11939. > > > Does anyone have any suggestions about what to do when your tftp to an ARC
  11940. > > > fails?  I am trying to tftp "netserve.dmf" to an arc, and it failed.  It
  11941. > > > worked fine in all my other ARC's.
  11942. > > >
  11943. > > > I know I can probably erase the config and start afresh, but I am hoping
  11944. > > > someone has a more recoverable solution.
  11945. > >
  11946. > > You can program the hiper arc to get the file on boot up from a tftp
  11947. > > server.
  11948. > > do a set bootr ip ?
  11949. > > you will see the command necessary
  11950. >
  11951. > But aren't the odds that if I was unable to tftp the netserve.dmf into the
  11952. > ARC, that the arc won't be able to tftp the file into itself upon bootup
  11953. > either?  I mean, woudln't I still probably need to erase the config?
  11954.  
  11955. Maybe but as I mentioned once before the reboot seem to defrag
  11956. flash on the ARC so probably this will work. If rebooting Your ARC
  11957. couple of times isn't very troublesome then do this -
  11958. *before reboot do "list files" on ARC and check what "Deleted
  11959. Sectors" value is.
  11960. After reload check "list files" again. Deletes Sectors should be
  11961. considerably smaller - You have more room for new files.
  11962.  
  11963. > >
  11964. > > krish
  11965. > >
  11966. > > >
  11967. > > > Brian
  11968. > > >
  11969. > > >
  11970.  
  11971. __________________________________
  11972. Kalev Nurklik
  11973. MicroLink Online
  11974. Sakala 19, 10141 Tallinn, Estonia
  11975. Tel: +372 6 308 909
  11976. Fax: +372 6 308 901
  11977. E-mail: k.nurklik@online.ee
  11978. http://www.online.ee
  11979.  
  11980. -
  11981.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11982.  with "unsubscribe usr-tc" in the body of the message.
  11983.  For information on digests or retrieving files and old messages send
  11984.  "help" to the same address.  Do not use quotes in your message.
  11985.  
  11986.  
  11987.  
  11988.  
  11989.  
  11990.  
  11991.  
  11992.  
  11993.  
  11994. -
  11995.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11996.  with "unsubscribe usr-tc" in the body of the message.
  11997.  For information on digests or retrieving files and old messages send
  11998.  "help" to the same address.  Do not use quotes in your message.
  11999.  
  12000.  
  12001. -------------------------------------------------------------------------------
  12002.  
  12003. From: "Ray Whelan" <Ray_Whelan@eur.3com.com>
  12004. Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased
  12005. Date: 13 Apr 1999 16:45:30 +0100
  12006.  
  12007.  
  12008.  
  12009. Hi Stefanita,
  12010.  
  12011. First are you getting modems sync up.
  12012. and if so and you just garbage across your screen ?
  12013. You must  used Quad code from TCS3.5 Beta ,  older code did have problems.
  12014.  
  12015. Ray Whelan
  12016.  
  12017.  
  12018.  
  12019.  
  12020.  
  12021. Stefanita Vilcu <vsv@dnt.ro> on 12/04/99 17:27:23
  12022.  
  12023. Please respond to usr-tc@lists.xmission.com
  12024.  
  12025. cc:    (Ray Whelan/IE/3Com)
  12026.  
  12027.  
  12028.  
  12029.  
  12030. I have tried the same, but I am not able to get the prompt.
  12031.  
  12032. Best Regards,
  12033.  
  12034. -vsv
  12035.  
  12036.  
  12037. Ray Whelan wrote:
  12038.  
  12039. > Hi ,
  12040. >
  12041. > Below is the configuration on the setup which I tested, the Quad code in still
  12042. > in Beta (tcs3.5),
  12043. >
  12044. > Quad to HiPer ARC  - 2 Wire Leased Line setup
  12045. >
  12046. >  Total Control QUAD Analog/Digital
  12047. >  Total Control HiPer ARC
  12048. >  Courier V.Everything
  12049. >  Quad  Code: <: 6.0.4 DS>
  12050. >  Courier Code: <;3.0.13>
  12051. >  Hiper ARC Code: < 4.1.59>
  12052. >
  12053. >  The following is how to configure the Courier modem to connect to the Quad
  12054. > modem and get login prompt from the ARC
  12055. >
  12056. > Configuration for Courier is as follows:
  12057. > Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on
  12058. > courier set to on,
  12059. > at&L1 &b1&n14&w also set the baud rate of the DTE to 115200
  12060. >
  12061. > Configuration of the ARC
  12062. > Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes
  12063. >
  12064. > Configuration of the Quad analog/digital
  12065. > at&L1&B1&N14
  12066. > ats47.5=1
  12067. > ats56.6=0
  12068. > ats0=0
  12069. >
  12070. > DIP 5 off
  12071. >
  12072. > Regards
  12073. > Ray Whelan
  12074. >
  12075. > Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52
  12076. >
  12077. > Please respond to usr-tc@lists.xmission.com
  12078. >
  12079. > To:   usr-tc@lists.xmission.com
  12080. > cc:    (Ray Whelan/IE/3Com)
  12081. > Subject:  (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation
  12082. >
  12083. > Hi folks,
  12084. >
  12085. > I wonder if someone of you can tell me how can I setup an TC chassis for
  12086. > leased line operation.
  12087. > I want that the phone line to be plugged in an Analog Quad Modem and the
  12088. > modem "to be connected" in a speciffic interface from the HiperArc. The
  12089. > ARC will be configured to make ppp over that line, with no
  12090. > authentication, and give the same IP address every time. Of course that
  12091. > modem will not be available for the dual E1 card.
  12092. >
  12093. > Thank you,
  12094. >
  12095. > Stefanita Vilcu, Network Administrator - Dynamic Network Technologies,
  12096. > Bucharest, Romania
  12097. > vsv@dnt.ro
  12098.  
  12099.  
  12100. -
  12101.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12102.  with "unsubscribe usr-tc" in the body of the message.
  12103.  For information on digests or retrieving files and old messages send
  12104.  "help" to the same address.  Do not use quotes in your message.
  12105.  
  12106.  
  12107.  
  12108.  
  12109.  
  12110.  
  12111.  
  12112.  
  12113.  
  12114. -
  12115.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12116.  with "unsubscribe usr-tc" in the body of the message.
  12117.  For information on digests or retrieving files and old messages send
  12118.  "help" to the same address.  Do not use quotes in your message.
  12119.  
  12120.  
  12121. -------------------------------------------------------------------------------
  12122.  
  12123. From: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
  12124. Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased
  12125. Date: 13 Apr 1999 19:58:03 +0400
  12126.  
  12127. Hello!
  12128.  
  12129. Ray Whelan wrote:
  12130.  
  12131. > Hi Stefanita,
  12132. >
  12133. > First are you getting modems sync up.
  12134. > and if so and you just garbage across your screen ?
  12135. > You must  used Quad code from TCS3.5 Beta ,  older code did have problems.
  12136.  
  12137.  As far as I know, TCS3.5 is last relise for Netserver Analog60/PRI. Can Netserver
  12138. support leased line operation with TCS3.5 too?
  12139.  
  12140.  
  12141.  
  12142. >
  12143. >
  12144. > Ray Whelan
  12145. >
  12146. > Stefanita Vilcu <vsv@dnt.ro> on 12/04/99 17:27:23
  12147. >
  12148. > Please respond to usr-tc@lists.xmission.com
  12149. >
  12150. > To:   usr-tc@lists.xmission.com
  12151. > cc:    (Ray Whelan/IE/3Com)
  12152. > Subject:  Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased lineoperation
  12153. >
  12154. > I have tried the same, but I am not able to get the prompt.
  12155. >
  12156. > Best Regards,
  12157. >
  12158. > -vsv
  12159. >
  12160. > Ray Whelan wrote:
  12161. >
  12162. > > Hi ,
  12163. > >
  12164. > > Below is the configuration on the setup which I tested, the Quad code in still
  12165. > > in Beta (tcs3.5),
  12166. > >
  12167. > > Quad to HiPer ARC  - 2 Wire Leased Line setup
  12168. > >
  12169. > >  Total Control QUAD Analog/Digital
  12170. > >  Total Control HiPer ARC
  12171. > >  Courier V.Everything
  12172. > >  Quad  Code: <: 6.0.4 DS>
  12173. > >  Courier Code: <;3.0.13>
  12174. > >  Hiper ARC Code: < 4.1.59>
  12175. > >
  12176. > >  The following is how to configure the Courier modem to connect to the Quad
  12177. > > modem and get login prompt from the ARC
  12178. > >
  12179. > > Configuration for Courier is as follows:
  12180. > > Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on
  12181. > > courier set to on,
  12182. > > at&L1 &b1&n14&w also set the baud rate of the DTE to 115200
  12183. > >
  12184. > > Configuration of the ARC
  12185. > > Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes
  12186. > >
  12187. > > Configuration of the Quad analog/digital
  12188. > > at&L1&B1&N14
  12189. > > ats47.5=1
  12190. > > ats56.6=0
  12191. > > ats0=0
  12192. > >
  12193. > > DIP 5 off
  12194. > >
  12195. > > Regards
  12196. > > Ray Whelan
  12197. > >
  12198. > > Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52
  12199. > >
  12200. > > Please respond to usr-tc@lists.xmission.com
  12201. > >
  12202. > > To:   usr-tc@lists.xmission.com
  12203. > > cc:    (Ray Whelan/IE/3Com)
  12204. > > Subject:  (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation
  12205. > >
  12206. > > Hi folks,
  12207. > >
  12208. > > I wonder if someone of you can tell me how can I setup an TC chassis for
  12209. > > leased line operation.
  12210. > > I want that the phone line to be plugged in an Analog Quad Modem and the
  12211. > > modem "to be connected" in a speciffic interface from the HiperArc. The
  12212. > > ARC will be configured to make ppp over that line, with no
  12213. > > authentication, and give the same IP address every time. Of course that
  12214. > > modem will not be available for the dual E1 card.
  12215. > >
  12216. > > Thank you,
  12217. > >
  12218. > > Stefanita Vilcu, Network Administrator - Dynamic Network Technologies,
  12219. > > Bucharest, Romania
  12220. > > vsv@dnt.ro
  12221. >
  12222. > -
  12223. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12224. >  with "unsubscribe usr-tc" in the body of the message.
  12225. >  For information on digests or retrieving files and old messages send
  12226. >  "help" to the same address.  Do not use quotes in your message.
  12227. >
  12228. > -
  12229. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12230. >  with "unsubscribe usr-tc" in the body of the message.
  12231. >  For information on digests or retrieving files and old messages send
  12232. >  "help" to the same address.  Do not use quotes in your message.
  12233.  
  12234.  
  12235. Best regards,
  12236. Vadim Tulinov.
  12237. -
  12238.  
  12239.  
  12240. -
  12241.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12242.  with "unsubscribe usr-tc" in the body of the message.
  12243.  For information on digests or retrieving files and old messages send
  12244.  "help" to the same address.  Do not use quotes in your message.
  12245.  
  12246.  
  12247. -------------------------------------------------------------------------------
  12248.  
  12249. From: K Mitchell <mitch@keyconn.net>
  12250. Subject: Re: (usr-tc) Problems with Winmodems
  12251. Date: 13 Apr 1999 13:14:19 -0400
  12252.  
  12253. At 09:45 AM 4/13/99 -0400, you wrote:
  12254. >Thus spake K Mitchell
  12255. >>At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote:
  12256. >>>    Recently we receive some complains from users of USR V.90
  12257. >>>Winmodems (model 5698) in connecting our Hiper TC.
  12258. >>>    Is there any known problem with these modems?
  12259. >
  12260. >>Winmodems are notorious for problems, but the latest firmware upgrade has
  12261. >>been working well here. I believe it's 5.32, check at 
  12262. >>http://808hi.com/56k/x2-lucent.htm
  12263. >
  12264. >Whoa, Kirk...he was talking about 3Com/USR winmodems...while they
  12265. >function on the same basic principles, the code is very different.  :)
  12266. >
  12267. >Yes, 5.32 and later on the Lucent's is good, but 3Com winmodems are a
  12268. >different matter entirely.
  12269.  
  12270. My mistake. I had just gotten in from working overnight and failed to read
  12271. line 1 to the end before starting on line.
  12272.  
  12273. >Yes, upgrading to these versions would be a huge improvement...still not
  12274. >perfect (my infamous ticket 58316 has just been reopened...fun joy...its
  12275. >now a toddler, had its first birthday a week or so ago), but much
  12276. >better.
  12277.  
  12278. As noted in my conversation with Todd on the list last week, I'm still at
  12279. ARC 4.1.72/DSP 1.2.60 till I see some satisfactory reports on the newer code.
  12280.  
  12281. Thanks for the correction,
  12282. Kirk
  12283.  
  12284.  
  12285.  
  12286. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  12287. Keystone Connect                http://www.keyconn.net
  12288. Altoona, PA   814-941-5000         We Unlock the World
  12289.  
  12290.  
  12291. -
  12292.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12293.  with "unsubscribe usr-tc" in the body of the message.
  12294.  For information on digests or retrieving files and old messages send
  12295.  "help" to the same address.  Do not use quotes in your message.
  12296.  
  12297.  
  12298. -------------------------------------------------------------------------------
  12299.  
  12300. From: Ahmed Saeed <Ahmed.Saeed@widener.edu>
  12301. Subject: Re: (usr-tc) Traps & Config
  12302. Date: 12 Apr 1999 13:32:26 -0400 (EDT)
  12303.  
  12304. paul, 
  12305.  
  12306. from what I understand, you want to use config of one hiper arc to 
  12307. config another hiper arc. 
  12308. lets call the first hiper arc A and the other is B. 
  12309.  
  12310. on the cli of A :
  12311.  
  12312. set bulk_file (any name)
  12313. save config
  12314. list files 
  12315.  
  12316. See if the file is there, tftp this file to the other hiper arc. and then 
  12317. on the cli of B:
  12318.  
  12319. reset config
  12320.  
  12321.  
  12322. the hiper arc would automatically load with the config.
  12323.  
  12324. Paul, keep in mind that the dynamic parameters will not be seen- only the 
  12325. ones manually entered. Let me give you an example, on the first hiper 
  12326. arc, you  have 3 dynamic hdms they will not show up when you do reset 
  12327. config on the other hiper arc. the parameters that you will see are the ip 
  12328. addresses of the default gateway, accounting server etc. 
  12329.  
  12330. also, the hiper arc B has to be given an ip address - so basic config 
  12331. needs to be done, it needs to be on a network.
  12332.  
  12333. this is also on 3kb now. 
  12334.  
  12335. Ahmed
  12336.  
  12337.  
  12338. arc, if you h
  12339.  
  12340.  
  12341. On Thu, 8 Apr 1999, Paul Farber wrote:
  12342.  
  12343. > hello all
  12344. > 
  12345. > Two questions, went to the 3Kb and got the info for "Capturing the
  12346. > configuration through the CLI".  Telenetted in and did "sho config", I
  12347. > don't thing I could rebuild a chassis from the information it listed.  I'm
  12348. > looking for more like the actual commands, or to tftp the config down to a
  12349. > hdd for safe keeping.
  12350. > 
  12351. > Also, can I set up traps via the CLI?  The 3KB says fire up TCM... any way
  12352. > to replicate the process with the good ol cmd line?
  12353. > 
  12354. > Thanks!
  12355. > 
  12356. > Paul D. Farber II
  12357. > Farber Technology
  12358. > Ph. 570-628-5303
  12359. > Fax 570-628-5545
  12360. > farber@admin.f-tech.net
  12361. > 
  12362. > 
  12363. > -
  12364. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12365. >  with "unsubscribe usr-tc" in the body of the message.
  12366. >  For information on digests or retrieving files and old messages send
  12367. >  "help" to the same address.  Do not use quotes in your message.
  12368. > 
  12369.  
  12370. -
  12371.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12372.  with "unsubscribe usr-tc" in the body of the message.
  12373.  For information on digests or retrieving files and old messages send
  12374.  "help" to the same address.  Do not use quotes in your message.
  12375.  
  12376.  
  12377. -------------------------------------------------------------------------------
  12378.  
  12379. From: Gilles Melanson <gilles@vianet.on.ca>
  12380. Subject: (usr-tc) 3com v90 Winmodems -> 1.2.43 code
  12381. Date: 14 Apr 1999 09:01:58 -0400 (EDT)
  12382.  
  12383. This doesn't work.
  12384.  
  12385. I have a pair of customers in different cities that dial into
  12386. 4.1.72/1.2.43 based chassis, with their brand new Dell computers.
  12387.  
  12388. Imagine that, it doesn't work.. or it doesn't work well, at all.  The
  12389. users are complaining of incredibly slow connections, and I have no idea
  12390. where to go from here.
  12391.  
  12392. Does 3com have newer winmodem code that fixes the problem?
  12393. Has anyone come up with a solution for this?
  12394.  
  12395. Thnx.
  12396.  
  12397. --
  12398. Gilles Melanson                         ViaNet Internet Solutions
  12399. System Administrator                    128 Larch St. Suite 301
  12400. gilles@vianet.on.ca                     Sudbury, ON Canada  P3E 5J8
  12401.  
  12402. The "-ell 65532" is an undocumented switch. THIS is the magic twinkle
  12403. dust. Works better if you wave a dead chicken at the same time... Causes lights
  12404. on the disks to go bonkers for a while.            -- DEC Mailing List
  12405.  
  12406.  
  12407. -
  12408.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12409.  with "unsubscribe usr-tc" in the body of the message.
  12410.  For information on digests or retrieving files and old messages send
  12411.  "help" to the same address.  Do not use quotes in your message.
  12412.  
  12413.  
  12414. -------------------------------------------------------------------------------
  12415.  
  12416. From: Jeff Carneal <jeff@apex.net>
  12417. Subject: (usr-tc) Caller ID on Chan T1?
  12418. Date: 14 Apr 1999 09:22:42 -0500 (CDT)
  12419.  
  12420.  
  12421. Forgive me if this has been discusess before, but after searching the
  12422. archives I found no mention of it.
  12423.  
  12424. We're running channelized T1 into hipers with e&m wink signaling, and I've
  12425. noticed that Calling-Station-ID is set to "" in the radiusd logs.  Now,
  12426. Called-Station-ID is set properly, but we're not getting the calling
  12427. station.
  12428.  
  12429. Additionally, I'm quite positive that the telco is sending 10 digits for
  12430. ANI, 10 digits for DNIS on every call (mf digit signaling).  Is caller ID
  12431. simply not supported on channelized T1 on the hipers?  Any other thoughts?
  12432.  
  12433. --
  12434.   Jeff Carneal - Sys Admin - Apex Internet          
  12435.   jeff@apex.net http://www.apex.net (502) 442-5363
  12436.  
  12437.   The opinions expressed above aren't really mine.
  12438.   They belong to someone else who also refuses to 
  12439.   take responsibility for them. 
  12440.  
  12441.  
  12442.  
  12443. -
  12444.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12445.  with "unsubscribe usr-tc" in the body of the message.
  12446.  For information on digests or retrieving files and old messages send
  12447.  "help" to the same address.  Do not use quotes in your message.
  12448.  
  12449.  
  12450. -------------------------------------------------------------------------------
  12451.  
  12452. From: "Brian M. Gordon" <administrator@westelcom.com>
  12453. Subject: (usr-tc) Clear Channel or Not?
  12454. Date: 14 Apr 1999 10:47:37 -0400
  12455.  
  12456. I usually order PRI so I am not as farmilar with channalized or switched T1
  12457. service.  The telephone company I just spoke to asked if I wanted Clear
  12458. channel or not?  Any ideas what the best thing to use for Total control
  12459. Hiper DSP's?
  12460.  
  12461. Thanks,
  12462.  
  12463. Brian Gordon
  12464. Network Administrator
  12465. Westelcom Internet
  12466. 518-566-8376 114 Voice
  12467. 518-566-8348 Fax
  12468. http://home.westelcom.com
  12469. administrator@westelcom.com
  12470.  
  12471.  
  12472. -
  12473.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12474.  with "unsubscribe usr-tc" in the body of the message.
  12475.  For information on digests or retrieving files and old messages send
  12476.  "help" to the same address.  Do not use quotes in your message.
  12477.  
  12478.  
  12479. -------------------------------------------------------------------------------
  12480.  
  12481. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  12482. Subject: Re: (usr-tc) Caller ID on Chan T1?
  12483. Date: 14 Apr 1999 10:27:12 -0500 (CDT)
  12484.  
  12485. On Wed, 14 Apr 1999, Jeff Carneal wrote:
  12486.  
  12487. > 
  12488. > Forgive me if this has been discusess before, but after searching the
  12489. > archives I found no mention of it.
  12490. > 
  12491. > We're running channelized T1 into hipers with e&m wink signaling, and I've
  12492. > noticed that Calling-Station-ID is set to "" in the radiusd logs.  Now,
  12493. > Called-Station-ID is set properly, but we're not getting the calling
  12494. > station.
  12495. > 
  12496. > Additionally, I'm quite positive that the telco is sending 10 digits for
  12497. > ANI, 10 digits for DNIS on every call (mf digit signaling).  Is caller ID
  12498. > simply not supported on channelized T1 on the hipers?  Any other thoughts?
  12499. > 
  12500.  
  12501. Check the DSP settings - Make sure that you have it set to receive 10 digits
  12502.  
  12503. krish
  12504.  
  12505.  
  12506. > --
  12507. >   Jeff Carneal - Sys Admin - Apex Internet          
  12508. >   jeff@apex.net http://www.apex.net (502) 442-5363
  12509. > 
  12510. >   The opinions expressed above aren't really mine.
  12511. >   They belong to someone else who also refuses to 
  12512. >   take responsibility for them. 
  12513. > 
  12514. > 
  12515. > 
  12516. > -
  12517. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12518. >  with "unsubscribe usr-tc" in the body of the message.
  12519. >  For information on digests or retrieving files and old messages send
  12520. >  "help" to the same address.  Do not use quotes in your message.
  12521. > 
  12522.  
  12523. -
  12524.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12525.  with "unsubscribe usr-tc" in the body of the message.
  12526.  For information on digests or retrieving files and old messages send
  12527.  "help" to the same address.  Do not use quotes in your message.
  12528.  
  12529.  
  12530. -------------------------------------------------------------------------------
  12531.  
  12532. From: access1 <access1@simplyweb.net>
  12533. Subject: (usr-tc) WYB USR Telco card Dual PRI/T-1 
  12534. Date: 14 Apr 1999 10:34:38 -0700
  12535.  
  12536. we want to buy 1 maybe 2 Dual PRI/T-1 USR Telco card sets. ( we found
  12537. one at a fair price so far).  request reasonable for this used equip.,
  12538. please send price privately to above. We need one soon. thanks.
  12539.  
  12540.  
  12541. -
  12542.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12543.  with "unsubscribe usr-tc" in the body of the message.
  12544.  For information on digests or retrieving files and old messages send
  12545.  "help" to the same address.  Do not use quotes in your message.
  12546.  
  12547.  
  12548. -------------------------------------------------------------------------------
  12549.  
  12550. From: "Wayne Barber" <barberw@tidewater.net>
  12551. Subject: RE: (usr-tc) Clear Channel or Not?
  12552. Date: 14 Apr 1999 14:04:50 -0400
  12553.  
  12554. Yes, you want Clear Channel if you can get it. This is a T1 with B8ZS and
  12555. ESF which doesn't rob bits the way AMI and SF does.
  12556.  
  12557. Wayne Barber
  12558. Coastal Telco Services
  12559.  
  12560. > -----Original Message-----
  12561. > From: owner-usr-tc@lists.xmission.com
  12562. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian M. Gordon
  12563. > Sent: Wednesday, April 14, 1999 10:48 AM
  12564. > To: usr-tc@lists.xmission.com
  12565. > Subject: (usr-tc) Clear Channel or Not?
  12566. > Importance: High
  12567. >
  12568. >
  12569. > I usually order PRI so I am not as farmilar with channalized or
  12570. > switched T1
  12571. > service.  The telephone company I just spoke to asked if I wanted Clear
  12572. > channel or not?  Any ideas what the best thing to use for Total control
  12573. > Hiper DSP's?
  12574. >
  12575. > Thanks,
  12576. >
  12577. > Brian Gordon
  12578. > Network Administrator
  12579. > Westelcom Internet
  12580. > 518-566-8376 114 Voice
  12581. > 518-566-8348 Fax
  12582. > http://home.westelcom.com
  12583. > administrator@westelcom.com
  12584. >
  12585. >
  12586. > -
  12587. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12588. >  with "unsubscribe usr-tc" in the body of the message.
  12589. >  For information on digests or retrieving files and old messages send
  12590. >  "help" to the same address.  Do not use quotes in your message.
  12591. >
  12592.  
  12593.  
  12594. -
  12595.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12596.  with "unsubscribe usr-tc" in the body of the message.
  12597.  For information on digests or retrieving files and old messages send
  12598.  "help" to the same address.  Do not use quotes in your message.
  12599.  
  12600.  
  12601. -------------------------------------------------------------------------------
  12602.  
  12603. From: "Tony Loosle" <tony@tcsourceone.com>
  12604. Subject: Re: (usr-tc) WTB Netserver 8 or 16 I +  (still looking)
  12605. Date: 14 Apr 1999 12:40:20 -0600
  12606.  
  12607. Eric,
  12608.     This first 16I is DOA.  it will not pick up or answer calls.  We are
  12609. trying the second one right now.  I'll let you know how it goes.
  12610.  
  12611. tony
  12612.  
  12613.  
  12614. Eric Billeter wrote:
  12615.  
  12616. > How many do you want and what do you want to pay for them..
  12617. >
  12618. > I have 16 of em (8 never used)
  12619. >
  12620. > Eric T. Billeter                   Cable One
  12621. > Internet Engineer                  1314 North 3rd Street
  12622. > ebilleter@cableone.net             Phoenix, AZ 85004
  12623. >
  12624. > -----Original Message-----
  12625. > From: owner-usr-tc@lists.xmission.com
  12626. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tony Loosle
  12627. > Sent: Thursday, April 08, 1999 9:14 AM
  12628. > To: isp-equipment@isp-equipment.com; usr-tc@lists.xmission.com
  12629. > Subject: (usr-tc) WTB Netserver 8 or 16 I + (still looking)
  12630. >
  12631. > Still looking for used netserver 8I+ and 16I+
  12632. >
  12633. > tony
  12634. > 435-753-5455
  12635. >
  12636. > -
  12637. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12638. >  with "unsubscribe usr-tc" in the body of the message.
  12639. >  For information on digests or retrieving files and old messages send
  12640. >  "help" to the same address.  Do not use quotes in your message.
  12641. >
  12642. > -
  12643. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12644. >  with "unsubscribe usr-tc" in the body of the message.
  12645. >  For information on digests or retrieving files and old messages send
  12646. >  "help" to the same address.  Do not use quotes in your message.
  12647.  
  12648.  
  12649. -
  12650.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12651.  with "unsubscribe usr-tc" in the body of the message.
  12652.  For information on digests or retrieving files and old messages send
  12653.  "help" to the same address.  Do not use quotes in your message.
  12654.  
  12655.  
  12656. -------------------------------------------------------------------------------
  12657.  
  12658. From: Steve Rivera <sales@wrca.net>
  12659. Subject: Re: (usr-tc) WYB USR Telco card Dual PRI/T-1 
  12660. Date: 14 Apr 1999 16:00:00 -0400
  12661.  
  12662. whats fair. I have them:)
  12663.  
  12664. At 10:34 AM 4/14/99 -0700, you wrote:
  12665. >we want to buy 1 maybe 2 Dual PRI/T-1 USR Telco card sets. ( we found
  12666. >one at a fair price so far).  request reasonable for this used equip.,
  12667. >please send price privately to above. We need one soon. thanks.
  12668. >
  12669. >
  12670. >-
  12671. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12672. > with "unsubscribe usr-tc" in the body of the message.
  12673. > For information on digests or retrieving files and old messages send
  12674. > "help" to the same address.  Do not use quotes in your message.
  12675. >
  12676.  
  12677. -
  12678.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12679.  with "unsubscribe usr-tc" in the body of the message.
  12680.  For information on digests or retrieving files and old messages send
  12681.  "help" to the same address.  Do not use quotes in your message.
  12682.  
  12683.  
  12684. -------------------------------------------------------------------------------
  12685.  
  12686. From: access1 <access1@simplyweb.net>
  12687. Subject: Re: (usr-tc) WYB USR Telco card Dual PRI/T-1
  12688. Date: 14 Apr 1999 13:32:37 -0700
  12689.  
  12690. got it covered. thanks
  12691.  
  12692. Steve Rivera wrote:
  12693.  
  12694. > whats fair. I have them:)
  12695. >
  12696. > At 10:34 AM 4/14/99 -0700, you wrote:
  12697. > >we want to buy 1 maybe 2 Dual PRI/T-1 USR Telco card sets. ( we found
  12698. > >one at a fair price so far).  request reasonable for this used equip.,
  12699. > >please send price privately to above. We need one soon. thanks.
  12700. > >
  12701. > >
  12702. > >-
  12703. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12704. > > with "unsubscribe usr-tc" in the body of the message.
  12705. > > For information on digests or retrieving files and old messages send
  12706. > > "help" to the same address.  Do not use quotes in your message.
  12707. > >
  12708. >
  12709. > -
  12710. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12711. >  with "unsubscribe usr-tc" in the body of the message.
  12712. >  For information on digests or retrieving files and old messages send
  12713. >  "help" to the same address.  Do not use quotes in your message.
  12714.  
  12715.  
  12716.  
  12717.  
  12718. -
  12719.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12720.  with "unsubscribe usr-tc" in the body of the message.
  12721.  For information on digests or retrieving files and old messages send
  12722.  "help" to the same address.  Do not use quotes in your message.
  12723.  
  12724.  
  12725. -------------------------------------------------------------------------------
  12726.  
  12727. From: Steve Rivera <sales@wrca.net>
  12728. Subject: Re: (usr-tc) WTB Netserver 8 or 16 I +  (still looking)
  12729. Date: 14 Apr 1999 17:12:33 -0400
  12730.  
  12731. Tony, was this unit refurbished or new?
  12732.  
  12733. was this unit At 12:40 PM 4/14/99 -0600, you wrote:
  12734. >Eric,
  12735. >    This first 16I is DOA.  it will not pick up or answer calls.  We are
  12736. >trying the second one right now.  I'll let you know how it goes.
  12737. >
  12738. >tony
  12739. >
  12740. >
  12741. >Eric Billeter wrote:
  12742. >
  12743. >> How many do you want and what do you want to pay for them..
  12744. >>
  12745. >> I have 16 of em (8 never used)
  12746. >>
  12747. >> Eric T. Billeter                   Cable One
  12748. >> Internet Engineer                  1314 North 3rd Street
  12749. >> ebilleter@cableone.net             Phoenix, AZ 85004
  12750. >>
  12751. >> -----Original Message-----
  12752. >> From: owner-usr-tc@lists.xmission.com
  12753. >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tony Loosle
  12754. >> Sent: Thursday, April 08, 1999 9:14 AM
  12755. >> To: isp-equipment@isp-equipment.com; usr-tc@lists.xmission.com
  12756. >> Subject: (usr-tc) WTB Netserver 8 or 16 I + (still looking)
  12757. >>
  12758. >> Still looking for used netserver 8I+ and 16I+
  12759. >>
  12760. >> tony
  12761. >> 435-753-5455
  12762. >>
  12763. >> -
  12764. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12765. >>  with "unsubscribe usr-tc" in the body of the message.
  12766. >>  For information on digests or retrieving files and old messages send
  12767. >>  "help" to the same address.  Do not use quotes in your message.
  12768. >>
  12769. >> -
  12770. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12771. >>  with "unsubscribe usr-tc" in the body of the message.
  12772. >>  For information on digests or retrieving files and old messages send
  12773. >>  "help" to the same address.  Do not use quotes in your message.
  12774. >
  12775. >
  12776. >-
  12777. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12778. > with "unsubscribe usr-tc" in the body of the message.
  12779. > For information on digests or retrieving files and old messages send
  12780. > "help" to the same address.  Do not use quotes in your message.
  12781. >
  12782.  
  12783. -
  12784.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12785.  with "unsubscribe usr-tc" in the body of the message.
  12786.  For information on digests or retrieving files and old messages send
  12787.  "help" to the same address.  Do not use quotes in your message.
  12788.  
  12789.  
  12790. -------------------------------------------------------------------------------
  12791.  
  12792. From: Brian <signal@shreve.net>
  12793. Subject: (usr-tc) VPN Tunnel to Linux box
  12794. Date: 14 Apr 1999 16:09:57 -0500 (CDT)
  12795.  
  12796.  
  12797. I am wanting to setup a single Tunnel from the ARC to a linux box, using
  12798. the tunneling supported by linux (I believe linux will do PPTP).  Does
  12799. anyone have an example of at least the ARC side of the setup, and perhaps
  12800. even some notes on the Linux side?
  12801.  
  12802. I believe the ARC supports l2tp and pptp right?  does it do ipsec?
  12803.  
  12804. Brian
  12805.  
  12806.  
  12807. Brian Feeny (BF304)     signal@shreve.net   
  12808. 318-222-2638 x 109    http://www.shreve.net/~signal      
  12809. Network Administrator   ShreveNet Inc. (ASN 11881)           
  12810.  
  12811.  
  12812. -
  12813.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12814.  with "unsubscribe usr-tc" in the body of the message.
  12815.  For information on digests or retrieving files and old messages send
  12816.  "help" to the same address.  Do not use quotes in your message.
  12817.  
  12818.  
  12819. -------------------------------------------------------------------------------
  12820.  
  12821. From: Scott Boggs <sboggs@unitedbank.net>
  12822. Subject: RE: (usr-tc) 3com v90 Winmodems -> 1.2.43 code
  12823. Date: 14 Apr 1999 17:51:04 -0400
  12824.  
  12825. We had a lot of complaints from users with "new" computers too.
  12826. But usually the installed modem code on their pc was a 1-3 months old.
  12827. I think there have been several revisions to the LT and Rockwell code
  12828. already this year.
  12829. Bottom line- upgrade the client modem.  
  12830. We run DSP1.2.43/ARC4.1.11 (will upgrade to 4.1.59-6 soon) and after
  12831. users with poor connect speeds did an upgrade on their end, everything is
  12832. great.
  12833. These upgrades are very easy also.
  12834.  
  12835. Below is an excerpt from a list message on 3-26-99, it really helped me!
  12836. Regards,
  12837. Scott Boggs
  12838. United Bank
  12839.  
  12840. ========================================
  12841. Here's the lowdown:
  12842. LT Winmodems: download the latest driver: 5.39. You can get it from
  12843. http://www.tidewater.net/56k.shtml.
  12844.  
  12845. Rockwell 56k PCI: these can be either HCF or ITU modems. HCF are real crap.
  12846. They need in init string of +ms=v34 to turn off all 56k attempts. The ITU
  12847. (or non-HCF) Rockwells use an init string of +ms=11,1 or update the drivers
  12848. from the manufacturer's site.
  12849.  
  12850. iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that
  12851. came with MacAddict(?) in January ( I think. I don't get the mag).
  12852.  
  12853. Go to http://www.56k.com for more info on the init strings.
  12854.  
  12855. Wayne Barber
  12856. Coastal Telco Services
  12857. ===========================================
  12858.  
  12859. > -----Original Message-----
  12860. > From:    Gilles Melanson [SMTP:gilles@vianet.on.ca]
  12861. > Sent:    Wednesday, April 14, 1999 9:02 AM
  12862. > To:    usr-tc@lists.xmission.com
  12863. > Subject:    (usr-tc) 3com v90 Winmodems -> 1.2.43 code
  12864. > 
  12865. > This doesn't work.
  12866. > 
  12867. > I have a pair of customers in different cities that dial into
  12868. > 4.1.72/1.2.43 based chassis, with their brand new Dell computers.
  12869. > 
  12870.  
  12871. -
  12872.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12873.  with "unsubscribe usr-tc" in the body of the message.
  12874.  For information on digests or retrieving files and old messages send
  12875.  "help" to the same address.  Do not use quotes in your message.
  12876.  
  12877.  
  12878. -------------------------------------------------------------------------------
  12879.  
  12880. From: Scott Boggs <sboggs@unitedbank.net>
  12881. Subject: RE: (usr-tc) Clear Channel or Not?
  12882. Date: 14 Apr 1999 18:09:04 -0400
  12883.  
  12884. In order to support v.90/x2/kflex, your lines must be trunk side config
  12885. rather that a line side config.  This nearly killed me last Jan.
  12886. Line side termination has an additional Digital/analog conversion
  12887. that will kill 56k connections.
  12888.  
  12889. Thanks,
  12890. Scott Boggs
  12891. United Bank
  12892.  
  12893. > -----Original Message-----
  12894. > From:    Brian M. Gordon [SMTP:administrator@westelcom.com]
  12895. > Sent:    Wednesday, April 14, 1999 10:48 AM
  12896. > To:    usr-tc@lists.xmission.com
  12897. > Subject:    (usr-tc) Clear Channel or Not?
  12898. > Importance:    High
  12899. > 
  12900. > I usually order PRI so I am not as farmilar with channalized or switched
  12901. > T1
  12902. > service.  The telephone company I just spoke to asked if I wanted Clear
  12903. > channel or not?  Any ideas what the best thing to use for Total control
  12904. > Hiper DSP's?
  12905. > 
  12906. > Thanks,
  12907. > 
  12908. > Brian Gordon
  12909. > Network Administrator
  12910. > Westelcom Internet
  12911. > 518-566-8376 114 Voice
  12912. > 518-566-8348 Fax
  12913. > http://home.westelcom.com
  12914. > administrator@westelcom.com
  12915. > 
  12916. > 
  12917. > -
  12918. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12919. >  with "unsubscribe usr-tc" in the body of the message.
  12920. >  For information on digests or retrieving files and old messages send
  12921. >  "help" to the same address.  Do not use quotes in your message.
  12922.  
  12923. -
  12924.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12925.  with "unsubscribe usr-tc" in the body of the message.
  12926.  For information on digests or retrieving files and old messages send
  12927.  "help" to the same address.  Do not use quotes in your message.
  12928.  
  12929.  
  12930. -------------------------------------------------------------------------------
  12931.  
  12932. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  12933. Subject: RE: (usr-tc) VPN Tunnel to Linux box
  12934. Date: 14 Apr 1999 18:23:21 -0500
  12935.  
  12936.  
  12937.  
  12938. |-----Original Message-----
  12939. |From: owner-usr-tc@lists.xmission.com
  12940. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  12941. |Sent: Wednesday, April 14, 1999 4:10 PM
  12942. |To: USRobotics TC Mailing List
  12943. |Subject: (usr-tc) VPN Tunnel to Linux box
  12944. |
  12945. |
  12946. |
  12947. |I am wanting to setup a single Tunnel from the ARC to a linux box, using
  12948. |the tunneling supported by linux (I believe linux will do PPTP).  Does
  12949. |anyone have an example of at least the ARC side of the setup, and perhaps
  12950. |even some notes on the Linux side?
  12951. |
  12952. |I believe the ARC supports l2tp and pptp right?  does it do ipsec?
  12953. |
  12954.  
  12955. PPTP server on linux? I have seen the PPTP client but not a server. Can you point
  12956. me to where you saw PPTP server for linux??
  12957.  
  12958. -M
  12959.  
  12960.  
  12961. -
  12962.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12963.  with "unsubscribe usr-tc" in the body of the message.
  12964.  For information on digests or retrieving files and old messages send
  12965.  "help" to the same address.  Do not use quotes in your message.
  12966.  
  12967.  
  12968. -------------------------------------------------------------------------------
  12969.  
  12970. From: slack <jhansen@xmission.com>
  12971. Subject: Re: (usr-tc) VPN Tunnel to Linux box
  12972. Date: 14 Apr 1999 17:59:13 -0600
  12973.  
  12974. On Wed, Apr 14, 1999 at 06:23:21PM -0500, Mike Wronski wrote:
  12975. > 
  12976. > |
  12977. > |I am wanting to setup a single Tunnel from the ARC to a linux box, using
  12978. > |the tunneling supported by linux (I believe linux will do PPTP).  Does
  12979. > |anyone have an example of at least the ARC side of the setup, and perhaps
  12980. > |even some notes on the Linux side?
  12981. > |
  12982. > |I believe the ARC supports l2tp and pptp right?  does it do ipsec?
  12983. > |
  12984. > 
  12985. > PPTP server on linux? I have seen the PPTP client but not a server. Can you point
  12986. > me to where you saw PPTP server for linux??
  12987. > 
  12988.  
  12989. http://www.moretonbay.com/vpn/pptp.html
  12990.  
  12991. -- 
  12992. Jason Hansen                                          jhansen@xmission.com
  12993.  
  12994. -
  12995.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12996.  with "unsubscribe usr-tc" in the body of the message.
  12997.  For information on digests or retrieving files and old messages send
  12998.  "help" to the same address.  Do not use quotes in your message.
  12999.  
  13000.  
  13001. -------------------------------------------------------------------------------
  13002.  
  13003. From: TM <myers@kwiknet.net>
  13004. Subject: (usr-tc) OID For Active Digital/ISDN Sessions
  13005. Date: 14 Apr 1999 21:17:30 -0400
  13006.  
  13007. Does anyone know the OID to get the number of active Digital/ISDN
  13008. sessions?  I have the OID for the number of active modems
  13009. (1.3.6.1.4.1.429.4.2.1.10.0).
  13010.  
  13011. Thanks...
  13012.  
  13013. -
  13014.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13015.  with "unsubscribe usr-tc" in the body of the message.
  13016.  For information on digests or retrieving files and old messages send
  13017.  "help" to the same address.  Do not use quotes in your message.
  13018.  
  13019.  
  13020. -------------------------------------------------------------------------------
  13021.  
  13022. From: Jeff Mcadams <jeffm@iglou.com>
  13023. Subject: Re: (usr-tc) OID For Active Digital/ISDN Sessions
  13024. Date: 14 Apr 1999 22:35:43 -0400 (EDT)
  13025.  
  13026. Thus spake TM
  13027. >Does anyone know the OID to get the number of active Digital/ISDN
  13028. >sessions?  I have the OID for the number of active modems
  13029. >(1.3.6.1.4.1.429.4.2.1.10.0).
  13030.  
  13031. I'm assuming this OID is from the HiPer Arc, not the NMC?  At least that
  13032. was the only way I could get a response...
  13033.  
  13034. If that is the case, then this OID gives you the number of active
  13035. session...period.  It (from what I can tell) makes no distinctions
  13036. between ISDN and modem calls.
  13037.  
  13038. In other words, since its from the Arc, it gives you the number of
  13039. active users, which can be either an ISDN or a modem call.
  13040.  
  13041. About the only way I could think of to get number of ISDN calls would be
  13042. to walk the mdmCsModulationType and divide up which modulations are
  13043. modem modulations and which are ISDN (v.110, v.120, x75, and
  13044. asyncsyncppp being the main ISDN ones.
  13045. -- 
  13046. Jeff McAdams                            Email: jeffm@iglou.com
  13047. Head Network Administrator              Voice: (502) 966-3848
  13048. IgLou Internet Services                        (800) 436-4456
  13049.  
  13050. -
  13051.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13052.  with "unsubscribe usr-tc" in the body of the message.
  13053.  For information on digests or retrieving files and old messages send
  13054.  "help" to the same address.  Do not use quotes in your message.
  13055.  
  13056.  
  13057. -------------------------------------------------------------------------------
  13058.  
  13059. From: "Ray Bagby" <rbagby@yore.net>
  13060. Subject: (usr-tc) off-hook here, off-hook there?
  13061. Date: 15 Apr 1999 02:05:48 -0500
  13062.  
  13063.     I'm just about going to have to tell some paid-in-full, non-camping
  13064. clients that they should find another Internet Service Provider because they
  13065. keep getting dropped after only 90 to 120 seconds. These people are in
  13066. another area-code with an independent phone company. I'm using SWBell. The
  13067. inde guy says his equipment is not getting an off-hook which would start his
  13068. billing timer, this in turn is activating the toll-fraud event which
  13069. disconnects the call.
  13070.     I've talked to Bell folks who "see" the off-hook in places hundreds of
  13071. miles away from here and I've talked to the folks at 3Com who logged on from
  13072. Chicago and had no problem. There-fore other people in different exchanges
  13073. have no trouble staying connected. It's just in this independent's system
  13074. that I'm having trouble. The SWBell folks have been great about trying to
  13075. find the problem but they're not seeing any trouble anywhere in their
  13076. system.
  13077.     I'm using a TC chassis with a T1 going into a DSP running 1.2.5, HiPer
  13078. ARC NAC running 4.1.72 and NMC on 5.6.2. (I've been told I should up-grade
  13079. but I've also been told it would not help the problem and the release notes
  13080. for the 4.1.59-6 says I should run it with NMC 5.5.5 and they are not giving
  13081. that one away!)
  13082.     My question: is there some setting somewhere I could change that would
  13083. not allow this independent phone company to "get" the off-hook and still
  13084. allow basically everybody else to "see" the off-hook? Anybody every dealt
  13085. with this problem before? In other words: HELP!!!
  13086.  
  13087.     Thank you, Ray
  13088.  
  13089.  
  13090. -
  13091.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13092.  with "unsubscribe usr-tc" in the body of the message.
  13093.  For information on digests or retrieving files and old messages send
  13094.  "help" to the same address.  Do not use quotes in your message.
  13095.  
  13096.  
  13097. -------------------------------------------------------------------------------
  13098.  
  13099. From: das <das@gol.com>
  13100. Subject: (usr-tc) ISDN calls not authenticating on a HiperDSP card
  13101. Date: 15 Apr 1999 21:18:14 +0900
  13102.  
  13103.  
  13104. Hi, I hope that someone can help me with this.
  13105.  
  13106. I've got a HiperDSP card running 1.2.2 that will not authenticate users.
  13107. Analog calls authenticate fine and the connection is established.  There
  13108. are no other problems with any of the quads or the other HiperDSP card 
  13109. in the same chassis.  I have tried hardware/software resets on the card
  13110. as well as a software reset on the modems.  I have rebooted the 
  13111. Netserver card (3.8.1) as well.  The card was originally at 1.2.5 but I 
  13112. reflashed it to 1.2.2 to see if that would have any effect.  Nothing has
  13113. worked yet.  Does anyone have any suggestions?
  13114.  
  13115. das
  13116.  
  13117.  
  13118. -- 
  13119. ____________________________________________
  13120. Alex Substanley       Global OnLine Japan
  13121.                 Engineering Department
  13122. Das Man               TEL: 81-3-5334-1700
  13123. Systems Engineer      FAX: 81-3-5334-1711
  13124. ____________________________________________
  13125.  
  13126. -
  13127.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13128.  with "unsubscribe usr-tc" in the body of the message.
  13129.  For information on digests or retrieving files and old messages send
  13130.  "help" to the same address.  Do not use quotes in your message.
  13131.  
  13132.  
  13133. -------------------------------------------------------------------------------
  13134.  
  13135. From: Steve Rivera <sales@wrca.net>
  13136. Subject: (usr-tc) Todays Special on AS5100 cards
  13137. Date: 15 Apr 1999 10:40:22 -0400
  13138.  
  13139. 5 in stock. All in new condition.
  13140. $500 each.
  13141.  
  13142. Cisco    AS51-16A-E
  13143.  
  13144.  
  13145. Steve Rivera  sales@wrca.net 732-833-2111
  13146. Check out product information and inventory.
  13147.        http://www.wrca.net NEW!
  13148. M-F 9:00-6:30 EST / 24HR EMAIL support and sales
  13149. '''''''''''''''''''''''''''''''''''''''''''''''
  13150. De-installed ISP,CLEC,LEC Net-Hardware Wanted '
  13151. '''''''''''''''''''''''''''''''''''''''''''''''
  13152.  
  13153.  
  13154.  
  13155.      
  13156.   
  13157.  
  13158.  
  13159.  
  13160.  
  13161. -
  13162.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13163.  with "unsubscribe usr-tc" in the body of the message.
  13164.  For information on digests or retrieving files and old messages send
  13165.  "help" to the same address.  Do not use quotes in your message.
  13166.  
  13167.  
  13168. -------------------------------------------------------------------------------
  13169.  
  13170. From: Brian <signal@shreve.net>
  13171. Subject: RE: (usr-tc) VPN Tunnel to Linux box
  13172. Date: 15 Apr 1999 10:58:47 -0500 (CDT)
  13173.  
  13174. On Wed, 14 Apr 1999, Mike Wronski wrote:
  13175.  
  13176. > 
  13177. > 
  13178. > |-----Original Message-----
  13179. > |From: owner-usr-tc@lists.xmission.com
  13180. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  13181. > |Sent: Wednesday, April 14, 1999 4:10 PM
  13182. > |To: USRobotics TC Mailing List
  13183. > |Subject: (usr-tc) VPN Tunnel to Linux box
  13184. > |
  13185. > |
  13186. > |
  13187. > |I am wanting to setup a single Tunnel from the ARC to a linux box, using
  13188. > |the tunneling supported by linux (I believe linux will do PPTP).  Does
  13189. > |anyone have an example of at least the ARC side of the setup, and perhaps
  13190. > |even some notes on the Linux side?
  13191. > |
  13192. > |I believe the ARC supports l2tp and pptp right?  does it do ipsec?
  13193. > |
  13194. > 
  13195. > PPTP server on linux? I have seen the PPTP client but not a server. Can you point
  13196. > me to where you saw PPTP server for linux??
  13197. > 
  13198.  
  13199. http://www.moretonbay.com/vpn/pptp.html
  13200.  
  13201. perhaps someone @3Com can do a test to see if your implementation of PPTP
  13202. will work with this.  Hopefully it will!  I will do my own testing as
  13203. well, but I have never used 3Com PPTP on the ARC so hopefully I will get
  13204. it right.
  13205.  
  13206.  
  13207. > -M
  13208. > 
  13209. > 
  13210. > -
  13211. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13212. >  with "unsubscribe usr-tc" in the body of the message.
  13213. >  For information on digests or retrieving files and old messages send
  13214. >  "help" to the same address.  Do not use quotes in your message.
  13215. > 
  13216.  
  13217. Brian Feeny (BF304)     signal@shreve.net   
  13218. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13219. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13220.  
  13221.  
  13222. -
  13223.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13224.  with "unsubscribe usr-tc" in the body of the message.
  13225.  For information on digests or retrieving files and old messages send
  13226.  "help" to the same address.  Do not use quotes in your message.
  13227.  
  13228.  
  13229. -------------------------------------------------------------------------------
  13230.  
  13231. From: Paul Farber <farber@admin.f-tech.net>
  13232. Subject: (usr-tc) Filters
  13233. Date: 15 Apr 1999 12:21:49 -0400 (EDT)
  13234.  
  13235. Hello all, just wondering if someone could check my simple IP filter that
  13236. I want to implement.  The filter will go on the eth0 interface.
  13237.  
  13238. #filter
  13239. IP:
  13240. 010 AND src-addr = 207.044.065.000/24;
  13241. 020 ACCEPT dst-addr = 000.000.000.000/0;
  13242. 030 AND src-addr = 000.000.000.000/0;
  13243. 040 ACCEPT dst-addr = 207.044.065.000/24;
  13244. 050 DENY;
  13245.  
  13246. I know there is a way to assign filters via RADIUS for each caller, but
  13247. all I want to make sure I only send/recieve packets with their IP as the
  13248. originating/destination.. ie kill spoofers, keep alive pings etc.
  13249.  
  13250. What would a radius assigned filter look like?  How do I get the IP to set
  13251. up filtering?  I am using CISTRON on LINUX.  Will share the results and
  13252. maybe write a FAQ once this is done.. there seems to be litte explination
  13253. on doing this.
  13254.  
  13255. Thanks. 
  13256.  
  13257. Paul D. Farber II
  13258. Farber Technology
  13259. Ph. 570-628-5303
  13260. Fax 570-628-5545
  13261. farber@admin.f-tech.net
  13262.  
  13263.  
  13264. -
  13265.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13266.  with "unsubscribe usr-tc" in the body of the message.
  13267.  For information on digests or retrieving files and old messages send
  13268.  "help" to the same address.  Do not use quotes in your message.
  13269.  
  13270.  
  13271. -------------------------------------------------------------------------------
  13272.  
  13273. From: Brian <signal@shreve.net>
  13274. Subject: RE: (usr-tc) VPN Tunnel to Linux box
  13275. Date: 15 Apr 1999 11:25:08 -0500 (CDT)
  13276.  
  13277.  
  13278.  
  13279. Ok, it would seem that all that needs to be done is something like this:
  13280.  
  13281. On linux PPTP server:
  13282.  
  13283. pptp --localip ip.of.thismachine --remoteip ip.of.hiperarc
  13284.  
  13285.  
  13286. From reading the documentation it would seem no configuration should be
  13287. necessary on the HiperARC.  And I hope I read this right.  It appears, it
  13288. can be entirly done in RADIUS which would be nice.  Something like this
  13289. perhaps:
  13290.  
  13291. pptp    Auth-Type = "Unix-PW"
  13292.         Service-Type = "Framed-User",
  13293.         Framed-Protocol = "PPP",
  13294.         Framed-IP-Address = "255.255.255.254",
  13295.         Framed-Netmask = "255.255.255.255",
  13296.         Framed-MTU = "1500",
  13297.         Max-Channels = "2",
  13298.         Framed-Routing = "None",
  13299.         Framed-Compression = "Van-Jacobson-TCP-IP",
  13300.     Tunnel-Type=PPTP,
  13301.     Tunnel-Server-Endpoint = "ip.of.pptpserver"
  13302.  
  13303.  
  13304. Is that all that is needed? I am assuming "Tunnel-Password",
  13305. "Tunnel-Security", etc are all optional parameters, and that all RADIUS
  13306. really needs to tell the ARC is the Tunnel Type and Endpoint.
  13307.  
  13308. Brian
  13309.  
  13310.  
  13311.  
  13312.  -----------------------------------------------------
  13313. Brian Feeny (BF304)     signal@shreve.net   
  13314. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13315. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13316.  
  13317.  
  13318. -
  13319.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13320.  with "unsubscribe usr-tc" in the body of the message.
  13321.  For information on digests or retrieving files and old messages send
  13322.  "help" to the same address.  Do not use quotes in your message.
  13323.  
  13324.  
  13325. -------------------------------------------------------------------------------
  13326.  
  13327. From: Brian <signal@shreve.net>
  13328. Subject: Re: (usr-tc) Filters
  13329. Date: 15 Apr 1999 11:35:03 -0500 (CDT)
  13330.  
  13331. On Thu, 15 Apr 1999, Paul Farber wrote:
  13332.  
  13333. > Hello all, just wondering if someone could check my simple IP filter that
  13334. > I want to implement.  The filter will go on the eth0 interface.
  13335. > 
  13336. > #filter
  13337. > IP:
  13338. > 010 AND src-addr = 207.044.065.000/24;
  13339. > 020 ACCEPT dst-addr = 000.000.000.000/0;
  13340. > 030 AND src-addr = 000.000.000.000/0;
  13341. > 040 ACCEPT dst-addr = 207.044.065.000/24;
  13342. > 050 DENY;
  13343. > 
  13344. > I know there is a way to assign filters via RADIUS for each caller, but
  13345. > all I want to make sure I only send/recieve packets with their IP as the
  13346. > originating/destination.. ie kill spoofers, keep alive pings etc.
  13347.  
  13348. they can still spoof any ip's in 207.44.65.0............
  13349.  
  13350. Using a RADIUS that supports "hint assigned" such as RADIATOR
  13351. (http://www.open.com.au/radiator/) will assign each user a dynamic filter
  13352. such that it blocks everything but their ip and netmask.
  13353.  
  13354.  
  13355. > 
  13356. > What would a radius assigned filter look like?  How do I get the IP to set
  13357. > up filtering?  I am using CISTRON on LINUX.  Will share the results and
  13358. > maybe write a FAQ once this is done.. there seems to be litte explination
  13359. > on doing this.
  13360. > 
  13361. > Thanks. 
  13362. > 
  13363. > Paul D. Farber II
  13364. > Farber Technology
  13365. > Ph. 570-628-5303
  13366. > Fax 570-628-5545
  13367. > farber@admin.f-tech.net
  13368. > 
  13369. > 
  13370. > -
  13371. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13372. >  with "unsubscribe usr-tc" in the body of the message.
  13373. >  For information on digests or retrieving files and old messages send
  13374. >  "help" to the same address.  Do not use quotes in your message.
  13375. > 
  13376.  
  13377. Brian Feeny (BF304)     signal@shreve.net   
  13378. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13379. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13380.  
  13381.  
  13382. -
  13383.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13384.  with "unsubscribe usr-tc" in the body of the message.
  13385.  For information on digests or retrieving files and old messages send
  13386.  "help" to the same address.  Do not use quotes in your message.
  13387.  
  13388.  
  13389. -------------------------------------------------------------------------------
  13390.  
  13391. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  13392. Subject: RE: (usr-tc) Filters
  13393. Date: 15 Apr 1999 11:37:50 -0500
  13394.  
  13395.  
  13396.  
  13397. |-----Original Message-----
  13398. |From: owner-usr-tc@lists.xmission.com
  13399. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber
  13400. |Sent: Thursday, April 15, 1999 11:22 AM
  13401. |To: usr-tc@lists.xmission.com
  13402. |Subject: (usr-tc) Filters
  13403. |
  13404. |
  13405. |Hello all, just wondering if someone could check my simple IP filter that
  13406. |I want to implement.  The filter will go on the eth0 interface.
  13407. |
  13408. |#filter
  13409. |IP:
  13410. |010 AND src-addr = 207.044.065.000/24;
  13411. |020 ACCEPT dst-addr = 000.000.000.000/0;
  13412. |030 AND src-addr = 000.000.000.000/0;
  13413. |040 ACCEPT dst-addr = 207.044.065.000/24;
  13414. |050 DENY;
  13415.  
  13416. How about output filter:
  13417. #filter
  13418. IP:
  13419. 010 ACCEPT dst-addr = 207.44.65.0/C;
  13420. 020 DENY;
  13421.  
  13422. Input filter
  13423. #filter
  13424. IP:
  13425. 010 ACCEPT src-addr = 207.44.65.0/C;
  13426. 020 DENY;
  13427.  
  13428.  
  13429.  
  13430. |I know there is a way to assign filters via RADIUS for each caller, but
  13431. |all I want to make sure I only send/recieve packets with their IP as the
  13432. |originating/destination.. ie kill spoofers, keep alive pings etc.
  13433. |
  13434. |What would a radius assigned filter look like?  How do I get the IP to set
  13435. |up filtering?  I am using CISTRON on LINUX.  Will share the results and
  13436. |maybe write a FAQ once this is done.. there seems to be litte explination
  13437. |on doing this.
  13438. |
  13439.  
  13440. Radius sends the filter in multiple instances of the VSA "IP-In-Filter" 0x9000 or
  13441. "IP-Out-Filter" 0x9003.
  13442.  
  13443. The format will be the same excluding the "#filter" and "IP:" tokens.
  13444.  
  13445. ...
  13446. IP-In-Filter = "010 ACCEPT src-addr = 207.44.65.0/C;"
  13447. IP-In-Filter = "020 DENY;"
  13448. ...
  13449.  
  13450.  
  13451. -M
  13452.  
  13453.  
  13454. -
  13455.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13456.  with "unsubscribe usr-tc" in the body of the message.
  13457.  For information on digests or retrieving files and old messages send
  13458.  "help" to the same address.  Do not use quotes in your message.
  13459.  
  13460.  
  13461. -------------------------------------------------------------------------------
  13462.  
  13463. From: Ronald Kushner <ron@glis.net>
  13464. Subject: Re: (usr-tc) off-hook here, off-hook there?
  13465. Date: 15 Apr 1999 12:42:31 -0400
  13466.  
  13467.  
  13468.  
  13469. Ray Bagby wrote:
  13470. > 
  13471. >     I'm just about going to have to tell some paid-in-full, non-camping
  13472. > clients that they should find another Internet Service Provider because they
  13473. > keep getting dropped after only 90 to 120 seconds. These people are in
  13474. > another area-code with an independent phone company. I'm using SWBell. The
  13475. > inde guy says his equipment is not getting an off-hook which would start his
  13476. > billing timer, this in turn is activating the toll-fraud event which
  13477. > disconnects the call.
  13478. <snip>
  13479. >     My question: is there some setting somewhere I could change that would
  13480. > not allow this independent phone company to "get" the off-hook and still
  13481. > allow basically everybody else to "see" the off-hook? Anybody every dealt
  13482. > with this problem before? In other words: HELP!!!
  13483.  
  13484. This is known as a supervision problem. When your equipment answers, it sends a wink
  13485. back to the switch telling it that the phone line was answered, and that wink is
  13486. translated by your switch into supervision signals (on hook/ off hook) that get
  13487. transmitted over the SS7 network. Usually the wink is heard as a click when you call
  13488. into your equipment. If you have a trunk side DS-1, they usually do not ring and you
  13489. can hear the supervision click or wink before the modem answers. 
  13490.  
  13491. I am not sure how this works on ISDN PRI, I imagine the D channel is used to transmit
  13492. supervision signals, since I can not hear the wink when I call my equipment. The
  13493. supervision signals are now transmitted by the telcos out of band via the SS7 network.
  13494. If the telco is not SS7 capable (doubtful these days) the terminating switch in the
  13495. SS7 network should send the inband signals to the other telco.
  13496.  
  13497. I really doubt your equipment is not sending a wink or signal saying it's on hook,
  13498. most modern switches will disconnect the call before 4 minutes because of toll fraud
  13499. involving older switches in the network. So you would have a problem with your SBC
  13500. customers as well.
  13501.  
  13502. The only way you can fix this is to pound SBC, they will have to put a protocol
  13503. analyzer into the X25 network to ensure supervision signals are sent to the other
  13504. telco. As long as you get the lingo down right, you'll find the right dim bulb that
  13505. will know how the fix your problem. If you don't get anywhere, file a complaint with
  13506. your state public service commission.
  13507.  
  13508. How small is this independent telephone company? Is it a local call for their
  13509. customers to call your numbers?
  13510.  
  13511. -Ron
  13512. GLISnet, Inc.
  13513. +1 810/939.9885
  13514.  
  13515. -
  13516.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13517.  with "unsubscribe usr-tc" in the body of the message.
  13518.  For information on digests or retrieving files and old messages send
  13519.  "help" to the same address.  Do not use quotes in your message.
  13520.  
  13521.  
  13522. -------------------------------------------------------------------------------
  13523.  
  13524. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  13525. Subject: RE: (usr-tc) VPN Tunnel to Linux box
  13526. Date: 15 Apr 1999 11:42:53 -0500
  13527.  
  13528.  
  13529.  
  13530. |-----Original Message-----
  13531. |From: owner-usr-tc@lists.xmission.com
  13532. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  13533. |Sent: Thursday, April 15, 1999 11:25 AM
  13534. |To: USRobotics TC Mailing List
  13535. |Subject: RE: (usr-tc) VPN Tunnel to Linux box
  13536. |
  13537. |
  13538. |
  13539. |
  13540. |Ok, it would seem that all that needs to be done is something like this:
  13541. |
  13542. |On linux PPTP server:
  13543. |
  13544. |pptp --localip ip.of.thismachine --remoteip ip.of.hiperarc
  13545. |
  13546. |
  13547. |>From reading the documentation it would seem no configuration should be
  13548. |necessary on the HiperARC.  And I hope I read this right.  It appears, it
  13549. |can be entirly done in RADIUS which would be nice.  Something like this
  13550. |perhaps:
  13551. |
  13552. |pptp    Auth-Type = "Unix-PW"
  13553. |        Service-Type = "Framed-User",
  13554. |        Framed-Protocol = "PPP",
  13555. |        Framed-IP-Address = "255.255.255.254",
  13556. |        Framed-Netmask = "255.255.255.255",
  13557. |        Framed-MTU = "1500",
  13558. |        Max-Channels = "2",
  13559. |        Framed-Routing = "None",
  13560. |        Framed-Compression = "Van-Jacobson-TCP-IP",
  13561. |    Tunnel-Type=PPTP,
  13562. |    Tunnel-Server-Endpoint = "ip.of.pptpserver"
  13563. |
  13564. |
  13565. |Is that all that is needed? I am assuming "Tunnel-Password",
  13566. |"Tunnel-Security", etc are all optional parameters, and that all RADIUS
  13567. |really needs to tell the ARC is the Tunnel Type and Endpoint.
  13568. |
  13569.  
  13570. Thats it. You do need to use NT or linux though. The server notes state that
  13571. Win9X is not supported yet.
  13572. I have not used the linux pptpd yet.. When I do, I will post my results..
  13573.  
  13574. -M
  13575.  
  13576.  
  13577. -
  13578.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13579.  with "unsubscribe usr-tc" in the body of the message.
  13580.  For information on digests or retrieving files and old messages send
  13581.  "help" to the same address.  Do not use quotes in your message.
  13582.  
  13583.  
  13584. -------------------------------------------------------------------------------
  13585.  
  13586. From: Griggs Jim <Griggs_Jim@prc.com>
  13587. Subject: (usr-tc) x2
  13588. Date: 15 Apr 1999 13:43:30 -0400
  13589.  
  13590. I have a Netserver/8  (Not the PLUS version) purchased circa mid '97 that
  13591. has x2 capable modems onboard.  -- At least according to the ATI7 response.
  13592. I have set the dip switch on the back of the unit to allow up to 57600
  13593. connect speed, but I am still not getting anything above 24000 even from a
  13594. phone line that I can routinely connect to elsewhere at 480000 or higher.
  13595. Am I missing an AT command somewhere ??  Even without a firmware upgrade to
  13596. v.90 I should still get a higher connection rate than 24k.
  13597.  
  13598.  
  13599. -
  13600.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13601.  with "unsubscribe usr-tc" in the body of the message.
  13602.  For information on digests or retrieving files and old messages send
  13603.  "help" to the same address.  Do not use quotes in your message.
  13604.  
  13605.  
  13606. -------------------------------------------------------------------------------
  13607.  
  13608. From: Brian <signal@shreve.net>
  13609. Subject: RE: (usr-tc) VPN Tunnel to Linux box
  13610. Date: 15 Apr 1999 12:54:56 -0500 (CDT)
  13611.  
  13612.  
  13613. > Thats it. You do need to use NT or linux though. The server notes state that
  13614. > Win9X is not supported yet.
  13615. > I have not used the linux pptpd yet.. When I do, I will post my results..
  13616.  
  13617. Thanks mike, I too will post if I get the ARC->Linux PPTP tunnel working.
  13618.  
  13619.  
  13620. > 
  13621. > -M
  13622. > 
  13623. > 
  13624. > -
  13625. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13626. >  with "unsubscribe usr-tc" in the body of the message.
  13627. >  For information on digests or retrieving files and old messages send
  13628. >  "help" to the same address.  Do not use quotes in your message.
  13629. > 
  13630.  
  13631. Brian Feeny (BF304)     signal@shreve.net   
  13632. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13633. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13634.  
  13635.  
  13636. -
  13637.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13638.  with "unsubscribe usr-tc" in the body of the message.
  13639.  For information on digests or retrieving files and old messages send
  13640.  "help" to the same address.  Do not use quotes in your message.
  13641.  
  13642.  
  13643. -------------------------------------------------------------------------------
  13644.  
  13645. From: "Jamie Orzechowski" <mhz@ripnet.com>
  13646. Subject: (usr-tc) Proxy ARP
  13647. Date: 15 Apr 1999 14:19:12 -0400
  13648.  
  13649. This is a multi-part message in MIME format.
  13650.  
  13651. ------=_NextPart_000_000D_01BE874A.EF6ED3A0
  13652. Content-Type: text/plain;
  13653.     charset="iso-8859-1"
  13654. Content-Transfer-Encoding: quoted-printable
  13655.  
  13656. Hi There ... I remeber setting up my ARC a long while ago and having to =
  13657. enable proxy arp ... I cannot find this command anywhere ... does nayone =
  13658. know how to enable proxy arp on the ARC??? ...=20
  13659.  
  13660. ------=_NextPart_000_000D_01BE874A.EF6ED3A0
  13661. Content-Type: text/html;
  13662.     charset="iso-8859-1"
  13663. Content-Transfer-Encoding: quoted-printable
  13664.  
  13665. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  13666. <HTML><HEAD>
  13667. <META content=3D"text/html; charset=3Diso-8859-1" =
  13668. http-equiv=3DContent-Type>
  13669. <META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
  13670. <STYLE></STYLE>
  13671. </HEAD>
  13672. <BODY bgColor=3D#ffffff>
  13673. <DIV><FONT size=3D2>Hi There ... I remeber setting up my ARC a long =
  13674. while ago and=20
  13675. having to enable proxy arp ... I cannot find this command anywhere ... =
  13676. does=20
  13677. nayone know how to enable proxy arp on the ARC??? ...=20
  13678. </FONT></DIV></BODY></HTML>
  13679.  
  13680. ------=_NextPart_000_000D_01BE874A.EF6ED3A0--
  13681.  
  13682.  
  13683. -
  13684.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13685.  with "unsubscribe usr-tc" in the body of the message.
  13686.  For information on digests or retrieving files and old messages send
  13687.  "help" to the same address.  Do not use quotes in your message.
  13688.  
  13689.  
  13690. -------------------------------------------------------------------------------
  13691.  
  13692. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  13693. Subject: Re: (usr-tc) Proxy ARP
  13694. Date: 15 Apr 1999 14:17:28 -0500 (CDT)
  13695.  
  13696.  enable ip proXY_ARP_ALL_DIALIN
  13697.  
  13698.  
  13699. krish
  13700.  
  13701.  
  13702.         \    T.S.V. Krishnan  \
  13703.          \      Network System Engineer \ ( : - : )
  13704.           \     3Com ............   \
  13705.         ----------------------------------------------/
  13706. tkrishna@bubba.ae.usr.com  
  13707. ----------------------------/ http://interproc.ae.usr.com ----/
  13708. The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
  13709.     Any Sufficiently advanced bug is indistinguishable for a feature.
  13710.                         - Rick Kulawiec
  13711.  
  13712. On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  13713.  
  13714. > Hi There ... I remeber setting up my ARC a long while ago and having to =
  13715. > enable proxy arp ... I cannot find this command anywhere ... does nayone =
  13716. > know how to enable proxy arp on the ARC??? ...=20
  13717. > 
  13718.  
  13719. -
  13720.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13721.  with "unsubscribe usr-tc" in the body of the message.
  13722.  For information on digests or retrieving files and old messages send
  13723.  "help" to the same address.  Do not use quotes in your message.
  13724.  
  13725.  
  13726. -------------------------------------------------------------------------------
  13727.  
  13728. From: Brian <signal@shreve.net>
  13729. Subject: (usr-tc) strange LIST CONN
  13730. Date: 15 Apr 1999 14:18:11 -0500 (CDT)
  13731.  
  13732.  
  13733. Is anyone else seeing alot of 
  13734. DIALIN INVALID 00-   -0000    00:00:00
  13735.  
  13736. in LIST CONN since upgrading to 4.1.59-6?
  13737.  
  13738.  
  13739. slot:1/mod:13   joshw                       DIALIN PPP  15-APR-1999 19:15:43  
  13740. slot:1/mod:14   mc2                         DIALIN PPP  15-APR-1999 14:20:00  
  13741. slot:1/mod:15                               DIALIN INVALID 00-   -0000  00:00:00  
  13742. slot:1/mod:16   mrmc                        DIALIN PPP  15-APR-1999 13:04:40  
  13743. slot:1/mod:17   small                       DIALIN PPP  15-APR-1999 18:37:55  
  13744.  
  13745.  
  13746. Brian Feeny (BF304)     signal@shreve.net   
  13747. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13748. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13749.  
  13750.  
  13751. -
  13752.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13753.  with "unsubscribe usr-tc" in the body of the message.
  13754.  For information on digests or retrieving files and old messages send
  13755.  "help" to the same address.  Do not use quotes in your message.
  13756.  
  13757.  
  13758. -------------------------------------------------------------------------------
  13759.  
  13760. From: Gilles Melanson <gilles@vianet.on.ca>
  13761. Subject: RE: (usr-tc) 3com v90 Winmodems -> 1.2.43 code
  13762. Date: 15 Apr 1999 15:29:38 -0400 (EDT)
  13763.  
  13764.  
  13765. Is it my understanding that the 3com PCI Winmodem is Rockwell based, and
  13766. that 3com makes a modem that can't connect to its own terminal servers?
  13767.  
  13768. Everyone is talking about LTs, which have nothing to do with 3com
  13769. Winmodems.  Rockwell?
  13770.  
  13771. Krish?  Krish?  Tell me it isn't so.  Please tell me there's a solution
  13772. for users with the latest 3com Winmodem Upgrade, from the web page.
  13773.  
  13774. /gm
  13775.  
  13776. --
  13777.  
  13778. > We had a lot of complaints from users with "new" computers too.
  13779. > But usually the installed modem code on their pc was a 1-3 months old.
  13780. > I think there have been several revisions to the LT and Rockwell code
  13781. > already this year.
  13782. > Bottom line- upgrade the client modem.  
  13783. > We run DSP1.2.43/ARC4.1.11 (will upgrade to 4.1.59-6 soon) and after
  13784. > users with poor connect speeds did an upgrade on their end, everything is
  13785. > great.
  13786. > These upgrades are very easy also.
  13787. > 
  13788. > Below is an excerpt from a list message on 3-26-99, it really helped me!
  13789. > Regards,
  13790. > Scott Boggs
  13791. > United Bank
  13792. > 
  13793. > ========================================
  13794. > Here's the lowdown:
  13795. > LT Winmodems: download the latest driver: 5.39. You can get it from
  13796. > http://www.tidewater.net/56k.shtml.
  13797. > 
  13798. > Rockwell 56k PCI: these can be either HCF or ITU modems. HCF are real crap.
  13799. > They need in init string of +ms=v34 to turn off all 56k attempts. The ITU
  13800. > (or non-HCF) Rockwells use an init string of +ms=11,1 or update the drivers
  13801. > from the manufacturer's site.
  13802. > 
  13803. > iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that
  13804. > came with MacAddict(?) in January ( I think. I don't get the mag).
  13805. > 
  13806. > Go to http://www.56k.com for more info on the init strings.
  13807. > 
  13808. > Wayne Barber
  13809. > Coastal Telco Services
  13810. > ===========================================
  13811. > 
  13812. > > -----Original Message-----
  13813. > > From:    Gilles Melanson [SMTP:gilles@vianet.on.ca]
  13814. > > Sent:    Wednesday, April 14, 1999 9:02 AM
  13815. > > To:    usr-tc@lists.xmission.com
  13816. > > Subject:    (usr-tc) 3com v90 Winmodems -> 1.2.43 code
  13817. > > 
  13818. > > This doesn't work.
  13819. > > 
  13820. > > I have a pair of customers in different cities that dial into
  13821. > > 4.1.72/1.2.43 based chassis, with their brand new Dell computers.
  13822. > > 
  13823. > 
  13824. > -
  13825. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13826. >  with "unsubscribe usr-tc" in the body of the message.
  13827. >  For information on digests or retrieving files and old messages send
  13828. >  "help" to the same address.  Do not use quotes in your message.
  13829. > 
  13830.  
  13831. --
  13832. Gilles Melanson                         ViaNet Internet Solutions
  13833. System Administrator                    128 Larch St. Suite 301
  13834. gilles@vianet.on.ca                     Sudbury, ON Canada  P3E 5J8
  13835.  
  13836. The "-ell 65532" is an undocumented switch. THIS is the magic twinkle
  13837. dust. Works better if you wave a dead chicken at the same time... Causes lights
  13838. on the disks to go bonkers for a while.            -- DEC Mailing List
  13839.  
  13840.  
  13841. -
  13842.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13843.  with "unsubscribe usr-tc" in the body of the message.
  13844.  For information on digests or retrieving files and old messages send
  13845.  "help" to the same address.  Do not use quotes in your message.
  13846.  
  13847.  
  13848. -------------------------------------------------------------------------------
  13849.  
  13850. From: Brian <signal@shreve.net>
  13851. Subject: (usr-tc) strange LIST CONN
  13852. Date: 15 Apr 1999 14:18:11 -0500 (CDT)
  13853.  
  13854.  
  13855. Is anyone else seeing alot of 
  13856. DIALIN INVALID 00-   -0000    00:00:00
  13857.  
  13858. in LIST CONN since upgrading to 4.1.59-6?
  13859.  
  13860.  
  13861. slot:1/mod:13   joshw                       DIALIN PPP  15-APR-1999 19:15:43  
  13862. slot:1/mod:14   mc2                         DIALIN PPP  15-APR-1999 14:20:00  
  13863. slot:1/mod:15                               DIALIN INVALID 00-   -0000  00:00:00  
  13864. slot:1/mod:16   mrmc                        DIALIN PPP  15-APR-1999 13:04:40  
  13865. slot:1/mod:17   small                       DIALIN PPP  15-APR-1999 18:37:55  
  13866.  
  13867.  
  13868. Brian Feeny (BF304)     signal@shreve.net   
  13869. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13870. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13871.  
  13872.  
  13873. -
  13874.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13875.  with "unsubscribe usr-tc" in the body of the message.
  13876.  For information on digests or retrieving files and old messages send
  13877.  "help" to the same address.  Do not use quotes in your message.
  13878.  
  13879.  
  13880. -------------------------------------------------------------------------------
  13881.  
  13882. From: Jeff Carneal <jeff@apex.net>
  13883. Subject: Re: (usr-tc) Caller ID on Chan T1?
  13884. Date: 15 Apr 1999 15:03:17 -0500 (CDT)
  13885.  
  13886. On Wed, 14 Apr 1999, Tatai SV Krishnan wrote:
  13887.  
  13888. > > Additionally, I'm quite positive that the telco is sending 10 digits for
  13889. > > ANI, 10 digits for DNIS on every call (mf digit signaling).  Is caller ID
  13890. > > simply not supported on channelized T1 on the hipers?  Any other thoughts?
  13891. > > 
  13892. > 
  13893. > Check the DSP settings - Make sure that you have it set to receive 10 digits
  13894.  
  13895. After looking in TCM, I don't see a place to make such a setting.  I see
  13896. only "Number of DTMF Tones", which should not apply in this case because
  13897. we're using MF signaling.  With DTMF you have to know how many digits to
  13898. read, but with MF you have the KP and ST to mark the beginning and end of
  13899. the digit strings, so I would think this would be unnecessary.
  13900.  
  13901. Am I looking in the wrong place or is there some other thing I'm missing
  13902. here?
  13903.  
  13904. --
  13905.   Jeff Carneal - Sys Admin - Apex Internet          
  13906.   jeff@apex.net http://www.apex.net (502) 442-5363
  13907.  
  13908.   The opinions expressed above aren't really mine.
  13909.   They belong to someone else who also refuses to 
  13910.   take responsibility for them. 
  13911.  
  13912.  
  13913. -
  13914.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13915.  with "unsubscribe usr-tc" in the body of the message.
  13916.  For information on digests or retrieving files and old messages send
  13917.  "help" to the same address.  Do not use quotes in your message.
  13918.  
  13919.  
  13920. -------------------------------------------------------------------------------
  13921.  
  13922. From: Jeff Mcadams <jeffm@iglou.com>
  13923. Subject: Re: (usr-tc) strange LIST CONN
  13924. Date: 15 Apr 1999 16:06:22 -0400 (EDT)
  13925.  
  13926. Thus spake Brian
  13927. >Is anyone else seeing alot of 
  13928. >DIALIN INVALID 00-   -0000    00:00:00
  13929.  
  13930. >in LIST CONN since upgrading to 4.1.59-6?
  13931.  
  13932. >slot:1/mod:13   joshw                       DIALIN PPP  15-APR-1999 19:15:43  
  13933. >slot:1/mod:14   mc2                         DIALIN PPP  15-APR-1999 14:20:00  
  13934. >slot:1/mod:15                               DIALIN INVALID 00-   -0000  00:00:00  
  13935. >slot:1/mod:16   mrmc                        DIALIN PPP  15-APR-1999 13:04:40  
  13936. >slot:1/mod:17   small                       DIALIN PPP  15-APR-1999 18:37:55  
  13937.  
  13938. I'm seeing it with 4.1.59-2, but what I've found is that those seem to
  13939. be ports that are currently handshaking.  ie, the modem has picked up,
  13940. but hasn't synced up yet.  After this, it'll go to DIALIN PPP with no
  13941. userid, then a userid will be added.
  13942.  
  13943. Again, I haven't investigated this in depth, but it seems to be how
  13944. things are working from just seeing at while watching other stuff.
  13945. -- 
  13946. Jeff McAdams                            Email: jeffm@iglou.com
  13947. Head Network Administrator              Voice: (502) 966-3848
  13948. IgLou Internet Services                        (800) 436-4456
  13949.  
  13950. -
  13951.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13952.  with "unsubscribe usr-tc" in the body of the message.
  13953.  For information on digests or retrieving files and old messages send
  13954.  "help" to the same address.  Do not use quotes in your message.
  13955.  
  13956.  
  13957. -------------------------------------------------------------------------------
  13958.  
  13959. From: Aaron Nabil <nabil@spiritone.com>
  13960. Subject: Re: (usr-tc) Filters
  13961. Date: 15 Apr 1999 13:24:53 -0700 (PDT)
  13962.  
  13963. Brian writes...
  13964. >On Thu, 15 Apr 1999, Paul Farber wrote:
  13965. >
  13966. >>  . . .
  13967. >> I know there is a way to assign filters via RADIUS for each caller, but
  13968. >> all I want to make sure I only send/recieve packets with their IP as the
  13969. >> originating/destination.. ie kill spoofers, keep alive pings etc.
  13970. >
  13971. >they can still spoof any ip's in 207.44.65.0............
  13972. >
  13973. >Using a RADIUS that supports "hint assigned" such as RADIATOR
  13974. >(http://www.open.com.au/radiator/) will assign each user a dynamic filter
  13975. >such that it blocks everything but their ip and netmask.
  13976.  
  13977. Way overkill.  Just enable the built-in anti-spoofing code, it'll
  13978. check the source address matches the assigned address.  It's documented
  13979. in the latest hiperarc release notes.
  13980.  
  13981.  
  13982. -- 
  13983. Aaron Nabil
  13984.  
  13985. -
  13986.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13987.  with "unsubscribe usr-tc" in the body of the message.
  13988.  For information on digests or retrieving files and old messages send
  13989.  "help" to the same address.  Do not use quotes in your message.
  13990.  
  13991.  
  13992. -------------------------------------------------------------------------------
  13993.  
  13994. From: Pete Ashdown <pashdown@xmission.com>
  13995. Subject: Re: (usr-tc) Filters
  13996. Date: 15 Apr 1999 14:42:30 -0600 (MDT)
  13997.  
  13998. Aaron Nabil said once upon a time:
  13999.  
  14000. >Way overkill.  Just enable the built-in anti-spoofing code, it'll
  14001. >check the source address matches the assigned address.  It's documented
  14002. >in the latest hiperarc release notes.
  14003.  
  14004. Does this take into account framed-route(s)?
  14005.  
  14006. -
  14007.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14008.  with "unsubscribe usr-tc" in the body of the message.
  14009.  For information on digests or retrieving files and old messages send
  14010.  "help" to the same address.  Do not use quotes in your message.
  14011.  
  14012.  
  14013. -------------------------------------------------------------------------------
  14014.  
  14015. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  14016. Subject: RE: (usr-tc) strange LIST CONN
  14017. Date: 15 Apr 1999 16:36:13 -0500
  14018.  
  14019.  
  14020.  
  14021. |-----Original Message-----
  14022. |From: owner-usr-tc@lists.xmission.com
  14023. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  14024. |Sent: Thursday, April 15, 1999 3:06 PM
  14025. |To: usr-tc@lists.xmission.com
  14026. |Subject: Re: (usr-tc) strange LIST CONN
  14027. |
  14028. |
  14029. |Thus spake Brian
  14030. |>Is anyone else seeing alot of 
  14031. |>DIALIN INVALID 00-   -0000    00:00:00
  14032. |
  14033. |>in LIST CONN since upgrading to 4.1.59-6?
  14034. |
  14035. |>slot:1/mod:13   joshw                       DIALIN PPP  15-APR-1999 19:15:43  
  14036. |>slot:1/mod:14   mc2                         DIALIN PPP  15-APR-1999 14:20:00  
  14037. |>slot:1/mod:15                               DIALIN INVALID 00-   -0000 
  14038. | 00:00:00  
  14039. |>slot:1/mod:16   mrmc                        DIALIN PPP  15-APR-1999 13:04:40  
  14040. |>slot:1/mod:17   small                       DIALIN PPP  15-APR-1999 18:37:55  
  14041. |
  14042. |I'm seeing it with 4.1.59-2, but what I've found is that those seem to
  14043. |be ports that are currently handshaking.  ie, the modem has picked up,
  14044. |but hasn't synced up yet.  After this, it'll go to DIALIN PPP with no
  14045. |userid, then a userid will be added.
  14046.  
  14047. That is a correct observation. It is a transient state for the port.
  14048.  
  14049. -M
  14050.  
  14051.  
  14052. -
  14053.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14054.  with "unsubscribe usr-tc" in the body of the message.
  14055.  For information on digests or retrieving files and old messages send
  14056.  "help" to the same address.  Do not use quotes in your message.
  14057.  
  14058.  
  14059. -------------------------------------------------------------------------------
  14060.  
  14061. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  14062. Subject: RE: (usr-tc) Filters
  14063. Date: 15 Apr 1999 16:36:13 -0500
  14064.  
  14065.  
  14066.  
  14067. |-----Original Message-----
  14068. |From: owner-usr-tc@lists.xmission.com
  14069. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown
  14070. |Sent: Thursday, April 15, 1999 3:43 PM
  14071. |To: usr-tc@lists.xmission.com
  14072. |Subject: Re: (usr-tc) Filters
  14073. |
  14074. |
  14075. |Aaron Nabil said once upon a time:
  14076. |
  14077. |>Way overkill.  Just enable the built-in anti-spoofing code, it'll
  14078. |>check the source address matches the assigned address.  It's documented
  14079. |>in the latest hiperarc release notes.
  14080. |
  14081. |Does this take into account framed-route(s)?
  14082. |
  14083. No.. The feature only checks the ip assigned to the interface.
  14084.  
  14085. -M
  14086.  
  14087.  
  14088. -
  14089.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14090.  with "unsubscribe usr-tc" in the body of the message.
  14091.  For information on digests or retrieving files and old messages send
  14092.  "help" to the same address.  Do not use quotes in your message.
  14093.  
  14094.  
  14095. -------------------------------------------------------------------------------
  14096.  
  14097. From: Brian <signal@shreve.net>
  14098. Subject: (usr-tc) TAP does not use facility
  14099. Date: 15 Apr 1999 17:10:08 -0500 (CDT)
  14100.  
  14101.  
  14102. I have a ARC which is set as follows:
  14103.  
  14104. HiPer>> list sysLOGS 
  14105.  
  14106. SYSLOG SINKS
  14107. SysLog          Log Level Msg Count Facility  Allow all
  14108.                                               Auth levels
  14109. 208.206.76.27   UNUSUAL   1061143   LOG_LOCAL1YES 
  14110. HiPer>> list tap
  14111.  
  14112. Id Type Perm Interface      User                Out  Fmt Facility  Levl
  14113. Address
  14114. 1  USER No                  bolinger            SYSL ASC LOG_LOCAL7VERB 
  14115. 2  USER No                  dandeb              SYSL ASC LOG_LOCAL7VERB 
  14116. 3  USER No                  bayoupub            SYSL ASC LOG_LOCAL7VERB 
  14117. 4  USER No                  jacobe              SYSL ASC LOG_LOCAL7VERB 
  14118. 5  USER No                  dblak               SYSL ASC LOG_LOCAL7VERB 
  14119.  
  14120.  
  14121.  
  14122. So basically this ARC logs to log_local1.  I setup 5 tap users which log
  14123. to log_local7.  But guess where the tap really logs?  log_local1.  
  14124.  
  14125. So it would appear that setting the facility for a tap user doesn't work,
  14126. and that it uses the facility of the arc instead.  Is this the way things
  14127. are supposed to work? If so what is the facility for a tap user for?
  14128.  
  14129. ARC code is 4.1.59-6.
  14130.  
  14131.  
  14132.  
  14133. Brian Feeny (BF304)     signal@shreve.net   
  14134. 318-222-2638 x 109    http://www.shreve.net/~signal      
  14135. Network Administrator   ShreveNet Inc. (ASN 11881)           
  14136.  
  14137.  
  14138. -
  14139.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14140.  with "unsubscribe usr-tc" in the body of the message.
  14141.  For information on digests or retrieving files and old messages send
  14142.  "help" to the same address.  Do not use quotes in your message.
  14143.  
  14144.  
  14145. -------------------------------------------------------------------------------
  14146.  
  14147. From: "Ray Bagby" <rbagby@yore.net>
  14148. Subject: Re: (usr-tc) off-hook here, off-hook there?
  14149. Date: 15 Apr 1999 17:37:02 -0500
  14150.  
  14151. > <snip>
  14152. > >     My question: is there some setting somewhere I could change that
  14153. would
  14154. > > not allow this independent phone company to "get" the off-hook and still
  14155. > > allow basically everybody else to "see" the off-hook? Anybody every
  14156. dealt
  14157. > > with this problem before? In other words: HELP!!!
  14158. >
  14159. > This is known as a supervision problem. When your equipment answers, it
  14160. sends a wink
  14161. > back to the switch telling it that the phone line was answered, and that
  14162. wink is
  14163. > translated by your switch into supervision signals (on hook/ off hook)
  14164. that get
  14165. > transmitted over the SS7 network. Usually the wink is heard as a click
  14166. when you call
  14167. > into your equipment. If you have a trunk side DS-1, they usually do not
  14168. ring and you
  14169. > can hear the supervision click or wink before the modem answers.
  14170. >
  14171. > How small is this independent telephone company? Is it a local call for
  14172. their
  14173. > customers to call your numbers?
  14174.  
  14175. Hi Ron, thanks for replying,
  14176.     No, it's not a local call for the folks there, in fact they're in
  14177. another area code and the company involved is pretty small. We finally did
  14178. resolve the problem though. Seems that setting the "Dial In Address" to 'no
  14179. address' took care of it. Now the question is: what happened Sunday
  14180. afternoon to change things? I checked the hard copy of the settings against
  14181. the settings after the problems started and nothing changed here. I guess I
  14182. should just be happy things are working again. ;-)
  14183.     Thanks again... ray
  14184.  
  14185.  
  14186.  
  14187. -
  14188.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14189.  with "unsubscribe usr-tc" in the body of the message.
  14190.  For information on digests or retrieving files and old messages send
  14191.  "help" to the same address.  Do not use quotes in your message.
  14192.  
  14193.  
  14194. -------------------------------------------------------------------------------
  14195.  
  14196. From: Brian <signal@shreve.net>
  14197. Subject: Re: (usr-tc) Filters
  14198. Date: 15 Apr 1999 17:41:51 -0500 (CDT)
  14199.  
  14200. On Thu, 15 Apr 1999, Aaron Nabil wrote:
  14201.  
  14202. > Brian writes...
  14203. > >On Thu, 15 Apr 1999, Paul Farber wrote:
  14204. > >
  14205. > >>  . . .
  14206. > >> I know there is a way to assign filters via RADIUS for each caller, but
  14207. > >> all I want to make sure I only send/recieve packets with their IP as the
  14208. > >> originating/destination.. ie kill spoofers, keep alive pings etc.
  14209. > >
  14210. > >they can still spoof any ip's in 207.44.65.0............
  14211. > >
  14212. > >Using a RADIUS that supports "hint assigned" such as RADIATOR
  14213. > >(http://www.open.com.au/radiator/) will assign each user a dynamic filter
  14214. > >such that it blocks everything but their ip and netmask.
  14215. > 
  14216. > Way overkill.  Just enable the built-in anti-spoofing code, it'll
  14217. > check the source address matches the assigned address.  It's documented
  14218. > in the latest hiperarc release notes.
  14219.  
  14220. The problem with that code though, if I remember right, is that it always
  14221. assumes a subnet mask of 255.255.255.255 does it not?
  14222.  
  14223.  
  14224.  
  14225. > 
  14226. > 
  14227. > -- 
  14228. > Aaron Nabil
  14229. > 
  14230. > -
  14231. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14232. >  with "unsubscribe usr-tc" in the body of the message.
  14233. >  For information on digests or retrieving files and old messages send
  14234. >  "help" to the same address.  Do not use quotes in your message.
  14235. > 
  14236.  
  14237. Brian Feeny (BF304)     signal@shreve.net   
  14238. 318-222-2638 x 109    http://www.shreve.net/~signal      
  14239. Network Administrator   ShreveNet Inc. (ASN 11881)           
  14240.  
  14241.  
  14242. -
  14243.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14244.  with "unsubscribe usr-tc" in the body of the message.
  14245.  For information on digests or retrieving files and old messages send
  14246.  "help" to the same address.  Do not use quotes in your message.
  14247.  
  14248.  
  14249. -------------------------------------------------------------------------------
  14250.  
  14251. From: K Mitchell <mitch@keyconn.net>
  14252. Subject: Re: (usr-tc) strange LIST CONN
  14253. Date: 15 Apr 1999 18:49:45 -0400
  14254.  
  14255. At 04:06 PM 4/15/99 -0400, you wrote:
  14256. >Thus spake Brian
  14257. >>Is anyone else seeing alot of 
  14258. >>DIALIN INVALID 00-   -0000    00:00:00
  14259. >
  14260. >I'm seeing it with 4.1.59-2, but what I've found is that those seem to
  14261. >be ports that are currently handshaking.  ie, the modem has picked up,
  14262. >but hasn't synced up yet.  After this, it'll go to DIALIN PPP with no
  14263. >userid, then a userid will be added.
  14264.  
  14265.   I've seen the same thing through every code revision I've had. The
  14266. sequence appears to be:  DIALIN INVALID 00-   -0000    00:00:00, then the
  14267. session start time is added, then changes to DIALIN PPP, then the user ID
  14268. is added last.
  14269. AFAIK it's nothing to be concerned about.
  14270.  
  14271. Kirk
  14272.  
  14273.  
  14274.  
  14275.  
  14276. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14277. Keystone Connect                http://www.keyconn.net
  14278. Altoona, PA   814-941-5000         We Unlock the World
  14279.  
  14280.  
  14281. -
  14282.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14283.  with "unsubscribe usr-tc" in the body of the message.
  14284.  For information on digests or retrieving files and old messages send
  14285.  "help" to the same address.  Do not use quotes in your message.
  14286.  
  14287.  
  14288. -------------------------------------------------------------------------------
  14289.  
  14290. From: Brian <signal@shreve.net>
  14291. Subject: Re: (usr-tc) strange LIST CONN
  14292. Date: 15 Apr 1999 18:20:13 -0500 (CDT)
  14293.  
  14294. On Thu, 15 Apr 1999, K Mitchell wrote:
  14295.  
  14296. > At 04:06 PM 4/15/99 -0400, you wrote:
  14297. > >Thus spake Brian
  14298. > >>Is anyone else seeing alot of 
  14299. > >>DIALIN INVALID 00-   -0000    00:00:00
  14300. > >
  14301. > >I'm seeing it with 4.1.59-2, but what I've found is that those seem to
  14302. > >be ports that are currently handshaking.  ie, the modem has picked up,
  14303. > >but hasn't synced up yet.  After this, it'll go to DIALIN PPP with no
  14304. > >userid, then a userid will be added.
  14305. > 
  14306. >   I've seen the same thing through every code revision I've had. The
  14307. > sequence appears to be:  DIALIN INVALID 00-   -0000    00:00:00, then the
  14308. > session start time is added, then changes to DIALIN PPP, then the user ID
  14309. > is added last.
  14310. > AFAIK it's nothing to be concerned about.
  14311.  
  14312. Well what it was, is that I saw modems in it nonstop.  Which is kinda neat
  14313. cause it shows you a modem that won't handshake.  I software downloaded
  14314. code to that card again, and it started working fine.  So if you ever see
  14315. that string non-stop I guess thats a sign of a possible bad modem.
  14316.  
  14317. Brian
  14318.  
  14319.  
  14320. > 
  14321. > Kirk
  14322. > 
  14323. > 
  14324. > 
  14325. > 
  14326. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14327. > Keystone Connect                http://www.keyconn.net
  14328. > Altoona, PA   814-941-5000         We Unlock the World
  14329. > 
  14330. > 
  14331. > -
  14332. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14333. >  with "unsubscribe usr-tc" in the body of the message.
  14334. >  For information on digests or retrieving files and old messages send
  14335. >  "help" to the same address.  Do not use quotes in your message.
  14336. > 
  14337.  
  14338. Brian Feeny (BF304)     signal@shreve.net   
  14339. 318-222-2638 x 109    http://www.shreve.net/~signal      
  14340. Network Administrator   ShreveNet Inc. (ASN 11881)           
  14341.  
  14342.  
  14343. -
  14344.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14345.  with "unsubscribe usr-tc" in the body of the message.
  14346.  For information on digests or retrieving files and old messages send
  14347.  "help" to the same address.  Do not use quotes in your message.
  14348.  
  14349.  
  14350. -------------------------------------------------------------------------------
  14351.  
  14352. From: Jeff Mcadams <jeffm@iglou.com>
  14353. Subject: Re: (usr-tc) TAP does not use facility
  14354. Date: 15 Apr 1999 20:09:28 -0400 (EDT)
  14355.  
  14356. Thus spake Brian
  14357. >I have a ARC which is set as follows:
  14358.  
  14359. >So basically this ARC logs to log_local1.  I setup 5 tap users which log
  14360. >to log_local7.  But guess where the tap really logs?  log_local1.  
  14361.  
  14362. >So it would appear that setting the facility for a tap user doesn't work,
  14363. >and that it uses the facility of the arc instead.  Is this the way things
  14364. >are supposed to work? If so what is the facility for a tap user for?
  14365.  
  14366. >ARC code is 4.1.59-6.
  14367.  
  14368. Hrmm...4.1.59-2 got this right.  I have normal syslogs going to
  14369. log_local3 and tap's going to log_local6.  Works like a charm here.
  14370. -- 
  14371. Jeff McAdams                            Email: jeffm@iglou.com
  14372. Head Network Administrator              Voice: (502) 966-3848
  14373. IgLou Internet Services                        (800) 436-4456
  14374.  
  14375. -
  14376.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14377.  with "unsubscribe usr-tc" in the body of the message.
  14378.  For information on digests or retrieving files and old messages send
  14379.  "help" to the same address.  Do not use quotes in your message.
  14380.  
  14381.  
  14382. -------------------------------------------------------------------------------
  14383.  
  14384. From: K Mitchell <mitch@keyconn.net>
  14385. Subject: Re: (usr-tc) strange LIST CONN
  14386. Date: 15 Apr 1999 20:27:03 -0400
  14387.  
  14388. At 06:20 PM 4/15/99 -0500, Brian wrote:
  14389. >> 
  14390. >>   I've seen the same thing through every code revision I've had. The
  14391. >> sequence appears to be:  DIALIN INVALID 00-   -0000    00:00:00, then the
  14392. >> session start time is added, then changes to DIALIN PPP, then the user ID
  14393. >> is added last.
  14394. >> AFAIK it's nothing to be concerned about.
  14395. >
  14396. >Well what it was, is that I saw modems in it nonstop.  Which is kinda neat
  14397. >cause it shows you a modem that won't handshake.  I software downloaded
  14398. >code to that card again, and it started working fine.  So if you ever see
  14399. >that string non-stop I guess thats a sign of a possible bad modem.
  14400.  
  14401. Did <list co> show this continuously, or only when someone was trying to
  14402. connect on that channel?
  14403.  
  14404.  
  14405.  
  14406. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14407. Keystone Connect                http://www.keyconn.net
  14408. Altoona, PA   814-941-5000         We Unlock the World
  14409.  
  14410.  
  14411. -
  14412.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14413.  with "unsubscribe usr-tc" in the body of the message.
  14414.  For information on digests or retrieving files and old messages send
  14415.  "help" to the same address.  Do not use quotes in your message.
  14416.  
  14417.  
  14418. -------------------------------------------------------------------------------
  14419.  
  14420. From: K Mitchell <mitch@keyconn.net>
  14421. Subject: (usr-tc) x2 Status question
  14422. Date: 15 Apr 1999 20:24:56 -0400
  14423.  
  14424.   I have a customer who is unable to connect at higher than 28.8 with his
  14425. "USR 56k/v34 Fax" internal modem, product code 00568700(can't find any more
  14426. specific info). My DSP sees only v34 modulation and channelNoSymbolRate(13)
  14427. under x2 status.
  14428. Any ideas?
  14429.  
  14430. Thanks,
  14431. Kirk
  14432.  
  14433.  
  14434.  
  14435. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14436. Keystone Connect                http://www.keyconn.net
  14437. Altoona, PA   814-941-5000         We Unlock the World
  14438.  
  14439.  
  14440. -
  14441.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14442.  with "unsubscribe usr-tc" in the body of the message.
  14443.  For information on digests or retrieving files and old messages send
  14444.  "help" to the same address.  Do not use quotes in your message.
  14445.  
  14446.  
  14447. -------------------------------------------------------------------------------
  14448.  
  14449. From: Mike Andrews <mandrews@termfrost.org>
  14450. Subject: Re: (usr-tc) x2 Status question
  14451. Date: 15 Apr 1999 20:47:27 -0400 (EDT)
  14452.  
  14453. That's probably "channel can't support 3200 symbol rate"...  it's the
  14454. user's phone line (or the telco's network serving him), not your end...
  14455. (unless *all* your users are like that)
  14456.  
  14457.  
  14458. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  14459. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  14460. Microsoft operating system is like a dog without a brick tied to its head."
  14461.  
  14462. On Thu, 15 Apr 1999, K Mitchell wrote:
  14463.  
  14464. >   I have a customer who is unable to connect at higher than 28.8 with his
  14465. > "USR 56k/v34 Fax" internal modem, product code 00568700(can't find any more
  14466. > specific info). My DSP sees only v34 modulation and channelNoSymbolRate(13)
  14467. > under x2 status.
  14468. > Any ideas?
  14469. > 
  14470. > Thanks,
  14471. > Kirk
  14472.  
  14473.  
  14474. -
  14475.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14476.  with "unsubscribe usr-tc" in the body of the message.
  14477.  For information on digests or retrieving files and old messages send
  14478.  "help" to the same address.  Do not use quotes in your message.
  14479.  
  14480.  
  14481. -------------------------------------------------------------------------------
  14482.  
  14483. From: "Greg Owens" <gowens@magnolia-net.com>
  14484. Subject: (usr-tc) DSP's per Chassis
  14485. Date: 15 Apr 1999 20:05:07 -0500
  14486.  
  14487. I know some of you have spoke on this this before, but refresh my
  14488. memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do
  14489. most of you feel this is OK to do or is now the time to break that extra
  14490. chassis out of the closet and start filling it. Thanks In advance for your
  14491. suggestions
  14492.         Greg Owens
  14493. Magnolia Internet Services
  14494.  
  14495.  
  14496. -
  14497.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14498.  with "unsubscribe usr-tc" in the body of the message.
  14499.  For information on digests or retrieving files and old messages send
  14500.  "help" to the same address.  Do not use quotes in your message.
  14501.  
  14502.  
  14503. -------------------------------------------------------------------------------
  14504.  
  14505. From: Brian <signal@shreve.net>
  14506. Subject: Re: (usr-tc) strange LIST CONN
  14507. Date: 15 Apr 1999 21:09:19 -0500 (CDT)
  14508.  
  14509. On Thu, 15 Apr 1999, K Mitchell wrote:
  14510.  
  14511. > At 06:20 PM 4/15/99 -0500, Brian wrote:
  14512. > >> 
  14513. > >>   I've seen the same thing through every code revision I've had. The
  14514. > >> sequence appears to be:  DIALIN INVALID 00-   -0000    00:00:00, then the
  14515. > >> session start time is added, then changes to DIALIN PPP, then the user ID
  14516. > >> is added last.
  14517. > >> AFAIK it's nothing to be concerned about.
  14518. > >
  14519. > >Well what it was, is that I saw modems in it nonstop.  Which is kinda neat
  14520. > >cause it shows you a modem that won't handshake.  I software downloaded
  14521. > >code to that card again, and it started working fine.  So if you ever see
  14522. > >that string non-stop I guess thats a sign of a possible bad modem.
  14523. > 
  14524. > Did <list co> show this continuously, or only when someone was trying to
  14525. > connect on that channel?
  14526.  
  14527. well we were on first available hunting on a busy chassis, so it looked
  14528. continous since it was always being hit by someone
  14529.  
  14530.  
  14531. > 
  14532. > 
  14533. > 
  14534. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14535. > Keystone Connect                http://www.keyconn.net
  14536. > Altoona, PA   814-941-5000         We Unlock the World
  14537. > 
  14538. > 
  14539. > -
  14540. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14541. >  with "unsubscribe usr-tc" in the body of the message.
  14542. >  For information on digests or retrieving files and old messages send
  14543. >  "help" to the same address.  Do not use quotes in your message.
  14544. > 
  14545.  
  14546. Brian Feeny (BF304)     signal@shreve.net   
  14547. 318-222-2638 x 109    http://www.shreve.net/~signal      
  14548. Network Administrator   ShreveNet Inc. (ASN 11881)           
  14549.  
  14550.  
  14551. -
  14552.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14553.  with "unsubscribe usr-tc" in the body of the message.
  14554.  For information on digests or retrieving files and old messages send
  14555.  "help" to the same address.  Do not use quotes in your message.
  14556.  
  14557.  
  14558. -------------------------------------------------------------------------------
  14559.  
  14560. From: Ronald Kushner <ron@glis.net>
  14561. Subject: Re: (usr-tc) off-hook here, off-hook there?
  14562. Date: 15 Apr 1999 23:23:57 -0400
  14563.  
  14564.  
  14565.  
  14566. Ray Bagby wrote:
  14567.  
  14568. > Hi Ron, thanks for replying,
  14569. >     No, it's not a local call for the folks there, in fact they're in
  14570. > another area code and the company involved is pretty small. We finally did
  14571. > resolve the problem though. Seems that setting the "Dial In Address" to 'no
  14572. > address' took care of it. Now the question is: what happened Sunday
  14573. > afternoon to change things? I checked the hard copy of the settings against
  14574. > the settings after the problems started and nothing changed here. I guess I
  14575. > should just be happy things are working again. ;-)
  14576. >     Thanks again... ray
  14577.  
  14578. Wow, cool. It is possiable that the long distance telco might not have been billing
  14579. customers for calling your equipment and they caught it, or they upgraded thier
  14580. switch. Apperantly whatever the DNIS was doing, it confused the network to think as if
  14581. the call was never answered.
  14582.  
  14583. Hmm, you might have been sending an additional wink across the trunk - dunno what that
  14584. does. I never thought about it, but the trunks delivered by the telcos might have some
  14585. strange security loopholes, since they were designed to talk to other switches. 
  14586.  
  14587. -Ron
  14588. GLISnet, Inc.
  14589. +1 810/939.9885
  14590.  
  14591. -
  14592.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14593.  with "unsubscribe usr-tc" in the body of the message.
  14594.  For information on digests or retrieving files and old messages send
  14595.  "help" to the same address.  Do not use quotes in your message.
  14596.  
  14597.  
  14598. -------------------------------------------------------------------------------
  14599.  
  14600. From: "Rob Bachta" <Rob_Bachta@mw.3com.com>
  14601. Subject: Re: (usr-tc) x2 Status question
  14602. Date: 16 Apr 1999 00:08:50 -0700
  14603.  
  14604.  
  14605.  
  14606. Hello Kirk,
  14607.  
  14608. The x2Status <channelNoSymbolRate> can mean a few things :
  14609.  
  14610. 1.  The line the user dialed from did not support a symbol rate of a least
  14611. 3200, which is required for a x2/v.90 connection.  If this is the case, they
  14612. probably made a 3000 symbol rate v.34 connection at 26400bps, or lower.  A
  14613. client that can not obtain a 3200 symbol rate, can indicate an impairment on
  14614. that line.  These may be of a temporary nature, like an electrical storm, but
  14615. might also be a noisy line due to wiring, faulty handset plugged into the
  14616. modems phone port, long loop length, or numerous other reasons.
  14617.  
  14618. Is this client seeing this every time or randomly?
  14619. Are they making a v.34 or v.34+ connection?
  14620. What is the symbol rate for this call?
  14621. Have them check <Extra Settings> and look for a AT command that a 'friend of a
  14622. friend' says worked great him.
  14623.  
  14624. 2. It is possible to see this status when a client initially makes a v.90/x2
  14625. connection, but later during the call falls back to v.34, because line
  14626. conditions have changed.  To check for this type of condition, look at the
  14627. initial connection rate to see if it is greater than 33600, or 33333 which would
  14628. indicate a v.90/x2 connection.
  14629.  
  14630. 3. The client side modem disabled 3429 & 3200 symbol rates.
  14631.  
  14632. 4. The TC modem had 3429 & 3200 symbol rates disabled.
  14633.  
  14634. I am working on adding the x2Status messages, and possible meanings to the
  14635. x2shoot4.pdf document currently on TotalService.  I guess I need to try harder
  14636. ;)
  14637.  
  14638. Regards,
  14639. Rob
  14640.  
  14641.  
  14642.  
  14643.  
  14644.  
  14645.  
  14646. K Mitchell <mitch@keyconn.net> on 04/15/99 05:24:56 PM
  14647.  
  14648. Please respond to usr-tc@lists.xmission.com
  14649.  
  14650. cc:    (Rob Bachta/MW/US/3Com)
  14651.  
  14652.  
  14653.  
  14654.  
  14655.   I have a customer who is unable to connect at higher than 28.8 with his
  14656. "USR 56k/v34 Fax" internal modem, product code 00568700(can't find any more
  14657. specific info). My DSP sees only v34 modulation and channelNoSymbolRate(13)
  14658. under x2 status.
  14659. Any ideas?
  14660.  
  14661. Thanks,
  14662. Kirk
  14663.  
  14664.  
  14665.  
  14666. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14667. Keystone Connect                http://www.keyconn.net
  14668. Altoona, PA   814-941-5000         We Unlock the World
  14669.  
  14670.  
  14671. -
  14672.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14673.  with "unsubscribe usr-tc" in the body of the message.
  14674.  For information on digests or retrieving files and old messages send
  14675.  "help" to the same address.  Do not use quotes in your message.
  14676.  
  14677.  
  14678.  
  14679.  
  14680.  
  14681.  
  14682.  
  14683.  
  14684. -
  14685.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14686.  with "unsubscribe usr-tc" in the body of the message.
  14687.  For information on digests or retrieving files and old messages send
  14688.  "help" to the same address.  Do not use quotes in your message.
  14689.  
  14690.  
  14691. -------------------------------------------------------------------------------
  14692.  
  14693. From: Aaron Nabil <nabil@spiritone.com>
  14694. Subject: Re: (usr-tc) Filters
  14695. Date: 15 Apr 1999 23:37:01 -0700 (PDT)
  14696.  
  14697. Brian writes...
  14698. >On Thu, 15 Apr 1999, Aaron Nabil wrote:
  14699. >
  14700. >> Brian writes...
  14701. >> >On Thu, 15 Apr 1999, Paul Farber wrote:
  14702. >> >
  14703. >> >>  . . .
  14704. >> >> I know there is a way to assign filters via RADIUS for each caller, but
  14705. >> >> all I want to make sure I only send/recieve packets with their IP as the
  14706. >> >> originating/destination.. ie kill spoofers, keep alive pings etc.
  14707. >> >
  14708. >> >they can still spoof any ip's in 207.44.65.0............
  14709. >> >
  14710. >> >Using a RADIUS that supports "hint assigned" such as RADIATOR
  14711. >> >(http://www.open.com.au/radiator/) will assign each user a dynamic filter
  14712. >> >such that it blocks everything but their ip and netmask.
  14713. >> 
  14714. >> Way overkill.  Just enable the built-in anti-spoofing code, it'll
  14715. >> check the source address matches the assigned address.  It's documented
  14716. >> in the latest hiperarc release notes.
  14717. >
  14718. >The problem with that code though, if I remember right, is that it always
  14719. >assumes a subnet mask of 255.255.255.255 does it not?
  14720.  
  14721. Might be, but since that's what all of my subnet masks are, it's
  14722. never been a problem. :)
  14723.  
  14724.  
  14725. -- 
  14726. Aaron Nabil
  14727.  
  14728. -
  14729.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14730.  with "unsubscribe usr-tc" in the body of the message.
  14731.  For information on digests or retrieving files and old messages send
  14732.  "help" to the same address.  Do not use quotes in your message.
  14733.  
  14734.  
  14735. -------------------------------------------------------------------------------
  14736.  
  14737. From: Paul Farber <farber@admin.f-tech.net>
  14738. Subject: Re: (usr-tc) DSP's per Chassis
  14739. Date: 16 Apr 1999 09:32:54 -0400 (EDT)
  14740.  
  14741. Has 3com fixed thier Multi chassis PPP problem yet?  The old netserver and
  14742. even some of the ARC code from the past would not do multilink accross
  14743. chassis.  If this is a concern (for ISDN cust.) you may want to make sure
  14744. that you have the code that remedies this.
  14745.  
  14746. Paul D. Farber II
  14747. Farber Technology
  14748. Ph. 570-628-5303
  14749. Fax 570-628-5545
  14750. farber@admin.f-tech.net
  14751.  
  14752. On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  14753.  
  14754. > we currently has a chasis with 10 DSP's and it's been working fine since
  14755. > november 1998 ... we are about to split it up between 2 chassis though just
  14756. > to be safe though ...
  14757. > 
  14758. > -----Original Message-----
  14759. > From: Greg Owens <gowens@magnolia-net.com>
  14760. > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  14761. > Date: Thursday, April 15, 1999 9:05 PM
  14762. > Subject: (usr-tc) DSP's per Chassis
  14763. > 
  14764. > 
  14765. > >I know some of you have spoke on this this before, but refresh my
  14766. > >memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do
  14767. > >most of you feel this is OK to do or is now the time to break that extra
  14768. > >chassis out of the closet and start filling it. Thanks In advance for your
  14769. > >suggestions
  14770. > >        Greg Owens
  14771. > >Magnolia Internet Services
  14772. > >
  14773. > >
  14774. > >-
  14775. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14776. > > with "unsubscribe usr-tc" in the body of the message.
  14777. > > For information on digests or retrieving files and old messages send
  14778. > > "help" to the same address.  Do not use quotes in your message.
  14779. > >
  14780. > >
  14781. > 
  14782. > 
  14783. > -
  14784. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14785. >  with "unsubscribe usr-tc" in the body of the message.
  14786. >  For information on digests or retrieving files and old messages send
  14787. >  "help" to the same address.  Do not use quotes in your message.
  14788. > 
  14789.  
  14790.  
  14791. -
  14792.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14793.  with "unsubscribe usr-tc" in the body of the message.
  14794.  For information on digests or retrieving files and old messages send
  14795.  "help" to the same address.  Do not use quotes in your message.
  14796.  
  14797.  
  14798. -------------------------------------------------------------------------------
  14799.  
  14800. From: Jeff Mcadams <jeffm@iglou.com>
  14801. Subject: Re: (usr-tc) DSP's per Chassis
  14802. Date: 16 Apr 1999 09:48:35 -0400 (EDT)
  14803.  
  14804. Thus spake Paul Farber
  14805. >Has 3com fixed thier Multi chassis PPP problem yet?  The old netserver
  14806. >and even some of the ARC code from the past would not do multilink
  14807. >accross chassis.  If this is a concern (for ISDN cust.) you may want to
  14808. >make sure that you have the code that remedies this.
  14809.  
  14810. The NETServer is still as broken as ever, and because of licensing
  14811. reasons, will stay that way.  The only way out of that quagmire is to
  14812. annoy 3Com enough until they agree to do the right thing and replace
  14813. NETServers that are being used in Multi-Chassis MultiLink scenarios with
  14814. Arcs.  So far, 3Com has not shown any inclination to avoid screwing over
  14815. their customers though (in this situation, and in others)...we'll see
  14816. what comes of it.  (Kurtiss, I never heard back from you about this
  14817. either ;)
  14818.  
  14819. With respect to Arcs, I haven't found any glaring problems with
  14820. Multi-Chassis Multilink on them yet.  We're still fairly new to them and
  14821. still working out some minor issues with them...nothing major, mostly
  14822. just still figuring out how they work in depth.  They seem to be pretty
  14823. solid though.  (4.1.59-2 fwiw)
  14824.  
  14825. >On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  14826. >> we currently has a chasis with 10 DSP's and it's been working fine
  14827. >> since november 1998 ... we are about to split it up between 2 chassis
  14828. >> though just to be safe though ...
  14829. -- 
  14830. Jeff McAdams                            Email: jeffm@iglou.com
  14831. Head Network Administrator              Voice: (502) 966-3848
  14832. IgLou Internet Services                        (800) 436-4456
  14833.  
  14834. -
  14835.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14836.  with "unsubscribe usr-tc" in the body of the message.
  14837.  For information on digests or retrieving files and old messages send
  14838.  "help" to the same address.  Do not use quotes in your message.
  14839.  
  14840.  
  14841. -------------------------------------------------------------------------------
  14842.  
  14843. From: K Mitchell <mitch@keyconn.net>
  14844. Subject: Re: (usr-tc) x2 Status question
  14845. Date: 16 Apr 1999 09:55:07 -0400
  14846.  
  14847. At 12:08 AM 4/16/99 -0700, you wrote:
  14848. >
  14849. >Is this client seeing this every time or randomly?
  14850. >Are they making a v.34 or v.34+ connection?
  14851. >What is the symbol rate for this call?
  14852. >Have them check <Extra Settings> and look for a AT command that a 'friend
  14853. of a
  14854. >friend' says worked great him.
  14855. >
  14856. >2. It is possible to see this status when a client initially makes a v.90/x2
  14857. >connection, but later during the call falls back to v.34, because line
  14858. >conditions have changed.  To check for this type of condition, look at the
  14859. >initial connection rate to see if it is greater than 33600, or 33333 which
  14860. would
  14861. >indicate a v.90/x2 connection.
  14862.  
  14863. Each time I've looked  at his connection, it was a straight v34 connection
  14864. with 28.8 initial and current connection speeds.
  14865.  
  14866. >3. The client side modem disabled 3429 & 3200 symbol rates.
  14867.  
  14868. How would I determine this?
  14869.  
  14870. >4. The TC modem had 3429 & 3200 symbol rates disabled.
  14871.  
  14872. I don't think this would be the case, as I'm seeing plenty of successful
  14873. v90 and x2 connections with appropriate connection speeds.
  14874.  
  14875. >I am working on adding the x2Status messages, and possible meanings to the
  14876. >x2shoot4.pdf document currently on TotalService.  I guess I need to try
  14877. harder
  14878.  
  14879. Thanks,
  14880. Kirk
  14881.  
  14882.  
  14883.  
  14884. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14885. Keystone Connect                http://www.keyconn.net
  14886. Altoona, PA   814-941-5000         We Unlock the World
  14887.  
  14888.  
  14889. -
  14890.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14891.  with "unsubscribe usr-tc" in the body of the message.
  14892.  For information on digests or retrieving files and old messages send
  14893.  "help" to the same address.  Do not use quotes in your message.
  14894.  
  14895.  
  14896. -------------------------------------------------------------------------------
  14897.  
  14898. From: "Jamie Orzechowski" <mhz@ripnet.com>
  14899. Subject: Re: (usr-tc) DSP's per Chassis
  14900. Date: 16 Apr 1999 09:56:59 -0400
  14901.  
  14902. multi chassis multilink?? I now have 2 arc's and was wondering how I can set
  14903. this up??
  14904.  
  14905.  
  14906. ----- Original Message -----
  14907. Sent: Friday, April 16, 1999 9:48 AM
  14908.  
  14909.  
  14910. > Thus spake Paul Farber
  14911. > >Has 3com fixed thier Multi chassis PPP problem yet?  The old netserver
  14912. > >and even some of the ARC code from the past would not do multilink
  14913. > >accross chassis.  If this is a concern (for ISDN cust.) you may want to
  14914. > >make sure that you have the code that remedies this.
  14915. >
  14916. > The NETServer is still as broken as ever, and because of licensing
  14917. > reasons, will stay that way.  The only way out of that quagmire is to
  14918. > annoy 3Com enough until they agree to do the right thing and replace
  14919. > NETServers that are being used in Multi-Chassis MultiLink scenarios with
  14920. > Arcs.  So far, 3Com has not shown any inclination to avoid screwing over
  14921. > their customers though (in this situation, and in others)...we'll see
  14922. > what comes of it.  (Kurtiss, I never heard back from you about this
  14923. > either ;)
  14924. >
  14925. > With respect to Arcs, I haven't found any glaring problems with
  14926. > Multi-Chassis Multilink on them yet.  We're still fairly new to them and
  14927. > still working out some minor issues with them...nothing major, mostly
  14928. > just still figuring out how they work in depth.  They seem to be pretty
  14929. > solid though.  (4.1.59-2 fwiw)
  14930. >
  14931. > >On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  14932. > >> we currently has a chasis with 10 DSP's and it's been working fine
  14933. > >> since november 1998 ... we are about to split it up between 2 chassis
  14934. > >> though just to be safe though ...
  14935. > --
  14936. > Jeff McAdams                            Email: jeffm@iglou.com
  14937. > Head Network Administrator              Voice: (502) 966-3848
  14938. > IgLou Internet Services                        (800) 436-4456
  14939. >
  14940. > -
  14941. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14942. >  with "unsubscribe usr-tc" in the body of the message.
  14943. >  For information on digests or retrieving files and old messages send
  14944. >  "help" to the same address.  Do not use quotes in your message.
  14945. >
  14946. >
  14947.  
  14948.  
  14949. -
  14950.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14951.  with "unsubscribe usr-tc" in the body of the message.
  14952.  For information on digests or retrieving files and old messages send
  14953.  "help" to the same address.  Do not use quotes in your message.
  14954.  
  14955.  
  14956. -------------------------------------------------------------------------------
  14957.  
  14958. From: K Mitchell <mitch@keyconn.net>
  14959. Subject: Re: (usr-tc) DSP's per Chassis
  14960. Date: 16 Apr 1999 10:04:59 -0400
  14961.  
  14962. At 08:05 PM 4/15/99 -0500, you wrote:
  14963. >I know some of you have spoke on this this before, but refresh my
  14964. >memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do
  14965. >most of you feel this is OK to do or is now the time to break that extra
  14966. >chassis out of the closet and start filling it. Thanks In advance for your
  14967. >suggestions
  14968.  
  14969. On a somewhat related note, currently my chassis is:
  14970. 14      YES          24 Channel High Density Modem    23      DYNAMIC NO
  14971. 15      YES          24 Channel High Density Modem    23      DYNAMIC NO
  14972. 16      YES          HiPer Access Router NAC          0       DYNAMIC NO
  14973. 17          NMC
  14974. with slots 1-13 empty. This is how it came. I'll be adding 1 or 2 DSPs
  14975. shortly and want to place them in slots 3 & 4, while moving 14 & 15 to 1 &
  14976. 2 respectively. Is there anything I need to do to make sure the cards
  14977. retain their setting as I move them and the chassis recognizes them in
  14978. their new home? Chassis awareness is enabled.
  14979.  
  14980. Thanks again,
  14981. Kirk
  14982.  
  14983.  
  14984.  
  14985. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  14986. Keystone Connect                http://www.keyconn.net
  14987. Altoona, PA   814-941-5000         We Unlock the World
  14988.  
  14989.  
  14990. -
  14991.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14992.  with "unsubscribe usr-tc" in the body of the message.
  14993.  For information on digests or retrieving files and old messages send
  14994.  "help" to the same address.  Do not use quotes in your message.
  14995.  
  14996.  
  14997. -------------------------------------------------------------------------------
  14998.  
  14999. From: Chris <helpchris@rconnect.com>
  15000. Subject: (usr-tc) Re: off-hook here, off-hook there?
  15001. Date: 16 Apr 1999 09:37:01 -0500
  15002.  
  15003. I had a similar problem, only both my telco and my customer's telco are
  15004. both small independents and it is a local call for my customer to call my
  15005. equipment. It was dropping the call after about 5 minutes. I set the Dial
  15006. in Address to noAddress and it fixed the problem that I have been pushing
  15007. on both telco's to fix for over a month. I'm don't know why it fixed it,
  15008. but it did. Would be nice to know why it fixed it. They are both on DMS100
  15009. and they are T1 not PRI.
  15010.  
  15011. Chris Henderson
  15012. Rural Connections ~ Information Services
  15013. http://www.rconnect.com
  15014.  
  15015. >
  15016. >----------------------------------------------------------------------
  15017. >
  15018. >Date: Thu, 15 Apr 1999 23:23:57 -0400
  15019. >From: Ronald Kushner <ron@glis.net>
  15020. >Subject: Re: (usr-tc) off-hook here, off-hook there?
  15021. >
  15022. >Ray Bagby wrote:
  15023. >
  15024. >> Hi Ron, thanks for replying,
  15025. >>     No, it's not a local call for the folks there, in fact they're in
  15026. >> another area code and the company involved is pretty small. We finally did
  15027. >> resolve the problem though. Seems that setting the "Dial In Address" to 'no
  15028. >> address' took care of it. Now the question is: what happened Sunday
  15029. >> afternoon to change things? I checked the hard copy of the settings against
  15030. >> the settings after the problems started and nothing changed here. I guess I
  15031. >> should just be happy things are working again. ;-)
  15032. >>     Thanks again... ray
  15033. >
  15034. >Wow, cool. It is possiable that the long distance telco might not have been 
  15035. >billing
  15036. >customers for calling your equipment and they caught it, or they upgraded
  15037. thier
  15038. >switch. Apperantly whatever the DNIS was doing, it confused the network to 
  15039. >think as if
  15040. >the call was never answered.
  15041. >
  15042. >Hmm, you might have been sending an additional wink across the trunk - dunno 
  15043. >what that
  15044. >does. I never thought about it, but the trunks delivered by the telcos might 
  15045. >have some
  15046. >strange security loopholes, since they were designed to talk to other 
  15047. >switches. 
  15048. >
  15049. >- -Ron
  15050. >GLISnet, Inc.
  15051. >+1 810/939.9885
  15052. >
  15053.  
  15054.  
  15055. -
  15056.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15057.  with "unsubscribe usr-tc" in the body of the message.
  15058.  For information on digests or retrieving files and old messages send
  15059.  "help" to the same address.  Do not use quotes in your message.
  15060.  
  15061.  
  15062. -------------------------------------------------------------------------------
  15063.  
  15064. From: Brian <signal@shreve.net>
  15065. Subject: Re: (usr-tc) Filters
  15066. Date: 16 Apr 1999 09:48:12 -0500 (CDT)
  15067.  
  15068.  
  15069. > >The problem with that code though, if I remember right, is that it always
  15070. > >assumes a subnet mask of 255.255.255.255 does it not?
  15071. > 
  15072. > Might be, but since that's what all of my subnet masks are, it's
  15073. > never been a problem. :)
  15074.  
  15075. nod.  Alot of isp's route /28's and whatnot to customers and so this isn't
  15076. a great thing for them.
  15077.  
  15078. I would really like to see 3Com expand the functionality to include the
  15079. appropriate netmask on the filter.  All the information is their, so they
  15080. just have to use it.  They could use framed-route as well.  It would be
  15081. great to have something like this built into the NAS and then we wouldn't
  15082. have to worry about building dynamic filters in RADIUS.  The bigger you
  15083. are the more of a problem it is, with users spoofing and playing games and
  15084. that taking up more of your admins time.  I am glad 3Com is moving in the
  15085. direction where they have this capibility, I just think it can be polished
  15086. a bit more, but I am patient :)
  15087.  
  15088.  
  15089. > 
  15090. > 
  15091. > -- 
  15092. > Aaron Nabil
  15093. > 
  15094. > -
  15095. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15096. >  with "unsubscribe usr-tc" in the body of the message.
  15097. >  For information on digests or retrieving files and old messages send
  15098. >  "help" to the same address.  Do not use quotes in your message.
  15099. > 
  15100.  
  15101. Brian Feeny (BF304)     signal@shreve.net   
  15102. 318-222-2638 x 109    http://www.shreve.net/~signal      
  15103. Network Administrator   ShreveNet Inc. (ASN 11881)           
  15104.  
  15105.  
  15106. -
  15107.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15108.  with "unsubscribe usr-tc" in the body of the message.
  15109.  For information on digests or retrieving files and old messages send
  15110.  "help" to the same address.  Do not use quotes in your message.
  15111.  
  15112.  
  15113. -------------------------------------------------------------------------------
  15114.  
  15115. From: Jeff Mcadams <jeffm@iglou.com>
  15116. Subject: Re: (usr-tc) DSP's per Chassis
  15117. Date: 16 Apr 1999 11:41:01 -0400 (EDT)
  15118.  
  15119. Thus spake Jamie Orzechowski
  15120. >multi chassis multilink?? I now have 2 arc's and was wondering how I
  15121. >can set this up??
  15122.  
  15123. You have to set up MPIP (Multilink PPP Inter-span Protocol I think is
  15124. what that stands for).  Basically, you set up NTP on all your systems to
  15125. make sure their time is synced up, then set up one as an MPIP server,
  15126. set mpip server_state on, add mpip client <ip address of MPIP client>
  15127. sharedsecret <mpip sharedsecret> type hiper, (be sure to add the MPIP
  15128. server as a client of itself), then on the MPIP client machines, you do
  15129. add mpip server <ip address of mpip server> sharedsecret <mpip shared
  15130. secret> priority 1.
  15131.  
  15132. You add mpip client entries on the mpip server for each of your mpip
  15133. clients, and on each mpip client add the mpip server entry.  Then
  15134. they'll cooperate when they get multi-link calls and everything should
  15135. just work.  :)
  15136.  
  15137. Do make sure you have ntp set up and enabled though as the times on the
  15138. systems have to be within a few seconds of each other for them to be
  15139. able to do this trick.  :)
  15140.  
  15141. >> Thus spake Paul Farber
  15142. >> >Has 3com fixed thier Multi chassis PPP problem yet?  The old
  15143. >> >netserver and even some of the ARC code from the past would not do
  15144. >> >multilink accross chassis.  If this is a concern (for ISDN cust.)
  15145. >> >you may want to make sure that you have the code that remedies this.
  15146. >>
  15147. >> The NETServer is still as broken as ever, and because of licensing
  15148. >> reasons, will stay that way.  The only way out of that quagmire is to
  15149. >> annoy 3Com enough until they agree to do the right thing and replace
  15150. >> NETServers that are being used in Multi-Chassis MultiLink scenarios
  15151. >> with Arcs.  So far, 3Com has not shown any inclination to avoid
  15152. >> screwing over their customers though (in this situation, and in
  15153. >> others)...we'll see what comes of it.  (Kurtiss, I never heard back
  15154. >> from you about this either ;)
  15155. >>
  15156. >> With respect to Arcs, I haven't found any glaring problems with
  15157. >> Multi-Chassis Multilink on them yet.  We're still fairly new to them
  15158. >> and still working out some minor issues with them...nothing major,
  15159. >> mostly just still figuring out how they work in depth.  They seem to
  15160. >> be pretty solid though.  (4.1.59-2 fwiw)
  15161. >>
  15162. >> >On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  15163. >> >> we currently has a chasis with 10 DSP's and it's been working fine
  15164. >> >> since november 1998 ... we are about to split it up between 2
  15165. >> >> chassis though just to be safe though ...
  15166. -- 
  15167. Jeff McAdams                            Email: jeffm@iglou.com
  15168. Head Network Administrator              Voice: (502) 966-3848
  15169. IgLou Internet Services                        (800) 436-4456
  15170.  
  15171. -
  15172.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15173.  with "unsubscribe usr-tc" in the body of the message.
  15174.  For information on digests or retrieving files and old messages send
  15175.  "help" to the same address.  Do not use quotes in your message.
  15176.  
  15177.  
  15178. -------------------------------------------------------------------------------
  15179.  
  15180. From: Paul Farber <farber@admin.f-tech.net>
  15181. Subject: Re: (usr-tc) DSP's per Chassis
  15182. Date: 16 Apr 1999 12:02:23 -0400 (EDT)
  15183.  
  15184. Why do I have a sneaky feeling that doing multi chassis multi link PPP is
  15185. WAY simpler on other RAS racks?
  15186.  
  15187. It seems that this is a workaround to a problem that 3Com has yet to
  15188. properly address.
  15189.  
  15190. Paul D. Farber II
  15191. Farber Technology
  15192. Ph. 570-628-5303
  15193. Fax 570-628-5545
  15194. farber@admin.f-tech.net
  15195.  
  15196. On Fri, 16 Apr 1999, Jeff Mcadams wrote:
  15197.  
  15198. > Thus spake Jamie Orzechowski
  15199. > >multi chassis multilink?? I now have 2 arc's and was wondering how I
  15200. > >can set this up??
  15201. > 
  15202. > You have to set up MPIP (Multilink PPP Inter-span Protocol I think is
  15203. > what that stands for).  Basically, you set up NTP on all your systems to
  15204. > make sure their time is synced up, then set up one as an MPIP server,
  15205. > set mpip server_state on, add mpip client <ip address of MPIP client>
  15206. > sharedsecret <mpip sharedsecret> type hiper, (be sure to add the MPIP
  15207. > server as a client of itself), then on the MPIP client machines, you do
  15208. > add mpip server <ip address of mpip server> sharedsecret <mpip shared
  15209. > secret> priority 1.
  15210. > 
  15211. > You add mpip client entries on the mpip server for each of your mpip
  15212. > clients, and on each mpip client add the mpip server entry.  Then
  15213. > they'll cooperate when they get multi-link calls and everything should
  15214. > just work.  :)
  15215. > 
  15216. > Do make sure you have ntp set up and enabled though as the times on the
  15217. > systems have to be within a few seconds of each other for them to be
  15218. > able to do this trick.  :)
  15219. > 
  15220. > >> Thus spake Paul Farber
  15221. > >> >Has 3com fixed thier Multi chassis PPP problem yet?  The old
  15222. > >> >netserver and even some of the ARC code from the past would not do
  15223. > >> >multilink accross chassis.  If this is a concern (for ISDN cust.)
  15224. > >> >you may want to make sure that you have the code that remedies this.
  15225. > >>
  15226. > >> The NETServer is still as broken as ever, and because of licensing
  15227. > >> reasons, will stay that way.  The only way out of that quagmire is to
  15228. > >> annoy 3Com enough until they agree to do the right thing and replace
  15229. > >> NETServers that are being used in Multi-Chassis MultiLink scenarios
  15230. > >> with Arcs.  So far, 3Com has not shown any inclination to avoid
  15231. > >> screwing over their customers though (in this situation, and in
  15232. > >> others)...we'll see what comes of it.  (Kurtiss, I never heard back
  15233. > >> from you about this either ;)
  15234. > >>
  15235. > >> With respect to Arcs, I haven't found any glaring problems with
  15236. > >> Multi-Chassis Multilink on them yet.  We're still fairly new to them
  15237. > >> and still working out some minor issues with them...nothing major,
  15238. > >> mostly just still figuring out how they work in depth.  They seem to
  15239. > >> be pretty solid though.  (4.1.59-2 fwiw)
  15240. > >>
  15241. > >> >On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  15242. > >> >> we currently has a chasis with 10 DSP's and it's been working fine
  15243. > >> >> since november 1998 ... we are about to split it up between 2
  15244. > >> >> chassis though just to be safe though ...
  15245. > -- 
  15246. > Jeff McAdams                            Email: jeffm@iglou.com
  15247. > Head Network Administrator              Voice: (502) 966-3848
  15248. > IgLou Internet Services                        (800) 436-4456
  15249. > 
  15250. > -
  15251. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15252. >  with "unsubscribe usr-tc" in the body of the message.
  15253. >  For information on digests or retrieving files and old messages send
  15254. >  "help" to the same address.  Do not use quotes in your message.
  15255. > 
  15256.  
  15257.  
  15258. -
  15259.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15260.  with "unsubscribe usr-tc" in the body of the message.
  15261.  For information on digests or retrieving files and old messages send
  15262.  "help" to the same address.  Do not use quotes in your message.
  15263.  
  15264.  
  15265. -------------------------------------------------------------------------------
  15266.  
  15267. From: Robert von Bismarck <rvb@petrel.ch>
  15268. Subject: RE: (usr-tc) DSP's per Chassis
  15269. Date: 16 Apr 1999 17:56:13 +0200
  15270.  
  15271. The ARC 4.1.72-7 has a very nasty memory leak when doing Multi-chassis PPP,
  15272. I recommend upgrading to 4.1.59-2. This is the only problem we have seen so
  15273. far, not very much demand for it though...
  15274.  
  15275. Cheers,
  15276.  
  15277. Robert
  15278.  
  15279.  
  15280.     -----Original Message-----
  15281.     From:    Paul Farber [SMTP:farber@admin.f-tech.net]
  15282.     Sent:    vendredi, 16. avril 1999 15:33
  15283.     To:    usr-tc@lists.xmission.com
  15284.     Subject:    Re: (usr-tc) DSP's per Chassis
  15285.  
  15286.     Has 3com fixed thier Multi chassis PPP problem yet?  The old
  15287. netserver and
  15288.     even some of the ARC code from the past would not do multilink
  15289. accross
  15290.     chassis.  If this is a concern (for ISDN cust.) you may want to make
  15291. sure
  15292.     that you have the code that remedies this.
  15293.  
  15294.     Paul D. Farber II
  15295.     Farber Technology
  15296.     Ph. 570-628-5303
  15297.     Fax 570-628-5545
  15298.     farber@admin.f-tech.net
  15299.  
  15300.     On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  15301.  
  15302.     > we currently has a chasis with 10 DSP's and it's been working fine
  15303. since
  15304.     > november 1998 ... we are about to split it up between 2 chassis
  15305. though just
  15306.     > to be safe though ...
  15307.     > 
  15308.     > -----Original Message-----
  15309.     > From: Greg Owens <gowens@magnolia-net.com>
  15310.     > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  15311.     > Date: Thursday, April 15, 1999 9:05 PM
  15312.     > Subject: (usr-tc) DSP's per Chassis
  15313.     > 
  15314.     > 
  15315.     > >I know some of you have spoke on this this before, but refresh my
  15316.     > >memory....We are about to add our 8th DSP card to our HyperArc
  15317. Chassis. Do
  15318.     > >most of you feel this is OK to do or is now the time to break
  15319. that extra
  15320.     > >chassis out of the closet and start filling it. Thanks In advance
  15321. for your
  15322.     > >suggestions
  15323.     > >        Greg Owens
  15324.     > >Magnolia Internet Services
  15325.     > >
  15326.     > >
  15327.     > >-
  15328.     > > To unsubscribe to usr-tc, send an email to
  15329. "majordomo@xmission.com"
  15330.     > > with "unsubscribe usr-tc" in the body of the message.
  15331.     > > For information on digests or retrieving files and old messages
  15332. send
  15333.     > > "help" to the same address.  Do not use quotes in your message.
  15334.     > >
  15335.     > >
  15336.     > 
  15337.     > 
  15338.     > -
  15339.     >  To unsubscribe to usr-tc, send an email to
  15340. "majordomo@xmission.com"
  15341.     >  with "unsubscribe usr-tc" in the body of the message.
  15342.     >  For information on digests or retrieving files and old messages
  15343. send
  15344.     >  "help" to the same address.  Do not use quotes in your message.
  15345.     > 
  15346.  
  15347.  
  15348.     -
  15349.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15350.      with "unsubscribe usr-tc" in the body of the message.
  15351.      For information on digests or retrieving files and old messages
  15352. send
  15353.      "help" to the same address.  Do not use quotes in your message.
  15354.  
  15355. -
  15356.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15357.  with "unsubscribe usr-tc" in the body of the message.
  15358.  For information on digests or retrieving files and old messages send
  15359.  "help" to the same address.  Do not use quotes in your message.
  15360.  
  15361.  
  15362. -------------------------------------------------------------------------------
  15363.  
  15364. From: Jeff Mcadams <jeffm@iglou.com>
  15365. Subject: Re: (usr-tc) DSP's per Chassis
  15366. Date: 16 Apr 1999 12:04:52 -0400 (EDT)
  15367.  
  15368. Thus spake Paul Farber
  15369. >Why do I have a sneaky feeling that doing multi chassis multi link PPP
  15370. >is WAY simpler on other RAS racks?
  15371.  
  15372. >It seems that this is a workaround to a problem that 3Com has yet to
  15373. >properly address.
  15374.  
  15375. I don't know that its a workaround really...more just a matter of how
  15376. that chose to implement it.  Most other RAS systems use a broadcast'ish
  15377. method of advertising and finding multilink bundles for multi-chassis
  15378. support.  Different strokes for different folks.  Each has plusses and
  15379. minuses (cue MZ's rant about using back-end servers being a "Bad Thing"
  15380. here).
  15381.  
  15382. It *has*, however, taken 3Com a *really* long time to get this to be
  15383. reliable...I don't know how long it did take, or is taking, other RAS
  15384. vendors to get this to be reliable...but I'd be surprised if took them
  15385. that long.  *shrug*
  15386.  
  15387. >On Fri, 16 Apr 1999, Jeff Mcadams wrote:
  15388. >> Thus spake Jamie Orzechowski
  15389. >> >multi chassis multilink?? I now have 2 arc's and was wondering how I
  15390. >> >can set this up??
  15391. >> 
  15392. >> You have to set up MPIP (Multilink PPP Inter-span Protocol I think is
  15393. >> what that stands for).  Basically, you set up NTP on all your systems
  15394. >> to make sure their time is synced up, then set up one as an MPIP
  15395. >> server, set mpip server_state on, add mpip client <ip address of MPIP
  15396. >> client> sharedsecret <mpip sharedsecret> type hiper, (be sure to add
  15397. >> the MPIP server as a client of itself), then on the MPIP client
  15398. >> machines, you do add mpip server <ip address of mpip server>
  15399. >> sharedsecret <mpip shared secret> priority 1.
  15400. >> 
  15401. >> You add mpip client entries on the mpip server for each of your mpip
  15402. >> clients, and on each mpip client add the mpip server entry.  Then
  15403. >> they'll cooperate when they get multi-link calls and everything
  15404. >> should just work.  :)
  15405. >> 
  15406. >> Do make sure you have ntp set up and enabled though as the times on
  15407. >> the systems have to be within a few seconds of each other for them to
  15408. >> be able to do this trick.  :)
  15409. >> 
  15410. >> >> Thus spake Paul Farber
  15411. >> >> >Has 3com fixed thier Multi chassis PPP problem yet?  The old
  15412. >> >> >netserver and even some of the ARC code from the past would not
  15413. >> >> >do multilink accross chassis.  If this is a concern (for ISDN
  15414. >> >> >cust.) you may want to make sure that you have the code that
  15415. >> >> >remedies this.
  15416. >> >>
  15417. >> >> The NETServer is still as broken as ever, and because of licensing
  15418. >> >> reasons, will stay that way.  The only way out of that quagmire is
  15419. >> >> to annoy 3Com enough until they agree to do the right thing and
  15420. >> >> replace NETServers that are being used in Multi-Chassis MultiLink
  15421. >> >> scenarios with Arcs.  So far, 3Com has not shown any inclination
  15422. >> >> to avoid screwing over their customers though (in this situation,
  15423. >> >> and in others)...we'll see what comes of it.  (Kurtiss, I never
  15424. >> >> heard back from you about this either ;)
  15425. >> >>
  15426. >> >> With respect to Arcs, I haven't found any glaring problems with
  15427. >> >> Multi-Chassis Multilink on them yet.  We're still fairly new to
  15428. >> >> them and still working out some minor issues with them...nothing
  15429. >> >> major, mostly just still figuring out how they work in depth.
  15430. >> >> They seem to be pretty solid though.  (4.1.59-2 fwiw)
  15431. >> >>
  15432. >> >> >On Thu, 15 Apr 1999, Jamie Orzechowski wrote:
  15433. >> >> >> we currently has a chasis with 10 DSP's and it's been working
  15434. >> >> >> fine since november 1998 ... we are about to split it up
  15435. >> >> >> between 2 chassis though just to be safe though ...
  15436. -- 
  15437. Jeff McAdams                            Email: jeffm@iglou.com
  15438. Head Network Administrator              Voice: (502) 966-3848
  15439. IgLou Internet Services                        (800) 436-4456
  15440.  
  15441. -
  15442.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15443.  with "unsubscribe usr-tc" in the body of the message.
  15444.  For information on digests or retrieving files and old messages send
  15445.  "help" to the same address.  Do not use quotes in your message.
  15446.  
  15447.  
  15448. -------------------------------------------------------------------------------
  15449.  
  15450. From: Jeff Mcadams <jeffm@iglou.com>
  15451. Subject: Re: (usr-tc) DSP's per Chassis
  15452. Date: 16 Apr 1999 12:06:43 -0400 (EDT)
  15453.  
  15454. Thus spake Robert von Bismarck
  15455. >The ARC 4.1.72-7 has a very nasty memory leak when doing Multi-chassis PPP,
  15456. >I recommend upgrading to 4.1.59-2. This is the only problem we have seen so
  15457. >far, not very much demand for it though...
  15458.  
  15459. Actually, I'd suggest 4.1.59-6, which is the service release.  We're
  15460. only on -2 because -6 apparently (from what I've been able to determine)
  15461. is missing a really teeny, tiny feature, that unfortunately we need, so
  15462. I'm still on -2.  Hopefully, with the next release or SR, I'll catch up with the
  15463. rest of the world, though I'm suspecting that'll be the 4.2 release
  15464. which I proly won't want to touch until at least the second SR of 4.2.
  15465. :/
  15466. -- 
  15467. Jeff McAdams                            Email: jeffm@iglou.com
  15468. Head Network Administrator              Voice: (502) 966-3848
  15469. IgLou Internet Services                        (800) 436-4456
  15470.  
  15471. -
  15472.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15473.  with "unsubscribe usr-tc" in the body of the message.
  15474.  For information on digests or retrieving files and old messages send
  15475.  "help" to the same address.  Do not use quotes in your message.
  15476.  
  15477.  
  15478. -------------------------------------------------------------------------------
  15479.  
  15480. From: Florin_Neamtu@3com.com
  15481. Subject: Re: (usr-tc) Configuring a "silent" TC
  15482. Date: 16 Apr 1999 12:24:28 -0400
  15483.  
  15484.  
  15485.  
  15486. TCM, selecteaza modemul (sau grupul de modeme, selectind LED-ul,-rile
  15487. respective), Program Settings, Line Interface Options , Line interface source
  15488. schimba pe "nic" si salveaza modoficarile
  15489. Did you try :
  15490. TCM: select chanel's LED(s) - "Configure " - "Program Settings" - "Line
  15491. Interface Source" and make sure is set for t1tdm (to use tdm bus,  nic would be
  15492. for NIC call termination).
  15493.  
  15494. Give it a try.
  15495.  
  15496. Regads,
  15497. Florin
  15498.  
  15499.  
  15500.  
  15501. -
  15502.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15503.  with "unsubscribe usr-tc" in the body of the message.
  15504.  For information on digests or retrieving files and old messages send
  15505.  "help" to the same address.  Do not use quotes in your message.
  15506.  
  15507.  
  15508. -------------------------------------------------------------------------------
  15509.  
  15510. From: Randy Cosby <dcosby@infowest.com>
  15511. Subject: (usr-tc) SET PPP DNS question
  15512. Date: 16 Apr 1999 11:57:22 -0600 (MDT)
  15513.  
  15514. _sho ver
  15515. V4.1.59 - 6
  15516. Wookie>> help set ppp dns
  15517.  
  15518. The possible SET PPP DNS_USAGE  commands are:
  15519.     SET PPP DNS_USAGE  [ NONE PPP SYSTEM  ]
  15520. or any unique abbreviation of the keywords
  15521.  
  15522. I can find no mention in release notes or the hiperarc command reference for 4.1.11 about
  15523. the difference between NONE, PPP and SYSTEM.  They just say this is off or on.   What's the
  15524. difference between system and ppp?
  15525.  
  15526. Thanks,
  15527.  
  15528. Randy
  15529.  
  15530. -
  15531.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15532.  with "unsubscribe usr-tc" in the body of the message.
  15533.  For information on digests or retrieving files and old messages send
  15534.  "help" to the same address.  Do not use quotes in your message.
  15535.  
  15536.  
  15537. -------------------------------------------------------------------------------
  15538.  
  15539. From: Netlink Hardware admin <hw@netlinkcom.com>
  15540. Subject: (usr-tc) Netserver 8/16 I and Multilink PPP
  15541. Date: 16 Apr 1999 12:50:39 -0500 (CDT)
  15542.  
  15543.  
  15544. Has anyone on this list successfully configured a Netserver 8/16 I (Plus)
  15545. to accept Multilink PPP connections?
  15546.  
  15547. Does the Multilink PPP on these only work with ISDN, or will solutions
  15548. such as Diamond's Shotgun technology work?
  15549.  
  15550. Thanks,
  15551.  
  15552. Curt
  15553.  
  15554.  
  15555. -
  15556.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15557.  with "unsubscribe usr-tc" in the body of the message.
  15558.  For information on digests or retrieving files and old messages send
  15559.  "help" to the same address.  Do not use quotes in your message.
  15560.  
  15561.  
  15562. -------------------------------------------------------------------------------
  15563.  
  15564. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  15565. Subject: RE: (usr-tc) SET PPP DNS question
  15566. Date: 16 Apr 1999 13:29:25 -0500
  15567.  
  15568.  
  15569.  
  15570. |-----Original Message-----
  15571. |From: owner-usr-tc@lists.xmission.com
  15572. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Cosby
  15573. |Sent: Friday, April 16, 1999 12:57 PM
  15574. |To: usr-tc@lists.xmission.com
  15575. |Subject: (usr-tc) SET PPP DNS question
  15576. |
  15577. |
  15578. |_sho ver
  15579. |V4.1.59 - 6
  15580. |Wookie>> help set ppp dns
  15581. |
  15582. |The possible SET PPP DNS_USAGE  commands are:
  15583. |    SET PPP DNS_USAGE  [ NONE PPP SYSTEM  ]
  15584. |or any unique abbreviation of the keywords
  15585. |
  15586. |I can find no mention in release notes or the hiperarc command 
  15587. |reference for 4.1.11 about
  15588. |the difference between NONE, PPP and SYSTEM.  They just say this is off 
  15589. |or on.   What's the
  15590. |difference between system and ppp?
  15591.  
  15592. This relates to DNS servers sent to the client during IPCP. 
  15593. NONE = Dont send any.
  15594. PPP = Send the ones configured for PPP "show PPP"
  15595. SYSTEM = Send the onces configured for the HARC "list dns servers"
  15596.  
  15597. -M
  15598.  
  15599.  
  15600. -
  15601.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15602.  with "unsubscribe usr-tc" in the body of the message.
  15603.  For information on digests or retrieving files and old messages send
  15604.  "help" to the same address.  Do not use quotes in your message.
  15605.  
  15606.  
  15607. -------------------------------------------------------------------------------
  15608.  
  15609. From: Brian <signal@shreve.net>
  15610. Subject: (usr-tc) hdm-analyzer.pl
  15611. Date: 16 Apr 1999 13:41:16 -0500 (CDT)
  15612.  
  15613.  
  15614. This may be of use to some.  I wrote a quick program that analyzes # of
  15615. calles arrived at an hdm vs. # of calls established and then prints the
  15616. results.  Its real rough but it works.
  15617.  
  15618. It parses the syslog output of an ARC.  I found I had a modem that took
  15619. 1000+ calls and none got established, and so I flashed it real quick,
  15620. really handy tool.  Perhaps some of you use something like this, just
  15621. something else, maybe even better:
  15622.  
  15623. #!/usr/bin/perl
  15624. # hdm-analyzer - Analyzes calls arrived vs. calls established
  15625. # from ARC syslog files.
  15626. # Usage: hdm-analyzer.pl <filename> <arc>
  15627. # 
  15628.  
  15629. $|=1;
  15630. $==56;          
  15631. $^L=" ";        
  15632. $date=`date "+%x %X"`;
  15633.  
  15634. $file=$ARGV[0];
  15635. $choice=$ARGV[1];
  15636.  
  15637. open(FILE,"$file");
  15638. while(<FILE>) {
  15639.     ($arc,$slotmod)=(split)[3,9];
  15640.     if ($choice eq $arc) {
  15641.         if(/arrived on interface (\S+)/) {
  15642.           $slotmod_a{$1}++;;
  15643.        }  elsif(/call id \d+, on interface (\S+)/) {
  15644.           $slotmod_e{$1}++;
  15645.         }
  15646.     }
  15647. }
  15648. close(FILE);
  15649.  
  15650. foreach (sort keys %slotmod_a) { 
  15651.    $percent=( (($slotmod_e{$_}/$slotmod_a{$_}) *100)); 
  15652.    write;
  15653. }
  15654.  
  15655.  
  15656. format STDOUT_TOP =
  15657. @||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  15658. "Modem Health Check - file: $file - chassis: $choice" 
  15659. @||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  15660. "$date"
  15661. slot:x/mod:y    Calls Arrived   Calls Established       Percent Success
  15662. ------------    --------------  -----------------       ---------------
  15663. .
  15664.  
  15665. format STDOUT =
  15666. @<<<<<<<<<<<<<  @<<<<<<<<<<<<   @<<<<<<<<<<<<<<<<       @<<<<<<<<<<<<<<
  15667. $_,$slotmod_a{$_},$slotmod_e{$_},$percent
  15668. .
  15669.  
  15670. output looks like:
  15671.  
  15672.                Modem Health Check - file: mar - chassis: mar1
  15673.                               04/16/99 13:39:12
  15674. slot:x/mod:y    Calls Arrived   Calls Established       Percent Success
  15675. ------------    --------------  -----------------       ---------------
  15676. slot:1/mod:12   4               4                       100
  15677. slot:1/mod:13   4               3                       75
  15678. slot:1/mod:19   4               4                       100
  15679. slot:1/mod:22   2               2                       100
  15680. slot:1/mod:5    6               6                       100
  15681. slot:1/mod:7    2               2                       100
  15682. slot:1/mod:8    1               1                       100
  15683. slot:1/mod:9    1               1                       100
  15684. slot:2/mod:1    2               2                       100
  15685. slot:2/mod:10   1               2                       200
  15686. slot:2/mod:12   1               1                       100
  15687. slot:2/mod:13   1               1                       100
  15688. slot:2/mod:2    3               3                       100
  15689. slot:2/mod:6    2               1                       50
  15690. slot:2/mod:9    1               2                       200
  15691.  
  15692.  
  15693. etc.  After a days worth of calls on a busy chassis, gives real good data.
  15694. Anything under 80% is pretty bad.  I have a 75% at the top, but thats only
  15695. off a sample set of data that had only 4 calls, not enough for a good
  15696. determination.  The reason for the few 200%'s i have, is simply because
  15697. the syslog output I had started after a call arrival but before a call
  15698. establish, so I ended up with 1 more establish than I should have.
  15699.  
  15700. I am going to have it actually grok callid's and discard that type of data
  15701. so it won't show those 200%'s etc.  It helped me solve some problems so I
  15702. wanted to post it in hopes someone else has good luck with it.
  15703.  
  15704. Brian
  15705.  
  15706.  
  15707.  
  15708. Brian Feeny (BF304)     signal@shreve.net   
  15709. 318-222-2638 x 109    http://www.shreve.net/~signal      
  15710. Network Administrator   ShreveNet Inc. (ASN 11881)           
  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. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  15723. Subject: Re: (usr-tc) multicasting over ARC's?
  15724. Date: 16 Apr 1999 15:50:03 -0500 (CDT)
  15725.  
  15726. On Thu, 8 Apr 1999, Pete Ashdown wrote:
  15727.  
  15728. > Is anyone doing multicasting over their ARC's?  Did you need to do anything
  15729. > to get it to run?
  15730.  
  15731. There are a few customer who I know are using the ARC for IGMP/multi cast.
  15732. You need to enable igmp on ther interface.
  15733.  
  15734. > 
  15735. > -
  15736. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15737. >  with "unsubscribe usr-tc" in the body of the message.
  15738. >  For information on digests or retrieving files and old messages send
  15739. >  "help" to the same address.  Do not use quotes in your message.
  15740. > 
  15741.  
  15742.  
  15743. -
  15744.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15745.  with "unsubscribe usr-tc" in the body of the message.
  15746.  For information on digests or retrieving files and old messages send
  15747.  "help" to the same address.  Do not use quotes in your message.
  15748.  
  15749.  
  15750. -------------------------------------------------------------------------------
  15751.  
  15752. From: Brian <signal@shreve.net>
  15753. Subject: (usr-tc) hdm-analyzer.pl (revised)
  15754. Date: 16 Apr 1999 16:38:38 -0500 (CDT)
  15755.  
  15756.  
  15757. Ok, this version of the hdm-analyzer actually tracks call id #'s and makes
  15758. sure it doesn't tally a call established unless it had a call arrived for
  15759. a particular id (to prevent > 100%, and skewed data).  I won't post this
  15760. here anymore after this, if anyone ever wants up update on what I have
  15761. done with it, you can just email me.  I plan to probably put some DBI::DBD
  15762. stuff in their and have it poke into a database, and then update an mrtg
  15763. graph with two lines showing the comparison of call arrived against call
  15764. established.
  15765.  
  15766. Brian
  15767.  
  15768. #!/usr/bin/perl
  15769. # hdm-analyzer - Analyzes calls arrived vs. calls established
  15770. # from ARC syslog files.
  15771. # Usage: hdm-analyzer.pl <filename> <arc>
  15772. # <signal@shreve.net>
  15773.  
  15774. $|=1;
  15775. $==56;          
  15776. $^L=" ";        
  15777. $date=`date "+%x %X"`;
  15778.  
  15779. $file=$ARGV[0];
  15780. $choice=$ARGV[1];
  15781.  
  15782. open(FILE,"$file");
  15783. while(<FILE>) {
  15784.     ($arc,$slotmod)=(split)[3,9];
  15785.     if ($choice eq $arc) {
  15786.         if(/call id = (\d+), has arrived on interface (\S+)/) {
  15787.           $idtrack{$1}=1;
  15788.           $slotmod_a{$2}++;;
  15789.         }  elsif((/call id (\d+), on interface (\S+)/)  && ($idtrack{$1} == 1)) {
  15790.           $slotmod_e{$2}++;
  15791.         }
  15792.     }
  15793. }
  15794. close(FILE);
  15795.  
  15796. foreach (sort keys %slotmod_a) { 
  15797.    $percent=( (($slotmod_e{$_}/$slotmod_a{$_}) *100));
  15798.    $failed=$slotmod_a{$_}-$slotmod_e{$_}; 
  15799.    write;
  15800. }
  15801.  
  15802.  
  15803. format STDOUT_TOP =
  15804. @||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  15805. "Modem Health Check - file: $file - chassis: $choice" 
  15806. @||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  15807. "$date"
  15808. slot:x/mod:y    Calls Arrived   Calls Established       Failed Attempts
  15809. Percent Success
  15810. ------------    --------------  -----------------       ---------------
  15811. ---------------
  15812. .
  15813.  
  15814. format STDOUT =
  15815. @<<<<<<<<<<<<<  @<<<<<<<<<<<<   @<<<<<<<<<<<<<<<<       @<<<<<<<<<<<<<<
  15816. @<<<<<<<<<<<<<<
  15817. $_,$slotmod_a{$_},$slotmod_e{$_},$failed,$percent
  15818. .
  15819.  
  15820.  
  15821. Brian Feeny (BF304)     signal@shreve.net   
  15822. 318-222-2638 x 109    http://www.shreve.net/~signal      
  15823. Network Administrator   ShreveNet Inc. (ASN 11881)           
  15824.  
  15825.  
  15826. -
  15827.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15828.  with "unsubscribe usr-tc" in the body of the message.
  15829.  For information on digests or retrieving files and old messages send
  15830.  "help" to the same address.  Do not use quotes in your message.
  15831.  
  15832.  
  15833. -------------------------------------------------------------------------------
  15834.  
  15835. From: Randy Doran <RandyDoran@USA.net>
  15836. Subject: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  15837. Date: 16 Apr 1999 17:39:24 -0400
  15838.  
  15839. I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code.
  15840. We have 53 PRIs in the hunt group and it hunts round robin from the switch,
  15841. i.e. it fills up the entire hunt group evenly.  I had one 14 PRI chassis
  15842. with a single ARC in this hunt.  The calls filled up all 14 of those PRIs.
  15843. But we started to get random regular busy signals on the hunt number when
  15844. we were no where near filled up.  I added a second HiPerARC back to the
  15845. chassis and the busy signals stopped.  My guess is that the ARC might not
  15846. be able to handle too many incoming call setups all at once and it sends
  15847. out a busy signal.  Some calls get through and then it eventually fills up.
  15848.  Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it
  15849. can handle the load. just a guess.
  15850.  
  15851.  Randy Doran
  15852.  RAS-Network Engineer
  15853.  CyberGate e.spire Internet Services
  15854.  
  15855. At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote:
  15856. >As long as you do not use IPX - Hiper arc will support 14 DSPs
  15857. >4.1.59 code 
  15858. >krish
  15859. >
  15860. >-----------------------------------------
  15861. >        \    T.S.V. Krishnan  \
  15862. >         \      Network System Engineer \ ( : - : )
  15863. >          \     3Com ............   \
  15864. >        ----------------------------------------------/
  15865. >tkrishna@bubba.ae.usr.com  
  15866. >----------------------------/ http://interproc.ae.usr.com ----/
  15867. >The Yadda Yadda Search - for simple anwers -
  15868. http://interproc.ae.usr.com/tkb.html
  15869. >-------------------------------------------------------------------------\
  15870. >    Any Sufficiently advanced bug is indistinguishable for a feature.
  15871. >                        - Rick Kulawiec
  15872. >-------------------------------------------------------------------------/
  15873. >
  15874. >On Tue, 16 Feb 1999, Randy Cosby wrote:
  15875. >
  15876. >> Not really an answer, but do you still need 2 ARC's for a full chassis?  I
  15877. >> thought with 4.1.72 and later, one ARC can handle a full chasis quite
  15878. >> easily.  If not, please correct me, cause I'm about to add my 11th card
  15879. with
  15880. >> 4.1.59 :)
  15881. >> 
  15882. >> Randy
  15883. >> 
  15884. >> > -----Original Message-----
  15885. >> > From: owner-usr-tc@lists.xmission.com
  15886. >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader
  15887. >> > Sent: Tuesday, February 16, 1999 4:51 PM
  15888. >> > To: usr-tc@lists.xmission.com
  15889. >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration
  15890. >> >
  15891. >> >
  15892. >> > We are an ISP with dialin PPP only that is authenticated by Radius.
  15893. >> > We have just purchase a 14 DSP, 2 ARC chassis.  Our experience to-date is
  15894. >> > with only 10 DSP, 2 ARC chassis.  Previously we have split a
  15895. >> > single class C
  15896. >> > between the 2 ARCs and have 121 IPs assigned to each.  Question: How to
  15897. >> > combine parts of two class Cs to a single card. For example 120 address
  15898. >> > from 1.2.3.xxx and 49 from 1.2.4.xxx.  I know I should be able to set up
  15899. >> > ippool for each part of each class C, but I don't know if the ARC's
  15900. >> > ethernet port needs to have an address from each class C or just one
  15901. or if
  15902. >> > it can be assigned an address from another class C completely.
  15903. >> >
  15904. >> >
  15905. >> >
  15906. >> >
  15907. >> > -
  15908. >> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15909. >> >  with "unsubscribe usr-tc" in the body of the message.
  15910. >> >  For information on digests or retrieving files and old messages send
  15911. >> >  "help" to the same address.  Do not use quotes in your message.
  15912. >> >
  15913. >> 
  15914. >> 
  15915. >> -
  15916. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15917. >>  with "unsubscribe usr-tc" in the body of the message.
  15918. >>  For information on digests or retrieving files and old messages send
  15919. >>  "help" to the same address.  Do not use quotes in your message.
  15920. >> 
  15921. >
  15922. >-
  15923. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15924. > with "unsubscribe usr-tc" in the body of the message.
  15925. > For information on digests or retrieving files and old messages send
  15926. > "help" to the same address.  Do not use quotes in your message.
  15927. >
  15928.  
  15929. -
  15930.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15931.  with "unsubscribe usr-tc" in the body of the message.
  15932.  For information on digests or retrieving files and old messages send
  15933.  "help" to the same address.  Do not use quotes in your message.
  15934.  
  15935.  
  15936. -------------------------------------------------------------------------------
  15937.  
  15938. From: Paul Farber <farber@admin.f-tech.net>
  15939. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  15940. Date: 16 Apr 1999 18:05:16 -0400 (EDT)
  15941.  
  15942. We'll be in this same prediciment shortly.  
  15943.  
  15944. Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  15945. would suck if the ARC has a 7 DSP limit. 
  15946.  
  15947. 3Com are you listening?
  15948.  
  15949. Paul D. Farber II
  15950. Farber Technology
  15951. Ph. 570-628-5303
  15952. Fax 570-628-5545
  15953. farber@admin.f-tech.net
  15954.  
  15955. On Fri, 16 Apr 1999, Randy Doran wrote:
  15956.  
  15957. > I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code.
  15958. > We have 53 PRIs in the hunt group and it hunts round robin from the switch,
  15959. > i.e. it fills up the entire hunt group evenly.  I had one 14 PRI chassis
  15960. > with a single ARC in this hunt.  The calls filled up all 14 of those PRIs.
  15961. > But we started to get random regular busy signals on the hunt number when
  15962. > we were no where near filled up.  I added a second HiPerARC back to the
  15963. > chassis and the busy signals stopped.  My guess is that the ARC might not
  15964. > be able to handle too many incoming call setups all at once and it sends
  15965. > out a busy signal.  Some calls get through and then it eventually fills up.
  15966. >  Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it
  15967. > can handle the load. just a guess.
  15968. > 
  15969. >  Randy Doran
  15970. >  RAS-Network Engineer
  15971. >  CyberGate e.spire Internet Services
  15972. > 
  15973. > At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote:
  15974. > >As long as you do not use IPX - Hiper arc will support 14 DSPs
  15975. > >4.1.59 code 
  15976. > >krish
  15977. > >
  15978. > >-----------------------------------------
  15979. > >        \    T.S.V. Krishnan  \
  15980. > >         \      Network System Engineer \ ( : - : )
  15981. > >          \     3Com ............   \
  15982. > >        ----------------------------------------------/
  15983. > >tkrishna@bubba.ae.usr.com  
  15984. > >----------------------------/ http://interproc.ae.usr.com ----/
  15985. > >The Yadda Yadda Search - for simple anwers -
  15986. > http://interproc.ae.usr.com/tkb.html
  15987. > >-------------------------------------------------------------------------\
  15988. > >    Any Sufficiently advanced bug is indistinguishable for a feature.
  15989. > >                        - Rick Kulawiec
  15990. > >-------------------------------------------------------------------------/
  15991. > >
  15992. > >On Tue, 16 Feb 1999, Randy Cosby wrote:
  15993. > >
  15994. > >> Not really an answer, but do you still need 2 ARC's for a full chassis?  I
  15995. > >> thought with 4.1.72 and later, one ARC can handle a full chasis quite
  15996. > >> easily.  If not, please correct me, cause I'm about to add my 11th card
  15997. > with
  15998. > >> 4.1.59 :)
  15999. > >> 
  16000. > >> Randy
  16001. > >> 
  16002. > >> > -----Original Message-----
  16003. > >> > From: owner-usr-tc@lists.xmission.com
  16004. > >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader
  16005. > >> > Sent: Tuesday, February 16, 1999 4:51 PM
  16006. > >> > To: usr-tc@lists.xmission.com
  16007. > >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration
  16008. > >> >
  16009. > >> >
  16010. > >> > We are an ISP with dialin PPP only that is authenticated by Radius.
  16011. > >> > We have just purchase a 14 DSP, 2 ARC chassis.  Our experience to-date is
  16012. > >> > with only 10 DSP, 2 ARC chassis.  Previously we have split a
  16013. > >> > single class C
  16014. > >> > between the 2 ARCs and have 121 IPs assigned to each.  Question: How to
  16015. > >> > combine parts of two class Cs to a single card. For example 120 address
  16016. > >> > from 1.2.3.xxx and 49 from 1.2.4.xxx.  I know I should be able to set up
  16017. > >> > ippool for each part of each class C, but I don't know if the ARC's
  16018. > >> > ethernet port needs to have an address from each class C or just one
  16019. > or if
  16020. > >> > it can be assigned an address from another class C completely.
  16021. > >> >
  16022. > >> >
  16023. > >> >
  16024. > >> >
  16025. > >> > -
  16026. > >> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16027. > >> >  with "unsubscribe usr-tc" in the body of the message.
  16028. > >> >  For information on digests or retrieving files and old messages send
  16029. > >> >  "help" to the same address.  Do not use quotes in your message.
  16030. > >> >
  16031. > >> 
  16032. > >> 
  16033. > >> -
  16034. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16035. > >>  with "unsubscribe usr-tc" in the body of the message.
  16036. > >>  For information on digests or retrieving files and old messages send
  16037. > >>  "help" to the same address.  Do not use quotes in your message.
  16038. > >> 
  16039. > >
  16040. > >-
  16041. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16042. > > with "unsubscribe usr-tc" in the body of the message.
  16043. > > For information on digests or retrieving files and old messages send
  16044. > > "help" to the same address.  Do not use quotes in your message.
  16045. > >
  16046. > 
  16047. > -
  16048. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16049. >  with "unsubscribe usr-tc" in the body of the message.
  16050. >  For information on digests or retrieving files and old messages send
  16051. >  "help" to the same address.  Do not use quotes in your message.
  16052. > 
  16053.  
  16054.  
  16055. -
  16056.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16057.  with "unsubscribe usr-tc" in the body of the message.
  16058.  For information on digests or retrieving files and old messages send
  16059.  "help" to the same address.  Do not use quotes in your message.
  16060.  
  16061.  
  16062. -------------------------------------------------------------------------------
  16063.  
  16064. From: Brian <signal@shreve.net>
  16065. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  16066. Date: 16 Apr 1999 17:18:10 -0500 (CDT)
  16067.  
  16068. On Fri, 16 Apr 1999, Paul Farber wrote:
  16069.  
  16070. > We'll be in this same prediciment shortly.  
  16071. > 
  16072. > Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  16073. > would suck if the ARC has a 7 DSP limit. 
  16074. > 
  16075. > 3Com are you listening?
  16076.  
  16077. But why, I mean 5 hdm's per arc is pretty good deal.  We run our chassis
  16078. 10HDM's + 2 ARC's.  Why?  Because when you buy alot of chassis, their is
  16079. no shortage of chassis and arcs, so why not use them?  This way each arc
  16080. has to do less load.  Also its great having 2 arc's in a chassis even if
  16081. you only have say 3 hdm's.  Then remotely, if an arc should go out (and
  16082. they do go out :) ), you just re-assign the ownership of the hdm's to the
  16083. other arc, and everything continues to work great, great redundancy.
  16084.  
  16085. Have you been buying double up kits and not complete chasiss?  Is that why
  16086. you don't have more arcs?  
  16087.  
  16088. For the difference in price between a full bundle and the double up kit,
  16089. you could easily sell the nmc, chassis, power supplies and make it all
  16090. back plus some, or keep the gear, or some of it, for spares.
  16091.  
  16092.  
  16093.  
  16094. > 
  16095. > Paul D. Farber II
  16096. > Farber Technology
  16097. > Ph. 570-628-5303
  16098. > Fax 570-628-5545
  16099. > farber@admin.f-tech.net
  16100. > 
  16101. > On Fri, 16 Apr 1999, Randy Doran wrote:
  16102. > 
  16103. > > I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code.
  16104. > > We have 53 PRIs in the hunt group and it hunts round robin from the switch,
  16105. > > i.e. it fills up the entire hunt group evenly.  I had one 14 PRI chassis
  16106. > > with a single ARC in this hunt.  The calls filled up all 14 of those PRIs.
  16107. > > But we started to get random regular busy signals on the hunt number when
  16108. > > we were no where near filled up.  I added a second HiPerARC back to the
  16109. > > chassis and the busy signals stopped.  My guess is that the ARC might not
  16110. > > be able to handle too many incoming call setups all at once and it sends
  16111. > > out a busy signal.  Some calls get through and then it eventually fills up.
  16112. > >  Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it
  16113. > > can handle the load. just a guess.
  16114. > > 
  16115. > >  Randy Doran
  16116. > >  RAS-Network Engineer
  16117. > >  CyberGate e.spire Internet Services
  16118. > > 
  16119. > > At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote:
  16120. > > >As long as you do not use IPX - Hiper arc will support 14 DSPs
  16121. > > >4.1.59 code 
  16122. > > >krish
  16123. > > >
  16124. > > >-----------------------------------------
  16125. > > >        \    T.S.V. Krishnan  \
  16126. > > >         \      Network System Engineer \ ( : - : )
  16127. > > >          \     3Com ............   \
  16128. > > >        ----------------------------------------------/
  16129. > > >tkrishna@bubba.ae.usr.com  
  16130. > > >----------------------------/ http://interproc.ae.usr.com ----/
  16131. > > >The Yadda Yadda Search - for simple anwers -
  16132. > > http://interproc.ae.usr.com/tkb.html
  16133. > > >-------------------------------------------------------------------------\
  16134. > > >    Any Sufficiently advanced bug is indistinguishable for a feature.
  16135. > > >                        - Rick Kulawiec
  16136. > > >-------------------------------------------------------------------------/
  16137. > > >
  16138. > > >On Tue, 16 Feb 1999, Randy Cosby wrote:
  16139. > > >
  16140. > > >> Not really an answer, but do you still need 2 ARC's for a full chassis?  I
  16141. > > >> thought with 4.1.72 and later, one ARC can handle a full chasis quite
  16142. > > >> easily.  If not, please correct me, cause I'm about to add my 11th card
  16143. > > with
  16144. > > >> 4.1.59 :)
  16145. > > >> 
  16146. > > >> Randy
  16147. > > >> 
  16148. > > >> > -----Original Message-----
  16149. > > >> > From: owner-usr-tc@lists.xmission.com
  16150. > > >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader
  16151. > > >> > Sent: Tuesday, February 16, 1999 4:51 PM
  16152. > > >> > To: usr-tc@lists.xmission.com
  16153. > > >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration
  16154. > > >> >
  16155. > > >> >
  16156. > > >> > We are an ISP with dialin PPP only that is authenticated by Radius.
  16157. > > >> > We have just purchase a 14 DSP, 2 ARC chassis.  Our experience to-date is
  16158. > > >> > with only 10 DSP, 2 ARC chassis.  Previously we have split a
  16159. > > >> > single class C
  16160. > > >> > between the 2 ARCs and have 121 IPs assigned to each.  Question: How to
  16161. > > >> > combine parts of two class Cs to a single card. For example 120 address
  16162. > > >> > from 1.2.3.xxx and 49 from 1.2.4.xxx.  I know I should be able to set up
  16163. > > >> > ippool for each part of each class C, but I don't know if the ARC's
  16164. > > >> > ethernet port needs to have an address from each class C or just one
  16165. > > or if
  16166. > > >> > it can be assigned an address from another class C completely.
  16167. > > >> >
  16168. > > >> >
  16169. > > >> >
  16170. > > >> >
  16171. > > >> > -
  16172. > > >> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16173. > > >> >  with "unsubscribe usr-tc" in the body of the message.
  16174. > > >> >  For information on digests or retrieving files and old messages send
  16175. > > >> >  "help" to the same address.  Do not use quotes in your message.
  16176. > > >> >
  16177. > > >> 
  16178. > > >> 
  16179. > > >> -
  16180. > > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16181. > > >>  with "unsubscribe usr-tc" in the body of the message.
  16182. > > >>  For information on digests or retrieving files and old messages send
  16183. > > >>  "help" to the same address.  Do not use quotes in your message.
  16184. > > >> 
  16185. > > >
  16186. > > >-
  16187. > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16188. > > > with "unsubscribe usr-tc" in the body of the message.
  16189. > > > For information on digests or retrieving files and old messages send
  16190. > > > "help" to the same address.  Do not use quotes in your message.
  16191. > > >
  16192. > > 
  16193. > > -
  16194. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16195. > >  with "unsubscribe usr-tc" in the body of the message.
  16196. > >  For information on digests or retrieving files and old messages send
  16197. > >  "help" to the same address.  Do not use quotes in your message.
  16198. > > 
  16199. > 
  16200. > 
  16201. > -
  16202. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16203. >  with "unsubscribe usr-tc" in the body of the message.
  16204. >  For information on digests or retrieving files and old messages send
  16205. >  "help" to the same address.  Do not use quotes in your message.
  16206. > 
  16207.  
  16208. Brian Feeny (BF304)     signal@shreve.net   
  16209. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16210. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16211.  
  16212.  
  16213. -
  16214.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16215.  with "unsubscribe usr-tc" in the body of the message.
  16216.  For information on digests or retrieving files and old messages send
  16217.  "help" to the same address.  Do not use quotes in your message.
  16218.  
  16219.  
  16220. -------------------------------------------------------------------------------
  16221.  
  16222. From: Paul Farber <farber@admin.f-tech.net>
  16223. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  16224. Date: 16 Apr 1999 18:05:16 -0400 (EDT)
  16225.  
  16226. We'll be in this same prediciment shortly.  
  16227.  
  16228. Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  16229. would suck if the ARC has a 7 DSP limit. 
  16230.  
  16231. 3Com are you listening?
  16232.  
  16233. Paul D. Farber II
  16234. Farber Technology
  16235. Ph. 570-628-5303
  16236. Fax 570-628-5545
  16237. farber@admin.f-tech.net
  16238.  
  16239. On Fri, 16 Apr 1999, Randy Doran wrote:
  16240.  
  16241. > I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code.
  16242. > We have 53 PRIs in the hunt group and it hunts round robin from the switch,
  16243. > i.e. it fills up the entire hunt group evenly.  I had one 14 PRI chassis
  16244. > with a single ARC in this hunt.  The calls filled up all 14 of those PRIs.
  16245. > But we started to get random regular busy signals on the hunt number when
  16246. > we were no where near filled up.  I added a second HiPerARC back to the
  16247. > chassis and the busy signals stopped.  My guess is that the ARC might not
  16248. > be able to handle too many incoming call setups all at once and it sends
  16249. > out a busy signal.  Some calls get through and then it eventually fills up.
  16250. >  Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it
  16251. > can handle the load. just a guess.
  16252. > 
  16253. >  Randy Doran
  16254. >  RAS-Network Engineer
  16255. >  CyberGate e.spire Internet Services
  16256. > 
  16257. > At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote:
  16258. > >As long as you do not use IPX - Hiper arc will support 14 DSPs
  16259. > >4.1.59 code 
  16260. > >krish
  16261. > >
  16262. > >-----------------------------------------
  16263. > >        \    T.S.V. Krishnan  \
  16264. > >         \      Network System Engineer \ ( : - : )
  16265. > >          \     3Com ............   \
  16266. > >        ----------------------------------------------/
  16267. > >tkrishna@bubba.ae.usr.com  
  16268. > >----------------------------/ http://interproc.ae.usr.com ----/
  16269. > >The Yadda Yadda Search - for simple anwers -
  16270. > http://interproc.ae.usr.com/tkb.html
  16271. > >-------------------------------------------------------------------------\
  16272. > >    Any Sufficiently advanced bug is indistinguishable for a feature.
  16273. > >                        - Rick Kulawiec
  16274. > >-------------------------------------------------------------------------/
  16275. > >
  16276. > >On Tue, 16 Feb 1999, Randy Cosby wrote:
  16277. > >
  16278. > >> Not really an answer, but do you still need 2 ARC's for a full chassis?  I
  16279. > >> thought with 4.1.72 and later, one ARC can handle a full chasis quite
  16280. > >> easily.  If not, please correct me, cause I'm about to add my 11th card
  16281. > with
  16282. > >> 4.1.59 :)
  16283. > >> 
  16284. > >> Randy
  16285. > >> 
  16286. > >> > -----Original Message-----
  16287. > >> > From: owner-usr-tc@lists.xmission.com
  16288. > >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader
  16289. > >> > Sent: Tuesday, February 16, 1999 4:51 PM
  16290. > >> > To: usr-tc@lists.xmission.com
  16291. > >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration
  16292. > >> >
  16293. > >> >
  16294. > >> > We are an ISP with dialin PPP only that is authenticated by Radius.
  16295. > >> > We have just purchase a 14 DSP, 2 ARC chassis.  Our experience to-date is
  16296. > >> > with only 10 DSP, 2 ARC chassis.  Previously we have split a
  16297. > >> > single class C
  16298. > >> > between the 2 ARCs and have 121 IPs assigned to each.  Question: How to
  16299. > >> > combine parts of two class Cs to a single card. For example 120 address
  16300. > >> > from 1.2.3.xxx and 49 from 1.2.4.xxx.  I know I should be able to set up
  16301. > >> > ippool for each part of each class C, but I don't know if the ARC's
  16302. > >> > ethernet port needs to have an address from each class C or just one
  16303. > or if
  16304. > >> > it can be assigned an address from another class C completely.
  16305. > >> >
  16306. > >> >
  16307. > >> >
  16308. > >> >
  16309. > >> > -
  16310. > >> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16311. > >> >  with "unsubscribe usr-tc" in the body of the message.
  16312. > >> >  For information on digests or retrieving files and old messages send
  16313. > >> >  "help" to the same address.  Do not use quotes in your message.
  16314. > >> >
  16315. > >> 
  16316. > >> 
  16317. > >> -
  16318. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16319. > >>  with "unsubscribe usr-tc" in the body of the message.
  16320. > >>  For information on digests or retrieving files and old messages send
  16321. > >>  "help" to the same address.  Do not use quotes in your message.
  16322. > >> 
  16323. > >
  16324. > >-
  16325. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16326. > > with "unsubscribe usr-tc" in the body of the message.
  16327. > > For information on digests or retrieving files and old messages send
  16328. > > "help" to the same address.  Do not use quotes in your message.
  16329. > >
  16330. > 
  16331. > -
  16332. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16333. >  with "unsubscribe usr-tc" in the body of the message.
  16334. >  For information on digests or retrieving files and old messages send
  16335. >  "help" to the same address.  Do not use quotes in your message.
  16336. > 
  16337.  
  16338.  
  16339. -
  16340.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16341.  with "unsubscribe usr-tc" in the body of the message.
  16342.  For information on digests or retrieving files and old messages send
  16343.  "help" to the same address.  Do not use quotes in your message.
  16344.  
  16345.  
  16346. -------------------------------------------------------------------------------
  16347.  
  16348. From: Erick_Mancera@3com.com
  16349. Subject: Re: (usr-tc) multicasting over ARC's?
  16350. Date: 16 Apr 1999 16:59:49 -0600
  16351.  
  16352.  
  16353.  
  16354. I was using this configuration with a customer in a test environment.
  16355. I don't remember which version of ARC we were using, but I think it shall work
  16356. with latest code.
  16357.  
  16358. Best Regards,
  16359. Erick Mancera
  16360.  
  16361. set ip multicast proxy interface eth:1
  16362. set ip igmp eth:1 multicast_forwarding enabled
  16363. set network user default igmp routing enabled multicast_forwarding enabled
  16364. multicast_proxy enable
  16365.  
  16366. set ip igmp slot:14/mod:1 routing enabled multicast_forwarding enabled
  16367. multicast_proxy enable
  16368.  
  16369.  
  16370.  
  16371.  
  16372.  
  16373.  
  16374. Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 04/16/99 04:50:03 PM
  16375.  
  16376. Please respond to usr-tc@lists.xmission.com
  16377.  
  16378. cc:   usr-tc@lists.xmission.com (Erick Mancera/MX/3Com)
  16379.  
  16380.  
  16381.  
  16382.  
  16383. On Thu, 8 Apr 1999, Pete Ashdown wrote:
  16384.  
  16385. > Is anyone doing multicasting over their ARC's?  Did you need to do anything
  16386. > to get it to run?
  16387.  
  16388. There are a few customer who I know are using the ARC for IGMP/multi cast.
  16389. You need to enable igmp on ther interface.
  16390.  
  16391. >
  16392. > -
  16393. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16394. >  with "unsubscribe usr-tc" in the body of the message.
  16395. >  For information on digests or retrieving files and old messages send
  16396. >  "help" to the same address.  Do not use quotes in your message.
  16397. >
  16398.  
  16399.  
  16400. -
  16401.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16402.  with "unsubscribe usr-tc" in the body of the message.
  16403.  For information on digests or retrieving files and old messages send
  16404.  "help" to the same address.  Do not use quotes in your message.
  16405.  
  16406.  
  16407.  
  16408.  
  16409.  
  16410.  
  16411.  
  16412.  
  16413.  
  16414. -
  16415.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16416.  with "unsubscribe usr-tc" in the body of the message.
  16417.  For information on digests or retrieving files and old messages send
  16418.  "help" to the same address.  Do not use quotes in your message.
  16419.  
  16420.  
  16421. -------------------------------------------------------------------------------
  16422.  
  16423. From: Jeff Mcadams <jeffm@iglou.com>
  16424. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  16425. Date: 17 Apr 1999 02:01:37 -0400 (EDT)
  16426.  
  16427. Thus spake Paul Farber
  16428. >We'll be in this same prediciment shortly.  
  16429.  
  16430. >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  16431. >would suck if the ARC has a 7 DSP limit. 
  16432.  
  16433. >3Com are you listening?
  16434.  
  16435. From my understanding...the limit for a single Arc is more typically 10
  16436. DSP's.  Obviously you can't do 20 DSP's in a chassis, so 7 is often
  16437. quoted as that would be a full to capacity chassis (14 DSP's, 2 Arcs).
  16438.  
  16439. >On Fri, 16 Apr 1999, Randy Doran wrote:
  16440. >> I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code.
  16441. >> We have 53 PRIs in the hunt group and it hunts round robin from the switch,
  16442. >> i.e. it fills up the entire hunt group evenly.  I had one 14 PRI chassis
  16443. >> with a single ARC in this hunt.  The calls filled up all 14 of those PRIs.
  16444. >> But we started to get random regular busy signals on the hunt number when
  16445. >> we were no where near filled up.  I added a second HiPerARC back to the
  16446. >> chassis and the busy signals stopped.  My guess is that the ARC might not
  16447. >> be able to handle too many incoming call setups all at once and it sends
  16448. >> out a busy signal.  Some calls get through and then it eventually fills up.
  16449. >>  Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it
  16450. >> can handle the load. just a guess.
  16451. -- 
  16452. Jeff McAdams                            Email: jeffm@iglou.com
  16453. Head Network Administrator              Voice: (502) 966-3848
  16454. IgLou Internet Services                        (800) 436-4456
  16455.  
  16456. -
  16457.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16458.  with "unsubscribe usr-tc" in the body of the message.
  16459.  For information on digests or retrieving files and old messages send
  16460.  "help" to the same address.  Do not use quotes in your message.
  16461.  
  16462.  
  16463. -------------------------------------------------------------------------------
  16464.  
  16465. From: MegaZone <megazone@megazone.org>
  16466. Subject: Re: (usr-tc) DSP's per Chassis
  16467. Date: 17 Apr 1999 03:36:03 -0700 (PDT)
  16468.  
  16469. Once upon a time Paul Farber shaped the electrons to say...
  16470. >Why do I have a sneaky feeling that doing multi chassis multi link PPP is
  16471. >WAY simpler on other RAS racks?
  16472.  
  16473. Because it is, at least on PortMasters and MAXen.  Cisco can be kind of 
  16474. complex - but that's an IOS trademark.
  16475.  
  16476. -MZ
  16477. -- 
  16478. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  16479. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  16480. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  16481. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  16482.  
  16483. -
  16484.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16485.  with "unsubscribe usr-tc" in the body of the message.
  16486.  For information on digests or retrieving files and old messages send
  16487.  "help" to the same address.  Do not use quotes in your message.
  16488.  
  16489.  
  16490. -------------------------------------------------------------------------------
  16491.  
  16492. From: Brian <signal@shreve.net>
  16493. Subject: (usr-tc) 4.1.59-6 hosing passwords
  16494. Date: 17 Apr 1999 22:46:34 -0500 (CDT)
  16495.  
  16496.  
  16497. Has any progress been made on the problem of 4.1.59-6 munging users
  16498. passwords?  I have seen some cases as of late where it actually hosed
  16499. almost the whole password and not just the last character.  This seems to
  16500. be pretty common problem as well.  I can't see that it actually effects
  16501. only certain users, it seems almost random.
  16502.  
  16503. Brian
  16504.  
  16505.  
  16506. Brian Feeny (BF304)     signal@shreve.net   
  16507. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16508. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16509.  
  16510.  
  16511. -
  16512.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16513.  with "unsubscribe usr-tc" in the body of the message.
  16514.  For information on digests or retrieving files and old messages send
  16515.  "help" to the same address.  Do not use quotes in your message.
  16516.  
  16517.  
  16518. -------------------------------------------------------------------------------
  16519.  
  16520. From: Corneliu Rudeanu <rudy@dntis.ro>
  16521. Subject: (usr-tc) Old 'No Accounting-Stop' issue
  16522. Date: 18 Apr 1999 07:27:24 +0300 (EEST)
  16523.  
  16524.  
  16525. I know it's not a new issue: sometimes I get no accounting stop radius
  16526. packets when the user disconnects. AFAIK there is no solution, even with
  16527. the (beta) TCS. 3.6. Is this correct? (I wish it would not...)
  16528.  
  16529. Is there any 'hand made' solution? As far as I seen, if an user(name)
  16530. disconnect once without any acctStop packet being generated, he wouldn't
  16531. get any acctStop packets even next times he connects/disconnects. All the
  16532. other users' sessions were handled ok, but doesn't make me feel better.
  16533. The only way I could get some acctStop packets for that user was to reboot
  16534. the HiperArc. And I don't call this a solution.
  16535.  
  16536. Any hints? Did anyone try to watch (from the radius server) the Alive
  16537. packets to decide if a session is 'still there'? Are those packets to
  16538. be trusted or they are generated in the same probabilistic way? :/)
  16539.  
  16540. Any idea appreciated.
  16541.  
  16542. Corneliu Rudeanu
  16543. DNT Romania
  16544.  
  16545.  
  16546.  
  16547. -
  16548.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16549.  with "unsubscribe usr-tc" in the body of the message.
  16550.  For information on digests or retrieving files and old messages send
  16551.  "help" to the same address.  Do not use quotes in your message.
  16552.  
  16553.  
  16554. -------------------------------------------------------------------------------
  16555.  
  16556. From: Aaron Nabil <nabil@spiritone.com>
  16557. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  16558. Date: 18 Apr 1999 14:23:02 -0700 (PDT)
  16559.  
  16560. Brian writes...
  16561. >Has any progress been made on the problem of 4.1.59-6 munging users
  16562. >passwords?  I have seen some cases as of late where it actually hosed
  16563. >almost the whole password and not just the last character.  This seems to
  16564. >be pretty common problem as well.  I can't see that it actually effects
  16565. >only certain users, it seems almost random.
  16566.  
  16567. It only affected certain users here, in fact in would hit them
  16568. every time they called in.
  16569.  
  16570. Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP.
  16571.  
  16572. -a
  16573.  
  16574. -
  16575.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16576.  with "unsubscribe usr-tc" in the body of the message.
  16577.  For information on digests or retrieving files and old messages send
  16578.  "help" to the same address.  Do not use quotes in your message.
  16579.  
  16580.  
  16581. -------------------------------------------------------------------------------
  16582.  
  16583. From: Brian <signal@shreve.net>
  16584. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  16585. Date: 18 Apr 1999 18:55:55 -0500 (CDT)
  16586.  
  16587. On Sun, 18 Apr 1999, Aaron Nabil wrote:
  16588.  
  16589. > Brian writes...
  16590. > >Has any progress been made on the problem of 4.1.59-6 munging users
  16591. > >passwords?  I have seen some cases as of late where it actually hosed
  16592. > >almost the whole password and not just the last character.  This seems to
  16593. > >be pretty common problem as well.  I can't see that it actually effects
  16594. > >only certain users, it seems almost random.
  16595. > 
  16596. > It only affected certain users here, in fact in would hit them
  16597. > every time they called in.
  16598. > 
  16599. > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP.
  16600.  
  16601.  
  16602. what negative effects can one expect from ppp offloading?
  16603.  
  16604. > 
  16605. > -a
  16606. > 
  16607. > -
  16608. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16609. >  with "unsubscribe usr-tc" in the body of the message.
  16610. >  For information on digests or retrieving files and old messages send
  16611. >  "help" to the same address.  Do not use quotes in your message.
  16612. > 
  16613.  
  16614. Brian Feeny (BF304)     signal@shreve.net   
  16615. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16616. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16617.  
  16618.  
  16619. -
  16620.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16621.  with "unsubscribe usr-tc" in the body of the message.
  16622.  For information on digests or retrieving files and old messages send
  16623.  "help" to the same address.  Do not use quotes in your message.
  16624.  
  16625.  
  16626. -------------------------------------------------------------------------------
  16627.  
  16628. From: Brian <signal@shreve.net>
  16629. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  16630. Date: 18 Apr 1999 19:29:00 -0500 (CDT)
  16631.  
  16632. On Sun, 18 Apr 1999, Brian wrote:
  16633.  
  16634. > On Sun, 18 Apr 1999, Aaron Nabil wrote:
  16635. > 
  16636. > > Brian writes...
  16637. > > >Has any progress been made on the problem of 4.1.59-6 munging users
  16638. > > >passwords?  I have seen some cases as of late where it actually hosed
  16639. > > >almost the whole password and not just the last character.  This seems to
  16640. > > >be pretty common problem as well.  I can't see that it actually effects
  16641. > > >only certain users, it seems almost random.
  16642. > > 
  16643. > > It only affected certain users here, in fact in would hit them
  16644. > > every time they called in.
  16645. > > 
  16646. > > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP.
  16647. > 
  16648. > 
  16649. > what negative effects can one expect from ppp offloading?
  16650. > 
  16651.  
  16652. correction: that should read "from not using ppp offloading".
  16653.  
  16654. > > 
  16655. > > -a
  16656. > > 
  16657. > > -
  16658. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16659. > >  with "unsubscribe usr-tc" in the body of the message.
  16660. > >  For information on digests or retrieving files and old messages send
  16661. > >  "help" to the same address.  Do not use quotes in your message.
  16662. > > 
  16663. > 
  16664. > -----------------------------------------------------
  16665. > Brian Feeny (BF304)     signal@shreve.net   
  16666. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  16667. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  16668. > 
  16669. > 
  16670. > -
  16671. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16672. >  with "unsubscribe usr-tc" in the body of the message.
  16673. >  For information on digests or retrieving files and old messages send
  16674. >  "help" to the same address.  Do not use quotes in your message.
  16675. > 
  16676.  
  16677. Brian Feeny (BF304)     signal@shreve.net   
  16678. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16679. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16680.  
  16681.  
  16682. -
  16683.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16684.  with "unsubscribe usr-tc" in the body of the message.
  16685.  For information on digests or retrieving files and old messages send
  16686.  "help" to the same address.  Do not use quotes in your message.
  16687.  
  16688.  
  16689. -------------------------------------------------------------------------------
  16690.  
  16691. From: mark@vielle.datasys.net (Mark R. Lindsey)
  16692. Subject: Re: (usr-tc) DSP's per Chassis
  16693. Date: 18 Apr 1999 22:23:54 -0400
  16694.  
  16695. : Once upon a time Paul Farber shaped the electrons to say...
  16696. : >Why do I have a sneaky feeling that doing multi chassis multi link PPP is
  16697. : >WAY simpler on other RAS racks?
  16698. : 
  16699. : Because it is, at least on PortMasters and MAXen.  Cisco can be kind of 
  16700. : complex - but that's an IOS trademark.
  16701.  
  16702. Bah, as Dogbert would say. IOS just doesn't assume you're a dialup ISP.
  16703. And if you are, there are copious, easily-accessible documents
  16704. describing the setup process, and the theory behind it.
  16705.  
  16706.  
  16707.  
  16708.  
  16709.  
  16710. -
  16711.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16712.  with "unsubscribe usr-tc" in the body of the message.
  16713.  For information on digests or retrieving files and old messages send
  16714.  "help" to the same address.  Do not use quotes in your message.
  16715.  
  16716.  
  16717. -------------------------------------------------------------------------------
  16718.  
  16719. From: das <das@gol.com>
  16720. Subject: (usr-tc) ISDN calls being dropped at authentication
  16721. Date: 19 Apr 1999 14:17:37 +0900
  16722.  
  16723. Hello, I posted this a while ago and didn't get a response.  If
  16724. anyone can help with this, I would appreciate it.
  16725.  
  16726. I've got a HiperDSP card running 1.2.2 that will not authenticate users.
  16727. Analog calls authenticate fine and the connection is established.  There
  16728. are no other problems with any of the quads or the other HiperDSP card
  16729. in the same chassis.  I have tried hardware/software resets on the card
  16730. as well as a software reset on the modems.  I have rebooted the
  16731. Netserver card (3.8.1) as well.  The card was originally at 1.2.5 but I
  16732. reflashed it to 1.2.2 to see if that would have any effect.  Nothing has
  16733. worked yet.  Does anyone have any suggestions?
  16734.  
  16735. -- 
  16736. ____________________________________________
  16737. Alex Substanley       Global OnLine Japan
  16738.                 Engineering Department
  16739. Das Man               TEL: 81-3-5334-1700
  16740. Systems Engineer      FAX: 81-3-5334-1711
  16741. ____________________________________________
  16742.  
  16743. -
  16744.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16745.  with "unsubscribe usr-tc" in the body of the message.
  16746.  For information on digests or retrieving files and old messages send
  16747.  "help" to the same address.  Do not use quotes in your message.
  16748.  
  16749.  
  16750. -------------------------------------------------------------------------------
  16751.  
  16752. From: Stefanita Vilcu <vsv@dnt.ro>
  16753. Subject: (usr-tc) tricking the HiperARC init string
  16754. Date: 19 Apr 1999 10:35:58 +0300
  16755.  
  16756. Hi,
  16757.  
  16758. I am looking for a  metod to skip the init string sended by the HiperARC
  16759. to the modem when it initializes for the first time the modem.  The
  16760. issue is that my modem is configured on leased line and the HiperARC
  16761. resets the &L1 switch.  The Init String from the interface configuration
  16762. is sent after the modem resets (I've tried to put &L1 in the InitString
  16763. on the set switched interface command).
  16764.  
  16765. TIA,
  16766.  
  16767. -vsv
  16768. --
  16769. Stefanita Valeriu Vilcu, Network Administrator
  16770. Dynamic Network Technologies
  16771. Calea Victoriei 155, bl. D1, sc. 8, et. 2
  16772. tel: +40-1-2106863 fax: +40-1-3122745 e-mail: vsv@dnt.ro
  16773. http://www.dnt.ro/~vsv/
  16774.  
  16775.  
  16776.  
  16777. -
  16778.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16779.  with "unsubscribe usr-tc" in the body of the message.
  16780.  For information on digests or retrieving files and old messages send
  16781.  "help" to the same address.  Do not use quotes in your message.
  16782.  
  16783.  
  16784. -------------------------------------------------------------------------------
  16785.  
  16786. From: Robert von Bismarck <rvb@petrel.ch>
  16787. Subject: RE: (usr-tc) DSP's per Chassis
  16788. Date: 19 Apr 1999 12:08:38 +0200
  16789.  
  16790. Heh... it's like winblows (tm), it works fine after revision 2 ;-)
  16791.  
  16792.  
  16793. ---
  16794. Robert von Bismarck
  16795. Network Systems Engineer
  16796. Petrel Communications SA / SPAN
  16797. Tel : +41 22 304 47 47
  16798. Fax : +41 22 300 48 43
  16799. e-mail : rvb@petrel.ch
  16800.  
  16801.  
  16802.     -----Original Message-----
  16803.     From:    Jeff Mcadams [SMTP:jeffm@iglou.com]
  16804.     Sent:    vendredi, 16. avril 1999 18:07
  16805.     To:    usr-tc@lists.xmission.com
  16806.     Subject:    Re: (usr-tc) DSP's per Chassis
  16807.  
  16808.     Thus spake Robert von Bismarck
  16809.     >The ARC 4.1.72-7 has a very nasty memory leak when doing
  16810. Multi-chassis PPP,
  16811.     >I recommend upgrading to 4.1.59-2. This is the only problem we have
  16812. seen so
  16813.     >far, not very much demand for it though...
  16814.  
  16815.     Actually, I'd suggest 4.1.59-6, which is the service release.  We're
  16816.     only on -2 because -6 apparently (from what I've been able to
  16817. determine)
  16818.     is missing a really teeny, tiny feature, that unfortunately we need,
  16819. so
  16820.     I'm still on -2.  Hopefully, with the next release or SR, I'll catch
  16821. up with the
  16822.     rest of the world, though I'm suspecting that'll be the 4.2 release
  16823.     which I proly won't want to touch until at least the second SR of
  16824. 4.2.
  16825.     :/
  16826.     -- 
  16827.     Jeff McAdams                            Email: jeffm@iglou.com
  16828.     Head Network Administrator              Voice: (502) 966-3848
  16829.     IgLou Internet Services                        (800) 436-4456
  16830.  
  16831.     -
  16832.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16833.      with "unsubscribe usr-tc" in the body of the message.
  16834.      For information on digests or retrieving files and old messages
  16835. send
  16836.      "help" to the same address.  Do not use quotes in your message.
  16837.  
  16838. -
  16839.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16840.  with "unsubscribe usr-tc" in the body of the message.
  16841.  For information on digests or retrieving files and old messages send
  16842.  "help" to the same address.  Do not use quotes in your message.
  16843.  
  16844.  
  16845. -------------------------------------------------------------------------------
  16846.  
  16847. From: mmm3@cornell.edu
  16848. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  16849. Date: 19 Apr 1999 09:26:39 -0400
  16850.  
  16851. >No, not great redundany, there seems to be a limit of how many DSP's the
  16852. >ARC can handle, so for a 10-14 DSP chassis, you would need 3 ARC's, as no
  16853. >ONE card would be able to handle all the DPS's reliably.
  16854.  
  16855. It's my understanding (and I've been know to be wrong...) that you're
  16856. limited to two ARCs in a chassis.
  16857.  
  16858.  
  16859. *********************************************************
  16860. Michelle M. Mogil
  16861. N&CS, Network Operations Center
  16862. Rhodes Hall, Cornell University, Ithaca, NY 14853
  16863. vox: (607) 255-0516, fax: (607) 255-8420
  16864. email: mmm3@cornell.edu
  16865. **********************************************
  16866.  
  16867.  
  16868.  
  16869. -
  16870.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16871.  with "unsubscribe usr-tc" in the body of the message.
  16872.  For information on digests or retrieving files and old messages send
  16873.  "help" to the same address.  Do not use quotes in your message.
  16874.  
  16875.  
  16876. -------------------------------------------------------------------------------
  16877.  
  16878. From: Paul Curnock <Paul_Curnock@pervasive.co.uk>
  16879. Subject: RE: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  16880. Date: 19 Apr 1999 14:31:52 +0100
  16881.  
  16882. I believe that new code is being beta tested to allow a single HiperARC to
  16883. support the entire chassis(but this is to try to provide load sharing over
  16884. multiple ARCs).  I'm pretty sure that you can have more than two ARCs per
  16885. chassis to provide alternate services based on DNIS numbers?, but I think
  16886. that you need a HiperNMC to speed things up a bit.
  16887.  
  16888.         -----Original Message-----
  16889.         From:    mmm3@cornell.edu [mailto:mmm3@cornell.edu]
  16890.         Sent:    19 April 1999 14:27
  16891.         To:    usr-tc@lists.xmission.com
  16892.         Subject:    Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't
  16893. work yet
  16894.  
  16895.         >No, not great redundany, there seems to be a limit of how
  16896. many DSP's the
  16897.         >ARC can handle, so for a 10-14 DSP chassis, you would need
  16898. 3 ARC's, as no
  16899.         >ONE card would be able to handle all the DPS's reliably.
  16900.  
  16901.         It's my understanding (and I've been know to be wrong...)
  16902. that you're
  16903.         limited to two ARCs in a chassis.
  16904.  
  16905.  
  16906.         *********************************************************
  16907.         Michelle M. Mogil
  16908.         N&CS, Network Operations Center
  16909.         Rhodes Hall, Cornell University, Ithaca, NY 14853
  16910.         vox: (607) 255-0516, fax: (607) 255-8420
  16911.         email: mmm3@cornell.edu
  16912.         **********************************************
  16913.  
  16914.  
  16915.  
  16916.         -
  16917.          To unsubscribe to usr-tc, send an email to
  16918. "majordomo@xmission.com"
  16919.          with "unsubscribe usr-tc" in the body of the message.
  16920.          For information on digests or retrieving files and old
  16921. messages send
  16922.          "help" to the same address.  Do not use quotes in your
  16923. message.
  16924.  
  16925. -
  16926.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16927.  with "unsubscribe usr-tc" in the body of the message.
  16928.  For information on digests or retrieving files and old messages send
  16929.  "help" to the same address.  Do not use quotes in your message.
  16930.  
  16931.  
  16932. -------------------------------------------------------------------------------
  16933.  
  16934. From: Paul Curnock <Paul_Curnock@pervasive.co.uk>
  16935. Subject: RE: (usr-tc) ISDN calls being dropped at authentication
  16936. Date: 19 Apr 1999 14:34:53 +0100
  16937.  
  16938. Have you checked that at*v2=0 setting you the modems?  Just a suggestion...
  16939.  
  16940.     -----Original Message-----
  16941.     From:    das [mailto:das@gol.com]
  16942.     Sent:    19 April 1999 06:18
  16943.     To:    usr-tc@lists.xmission.com
  16944.     Subject:    (usr-tc) ISDN calls being dropped at authentication
  16945.  
  16946.     Hello, I posted this a while ago and didn't get a response.  If
  16947.     anyone can help with this, I would appreciate it.
  16948.  
  16949.     I've got a HiperDSP card running 1.2.2 that will not authenticate
  16950. users.
  16951.     Analog calls authenticate fine and the connection is established.
  16952. There
  16953.     are no other problems with any of the quads or the other HiperDSP
  16954. card
  16955.     in the same chassis.  I have tried hardware/software resets on the
  16956. card
  16957.     as well as a software reset on the modems.  I have rebooted the
  16958.     Netserver card (3.8.1) as well.  The card was originally at 1.2.5
  16959. but I
  16960.     reflashed it to 1.2.2 to see if that would have any effect.  Nothing
  16961. has
  16962.     worked yet.  Does anyone have any suggestions?
  16963.  
  16964.     -- 
  16965.     ____________________________________________
  16966.     Alex Substanley       Global OnLine Japan
  16967.                     Engineering Department
  16968.     Das Man               TEL: 81-3-5334-1700
  16969.     Systems Engineer      FAX: 81-3-5334-1711
  16970.     ____________________________________________
  16971.  
  16972.     -
  16973.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16974.      with "unsubscribe usr-tc" in the body of the message.
  16975.      For information on digests or retrieving files and old messages
  16976. send
  16977.      "help" to the same address.  Do not use quotes in your message.
  16978.  
  16979. -
  16980.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16981.  with "unsubscribe usr-tc" in the body of the message.
  16982.  For information on digests or retrieving files and old messages send
  16983.  "help" to the same address.  Do not use quotes in your message.
  16984.  
  16985.  
  16986. -------------------------------------------------------------------------------
  16987.  
  16988. From: "Tony Loosle" <tony@tcsourceone.com>
  16989. Subject: Re: (usr-tc) Stack Compression on Webramp causing problems
  16990. Date: 19 Apr 1999 08:57:00 -0600
  16991.  
  16992. your message is from awhile ago.  Did you find the problem?  was the
  16993. compression the reason for the problem?  How did you turn it off??
  16994.  
  16995. thanks!!
  16996.  
  16997. tony
  16998.  
  16999.  
  17000. Mark Lemmert wrote:
  17001.  
  17002. > I have several webramp customers that are having trouble. I've
  17003. > isolated the problem with 3com and if I turn off 'stack compression'
  17004. > on the webramp everything should work fine.
  17005. >
  17006. > I've looked through all the webramp pdf docs and I can't find anywhere
  17007. > the command or place on the web interface to set this on or off.
  17008. > Does anybody know how to do this? Thanks!
  17009. >
  17010. > -Mark Lemmert                           AthEnet Data Exchange
  17011. > Chief Technical Officer                 888-919-8700
  17012. >
  17013. > -
  17014. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17015. >  with "unsubscribe usr-tc" in the body of the message.
  17016. >  For information on digests or retrieving files and old messages send
  17017. >  "help" to the same address.  Do not use quotes in your message.
  17018.  
  17019.  
  17020. -
  17021.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17022.  with "unsubscribe usr-tc" in the body of the message.
  17023.  For information on digests or retrieving files and old messages send
  17024.  "help" to the same address.  Do not use quotes in your message.
  17025.  
  17026.  
  17027. -------------------------------------------------------------------------------
  17028.  
  17029. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  17030. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  17031. Date: 19 Apr 1999 09:58:54 -0500
  17032.  
  17033. |-----Original Message-----
  17034. |From: owner-usr-tc@lists.xmission.com
  17035. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  17036. |Sent: Sunday, April 18, 1999 7:29 PM
  17037. |To: usr-tc@lists.xmission.com
  17038. |Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  17039. |
  17040. |
  17041. |On Sun, 18 Apr 1999, Brian wrote:
  17042. |
  17043. |> On Sun, 18 Apr 1999, Aaron Nabil wrote:
  17044. |>
  17045. |> > Brian writes...
  17046. |> > >Has any progress been made on the problem of 4.1.59-6 munging users
  17047. |> > >passwords?  I have seen some cases as of late where it actually hosed
  17048. |> > >almost the whole password and not just the last character.  This seems to
  17049. |> > >be pretty common problem as well.  I can't see that it actually effects
  17050. |> > >only certain users, it seems almost random.
  17051. |> >
  17052. |> > It only affected certain users here, in fact in would hit them
  17053. |> > every time they called in.
  17054. |> >
  17055. |> > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP.
  17056. |>
  17057. |>
  17058. |> what negative effects can one expect from ppp offloading?
  17059. |>
  17060. |
  17061. |correction: that should read "from not using ppp offloading".
  17062. |
  17063.  
  17064. Not much from a performance standpoint. The feature allows the DSP's to share
  17065. some of the overhead of PPP with the HARC. (Normally the modem does not have any
  17066. knowledge of PPP its only a data pipe). By disabling offloading the HARC will
  17067. handle all aspects of the PPP termination. The HARC has more than enough power to
  17068. do this with almost no noticalbe change in performance to the dial user.  How
  17069. many DSP's does your HARC control?
  17070.  
  17071. -M
  17072.  
  17073.  
  17074. -
  17075.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17076.  with "unsubscribe usr-tc" in the body of the message.
  17077.  For information on digests or retrieving files and old messages send
  17078.  "help" to the same address.  Do not use quotes in your message.
  17079.  
  17080.  
  17081. -------------------------------------------------------------------------------
  17082.  
  17083. From: <sagarwal@crash.ae.usr.com>
  17084. Subject: Re: (usr-tc) Stack Compression on Webramp causing problems
  17085. Date: 19 Apr 1999 10:06:27 -0500 (CDT)
  17086.  
  17087. In the webramp GUI if you go to the advanced configuration section
  17088. you will find the option to disable the STAC compression. From
  17089. the command line you can use the setprofile command to do the
  17090. same.
  17091.  
  17092. setprofile "-n < profile id> -S < 1- enable 0 - disable>"
  17093.  
  17094. Sanjay
  17095.  
  17096. On Mon, 19 Apr 1999, Tony Loosle wrote:
  17097.  
  17098. > your message is from awhile ago.  Did you find the problem?  was the
  17099. > compression the reason for the problem?  How did you turn it off??
  17100. > 
  17101. > thanks!!
  17102. > 
  17103. > tony
  17104. > 
  17105. > 
  17106. > Mark Lemmert wrote:
  17107. > 
  17108. > > I have several webramp customers that are having trouble. I've
  17109. > > isolated the problem with 3com and if I turn off 'stack compression'
  17110. > > on the webramp everything should work fine.
  17111. > >
  17112. > > I've looked through all the webramp pdf docs and I can't find anywhere
  17113. > > the command or place on the web interface to set this on or off.
  17114. > > Does anybody know how to do this? Thanks!
  17115. > >
  17116. > > -Mark Lemmert                           AthEnet Data Exchange
  17117. > > Chief Technical Officer                 888-919-8700
  17118. > >
  17119. > > -
  17120. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17121. > >  with "unsubscribe usr-tc" in the body of the message.
  17122. > >  For information on digests or retrieving files and old messages send
  17123. > >  "help" to the same address.  Do not use quotes in your message.
  17124. > 
  17125. > 
  17126. > -
  17127. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17128. >  with "unsubscribe usr-tc" in the body of the message.
  17129. >  For information on digests or retrieving files and old messages send
  17130. >  "help" to the same address.  Do not use quotes in your message.
  17131. > 
  17132.  
  17133.  
  17134. -
  17135.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17136.  with "unsubscribe usr-tc" in the body of the message.
  17137.  For information on digests or retrieving files and old messages send
  17138.  "help" to the same address.  Do not use quotes in your message.
  17139.  
  17140.  
  17141. -------------------------------------------------------------------------------
  17142.  
  17143. From: Chris Peltier <cpeltier@netcarrier.com>
  17144. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  17145. Date: 19 Apr 1999 11:27:42 -0400
  17146.  
  17147.  
  17148.  
  17149. > |> what negative effects can one expect from ppp offloading?
  17150. > |>
  17151. Will this effect Webramp users?
  17152.  
  17153. -Chris 
  17154.  
  17155. -
  17156.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17157.  with "unsubscribe usr-tc" in the body of the message.
  17158.  For information on digests or retrieving files and old messages send
  17159.  "help" to the same address.  Do not use quotes in your message.
  17160.  
  17161.  
  17162. -------------------------------------------------------------------------------
  17163.  
  17164. From: Pete Ashdown <pashdown@xmission.com>
  17165. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  17166. Date: 19 Apr 1999 09:32:02 -0600 (MDT)
  17167.  
  17168. Paul Farber said once upon a time:
  17169.  
  17170. >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  17171. >would suck if the ARC has a 7 DSP limit. 
  17172.  
  17173. I have been running with 11 DSP's per chassis for almost as long as the
  17174. HiPer system has been out.  It works just fine, and segments nicely (253
  17175. ISDN B channels = /24 subnet - 1).
  17176.  
  17177. -
  17178.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17179.  with "unsubscribe usr-tc" in the body of the message.
  17180.  For information on digests or retrieving files and old messages send
  17181.  "help" to the same address.  Do not use quotes in your message.
  17182.  
  17183.  
  17184. -------------------------------------------------------------------------------
  17185.  
  17186. From: "Roy, Richard" <richard.roy@nbtel.nb.ca>
  17187. Subject: (usr-tc) syslog + PPP critical message going at the console.
  17188. Date: 16 Apr 1999 09:58:38 -0300
  17189.  
  17190.  
  17191. We are using 4.1.59-6 HA code and I'm using syslog to capture logs. If a
  17192. user enter a wrong password, I receive a critical PPP message on the
  17193. console. Here an example:
  17194.  
  17195. Version 4.0.35
  17196. # tail  auth.log | grep rro
  17197. Apr 15 11:30:51 stjhts18c.nbnet.nb.ca At 14:30:51, Facility "Auth Facility",
  17198. Lev
  17199. el "COMMON":: Port slot:15/mod:13 unable to authenticate user - RADIUS
  17200. failure f
  17201. or: rro
  17202.  
  17203. Version 4.1.59-6
  17204. Apr 15 11:48:06 mctnts05c.nbnet.nb.ca At 14:48:06, Facility "Auth Facility",
  17205. Lev
  17206. el "COMMON":: Port slot:14/mod:1 unable to authenticate user - RADIUS
  17207. failure fo
  17208. r: rro
  17209. Apr 15 11:48:06 mctnts05c.nbnet.nb.ca At 14:48:06, Facility "PPP", Level
  17210. "CRITIC
  17211. AL":: PPP  login failed on slot:14/mod:1 id: 218105418 username: rro
  17212.  
  17213. As you can see, 4.1.59-6 adds an extra record in the log. I called 3Com
  17214. support and they recommend me to do the following:
  17215. set accounting log_unauthenticated_calls false
  17216.  
  17217. It didn't stop the error message going at the console. Also, I changed the
  17218. loglevel for facility PPP and still have the same behaviors.
  17219.  
  17220. If someone has a solution to stop "Critical PPP" error messages going at the
  17221. console, please let me know.
  17222.  
  17223. Thank you.
  17224.  
  17225. Richard Roy
  17226. NBTel Internet
  17227. www.nbtel.nb.ca <http://www.nbtel.nb.ca> 
  17228. www.nbnet.nb.ca
  17229.  
  17230. -
  17231.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17232.  with "unsubscribe usr-tc" in the body of the message.
  17233.  For information on digests or retrieving files and old messages send
  17234.  "help" to the same address.  Do not use quotes in your message.
  17235.  
  17236.  
  17237. -------------------------------------------------------------------------------
  17238.  
  17239. From: "Andres Kroonmaa" <andre@ml.ee>
  17240. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  17241. Date: 19 Apr 1999 18:50:52 +0200 EET
  17242.  
  17243.  
  17244. On 19 Apr 99, at 9:58, Mike Wronski <usr-tc@lists.xmission.com> wrote:
  17245. > |> > Brian writes...
  17246. > |> > >Has any progress been made on the problem of 4.1.59-6 munging users
  17247. > |> > >passwords?  I have seen some cases as of late where it actually hosed
  17248. > |> > >almost the whole password and not just the last character.  This seems to
  17249. > |> > >be pretty common problem as well.  I can't see that it actually effects
  17250. > |> > >only certain users, it seems almost random.
  17251. > |> >
  17252. > |> > It only affected certain users here, in fact in would hit them
  17253. > |> > every time they called in.
  17254. > |> >
  17255. > |> > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP.
  17256. > |>
  17257. > |> what negative effects can one expect from ppp offloading?
  17258. > |
  17259. > |correction: that should read "from not using ppp offloading".
  17260. > 
  17261. > Not much from a performance standpoint. The feature allows the DSP's to share
  17262. > some of the overhead of PPP with the HARC. (Normally the modem does not have any
  17263. > knowledge of PPP its only a data pipe). By disabling offloading the HARC will
  17264. > handle all aspects of the PPP termination. The HARC has more than enough power to
  17265. > do this with almost no noticalbe change in performance to the dial user.  How
  17266. > many DSP's does your HARC control?
  17267.  
  17268.  I've been assuming that making modem aware of PPP framing makes it possible
  17269.  for modem to do "per-packet" instead of "per-v42-buffer" compression, and
  17270.  that being the whole point of PPP offloading. With modem not knowing or
  17271.  caring what it is piping, it would love to wait for more data to come from
  17272.  HARC before sending a buffer to remote end. This could translate into
  17273.  increased latency for small packets like acks. But I'm not sure if this is
  17274.  sane assumption, as ARC and modems are communicating with packets anyway.
  17275.  I'd agree that turning off PPP offloading has little to no impact on HARC's
  17276.  CPU utilisation, but is it the same with client perception of performance?
  17277.  If so, then what's the point in this offloading altogether (other than adding
  17278.  another nice place in code to introduce bugs)?
  17279.  Mike, could you clarify on that matter?
  17280.  
  17281.  PS. Can anyone from 3com shed some light on when hdm E1-PRI service release
  17282.  it out?
  17283.  
  17284.  
  17285.  ----------------------------------------------------------------------
  17286.   Andres Kroonmaa                                mail: andre@online.ee
  17287.   Senior Network Engineer
  17288.   Organization:            MicroLink Online       Tel:        6308 909
  17289.   Tallinn, Sakala 19                              Pho:  +372  6308 909
  17290.   Estonia, EE0001        http://www.online.ee     Fax:  +372  6308 901
  17291.  ----------------------------------------------------------------------
  17292.  
  17293. -
  17294.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17295.  with "unsubscribe usr-tc" in the body of the message.
  17296.  For information on digests or retrieving files and old messages send
  17297.  "help" to the same address.  Do not use quotes in your message.
  17298.  
  17299.  
  17300. -------------------------------------------------------------------------------
  17301.  
  17302. From: Brian Elfert <brian@citilink.com>
  17303. Subject: (usr-tc) T1 receive levels
  17304. Date: 19 Apr 1999 13:38:26 -0500 (CDT)
  17305.  
  17306. How can I determine the receive level on a span on a T1 card?
  17307.  
  17308. Brian
  17309.  
  17310.  
  17311. -
  17312.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17313.  with "unsubscribe usr-tc" in the body of the message.
  17314.  For information on digests or retrieving files and old messages send
  17315.  "help" to the same address.  Do not use quotes in your message.
  17316.  
  17317.  
  17318. -------------------------------------------------------------------------------
  17319.  
  17320. From: "Sam Lowe" <slowe@universalcom.net>
  17321. Subject: (usr-tc) Lost ISDN connectivity
  17322. Date: 19 Apr 1999 14:13:25 -0500
  17323.  
  17324. We rebooted out TC last night and lost the ability for ISDN users to
  17325. connect.  Nothing had changed that we know of.  We had previously disabled
  17326. ppp offloading to accomodate our webramp users.  Once we enabled it, the
  17327. ISDN users could connect.  We disabled it again so the webramps could come
  17328. in, and now everything seems to work.  Any explanations?
  17329.  
  17330. I have followed the webramp issues for some time, and disabling the ppp
  17331. offloading is the only fix that seems to work.  Has anyone found a more
  17332. definitive answer?
  17333.  
  17334. How/why does this affect my ISDN customers?
  17335.  
  17336.  
  17337. Samuel S. Lowe
  17338. Director, Data Network Services
  17339. UniversalCom, Inc.
  17340. slowe@universalcom.net
  17341.  
  17342.  
  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: ROC Services <rocsoft@itol.com>
  17354. Subject: (usr-tc) Looping LCP with Cisco 700 series
  17355. Date: 19 Apr 1999 14:59:01 -0500 (CDT)
  17356.  
  17357. Yet another interesting, maybe HiPer-related issue:  
  17358.  
  17359. I've got an ISDN customer who's unable to connect with a Cisco 766 router.  
  17360. Others with Cisco 7xx series routers seem to have no problem.  This guy
  17361. had a Cisco technician on the phone, who mentioned that I need to obtain a
  17362. patch from 3Com to deal with "looping LCP" and that 3Com would know
  17363. "exactly what I'm talking about."
  17364.  
  17365. On this end, it looks like the HiPer's doing exactly what it should be.
  17366. We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats.  The Cisco
  17367. tech says that the router never sees the ACK.
  17368.  
  17369. Is this a 3Com issue, or a Cisco issue?  I'm pointing my finger at the
  17370. 766, Cisco is pointing fingers at the HiPer.
  17371.  
  17372. HARC 4.1.59-6, HDSP 2.1.43
  17373.  
  17374. PPP Offloading is currently disabled, because it seems to eliminate the
  17375. password-munging problem that has been discussed lately.  I tried enabling
  17376. it and it didn't make any difference.  RECEIVE_ACCM is also disabled, it
  17377. seems I recall something about certain ISDN routers becoming unhappy with
  17378. that setting enabled.
  17379.  
  17380. I've seen my share of problems with the 760 series of routers, and
  17381. wouldn't mind at all telling the customer to get an 800 series, which
  17382. we've never had any trouble with.  But, since this Cisco tech seems firmly
  17383. convinced that it's a 3Com issue and that a fix is available, I thought
  17384. I'd send it in the general direction of 3Com and some users of 3Com
  17385. equipment.
  17386.  
  17387. Here's the "mon ppp" output, which to me looks like the HiPer is doing
  17388. exactly what it should be:
  17389.  
  17390. Outgoing PPP Data on interface: slot:2/mod:14
  17391.     LCP        CFG_REQ           MRU            05 ea
  17392.                                  ASYNC_MAP      00 00 00 00
  17393.                                  AUTH_TYPE      c0 23
  17394.                                  MAGIC_NUM      54 86 e1 99
  17395.                                  PROTO_COMP
  17396.                                  AC_COMP
  17397.                                  MPP_MRRU       05 ea
  17398.                                  MPP_ENDPTID    00
  17399.  
  17400. Incoming PPP Data on interface: slot:2/mod:14
  17401.     LCP        CFG_REQ           MRU            05 f2
  17402.                                  MAGIC_NUM      00 12 6d 71
  17403.                                  MPP_MRRU       07 08
  17404.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17405.                                  LINK_DESCR     00 11
  17406.  
  17407. Outgoing PPP Data on interface: slot:2/mod:14
  17408.     LCP        CFG_ACK           MRU            05 f2
  17409.                                  MAGIC_NUM      00 12 6d 71
  17410.                                  MPP_MRRU       07 08
  17411.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17412.                                  LINK_DESCR     00 11
  17413.  
  17414. Outgoing PPP Data on interface: slot:2/mod:14
  17415.     LCP        CFG_REQ           MRU            05 ea
  17416.                                  ASYNC_MAP      00 00 00 00
  17417.                                  AUTH_TYPE      c0 23
  17418.                                  MAGIC_NUM      54 86 e1 99
  17419.                                  PROTO_COMP
  17420.                                  AC_COMP
  17421.                                  MPP_MRRU       05 ea
  17422.                                  MPP_ENDPTID    00
  17423.  
  17424. Incoming PPP Data on interface: slot:2/mod:14
  17425.     LCP        CFG_REQ           MRU            05 f2
  17426.                                  MAGIC_NUM      00 12 6d 71
  17427.                                  MPP_MRRU       07 08
  17428.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17429.                                  LINK_DESCR     00 11
  17430.  
  17431. Outgoing PPP Data on interface: slot:2/mod:14
  17432.     LCP        CFG_ACK           MRU            05 f2
  17433.                                  MAGIC_NUM      00 12 6d 71
  17434.                                  MPP_MRRU       07 08
  17435.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17436.                                  LINK_DESCR     00 11
  17437.  
  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: ROC Services <rocsoft@itol.com>
  17451. Subject: (usr-tc) Looping LCP with Cisco 700 series
  17452. Date: 19 Apr 1999 14:59:01 -0500 (CDT)
  17453.  
  17454. Yet another interesting, maybe HiPer-related issue:  
  17455.  
  17456. I've got an ISDN customer who's unable to connect with a Cisco 766 router.  
  17457. Others with Cisco 7xx series routers seem to have no problem.  This guy
  17458. had a Cisco technician on the phone, who mentioned that I need to obtain a
  17459. patch from 3Com to deal with "looping LCP" and that 3Com would know
  17460. "exactly what I'm talking about."
  17461.  
  17462. On this end, it looks like the HiPer's doing exactly what it should be.
  17463. We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats.  The Cisco
  17464. tech says that the router never sees the ACK.
  17465.  
  17466. Is this a 3Com issue, or a Cisco issue?  I'm pointing my finger at the
  17467. 766, Cisco is pointing fingers at the HiPer.
  17468.  
  17469. HARC 4.1.59-6, HDSP 2.1.43
  17470.  
  17471. PPP Offloading is currently disabled, because it seems to eliminate the
  17472. password-munging problem that has been discussed lately.  I tried enabling
  17473. it and it didn't make any difference.  RECEIVE_ACCM is also disabled, it
  17474. seems I recall something about certain ISDN routers becoming unhappy with
  17475. that setting enabled.
  17476.  
  17477. I've seen my share of problems with the 760 series of routers, and
  17478. wouldn't mind at all telling the customer to get an 800 series, which
  17479. we've never had any trouble with.  But, since this Cisco tech seems firmly
  17480. convinced that it's a 3Com issue and that a fix is available, I thought
  17481. I'd send it in the general direction of 3Com and some users of 3Com
  17482. equipment.
  17483.  
  17484. Here's the "mon ppp" output, which to me looks like the HiPer is doing
  17485. exactly what it should be:
  17486.  
  17487. Outgoing PPP Data on interface: slot:2/mod:14
  17488.     LCP        CFG_REQ           MRU            05 ea
  17489.                                  ASYNC_MAP      00 00 00 00
  17490.                                  AUTH_TYPE      c0 23
  17491.                                  MAGIC_NUM      54 86 e1 99
  17492.                                  PROTO_COMP
  17493.                                  AC_COMP
  17494.                                  MPP_MRRU       05 ea
  17495.                                  MPP_ENDPTID    00
  17496.  
  17497. Incoming PPP Data on interface: slot:2/mod:14
  17498.     LCP        CFG_REQ           MRU            05 f2
  17499.                                  MAGIC_NUM      00 12 6d 71
  17500.                                  MPP_MRRU       07 08
  17501.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17502.                                  LINK_DESCR     00 11
  17503.  
  17504. Outgoing PPP Data on interface: slot:2/mod:14
  17505.     LCP        CFG_ACK           MRU            05 f2
  17506.                                  MAGIC_NUM      00 12 6d 71
  17507.                                  MPP_MRRU       07 08
  17508.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17509.                                  LINK_DESCR     00 11
  17510.  
  17511. Outgoing PPP Data on interface: slot:2/mod:14
  17512.     LCP        CFG_REQ           MRU            05 ea
  17513.                                  ASYNC_MAP      00 00 00 00
  17514.                                  AUTH_TYPE      c0 23
  17515.                                  MAGIC_NUM      54 86 e1 99
  17516.                                  PROTO_COMP
  17517.                                  AC_COMP
  17518.                                  MPP_MRRU       05 ea
  17519.                                  MPP_ENDPTID    00
  17520.  
  17521. Incoming PPP Data on interface: slot:2/mod:14
  17522.     LCP        CFG_REQ           MRU            05 f2
  17523.                                  MAGIC_NUM      00 12 6d 71
  17524.                                  MPP_MRRU       07 08
  17525.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17526.                                  LINK_DESCR     00 11
  17527.  
  17528. Outgoing PPP Data on interface: slot:2/mod:14
  17529.     LCP        CFG_ACK           MRU            05 f2
  17530.                                  MAGIC_NUM      00 12 6d 71
  17531.                                  MPP_MRRU       07 08
  17532.                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17533.                                  LINK_DESCR     00 11
  17534.  
  17535.  
  17536.  
  17537.  
  17538. -
  17539.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17540.  with "unsubscribe usr-tc" in the body of the message.
  17541.  For information on digests or retrieving files and old messages send
  17542.  "help" to the same address.  Do not use quotes in your message.
  17543.  
  17544.  
  17545. -------------------------------------------------------------------------------
  17546.  
  17547. From: Brian <signal@shreve.net>
  17548. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  17549. Date: 19 Apr 1999 16:40:05 -0500 (CDT)
  17550.  
  17551. On Mon, 19 Apr 1999, Pete Ashdown wrote:
  17552.  
  17553. > Paul Farber said once upon a time:
  17554. > 
  17555. > >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  17556. > >would suck if the ARC has a 7 DSP limit. 
  17557. > 
  17558. > I have been running with 11 DSP's per chassis for almost as long as the
  17559. > HiPer system has been out.  It works just fine, and segments nicely (253
  17560. > ISDN B channels = /24 subnet - 1).
  17561.  
  17562. Pete, so thats 11 DSP's per arc as well? (you said "per chassis" I was
  17563. unclear to the number of ARC's you meant).
  17564.  
  17565.  
  17566.  
  17567. > 
  17568. > -
  17569. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17570. >  with "unsubscribe usr-tc" in the body of the message.
  17571. >  For information on digests or retrieving files and old messages send
  17572. >  "help" to the same address.  Do not use quotes in your message.
  17573. > 
  17574.  
  17575. Brian Feeny (BF304)     signal@shreve.net   
  17576. 318-222-2638 x 109    http://www.shreve.net/~signal      
  17577. Network Administrator   ShreveNet Inc. (ASN 11881)           
  17578.  
  17579.  
  17580. -
  17581.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17582.  with "unsubscribe usr-tc" in the body of the message.
  17583.  For information on digests or retrieving files and old messages send
  17584.  "help" to the same address.  Do not use quotes in your message.
  17585.  
  17586.  
  17587. -------------------------------------------------------------------------------
  17588.  
  17589. From: Brian <signal@shreve.net>
  17590. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  17591. Date: 19 Apr 1999 16:38:48 -0500 (CDT)
  17592.  
  17593. > 
  17594. > Not much from a performance standpoint. The feature allows the DSP's to share
  17595. > some of the overhead of PPP with the HARC. (Normally the modem does not have any
  17596. > knowledge of PPP its only a data pipe). By disabling offloading the HARC will
  17597. > handle all aspects of the PPP termination. The HARC has more than enough power to
  17598. > do this with almost no noticalbe change in performance to the dial user.  How
  17599. > many DSP's does your HARC control?
  17600.  
  17601. 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  17602. getting munged in 1.2.43.  If this is the case, than certainly everyone
  17603. should do it right?
  17604.  
  17605.  
  17606. > 
  17607. > -M
  17608. > 
  17609. > 
  17610. > -
  17611. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17612. >  with "unsubscribe usr-tc" in the body of the message.
  17613. >  For information on digests or retrieving files and old messages send
  17614. >  "help" to the same address.  Do not use quotes in your message.
  17615. > 
  17616.  
  17617. Brian Feeny (BF304)     signal@shreve.net   
  17618. 318-222-2638 x 109    http://www.shreve.net/~signal      
  17619. Network Administrator   ShreveNet Inc. (ASN 11881)           
  17620.  
  17621.  
  17622. -
  17623.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17624.  with "unsubscribe usr-tc" in the body of the message.
  17625.  For information on digests or retrieving files and old messages send
  17626.  "help" to the same address.  Do not use quotes in your message.
  17627.  
  17628.  
  17629. -------------------------------------------------------------------------------
  17630.  
  17631. From: access1 <access1@simplyweb.net>
  17632. Subject: (usr-tc) WTB USR NetServer PRI 
  17633. Date: 19 Apr 1999 14:51:19 -0700
  17634.  
  17635. We need a NetServer PRI card set as a back-up. Anyone, please provide
  17636.   availability and a great price so we can buy one. Prefer p/n 002469
  17637. but will
  17638.   also accept 00972. COD cashiers to seller.
  17639.  
  17640.   _________________________________
  17641.  
  17642.  
  17643. -
  17644.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17645.  with "unsubscribe usr-tc" in the body of the message.
  17646.  For information on digests or retrieving files and old messages send
  17647.  "help" to the same address.  Do not use quotes in your message.
  17648.  
  17649.  
  17650. -------------------------------------------------------------------------------
  17651.  
  17652. From: <sagarwal@crash.ae.usr.com>
  17653. Subject: Re: (usr-tc) Looping LCP with Cisco 700 series
  17654. Date: 19 Apr 1999 16:48:06 -0500 (CDT)
  17655.  
  17656. Cisco 766 Router works fine with Hiper ARC 4.1.59-6 and HDSP 1.2.43 code.
  17657. What are you trying to setup  MLPPP or MPIP.
  17658.  
  17659. Is Cisco 766 setup to do CHAP or PAP. I tested MPIP with Cisco 766 and it
  17660. worked fine. 
  17661.  
  17662. There is no patch on our side. Some thing to do with Cisco
  17663. configuration. Also install the latest code on Cisco 766 router.
  17664.  
  17665. Regards
  17666.  
  17667. Sanjay Agarwal
  17668.  
  17669. On Mon, 19 Apr 1999, ROC Services wrote:
  17670.  
  17671. > Yet another interesting, maybe HiPer-related issue:  
  17672. > 
  17673. > I've got an ISDN customer who's unable to connect with a Cisco 766 router.  
  17674. > Others with Cisco 7xx series routers seem to have no problem.  This guy
  17675. > had a Cisco technician on the phone, who mentioned that I need to obtain a
  17676. > patch from 3Com to deal with "looping LCP" and that 3Com would know
  17677. > "exactly what I'm talking about."
  17678. > 
  17679. > On this end, it looks like the HiPer's doing exactly what it should be.
  17680. > We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats.  The Cisco
  17681. > tech says that the router never sees the ACK.
  17682. > 
  17683. > Is this a 3Com issue, or a Cisco issue?  I'm pointing my finger at the
  17684. > 766, Cisco is pointing fingers at the HiPer.
  17685. > 
  17686. > HARC 4.1.59-6, HDSP 2.1.43
  17687. > 
  17688. > PPP Offloading is currently disabled, because it seems to eliminate the
  17689. > password-munging problem that has been discussed lately.  I tried enabling
  17690. > it and it didn't make any difference.  RECEIVE_ACCM is also disabled, it
  17691. > seems I recall something about certain ISDN routers becoming unhappy with
  17692. > that setting enabled.
  17693. > 
  17694. > I've seen my share of problems with the 760 series of routers, and
  17695. > wouldn't mind at all telling the customer to get an 800 series, which
  17696. > we've never had any trouble with.  But, since this Cisco tech seems firmly
  17697. > convinced that it's a 3Com issue and that a fix is available, I thought
  17698. > I'd send it in the general direction of 3Com and some users of 3Com
  17699. > equipment.
  17700. > 
  17701. > Here's the "mon ppp" output, which to me looks like the HiPer is doing
  17702. > exactly what it should be:
  17703. > 
  17704. > Outgoing PPP Data on interface: slot:2/mod:14
  17705. >     LCP        CFG_REQ           MRU            05 ea
  17706. >                                  ASYNC_MAP      00 00 00 00
  17707. >                                  AUTH_TYPE      c0 23
  17708. >                                  MAGIC_NUM      54 86 e1 99
  17709. >                                  PROTO_COMP
  17710. >                                  AC_COMP
  17711. >                                  MPP_MRRU       05 ea
  17712. >                                  MPP_ENDPTID    00
  17713. > 
  17714. > Incoming PPP Data on interface: slot:2/mod:14
  17715. >     LCP        CFG_REQ           MRU            05 f2
  17716. >                                  MAGIC_NUM      00 12 6d 71
  17717. >                                  MPP_MRRU       07 08
  17718. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17719. >                                  LINK_DESCR     00 11
  17720. > 
  17721. > Outgoing PPP Data on interface: slot:2/mod:14
  17722. >     LCP        CFG_ACK           MRU            05 f2
  17723. >                                  MAGIC_NUM      00 12 6d 71
  17724. >                                  MPP_MRRU       07 08
  17725. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17726. >                                  LINK_DESCR     00 11
  17727. > 
  17728. > Outgoing PPP Data on interface: slot:2/mod:14
  17729. >     LCP        CFG_REQ           MRU            05 ea
  17730. >                                  ASYNC_MAP      00 00 00 00
  17731. >                                  AUTH_TYPE      c0 23
  17732. >                                  MAGIC_NUM      54 86 e1 99
  17733. >                                  PROTO_COMP
  17734. >                                  AC_COMP
  17735. >                                  MPP_MRRU       05 ea
  17736. >                                  MPP_ENDPTID    00
  17737. > 
  17738. > Incoming PPP Data on interface: slot:2/mod:14
  17739. >     LCP        CFG_REQ           MRU            05 f2
  17740. >                                  MAGIC_NUM      00 12 6d 71
  17741. >                                  MPP_MRRU       07 08
  17742. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17743. >                                  LINK_DESCR     00 11
  17744. > 
  17745. > Outgoing PPP Data on interface: slot:2/mod:14
  17746. >     LCP        CFG_ACK           MRU            05 f2
  17747. >                                  MAGIC_NUM      00 12 6d 71
  17748. >                                  MPP_MRRU       07 08
  17749. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17750. >                                  LINK_DESCR     00 11
  17751. > 
  17752. > 
  17753. > 
  17754. > 
  17755. > -
  17756. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17757. >  with "unsubscribe usr-tc" in the body of the message.
  17758. >  For information on digests or retrieving files and old messages send
  17759. >  "help" to the same address.  Do not use quotes in your message.
  17760. > 
  17761.  
  17762.  
  17763. -
  17764.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17765.  with "unsubscribe usr-tc" in the body of the message.
  17766.  For information on digests or retrieving files and old messages send
  17767.  "help" to the same address.  Do not use quotes in your message.
  17768.  
  17769.  
  17770. -------------------------------------------------------------------------------
  17771.  
  17772. From: Pete Ashdown <pashdown@xmission.com>
  17773. Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
  17774. Date: 19 Apr 1999 15:49:10 -0600 (MDT)
  17775.  
  17776. Brian said once upon a time:
  17777. >
  17778. >On Mon, 19 Apr 1999, Pete Ashdown wrote:
  17779. >
  17780. >> Paul Farber said once upon a time:
  17781. >> 
  17782. >> >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it
  17783. >> >would suck if the ARC has a 7 DSP limit. 
  17784. >> 
  17785. >> I have been running with 11 DSP's per chassis for almost as long as the
  17786. >> HiPer system has been out.  It works just fine, and segments nicely (253
  17787. >> ISDN B channels = /24 subnet - 1).
  17788. >
  17789. >Pete, so thats 11 DSP's per arc as well? (you said "per chassis" I was
  17790. >unclear to the number of ARC's you meant).
  17791.  
  17792. Yes, 1 ARC per chassis.  I'm a cheapskate.
  17793.  
  17794. -
  17795.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17796.  with "unsubscribe usr-tc" in the body of the message.
  17797.  For information on digests or retrieving files and old messages send
  17798.  "help" to the same address.  Do not use quotes in your message.
  17799.  
  17800.  
  17801. -------------------------------------------------------------------------------
  17802.  
  17803. From: ryan ryan <sales.ryan@usa.net>
  17804. Subject: (usr-tc) WTB USR NetServer PRI cards
  17805. Date: 19 Apr 1999 15:40:47 MDT
  17806.  
  17807. We're looking for a USR PRI NetServer card set.  Can use USR pn/ 002469 o=
  17808. r
  17809. 00972.  please reasonable price. NIC and NAC set. =
  17810.  
  17811.  
  17812. ____________________________________________________________________
  17813. Get free e-mail and a permanent address at http://www.netaddress.com/?N=3D=
  17814. 1
  17815.  
  17816. -
  17817.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17818.  with "unsubscribe usr-tc" in the body of the message.
  17819.  For information on digests or retrieving files and old messages send
  17820.  "help" to the same address.  Do not use quotes in your message.
  17821.  
  17822.  
  17823. -------------------------------------------------------------------------------
  17824.  
  17825. From: access1 <access1@simplyweb.net>
  17826. Subject: (usr-tc) For Sale Cisco 2501 & 1602 
  17827. Date: 19 Apr 1999 15:07:24 -0700
  17828.  
  17829. FOR SALE
  17830. Cisco 2501 --New - never registered, all new box, manuals etc. IP/IPX
  17831. feature set.   $1500.
  17832.  
  17833. Cisco 1602 (3 ea.)  -- New -- never registered, all new box, manuals
  17834. etc. IP/IPX feature set. $1100 ea.
  17835. Sell separate. terms: COD cashiers or Credit card.
  17836.  
  17837.  
  17838.  
  17839.  
  17840.  
  17841. -
  17842.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17843.  with "unsubscribe usr-tc" in the body of the message.
  17844.  For information on digests or retrieving files and old messages send
  17845.  "help" to the same address.  Do not use quotes in your message.
  17846.  
  17847.  
  17848. -------------------------------------------------------------------------------
  17849.  
  17850. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  17851. Subject: Re: (usr-tc) Looping LCP with Cisco 700 series
  17852. Date: 19 Apr 1999 17:26:28 -0500 (CDT)
  17853.  
  17854. On Mon, 19 Apr 1999, ROC Services wrote:
  17855.  
  17856. > Yet another interesting, maybe HiPer-related issue:  
  17857. > 
  17858. > I've got an ISDN customer who's unable to connect with a Cisco 766 router.  
  17859. > Others with Cisco 7xx series routers seem to have no problem.  This guy
  17860. > had a Cisco technician on the phone, who mentioned that I need to obtain a
  17861. > patch from 3Com to deal with "looping LCP" and that 3Com would know
  17862. > "exactly what I'm talking about."
  17863.  
  17864. Wov - interesting - So cisco does not not why there is a LCP loop?
  17865.  
  17866. All it is that the Cisco/Hiper arc are not convering on IPCP and the 
  17867. other end is telling you thatit is receiving the same LCP that it sent
  17868.  
  17869. Basically your connection either got dropped or disconnected.
  17870.  
  17871. krish
  17872.  
  17873. > 
  17874. > On this end, it looks like the HiPer's doing exactly what it should be.
  17875. > We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats.  The Cisco
  17876. > tech says that the router never sees the ACK.
  17877. > 
  17878. > Is this a 3Com issue, or a Cisco issue?  I'm pointing my finger at the
  17879. > 766, Cisco is pointing fingers at the HiPer.
  17880. > 
  17881. > HARC 4.1.59-6, HDSP 2.1.43
  17882. > 
  17883. > PPP Offloading is currently disabled, because it seems to eliminate the
  17884. > password-munging problem that has been discussed lately.  I tried enabling
  17885. > it and it didn't make any difference.  RECEIVE_ACCM is also disabled, it
  17886. > seems I recall something about certain ISDN routers becoming unhappy with
  17887. > that setting enabled.
  17888. > 
  17889. > I've seen my share of problems with the 760 series of routers, and
  17890. > wouldn't mind at all telling the customer to get an 800 series, which
  17891. > we've never had any trouble with.  But, since this Cisco tech seems firmly
  17892. > convinced that it's a 3Com issue and that a fix is available, I thought
  17893. > I'd send it in the general direction of 3Com and some users of 3Com
  17894. > equipment.
  17895. > 
  17896. > Here's the "mon ppp" output, which to me looks like the HiPer is doing
  17897. > exactly what it should be:
  17898. > 
  17899. > Outgoing PPP Data on interface: slot:2/mod:14
  17900. >     LCP        CFG_REQ           MRU            05 ea
  17901. >                                  ASYNC_MAP      00 00 00 00
  17902. >                                  AUTH_TYPE      c0 23
  17903. >                                  MAGIC_NUM      54 86 e1 99
  17904. >                                  PROTO_COMP
  17905. >                                  AC_COMP
  17906. >                                  MPP_MRRU       05 ea
  17907. >                                  MPP_ENDPTID    00
  17908. > 
  17909. > Incoming PPP Data on interface: slot:2/mod:14
  17910. >     LCP        CFG_REQ           MRU            05 f2
  17911. >                                  MAGIC_NUM      00 12 6d 71
  17912. >                                  MPP_MRRU       07 08
  17913. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17914. >                                  LINK_DESCR     00 11
  17915. > 
  17916. > Outgoing PPP Data on interface: slot:2/mod:14
  17917. >     LCP        CFG_ACK           MRU            05 f2
  17918. >                                  MAGIC_NUM      00 12 6d 71
  17919. >                                  MPP_MRRU       07 08
  17920. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17921. >                                  LINK_DESCR     00 11
  17922. > 
  17923. > Outgoing PPP Data on interface: slot:2/mod:14
  17924. >     LCP        CFG_REQ           MRU            05 ea
  17925. >                                  ASYNC_MAP      00 00 00 00
  17926. >                                  AUTH_TYPE      c0 23
  17927. >                                  MAGIC_NUM      54 86 e1 99
  17928. >                                  PROTO_COMP
  17929. >                                  AC_COMP
  17930. >                                  MPP_MRRU       05 ea
  17931. >                                  MPP_ENDPTID    00
  17932. > 
  17933. > Incoming PPP Data on interface: slot:2/mod:14
  17934. >     LCP        CFG_REQ           MRU            05 f2
  17935. >                                  MAGIC_NUM      00 12 6d 71
  17936. >                                  MPP_MRRU       07 08
  17937. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17938. >                                  LINK_DESCR     00 11
  17939. > 
  17940. > Outgoing PPP Data on interface: slot:2/mod:14
  17941. >     LCP        CFG_ACK           MRU            05 f2
  17942. >                                  MAGIC_NUM      00 12 6d 71
  17943. >                                  MPP_MRRU       07 08
  17944. >                                  MPP_ENDPTID    03 00 40 f9 13 6f 6d
  17945. >                                  LINK_DESCR     00 11
  17946. > 
  17947. > 
  17948. > 
  17949. > 
  17950. > -
  17951. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17952. >  with "unsubscribe usr-tc" in the body of the message.
  17953. >  For information on digests or retrieving files and old messages send
  17954. >  "help" to the same address.  Do not use quotes in your message.
  17955. > 
  17956.  
  17957. -
  17958.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17959.  with "unsubscribe usr-tc" in the body of the message.
  17960.  For information on digests or retrieving files and old messages send
  17961.  "help" to the same address.  Do not use quotes in your message.
  17962.  
  17963.  
  17964. -------------------------------------------------------------------------------
  17965.  
  17966. From: Robert von Bismarck <rvb@petrel.ch>
  17967. Subject: RE: (usr-tc) Looping LCP with Cisco 700 series
  17968. Date: 20 Apr 1999 18:17:57 +0200
  17969.  
  17970. I had a problem with Cisco 7xx series not connecting to an ARC/DSP chassis
  17971. in the beginning of ARC-DSP times. This was fixed long ago by an ARC
  17972. software upgrade (was ER 4.0.53 I think...) It does MLPPP nicely now, with
  17973. BOD and all...
  17974.  
  17975. For info : I'm running 4.1.72-7 and 1.2.5 (when will the new E1-PRI-HDM code
  17976. be out ?)
  17977.  
  17978. This "looping LCP" thing seems to be very cisco-related, a 1603 (running IOS
  17979. 11.3 IP-PLUS) will loop about 4-5 times before beginning IPCP negotiation
  17980. I'd love to check if the bug's still there with IOS 12.x but I don't have
  17981. that IOS handy for my routers... Guess it'll have to wait for a while then.
  17982.  
  17983.  
  17984. ---
  17985. Robert von Bismarck
  17986. Network Systems Engineer
  17987. Petrel Communications SA / SPAN
  17988. Tel : +41 22 304 47 47
  17989. Fax : +41 22 300 48 43
  17990. e-mail : rvb@petrel.ch
  17991.  
  17992.  
  17993.     -----Original Message-----
  17994.     From:    ROC Services [SMTP:rocsoft@itol.com]
  17995.     Sent:    lundi, 19. avril 1999 21:59
  17996.     To:    usr-tc@lists.xmission.com
  17997.     Subject:    (usr-tc) Looping LCP with Cisco 700 series
  17998.  
  17999.     Yet another interesting, maybe HiPer-related issue:  
  18000.  
  18001.     I've got an ISDN customer who's unable to connect with a Cisco 766
  18002. router.  
  18003.     Others with Cisco 7xx series routers seem to have no problem.  This
  18004. guy
  18005.     had a Cisco technician on the phone, who mentioned that I need to
  18006. obtain a
  18007.     patch from 3Com to deal with "looping LCP" and that 3Com would know
  18008.     "exactly what I'm talking about."
  18009.  
  18010.     On this end, it looks like the HiPer's doing exactly what it should
  18011. be.
  18012.     We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats.  The
  18013. Cisco
  18014.     tech says that the router never sees the ACK.
  18015.  
  18016.     Is this a 3Com issue, or a Cisco issue?  I'm pointing my finger at
  18017. the
  18018.     766, Cisco is pointing fingers at the HiPer.
  18019.  
  18020.     HARC 4.1.59-6, HDSP 2.1.43
  18021.  
  18022.     PPP Offloading is currently disabled, because it seems to eliminate
  18023. the
  18024.     password-munging problem that has been discussed lately.  I tried
  18025. enabling
  18026.     it and it didn't make any difference.  RECEIVE_ACCM is also
  18027. disabled, it
  18028.     seems I recall something about certain ISDN routers becoming unhappy
  18029. with
  18030.     that setting enabled.
  18031.  
  18032.     I've seen my share of problems with the 760 series of routers, and
  18033.     wouldn't mind at all telling the customer to get an 800 series,
  18034. which
  18035.     we've never had any trouble with.  But, since this Cisco tech seems
  18036. firmly
  18037.     convinced that it's a 3Com issue and that a fix is available, I
  18038. thought
  18039.     I'd send it in the general direction of 3Com and some users of 3Com
  18040.     equipment.
  18041.  
  18042.     Here's the "mon ppp" output, which to me looks like the HiPer is
  18043. doing
  18044.     exactly what it should be:
  18045.  
  18046.     Outgoing PPP Data on interface: slot:2/mod:14
  18047.         LCP        CFG_REQ           MRU            05 ea
  18048.                                      ASYNC_MAP      00 00 00 00
  18049.                                      AUTH_TYPE      c0 23
  18050.                                      MAGIC_NUM      54 86 e1 99
  18051.                                      PROTO_COMP
  18052.                                      AC_COMP
  18053.                                      MPP_MRRU       05 ea
  18054.                                      MPP_ENDPTID    00
  18055.  
  18056.     Incoming PPP Data on interface: slot:2/mod:14
  18057.         LCP        CFG_REQ           MRU            05 f2
  18058.                                      MAGIC_NUM      00 12 6d 71
  18059.                                      MPP_MRRU       07 08
  18060.                                      MPP_ENDPTID    03 00 40 f9 13 6f 6d
  18061.                                      LINK_DESCR     00 11
  18062.  
  18063.     Outgoing PPP Data on interface: slot:2/mod:14
  18064.         LCP        CFG_ACK           MRU            05 f2
  18065.                                      MAGIC_NUM      00 12 6d 71
  18066.                                      MPP_MRRU       07 08
  18067.                                      MPP_ENDPTID    03 00 40 f9 13 6f 6d
  18068.                                      LINK_DESCR     00 11
  18069.  
  18070.     Outgoing PPP Data on interface: slot:2/mod:14
  18071.         LCP        CFG_REQ           MRU            05 ea
  18072.                                      ASYNC_MAP      00 00 00 00
  18073.                                      AUTH_TYPE      c0 23
  18074.                                      MAGIC_NUM      54 86 e1 99
  18075.                                      PROTO_COMP
  18076.                                      AC_COMP
  18077.                                      MPP_MRRU       05 ea
  18078.                                      MPP_ENDPTID    00
  18079.  
  18080.     Incoming PPP Data on interface: slot:2/mod:14
  18081.         LCP        CFG_REQ           MRU            05 f2
  18082.                                      MAGIC_NUM      00 12 6d 71
  18083.                                      MPP_MRRU       07 08
  18084.                                      MPP_ENDPTID    03 00 40 f9 13 6f 6d
  18085.                                      LINK_DESCR     00 11
  18086.  
  18087.     Outgoing PPP Data on interface: slot:2/mod:14
  18088.         LCP        CFG_ACK           MRU            05 f2
  18089.                                      MAGIC_NUM      00 12 6d 71
  18090.                                      MPP_MRRU       07 08
  18091.                                      MPP_ENDPTID    03 00 40 f9 13 6f 6d
  18092.                                      LINK_DESCR     00 11
  18093.  
  18094.  
  18095.  
  18096.  
  18097.     -
  18098.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18099.      with "unsubscribe usr-tc" in the body of the message.
  18100.      For information on digests or retrieving files and old messages
  18101. send
  18102.      "help" to the same address.  Do not use quotes in your message.
  18103.  
  18104. -
  18105.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18106.  with "unsubscribe usr-tc" in the body of the message.
  18107.  For information on digests or retrieving files and old messages send
  18108.  "help" to the same address.  Do not use quotes in your message.
  18109.  
  18110.  
  18111. -------------------------------------------------------------------------------
  18112.  
  18113. From: Steve Rivera <sales@wrca.net>
  18114. Subject: Re: (usr-tc) WTB USR NetServer PRI cards
  18115. Date: 20 Apr 1999 12:46:10 -0400
  18116.  
  18117. $1500 for the netserver pri card with nic.
  18118.  
  18119. At 03:40 PM 4/19/99 MDT, you wrote:
  18120. >We're looking for a USR PRI NetServer card set.  Can use USR pn/ 002469 or
  18121. >00972.  please reasonable price. NIC and NAC set. 
  18122. >
  18123. >____________________________________________________________________
  18124. >Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
  18125. >
  18126. >-
  18127. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18128. > with "unsubscribe usr-tc" in the body of the message.
  18129. > For information on digests or retrieving files and old messages send
  18130. > "help" to the same address.  Do not use quotes in your message.
  18131. >
  18132.  
  18133. -
  18134.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18135.  with "unsubscribe usr-tc" in the body of the message.
  18136.  For information on digests or retrieving files and old messages send
  18137.  "help" to the same address.  Do not use quotes in your message.
  18138.  
  18139.  
  18140. -------------------------------------------------------------------------------
  18141.  
  18142. From: "Andrey Zimin" <horgi@mtu.ru>
  18143. Subject: Re: (usr-tc) Looping LCP with Cisco 700 series
  18144. Date: 20 Apr 1999 20:59:19 +0400
  18145.  
  18146. > For info : I'm running 4.1.72-7 and 1.2.5 (when will the new E1-PRI-HDM code
  18147. > be out ?)
  18148. It out, but 3COM's web administrator not insert it in SL... :-))
  18149.  
  18150. Need fix for hands.sys
  18151.  
  18152. :-/
  18153.  
  18154. ===
  18155. Good luck!
  18156.      Andrey Zimin
  18157. AVZ7-RIPE
  18158.  
  18159.  
  18160. -
  18161.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18162.  with "unsubscribe usr-tc" in the body of the message.
  18163.  For information on digests or retrieving files and old messages send
  18164.  "help" to the same address.  Do not use quotes in your message.
  18165.  
  18166.  
  18167. -------------------------------------------------------------------------------
  18168.  
  18169. From: access1 <access1@simplyweb.net>
  18170. Subject: Re: (usr-tc) WTB USR NetServer PRI cards
  18171. Date: 20 Apr 1999 10:12:56 -0700
  18172.  
  18173. pass. thanks for the response.
  18174.  
  18175. Steve Rivera wrote:
  18176.  
  18177. > $1500 for the netserver pri card with nic.
  18178. >
  18179. > At 03:40 PM 4/19/99 MDT, you wrote:
  18180. > >We're looking for a USR PRI NetServer card set.  Can use USR pn/ 002469 or
  18181. > >00972.  please reasonable price. NIC and NAC set.
  18182. > >
  18183. > >____________________________________________________________________
  18184. > >Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
  18185. > >
  18186. > >-
  18187. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18188. > > with "unsubscribe usr-tc" in the body of the message.
  18189. > > For information on digests or retrieving files and old messages send
  18190. > > "help" to the same address.  Do not use quotes in your message.
  18191. > >
  18192. >
  18193. > -
  18194. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18195. >  with "unsubscribe usr-tc" in the body of the message.
  18196. >  For information on digests or retrieving files and old messages send
  18197. >  "help" to the same address.  Do not use quotes in your message.
  18198.  
  18199.  
  18200.  
  18201.  
  18202. -
  18203.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18204.  with "unsubscribe usr-tc" in the body of the message.
  18205.  For information on digests or retrieving files and old messages send
  18206.  "help" to the same address.  Do not use quotes in your message.
  18207.  
  18208.  
  18209. -------------------------------------------------------------------------------
  18210.  
  18211. From: Thomas Blauvelt <blauvelt@aldus.northnet.org>
  18212. Subject: (usr-tc) WTB: Modem Pool 16 and MP/16-I
  18213. Date: 20 Apr 1999 13:18:22 -0400 (EDT)
  18214.  
  18215.  
  18216.     We are looking to purchase a few of the discontinued Modem Pool 16
  18217. (part number 00939) and the Modem Pool 16-I (part number 01219) boxes.
  18218.  
  18219.     New or used. Anyone know where these are available?
  18220.  
  18221.     Thanks.
  18222.  
  18223.  
  18224.  
  18225.                 tom blauvelt
  18226.  
  18227.  
  18228. Thomas Blauvelt        NorthNet Internet Services, Inc.
  18229.             North Country Reference & Research Resources Council
  18230. blauvelt@northnet.org    7 Commerce Lane  Canton NY 13617 USA  (315) 386-4569
  18231.  
  18232.  
  18233. -
  18234.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18235.  with "unsubscribe usr-tc" in the body of the message.
  18236.  For information on digests or retrieving files and old messages send
  18237.  "help" to the same address.  Do not use quotes in your message.
  18238.  
  18239.  
  18240. -------------------------------------------------------------------------------
  18241.  
  18242. From: "Michael E. Ezzell" <mezzell@networkacg.com>
  18243. Subject: (usr-tc) Munich Recovery
  18244. Date: 20 Apr 1999 12:36:01 -0500
  18245.  
  18246. Could someone explain these?
  18247.  
  18248. Apr 20 06:45:47 argon MUNICH RECOVERY 29 (Action request timeout)
  18249. Apr 20 11:25:23 argon MUNICH RECOVERY 30 (Action request timeout)
  18250. Apr 20 11:52:30 argon MUNICH RECOVERY 31 (Action request timeout)
  18251.  
  18252. They are coming from my Netserver... and I am having problems with ISDN
  18253. connections (from Cisco 762s and 1604s) becoming very doggy and dropping
  18254. most packets, or just suddenly failing to pass data.
  18255.  
  18256. Sometimes this condition remedies itself, but other times I have to knock
  18257. down the connection from the Netserver.  When the remote router dials back
  18258. in, all is well... for a time.
  18259.  
  18260. Thanks
  18261.  
  18262. ___________________________
  18263. Michael Ezzell, DNRC
  18264. Internet Services Director
  18265. The Austin Consultant Group
  18266. Oklahoma City, Oklahoma
  18267. 405-848-0941
  18268. mailto:mezzell@networkacg.com
  18269. mailto:staff@accessacg.net
  18270.  
  18271.  
  18272. -
  18273.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18274.  with "unsubscribe usr-tc" in the body of the message.
  18275.  For information on digests or retrieving files and old messages send
  18276.  "help" to the same address.  Do not use quotes in your message.
  18277.  
  18278.  
  18279. -------------------------------------------------------------------------------
  18280.  
  18281. From: "Matthew E. Pearson" <mpearson@tiac.net>
  18282. Subject: (usr-tc) Problems with RIPv2 and Cisco Routers
  18283. Date: 20 Apr 1999 14:02:20 -0400
  18284.  
  18285. Anyone ever see a weird problem that a TC running RIPv2 doesnt properly send
  18286. its updates to a Cisco 2501 router? We are setup to accept ripv1 and v2 from
  18287. the local ether but we aren't getting squat. The same identical TC config
  18288. talks to the Cisco 7500 series boxes we have but the Cisco2501s have no
  18289. clue. They are running IOS 11.1 . Any help would be appreciated.
  18290.  
  18291.  
  18292. -
  18293.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18294.  with "unsubscribe usr-tc" in the body of the message.
  18295.  For information on digests or retrieving files and old messages send
  18296.  "help" to the same address.  Do not use quotes in your message.
  18297.  
  18298.  
  18299. -------------------------------------------------------------------------------
  18300.  
  18301. From: "Marshall Morgan" <marshall@netdoor.com>
  18302. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18303. Date: 20 Apr 1999 19:19:13 -0500
  18304.  
  18305. Do we need to reboot for this to take effect?
  18306.  
  18307. disaBLE ppp ofFLOADING
  18308.  
  18309. Marshall Morgan
  18310.  
  18311. Internet Doorway, Inc. (aka NETDOOR)
  18312. 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18313.  
  18314. > -----Original Message-----
  18315. > From: owner-usr-tc@lists.xmission.com
  18316. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18317. > Sent: Monday, April 19, 1999 4:39 PM
  18318. > To: usr-tc@lists.xmission.com
  18319. > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18320. > 
  18321. > 
  18322. > > 
  18323. > > Not much from a performance standpoint. The feature allows the 
  18324. > DSP's to share
  18325. > > some of the overhead of PPP with the HARC. (Normally the modem 
  18326. > does not have any
  18327. > > knowledge of PPP its only a data pipe). By disabling offloading 
  18328. > the HARC will
  18329. > > handle all aspects of the PPP termination. The HARC has more than 
  18330. > enough power to
  18331. > > do this with almost no noticalbe change in performance to the 
  18332. > dial user.  How
  18333. > > many DSP's does your HARC control?
  18334. > 
  18335. > 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  18336. > getting munged in 1.2.43.  If this is the case, than certainly everyone
  18337. > should do it right?
  18338. > 
  18339.  
  18340.  
  18341. -
  18342.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18343.  with "unsubscribe usr-tc" in the body of the message.
  18344.  For information on digests or retrieving files and old messages send
  18345.  "help" to the same address.  Do not use quotes in your message.
  18346.  
  18347.  
  18348. -------------------------------------------------------------------------------
  18349.  
  18350. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  18351. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18352. Date: 20 Apr 1999 19:45:29 -0500 (CDT)
  18353.  
  18354. On Tue, 20 Apr 1999, Marshall Morgan wrote:
  18355.  
  18356. > Do we need to reboot for this to take effect?
  18357. > 
  18358. > disaBLE ppp ofFLOADING
  18359.  
  18360. No  - you do not need to reboot.  For the past two weeks we have been 
  18361. trying to reproduce the problem but have not been successful so far - Any 
  18362. chance that one of you can help us getting a trace - tap or anything that 
  18363. would help?
  18364.  
  18365. krish
  18366.  
  18367. > 
  18368. > Marshall Morgan
  18369. > 
  18370. > Internet Doorway, Inc. (aka NETDOOR)
  18371. > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18372. > 
  18373. > > -----Original Message-----
  18374. > > From: owner-usr-tc@lists.xmission.com
  18375. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18376. > > Sent: Monday, April 19, 1999 4:39 PM
  18377. > > To: usr-tc@lists.xmission.com
  18378. > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18379. > > 
  18380. > > 
  18381. > > > 
  18382. > > > Not much from a performance standpoint. The feature allows the 
  18383. > > DSP's to share
  18384. > > > some of the overhead of PPP with the HARC. (Normally the modem 
  18385. > > does not have any
  18386. > > > knowledge of PPP its only a data pipe). By disabling offloading 
  18387. > > the HARC will
  18388. > > > handle all aspects of the PPP termination. The HARC has more than 
  18389. > > enough power to
  18390. > > > do this with almost no noticalbe change in performance to the 
  18391. > > dial user.  How
  18392. > > > many DSP's does your HARC control?
  18393. > > 
  18394. > > 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  18395. > > getting munged in 1.2.43.  If this is the case, than certainly everyone
  18396. > > should do it right?
  18397. > > 
  18398. > 
  18399. > 
  18400. > -
  18401. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18402. >  with "unsubscribe usr-tc" in the body of the message.
  18403. >  For information on digests or retrieving files and old messages send
  18404. >  "help" to the same address.  Do not use quotes in your message.
  18405. > 
  18406.  
  18407. -
  18408.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18409.  with "unsubscribe usr-tc" in the body of the message.
  18410.  For information on digests or retrieving files and old messages send
  18411.  "help" to the same address.  Do not use quotes in your message.
  18412.  
  18413.  
  18414. -------------------------------------------------------------------------------
  18415.  
  18416. From: <pferraro@wna-linknet.com>
  18417. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18418. Date: 20 Apr 1999 22:38:23 -0400 (EDT)
  18419.  
  18420.  
  18421.     We have been running this code along with the 1.2.43 DSP code for
  18422. a couple of weeks.  We are using Merit Radiusd.  These are Channelized
  18423. T-1s  The radius user file has the standard DEFAULT user and a couple of
  18424. separate entries for ISDN and Static IPs.  It also authenticates for our
  18425. HiperArc/Quad modem hub.  This hub is running 4.1.72-7 on the HiperArc and
  18426. the 5.9.10 code on the quads.
  18427.  
  18428.   We were a little reluctant to put the 4.1.59-6 code up, but to date, we
  18429. have not had any problems with passwords being "MUNGED"  These are
  18430. supporting about 1000 customers!
  18431.  
  18432. ==============================================================================
  18433. Phillip Ferraro                WorldNet Access, Inc
  18434. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  18435. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  18436. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  18437. ==============================================================================
  18438.  
  18439. On Tue, 20 Apr 1999, Tatai SV Krishnan wrote:
  18440.  
  18441. > On Tue, 20 Apr 1999, Marshall Morgan wrote:
  18442. > 
  18443. > > Do we need to reboot for this to take effect?
  18444. > > 
  18445. > > disaBLE ppp ofFLOADING
  18446. > 
  18447. > No  - you do not need to reboot.  For the past two weeks we have been 
  18448. > trying to reproduce the problem but have not been successful so far - Any 
  18449. > chance that one of you can help us getting a trace - tap or anything that 
  18450. > would help?
  18451. > 
  18452. > krish
  18453. > 
  18454. > > 
  18455. > > Marshall Morgan
  18456. > > 
  18457. > > Internet Doorway, Inc. (aka NETDOOR)
  18458. > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18459. > > 
  18460. > > > -----Original Message-----
  18461. > > > From: owner-usr-tc@lists.xmission.com
  18462. > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18463. > > > Sent: Monday, April 19, 1999 4:39 PM
  18464. > > > To: usr-tc@lists.xmission.com
  18465. > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18466. > > > 
  18467. > > > 
  18468. > > > > 
  18469. > > > > Not much from a performance standpoint. The feature allows the 
  18470. > > > DSP's to share
  18471. > > > > some of the overhead of PPP with the HARC. (Normally the modem 
  18472. > > > does not have any
  18473. > > > > knowledge of PPP its only a data pipe). By disabling offloading 
  18474. > > > the HARC will
  18475. > > > > handle all aspects of the PPP termination. The HARC has more than 
  18476. > > > enough power to
  18477. > > > > do this with almost no noticalbe change in performance to the 
  18478. > > > dial user.  How
  18479. > > > > many DSP's does your HARC control?
  18480. > > > 
  18481. > > > 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  18482. > > > getting munged in 1.2.43.  If this is the case, than certainly everyone
  18483. > > > should do it right?
  18484. > > > 
  18485. > > 
  18486. > > 
  18487. > > -
  18488. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18489. > >  with "unsubscribe usr-tc" in the body of the message.
  18490. > >  For information on digests or retrieving files and old messages send
  18491. > >  "help" to the same address.  Do not use quotes in your message.
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18504.  with "unsubscribe usr-tc" in the body of the message.
  18505.  For information on digests or retrieving files and old messages send
  18506.  "help" to the same address.  Do not use quotes in your message.
  18507.  
  18508.  
  18509. -------------------------------------------------------------------------------
  18510.  
  18511. From: Brian <signal@shreve.net>
  18512. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18513. Date: 21 Apr 1999 14:19:44 -0500 (CDT)
  18514.  
  18515. On Tue, 20 Apr 1999, Tatai SV Krishnan wrote:
  18516.  
  18517. > On Tue, 20 Apr 1999, Marshall Morgan wrote:
  18518. > 
  18519. > > Do we need to reboot for this to take effect?
  18520. > > 
  18521. > > disaBLE ppp ofFLOADING
  18522. > 
  18523. > No  - you do not need to reboot.  For the past two weeks we have been 
  18524. > trying to reproduce the problem but have not been successful so far - Any 
  18525. > chance that one of you can help us getting a trace - tap or anything that 
  18526. > would help?
  18527.  
  18528. I tried that, and it really screwed my logs up, because it would appear
  18529. that the facility is broken in tap syslog on 4.1.59-6.  I set it to log to
  18530. local6, but it logged to the syslog facility of the ARC instead of the
  18531. facility I set for the tap user.  Is this a known issue?
  18532.  
  18533.  
  18534. > 
  18535. > krish
  18536. > 
  18537. > > 
  18538. > > Marshall Morgan
  18539. > > 
  18540. > > Internet Doorway, Inc. (aka NETDOOR)
  18541. > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18542. > > 
  18543. > > > -----Original Message-----
  18544. > > > From: owner-usr-tc@lists.xmission.com
  18545. > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18546. > > > Sent: Monday, April 19, 1999 4:39 PM
  18547. > > > To: usr-tc@lists.xmission.com
  18548. > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18549. > > > 
  18550. > > > 
  18551. > > > > 
  18552. > > > > Not much from a performance standpoint. The feature allows the 
  18553. > > > DSP's to share
  18554. > > > > some of the overhead of PPP with the HARC. (Normally the modem 
  18555. > > > does not have any
  18556. > > > > knowledge of PPP its only a data pipe). By disabling offloading 
  18557. > > > the HARC will
  18558. > > > > handle all aspects of the PPP termination. The HARC has more than 
  18559. > > > enough power to
  18560. > > > > do this with almost no noticalbe change in performance to the 
  18561. > > > dial user.  How
  18562. > > > > many DSP's does your HARC control?
  18563. > > > 
  18564. > > > 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  18565. > > > getting munged in 1.2.43.  If this is the case, than certainly everyone
  18566. > > > should do it right?
  18567. > > > 
  18568. > > 
  18569. > > 
  18570. > > -
  18571. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18572. > >  with "unsubscribe usr-tc" in the body of the message.
  18573. > >  For information on digests or retrieving files and old messages send
  18574. > >  "help" to the same address.  Do not use quotes in your message.
  18575. > > 
  18576. > 
  18577. > -
  18578. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18579. >  with "unsubscribe usr-tc" in the body of the message.
  18580. >  For information on digests or retrieving files and old messages send
  18581. >  "help" to the same address.  Do not use quotes in your message.
  18582. > 
  18583.  
  18584. Brian Feeny (BF304)     signal@shreve.net   
  18585. 318-222-2638 x 109    http://www.shreve.net/~signal      
  18586. Network Administrator   ShreveNet Inc. (ASN 11881)           
  18587.  
  18588.  
  18589. -
  18590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18591.  with "unsubscribe usr-tc" in the body of the message.
  18592.  For information on digests or retrieving files and old messages send
  18593.  "help" to the same address.  Do not use quotes in your message.
  18594.  
  18595.  
  18596. -------------------------------------------------------------------------------
  18597.  
  18598. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  18599. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18600. Date: 21 Apr 1999 15:23:50 -0500 (CDT)
  18601.  
  18602. On Wed, 21 Apr 1999, Brian wrote:
  18603.  
  18604. > On Tue, 20 Apr 1999, Tatai SV Krishnan wrote:
  18605. > 
  18606. > > On Tue, 20 Apr 1999, Marshall Morgan wrote:
  18607. > > 
  18608. > > > Do we need to reboot for this to take effect?
  18609. > > > 
  18610. > > > disaBLE ppp ofFLOADING
  18611. > > 
  18612. > > No  - you do not need to reboot.  For the past two weeks we have been 
  18613. > > trying to reproduce the problem but have not been successful so far - Any 
  18614. > > chance that one of you can help us getting a trace - tap or anything that 
  18615. > > would help?
  18616. > 
  18617. > I tried that, and it really screwed my logs up, because it would appear
  18618. > that the facility is broken in tap syslog on 4.1.59-6.  I set it to log to
  18619. > local6, but it logged to the syslog facility of the ARC instead of the
  18620. > facility I set for the tap user.  Is this a known issue?
  18621. > 
  18622. Looks more like a syslogd issue, if configured for local6 the logs are 
  18623. sent out as local6.  What is OS here ?  Solaris? Linux?
  18624.  
  18625. Also we can do a snoop on the wire to find out what is being sent out by 
  18626. the HiPer arc - I have setup local7 and the logs here go to local7
  18627.  
  18628. krish
  18629.  
  18630.  
  18631. > 
  18632. > > 
  18633. > > krish
  18634. > > 
  18635. > > > 
  18636. > > > Marshall Morgan
  18637. > > > 
  18638. > > > Internet Doorway, Inc. (aka NETDOOR)
  18639. > > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18640. > > > 
  18641. > > > > -----Original Message-----
  18642. > > > > From: owner-usr-tc@lists.xmission.com
  18643. > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18644. > > > > Sent: Monday, April 19, 1999 4:39 PM
  18645. > > > > To: usr-tc@lists.xmission.com
  18646. > > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18647. > > > > 
  18648. > > > > 
  18649. > > > > > 
  18650. > > > > > Not much from a performance standpoint. The feature allows the 
  18651. > > > > DSP's to share
  18652. > > > > > some of the overhead of PPP with the HARC. (Normally the modem 
  18653. > > > > does not have any
  18654. > > > > > knowledge of PPP its only a data pipe). By disabling offloading 
  18655. > > > > the HARC will
  18656. > > > > > handle all aspects of the PPP termination. The HARC has more than 
  18657. > > > > enough power to
  18658. > > > > > do this with almost no noticalbe change in performance to the 
  18659. > > > > dial user.  How
  18660. > > > > > many DSP's does your HARC control?
  18661. > > > > 
  18662. > > > > 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  18663. > > > > getting munged in 1.2.43.  If this is the case, than certainly everyone
  18664. > > > > should do it right?
  18665. > > > > 
  18666. > > > 
  18667. > > > 
  18668. > > > -
  18669. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18670. > > >  with "unsubscribe usr-tc" in the body of the message.
  18671. > > >  For information on digests or retrieving files and old messages send
  18672. > > >  "help" to the same address.  Do not use quotes in your message.
  18673. > > > 
  18674. > > 
  18675. > > -
  18676. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18677. > >  with "unsubscribe usr-tc" in the body of the message.
  18678. > >  For information on digests or retrieving files and old messages send
  18679. > >  "help" to the same address.  Do not use quotes in your message.
  18680. > > 
  18681. > 
  18682. > -----------------------------------------------------
  18683. > Brian Feeny (BF304)     signal@shreve.net   
  18684. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  18685. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  18686. > 
  18687. > 
  18688. > -
  18689. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18690. >  with "unsubscribe usr-tc" in the body of the message.
  18691. >  For information on digests or retrieving files and old messages send
  18692. >  "help" to the same address.  Do not use quotes in your message.
  18693. > 
  18694.  
  18695. -
  18696.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18697.  with "unsubscribe usr-tc" in the body of the message.
  18698.  For information on digests or retrieving files and old messages send
  18699.  "help" to the same address.  Do not use quotes in your message.
  18700.  
  18701.  
  18702. -------------------------------------------------------------------------------
  18703.  
  18704. From: Brian <signal@shreve.net>
  18705. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18706. Date: 21 Apr 1999 15:18:00 -0500 (CDT)
  18707.  
  18708. On Wed, 21 Apr 1999, Tatai SV Krishnan wrote:
  18709.  
  18710. > On Wed, 21 Apr 1999, Brian wrote:
  18711. > 
  18712. > > On Tue, 20 Apr 1999, Tatai SV Krishnan wrote:
  18713. > > 
  18714. > > > On Tue, 20 Apr 1999, Marshall Morgan wrote:
  18715. > > > 
  18716. > > > > Do we need to reboot for this to take effect?
  18717. > > > > 
  18718. > > > > disaBLE ppp ofFLOADING
  18719. > > > 
  18720. > > > No  - you do not need to reboot.  For the past two weeks we have been 
  18721. > > > trying to reproduce the problem but have not been successful so far - Any 
  18722. > > > chance that one of you can help us getting a trace - tap or anything that 
  18723. > > > would help?
  18724. > > 
  18725. > > I tried that, and it really screwed my logs up, because it would appear
  18726. > > that the facility is broken in tap syslog on 4.1.59-6.  I set it to log to
  18727. > > local6, but it logged to the syslog facility of the ARC instead of the
  18728. > > facility I set for the tap user.  Is this a known issue?
  18729. > > 
  18730. > Looks more like a syslogd issue, if configured for local6 the logs are 
  18731. > sent out as local6.  What is OS here ?  Solaris? Linux?
  18732. > 
  18733. > Also we can do a snoop on the wire to find out what is being sent out by 
  18734. > the HiPer arc - I have setup local7 and the logs here go to local7
  18735.  
  18736. ok, I can double check, but I had local7 going to a seperate file in
  18737. syslog, and it still came out the facility of the hiper.  I will check
  18738. again though.
  18739.  
  18740.  
  18741. > 
  18742. > krish
  18743. > 
  18744. > 
  18745. > > 
  18746. > > > 
  18747. > > > krish
  18748. > > > 
  18749. > > > > 
  18750. > > > > Marshall Morgan
  18751. > > > > 
  18752. > > > > Internet Doorway, Inc. (aka NETDOOR)
  18753. > > > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18754. > > > > 
  18755. > > > > > -----Original Message-----
  18756. > > > > > From: owner-usr-tc@lists.xmission.com
  18757. > > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18758. > > > > > Sent: Monday, April 19, 1999 4:39 PM
  18759. > > > > > To: usr-tc@lists.xmission.com
  18760. > > > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18761. > > > > > 
  18762. > > > > > 
  18763. > > > > > > 
  18764. > > > > > > Not much from a performance standpoint. The feature allows the 
  18765. > > > > > DSP's to share
  18766. > > > > > > some of the overhead of PPP with the HARC. (Normally the modem 
  18767. > > > > > does not have any
  18768. > > > > > > knowledge of PPP its only a data pipe). By disabling offloading 
  18769. > > > > > the HARC will
  18770. > > > > > > handle all aspects of the PPP termination. The HARC has more than 
  18771. > > > > > enough power to
  18772. > > > > > > do this with almost no noticalbe change in performance to the 
  18773. > > > > > dial user.  How
  18774. > > > > > > many DSP's does your HARC control?
  18775. > > > > > 
  18776. > > > > > 5 per arc.  I have heard disabling ppp offloading fixes the passwords from
  18777. > > > > > getting munged in 1.2.43.  If this is the case, than certainly everyone
  18778. > > > > > should do it right?
  18779. > > > > > 
  18780. > > > > 
  18781. > > > > 
  18782. > > > > -
  18783. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18784. > > > >  with "unsubscribe usr-tc" in the body of the message.
  18785. > > > >  For information on digests or retrieving files and old messages send
  18786. > > > >  "help" to the same address.  Do not use quotes in your message.
  18787. > > > > 
  18788. > > > 
  18789. > > > -
  18790. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18791. > > >  with "unsubscribe usr-tc" in the body of the message.
  18792. > > >  For information on digests or retrieving files and old messages send
  18793. > > >  "help" to the same address.  Do not use quotes in your message.
  18794. > > > 
  18795. > > 
  18796. > > -----------------------------------------------------
  18797. > > Brian Feeny (BF304)     signal@shreve.net   
  18798. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  18799. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  18800. > > 
  18801. > > 
  18802. > > -
  18803. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18804. > >  with "unsubscribe usr-tc" in the body of the message.
  18805. > >  For information on digests or retrieving files and old messages send
  18806. > >  "help" to the same address.  Do not use quotes in your message.
  18807. > > 
  18808. > 
  18809.  
  18810. Brian Feeny (BF304)     signal@shreve.net   
  18811. 318-222-2638 x 109    http://www.shreve.net/~signal      
  18812. Network Administrator   ShreveNet Inc. (ASN 11881)           
  18813.  
  18814.  
  18815. -
  18816.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18817.  with "unsubscribe usr-tc" in the body of the message.
  18818.  For information on digests or retrieving files and old messages send
  18819.  "help" to the same address.  Do not use quotes in your message.
  18820.  
  18821.  
  18822. -------------------------------------------------------------------------------
  18823.  
  18824. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  18825. Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18826. Date: 21 Apr 1999 15:39:12 -0500
  18827.  
  18828. I have sucessfully used the 6 different log facilitys with 59-6.. Dont know what
  18829. is happening with your settup..
  18830.  
  18831. -M
  18832.  
  18833.  
  18834. |-----Original Message-----
  18835. |From: owner-usr-tc@lists.xmission.com
  18836. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18837. |Sent: Wednesday, April 21, 1999 3:18 PM
  18838. |To: Tatai SV Krishnan
  18839. |Cc: usr-tc@lists.xmission.com; Marshall Morgan
  18840. |Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18841. |
  18842. |
  18843. |On Wed, 21 Apr 1999, Tatai SV Krishnan wrote:
  18844. |
  18845. |> On Wed, 21 Apr 1999, Brian wrote:
  18846. |>
  18847. |> > On Tue, 20 Apr 1999, Tatai SV Krishnan wrote:
  18848. |> >
  18849. |> > > On Tue, 20 Apr 1999, Marshall Morgan wrote:
  18850. |> > >
  18851. |> > > > Do we need to reboot for this to take effect?
  18852. |> > > >
  18853. |> > > > disaBLE ppp ofFLOADING
  18854. |> > >
  18855. |> > > No  - you do not need to reboot.  For the past two weeks we have been
  18856. |> > > trying to reproduce the problem but have not been successful so far - Any
  18857. |> > > chance that one of you can help us getting a trace - tap or anything that
  18858. |> > > would help?
  18859. |> >
  18860. |> > I tried that, and it really screwed my logs up, because it would appear
  18861. |> > that the facility is broken in tap syslog on 4.1.59-6.  I set it to log to
  18862. |> > local6, but it logged to the syslog facility of the ARC instead of the
  18863. |> > facility I set for the tap user.  Is this a known issue?
  18864. |> >
  18865. |> Looks more like a syslogd issue, if configured for local6 the logs are
  18866. |> sent out as local6.  What is OS here ?  Solaris? Linux?
  18867. |>
  18868. |> Also we can do a snoop on the wire to find out what is being sent out by
  18869. |> the HiPer arc - I have setup local7 and the logs here go to local7
  18870. |
  18871. |ok, I can double check, but I had local7 going to a seperate file in
  18872. |syslog, and it still came out the facility of the hiper.  I will check
  18873. |again though.
  18874. |
  18875. |
  18876. |>
  18877. |> krish
  18878. |>
  18879. |>
  18880. |> >
  18881. |> > >
  18882. |> > > krish
  18883. |> > >
  18884. |> > > >
  18885. |> > > > Marshall Morgan
  18886. |> > > >
  18887. |> > > > Internet Doorway, Inc. (aka NETDOOR)
  18888. |> > > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  18889. |> > > >
  18890. |> > > > > -----Original Message-----
  18891. |> > > > > From: owner-usr-tc@lists.xmission.com
  18892. |> > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  18893. |> > > > > Sent: Monday, April 19, 1999 4:39 PM
  18894. |> > > > > To: usr-tc@lists.xmission.com
  18895. |> > > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
  18896. |> > > > >
  18897. |> > > > >
  18898. |> > > > > >
  18899. |> > > > > > Not much from a performance standpoint. The feature allows the
  18900. |> > > > > DSP's to share
  18901. |> > > > > > some of the overhead of PPP with the HARC. (Normally the modem
  18902. |> > > > > does not have any
  18903. |> > > > > > knowledge of PPP its only a data pipe). By disabling offloading
  18904. |> > > > > the HARC will
  18905. |> > > > > > handle all aspects of the PPP termination. The HARC has more than
  18906. |> > > > > enough power to
  18907. |> > > > > > do this with almost no noticalbe change in performance to the
  18908. |> > > > > dial user.  How
  18909. |> > > > > > many DSP's does your HARC control?
  18910. |> > > > >
  18911. |> > > > > 5 per arc.  I have heard disabling ppp offloading fixes the
  18912. |passwords from
  18913. |> > > > > getting munged in 1.2.43.  If this is the case, than
  18914. |certainly everyone
  18915. |> > > > > should do it right?
  18916. |> > > > >
  18917. |> > > >
  18918. |> > > >
  18919. |> > > > -
  18920. |> > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18921. |> > > >  with "unsubscribe usr-tc" in the body of the message.
  18922. |> > > >  For information on digests or retrieving files and old messages send
  18923. |> > > >  "help" to the same address.  Do not use quotes in your message.
  18924. |> > > >
  18925. |> > >
  18926. |> > > -
  18927. |> > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18928. |> > >  with "unsubscribe usr-tc" in the body of the message.
  18929. |> > >  For information on digests or retrieving files and old messages send
  18930. |> > >  "help" to the same address.  Do not use quotes in your message.
  18931. |> > >
  18932. |> >
  18933. |> > -----------------------------------------------------
  18934. |> > Brian Feeny (BF304)     signal@shreve.net
  18935. |> > 318-222-2638 x 109    http://www.shreve.net/~signal
  18936. |> > Network Administrator   ShreveNet Inc. (ASN 11881)
  18937. |> >
  18938. |> >
  18939. |> > -
  18940. |> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18941. |> >  with "unsubscribe usr-tc" in the body of the message.
  18942. |> >  For information on digests or retrieving files and old messages send
  18943. |> >  "help" to the same address.  Do not use quotes in your message.
  18944. |> >
  18945. |>
  18946. |
  18947. |-----------------------------------------------------
  18948. |Brian Feeny (BF304)     signal@shreve.net
  18949. |318-222-2638 x 109    http://www.shreve.net/~signal
  18950. |Network Administrator   ShreveNet Inc. (ASN 11881)
  18951. |
  18952. |
  18953. |-
  18954. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18955. | with "unsubscribe usr-tc" in the body of the message.
  18956. | For information on digests or retrieving files and old messages send
  18957. | "help" to the same address.  Do not use quotes in your message.
  18958. |
  18959.  
  18960.  
  18961. -
  18962.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18963.  with "unsubscribe usr-tc" in the body of the message.
  18964.  For information on digests or retrieving files and old messages send
  18965.  "help" to the same address.  Do not use quotes in your message.
  18966.  
  18967.  
  18968. -------------------------------------------------------------------------------
  18969.  
  18970. From: "C Thompson" <cthompson@wingnet.net>
  18971. Subject: (usr-tc) USR TC for sale w/Hiper ARC
  18972. Date: 21 Apr 1999 17:21:43 -0500
  18973.  
  18974. We are looking at the possiblity of selling one of our USR/3com Total 
  18975. Control racks.  Specs are as follows:  
  18976.  
  18977. Rackmount chassis
  18978. Integrated fan tray
  18979. 1 70 amp PS
  18980. 1 NMC with memory upgrade
  18981. 1 Dual PRI/T1 card
  18982. 12 digital/analog quad modem cards
  18983. 1 Hiper ARC card (relatively new)
  18984.  
  18985. Asking price = around $7250
  18986.  
  18987. Contact me if interested, or if you wish to register 
  18988. a bid.
  18989.  
  18990.  
  18991.  
  18992. Craig Thompson
  18993. WingNET Internet Services,
  18994. P.O. Box 3000 // Cleveland, TN 37320-3000
  18995. 423-559-LINK (v)  423-559-5444 (f)
  18996. http://www.wingnet.net
  18997.  
  18998. Things are more like they are today than they ever were before.
  18999.  
  19000.  
  19001. -
  19002.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19003.  with "unsubscribe usr-tc" in the body of the message.
  19004.  For information on digests or retrieving files and old messages send
  19005.  "help" to the same address.  Do not use quotes in your message.
  19006.  
  19007.  
  19008. -------------------------------------------------------------------------------
  19009.  
  19010. From: Paul Farber <farber@admin.f-tech.net>
  19011. Subject: (usr-tc) ARC Traps
  19012. Date: 21 Apr 1999 18:33:22 -0400 (EDT)
  19013.  
  19014. Hello all
  19015.  
  19016. I need to set up traps on the ol ARC to debug these call failures we seem
  19017. to have to live with.
  19018.  
  19019. I can get the ARC to syslog to my Linux box, but no traps ever come out of
  19020. the damned thing.
  19021.  
  19022. I 3kb'ed it and they assume that I am gonna use thier alarm server (it
  19023. seems).  I am using UCD-SNMP 3.5.3 and it will accept cold start traps
  19024. from local linux boxes, but the ARC dosen't want to caugh them up.  And I
  19025. know that I am getting call failures.
  19026.  
  19027. Does the normal syslog report call failures? The ARC chatters alot.. but
  19028. from what I have so far there have been no call failures (i wish).
  19029.  
  19030. Thanks.
  19031.  
  19032. Paul D. Farber II
  19033. Farber Technology
  19034. Ph. 570-628-5303
  19035. Fax 570-628-5545
  19036. farber@admin.f-tech.net
  19037.  
  19038.  
  19039. -
  19040.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19041.  with "unsubscribe usr-tc" in the body of the message.
  19042.  For information on digests or retrieving files and old messages send
  19043.  "help" to the same address.  Do not use quotes in your message.
  19044.  
  19045.  
  19046. -------------------------------------------------------------------------------
  19047.  
  19048. From: Greg Genge <greg@dynavar.com>
  19049. Subject: (usr-tc) Multiple TC Chassis 48 Port and HiPer Arc cards for sale, DSP
  19050. Date: 21 Apr 1999 17:22:22 -0600
  19051.  
  19052. I Have a customer upgrading to all DSP Cards and we have a number of Total
  19053. Control Shelves currently in production coming out soon. These all have
  19054. Dual Pri/T1, 48 Quad Digital, HiPer Arc card and HiPer NMC all running
  19055. latest code and ALL X2/V.90 enabled. from what I have seen these should go
  19056. for between $5500 and $7000 US each depending on Quantity, most are in Dual
  19057. 45Amp chassis and include the Fan tray (can be upgraded to newer 70Amp
  19058. integrated Fan tray chassis for additional charge). If you are interested,
  19059. send me your bid, Include how much, How many you would like. I need these
  19060. all to be gone by May 15th and will ship reasonable offers that come in.
  19061.  
  19062. I also have a number of Arc cards, taking offers for these as well around
  19063. $2000 each USD.
  19064.  
  19065. Also have lots of NMC and Netserver memory upgrades $100 US each, 2 or more
  19066. $75 each.
  19067.  
  19068. Also have
  19069.  
  19070. Regards, Greg  . . . . . Questions, Call me at 877-Dynavar
  19071.  
  19072.  
  19073. Gregory F. Genge, President, Dynavar Networking, Inc.
  19074. Toll Free  877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct,
  19075. 5005 Fax, http://www.dynavar.com
  19076. #300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
  19077. Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
  19078. Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible,
  19079. Microcom (Compaq), Garrett, Sonic, Cobalt.
  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: Greg Genge <greg@dynavar.com>
  19091. Subject: (usr-tc) 3446-0 HiPer DSP Cardsets Only $8335 trade 12Quads for 2 FREE
  19092. Date: 21 Apr 1999 17:33:30 -0600
  19093.  
  19094. We have a huge inventory of DSP Cardsets 48 ports, 003446-0 for only $8335
  19095. brand new (only for this list's members). Then you can trade in 12 Quad
  19096. cards and get another 48 ports of DSP cards for FREE from 3COM. For details
  19097. on our website, go to:
  19098.  
  19099. http://www.dynavar.com/product/3com/3com.htm
  19100.  
  19101. AND YES WE ARE AN NSP AUTHORIZED 3COM TOTAL CONTROL RESELLER (Largest in
  19102. Canada), Price includes delivery anywhere in US or Canada.
  19103.  
  19104. We also have sets of used Quad cards going for $3995 US OBO. that you can
  19105. trade in. Better pricing on multiple sets.
  19106.  
  19107. Questions call Greg at 877-DYNAVAR toll free.
  19108.  
  19109. Gregory F. Genge, President, Dynavar Networking, Inc.
  19110. Toll Free  877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct,
  19111. 5005 Fax, http://www.dynavar.com
  19112. #300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
  19113. Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
  19114. Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible,
  19115. Microcom (Compaq), Garrett, Sonic, Cobalt.
  19116.  
  19117. -
  19118.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19119.  with "unsubscribe usr-tc" in the body of the message.
  19120.  For information on digests or retrieving files and old messages send
  19121.  "help" to the same address.  Do not use quotes in your message.
  19122.  
  19123.  
  19124. -------------------------------------------------------------------------------
  19125.  
  19126. From: Robert von Bismarck <rvb@petrel.ch>
  19127. Subject: (usr-tc) Accepting 2400bps modem connections on HDM
  19128. Date: 22 Apr 1999 10:11:10 +0200
  19129.  
  19130. Hi,
  19131.  
  19132. What do I need to set up in an HDM to accept a pure 2400 bps (V.22bis)
  19133. connection ?
  19134.  
  19135. I have several customers who'd like to dial in with some handheld modems
  19136. that will only do V.22bis or Group3 FAX...
  19137.  
  19138. Thanks for any infos...
  19139.  
  19140. Robert
  19141.  
  19142.  
  19143. -
  19144.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19145.  with "unsubscribe usr-tc" in the body of the message.
  19146.  For information on digests or retrieving files and old messages send
  19147.  "help" to the same address.  Do not use quotes in your message.
  19148.  
  19149.  
  19150. -------------------------------------------------------------------------------
  19151.  
  19152. From: Robert von Bismarck <rvb@petrel.ch>
  19153. Subject: (usr-tc) MPIP, RIP and ping/traceroute
  19154. Date: 22 Apr 1999 16:01:28 +0200
  19155.  
  19156. I'm trying to set up my first MPIP connections with HiPerARC's
  19157.  
  19158. I have some problems with RIP updates and IP routing. My gateway router
  19159. seems to get a little confused with two entries in its RIP routing table. 
  19160.  
  19161.  Router# sh ip route rip
  19162. [ deleted items]
  19163. R    g.h.i.j [120/1] via a.r.c.1, 00:00:13, FastEthernet0/0
  19164.     g.h.i.j [120/1] via a.r.c.2, 00:00:22, FastEthernet0/0
  19165. Router# ping g.h.i.j
  19166.  
  19167. Type escape sequence to abort.
  19168. Sending 5, 100-byte ICMP Echoes to g.h.i.j, timeout is 2 seconds:
  19169. !..!!
  19170. Success rate is 60 percent (3/5), round-trip min/avg/max = 56/57/60 ms 
  19171.  
  19172. The pings go through slowly (I tried with a 64k connection, and it is okay
  19173. and much faster) and are not even all ACKed...
  19174.  
  19175. I tried doing a download with the ISDN device (a zyxel prestige router) and
  19176. got a lousy 3.5kb/s. with single-channel ISDN I get about 7.5kb/s.
  19177.  
  19178. Is there something special about MPIP, or is it simply lousy ?
  19179.  
  19180. I'm running ARC 4.1.72-7 and 1.2.5 on the DSP's (yeah, I should upgrade to
  19181. 4.1.59-6 now that 1.2.43 is out for the E1 HDM's, but I'm lazy and
  19182. overfilled with work)
  19183.  
  19184. Here's the setup of my PoP
  19185.  
  19186. ARC 1 with 5 DSP's and ARC2 with 5 DSP's, and ARC3 (spare) acting as MPIP
  19187. server
  19188. All the DSP's are in the same hunt group.
  19189.  
  19190. I did SET NETWORK USER default PPP MAX_CHANNELS 1 to disable MLPPP for all
  19191. users unless specified otherwise
  19192.  
  19193. I set up MPIP like this :
  19194.  
  19195. ARC1 : 
  19196. SET NTP PRIMARY_SERVER a.b.c.d
  19197. ENABLE NTP
  19198. ADD MPIP SERVER w.x.y.z SHAREDSECRET CRYPT
  19199. SET MPIP CLIENT_STATE ON
  19200.  
  19201. ARC2 :
  19202. Same as ARC1
  19203.  
  19204. ARC3:
  19205. SET NTP PRIMARY_SERVER a.b.c.d
  19206. ENABLE NTP
  19207. ADD MPIP CLIENT a.r.c.1 SHAREDSECRET CRYPT TYPE HIPER
  19208. ADD MPIP CLIENT a.r.c.2 SHAREDSECRET CRYPT TYPE HIPER
  19209.  
  19210. The RADIUS entry for the user is : 
  19211.  
  19212. test Password = "mpip" , Expiration = "Dec 24 2010"
  19213.     User-Service-Type = Framed-User,
  19214.     Framed-Address = g.h.i.j,
  19215.     Framed-Netmask = 255.255.255.255,
  19216.     Port-Limit = 2
  19217.  
  19218. The ARC's are all in different subnets, I don't know if that matters...
  19219.  
  19220. Thanks for any help, because the salesmen are chasing me to get 128k MLPPP
  19221. up and running...
  19222.  
  19223. Robert
  19224.  
  19225.  
  19226.  
  19227. -
  19228.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19229.  with "unsubscribe usr-tc" in the body of the message.
  19230.  For information on digests or retrieving files and old messages send
  19231.  "help" to the same address.  Do not use quotes in your message.
  19232.  
  19233.  
  19234. -------------------------------------------------------------------------------
  19235.  
  19236. From: "Brian M. Gordon" <administrator@westelcom.com>
  19237. Subject: IMAC??  (usr-tc)
  19238. Date: 22 Apr 1999 10:12:06 -0400
  19239.  
  19240. I have Hiper DSP's And Hiper ARC all newest code.
  19241.  
  19242. Whats the deal with IMAC is it totally incompatable unless you drop it down
  19243. to V.34?
  19244.  
  19245. Brian Gordon, MCP, A+
  19246. Network Administrator
  19247. Westelcom Internet
  19248. 518-566-8376 Voice
  19249. 518-566-8348 Fax
  19250. http://home.westelcom.com
  19251. administrator@westelcom.com
  19252.  
  19253.  
  19254. -
  19255.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19256.  with "unsubscribe usr-tc" in the body of the message.
  19257.  For information on digests or retrieving files and old messages send
  19258.  "help" to the same address.  Do not use quotes in your message.
  19259.  
  19260.  
  19261. -------------------------------------------------------------------------------
  19262.  
  19263. From: "Wayne Barber" <barberw@tidewater.net>
  19264. Subject: RE: IMAC??  (usr-tc)
  19265. Date: 22 Apr 1999 10:22:46 -0400
  19266.  
  19267. They need to install the Apple Modem Updater 1.2.1 which has been out since
  19268. at least January. How you get it to them can be a problem if they don't have
  19269. the floppy drive. I've heard it came on the CD with the January MacAddict
  19270. magazine.
  19271.  
  19272. Wayne Barber
  19273. Coastal Telco Services
  19274.  
  19275. > -----Original Message-----
  19276. > From: owner-usr-tc@lists.xmission.com
  19277. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian M. Gordon
  19278. > Sent: Thursday, April 22, 1999 10:12 AM
  19279. > To: usr-tc@lists.xmission.com
  19280. > Subject: IMAC?? (usr-tc)
  19281. >
  19282. >
  19283. > I have Hiper DSP's And Hiper ARC all newest code.
  19284. >
  19285. > Whats the deal with IMAC is it totally incompatable unless you
  19286. > drop it down
  19287. > to V.34?
  19288. >
  19289. > Brian Gordon, MCP, A+
  19290. > Network Administrator
  19291. > Westelcom Internet
  19292. > 518-566-8376 Voice
  19293. > 518-566-8348 Fax
  19294. > http://home.westelcom.com
  19295. > administrator@westelcom.com
  19296. >
  19297. >
  19298. > -
  19299. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19300. >  with "unsubscribe usr-tc" in the body of the message.
  19301. >  For information on digests or retrieving files and old messages send
  19302. >  "help" to the same address.  Do not use quotes in your message.
  19303. >
  19304.  
  19305.  
  19306. -
  19307.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19308.  with "unsubscribe usr-tc" in the body of the message.
  19309.  For information on digests or retrieving files and old messages send
  19310.  "help" to the same address.  Do not use quotes in your message.
  19311.  
  19312.  
  19313. -------------------------------------------------------------------------------
  19314.  
  19315. From: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
  19316. Subject: (usr-tc) FS: USR QUAD ANALOG/DIGITAL MODEMS
  19317. Date: 22 Apr 1999 11:13:21 -0400
  19318.  
  19319. Hello-
  19320.  
  19321. We are slowly replenishing our stock of USR Total Control Units and parts.
  19322.  
  19323. We now have (100+) Quad Analog/Digital Modems - V.34 USR# 000793-04 
  19324. $175.00 each (NAC only)
  19325.  
  19326. Also (6) Netserver PRI cards (NAC & NIC) USR#69-001393-00 Rev. 1 
  19327. w/ token ring NIC USR#69001827-00 Rev. C
  19328. $OFFER
  19329.  
  19330. (20) AC PSU 45A Power Supplies
  19331. $OFFER
  19332.  
  19333. More chassis in next week. ( I hope) 
  19334.  
  19335. With Warmest Regards,
  19336. Andrew Shlensky
  19337. ****************************
  19338. PC Global, Incorporated 
  19339. (305) 667-2111 TEL
  19340. (305) 667-3636 FAX
  19341. URL:     http://www.pcglobal.net
  19342. E-MAIL: andrew@pcglobal.net
  19343. ICQ:       21219089    
  19344.  
  19345.  
  19346. -
  19347.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19348.  with "unsubscribe usr-tc" in the body of the message.
  19349.  For information on digests or retrieving files and old messages send
  19350.  "help" to the same address.  Do not use quotes in your message.
  19351.  
  19352.  
  19353. -------------------------------------------------------------------------------
  19354.  
  19355. From: Jeff Mcadams <jeffm@iglou.com>
  19356. Subject: (usr-tc) OK...this is a weird one...
  19357. Date: 22 Apr 1999 11:23:09 -0400 (EDT)
  19358.  
  19359. Alright...I've got a few of my HiPer Arcs around here...had one in
  19360. service here in our main location here in Louisville, no problems.  Get
  19361. all the calls off of it and moved over to other equipment so I can take
  19362. it down to our POP in Lexington and replace two NETServers with it.
  19363. (this was yesterday).  I take out the two NETServers (chassis had 4
  19364. DSP's and two NETServers there) and plug the HiPer Arc into it.  The
  19365. HiPer Arc decides its going to do it long pause during boot-up thing.
  19366.  
  19367. This is the thing I ran into before where it pauses about 45 seconds
  19368. between each letter of "Loading kernel ... OK" during bootup...meaning
  19369. the boot up process takes about 10 minutes.  Last time this happened to
  19370. me I did the AT{FZ} thing during bootup to format and reflash the card
  19371. with the image and it fixed it.  Down in Lexington yesterday, I didn't
  19372. have a platform that I could run zmodem on (I was connected to the
  19373. console with an old Wyse60 terminal), so I put the NETServers back in
  19374. and bring the HiPer Arc back to Louisville to play with it some more
  19375. here.
  19376.  
  19377. I plug it in to a chassis this morning (the original one it was in
  19378. before I took it out to take down to Lexington), and it boots up
  19379. immediately, no pauses.  So for yucks, I take it out and put it in a
  19380. different chassis here in Louisville, and again, it boots up with no
  19381. pauses.
  19382.  
  19383. All three chassis are getting clocking from the backplane
  19384. (backplaneActive), the Lexington chassis and the second Louisville
  19385. chassis have NMC versions 5.5.1, the first Louisville chassis has NMC
  19386. version 5.5.5, the second Louisville chassis doesn't have any other
  19387. cards in it at all!  All chassis have the integrated fan tray with
  19388. enhanced packet bus and all.  Boot Rom version on the Arc is 1.16.  I
  19389. can't think of anything else that would be of any significance here.
  19390.  
  19391. One of the NETServers is fully functioning in slot 16 of the Lexington
  19392. chassis where I had plugged the HiPer Arc in.  The Arc was power cycled
  19393. and reseated multiple times while in the Lexington chassis.
  19394.  
  19395. Anyone have any enlightenment to share here?  I'm out of ideas.  I'm
  19396. planning on going back tomorrow and planning on taking a laptop with me
  19397. rather than the terminal so I can do a zmodem transfer (with flash
  19398. format) if necessary to get this thing working in that chassis.  I'd
  19399. *really* rather have an idea of what's causing rather than blindly
  19400. trying the flash format and have that *possibly* not fix it.
  19401. -- 
  19402. Jeff McAdams                            Email: jeffm@iglou.com
  19403. Head Network Administrator              Voice: (502) 966-3848
  19404. IgLou Internet Services                        (800) 436-4456
  19405.  
  19406. -
  19407.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19408.  with "unsubscribe usr-tc" in the body of the message.
  19409.  For information on digests or retrieving files and old messages send
  19410.  "help" to the same address.  Do not use quotes in your message.
  19411.  
  19412.  
  19413. -------------------------------------------------------------------------------
  19414.  
  19415. From: "John Verreault" <verreaul@aei.ca>
  19416. Subject: (usr-tc) HiperDSP Question
  19417. Date: 22 Apr 1999 11:24:53 -0400
  19418.  
  19419. I have one DSP card with a daughtercard.
  19420.  
  19421. All of my other DSP cards do not have a daughtercard.
  19422.  
  19423. Question: What is the daughtercard for???
  19424.  
  19425. Thanks
  19426. John
  19427.  
  19428.  
  19429. -
  19430.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19431.  with "unsubscribe usr-tc" in the body of the message.
  19432.  For information on digests or retrieving files and old messages send
  19433.  "help" to the same address.  Do not use quotes in your message.
  19434.  
  19435.  
  19436. -------------------------------------------------------------------------------
  19437.  
  19438. From: Brian <signal@shreve.net>
  19439. Subject: (usr-tc) tele com tests
  19440. Date: 22 Apr 1999 11:33:01 -0500 (CDT)
  19441.  
  19442.  
  19443. Anyone check out the April 19th issue of tele com?  They did tests on RAS
  19444. boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel.
  19445.  
  19446. Surprisingly, the 3Com box had the lowest density!  I guess 3Com is sort
  19447. of behind now in that area, even though they were one of the first to
  19448. offer the higher density boxes.
  19449.  
  19450. The Nortel 1800 looks like it is going to be a really nice box.  the 3Com
  19451. ARC based box (4.1.59) had the 2nd highest call completion rates, only to
  19452. be beat by the Nortel box by .8%.  the 3Com box was one of the most
  19453. expensive (only the lucent was more expensive).
  19454.  
  19455. The 3Com gear did not do well on the stress test IMHO.  And reading thru
  19456. the article, trying to find flaws, it looked like a pretty good test.
  19457. They do not mention what version of DSP code was in use however, I am
  19458. assuming 1.2.60, but I really don't know.  Can anyone from 3com perhaps
  19459. give insight on the stress test results, and possibly why the 3Com box
  19460. would score so poorly?  The throughput of the Assured Access, Ascend, and
  19461. Cisco boxes was pretty much the same, and very good.  Nortel, Lucent and
  19462. 3Com seemed more chaotic, with large jumps in throughput between different
  19463. sized packets.  The 3Com performed over 25% better with packets of 1518
  19464. and 256 in size vs packets of 108 in size.
  19465.  
  19466. It really appears alot was done to level the playing field to make this a
  19467. fair test.
  19468.  
  19469. I do not know whether 1 or 2 ARC's were used, and that may have all the
  19470. difference in the world as to why the tests scored the way they did.  They
  19471. used 383 ports simultaneously per box to do the test, and I am not sure
  19472. whether that was e1 or t1 code and how many hdm's and how many arcs. Does
  19473. anyone know?
  19474.  
  19475.  
  19476. Brian Feeny (BF304)     signal@shreve.net   
  19477. 318-222-2638 x 109    http://www.shreve.net/~signal      
  19478. Network Administrator   ShreveNet Inc. (ASN 11881)           
  19479.  
  19480.  
  19481. -
  19482.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19483.  with "unsubscribe usr-tc" in the body of the message.
  19484.  For information on digests or retrieving files and old messages send
  19485.  "help" to the same address.  Do not use quotes in your message.
  19486.  
  19487.  
  19488. -------------------------------------------------------------------------------
  19489.  
  19490. From: Marcelo Souza <mpsouza@centroin.com.br>
  19491. Subject: (usr-tc) Netserver messages
  19492. Date: 22 Apr 1999 13:39:13 -0300 (EST)
  19493.  
  19494.  
  19495.     I have one TC with Netserver that is giving lots of the following
  19496. syslog messages:
  19497.  
  19498. Apr 22 11:48:51 netserver1 S19 didn't get online! status=-1,
  19499. connect_fail=36, link_fail=31
  19500.  
  19501. Apr 22 12:22:54 netserver1 S43 didn't get online! status=-1,
  19502. connect_fail=79, link_fail=31
  19503.  
  19504.     What does it mean?
  19505.  
  19506. U.S. Robotics
  19507. Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.6.22
  19508.   Build date: Aug  1 1997
  19509.   Build time: 16:52:40
  19510.  
  19511. NMC v5.5.5
  19512.  
  19513.  
  19514. - Marcelo
  19515.  
  19516.  
  19517. -
  19518.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19519.  with "unsubscribe usr-tc" in the body of the message.
  19520.  For information on digests or retrieving files and old messages send
  19521.  "help" to the same address.  Do not use quotes in your message.
  19522.  
  19523.  
  19524. -------------------------------------------------------------------------------
  19525.  
  19526. From: Hofmann <jay@iglou.com>
  19527. Subject: (usr-tc) RE: (3Com - TotalControl): Lucent WildWire/V.90 Modems Not Connecting
  19528. Date: 22 Apr 1999 13:21:56 -0400
  19529.  
  19530. I have a user that can connect but gets very poor speeds.  Here is a copy of the logs he sent.
  19531.  
  19532. 04-20-1999 22:48:02.42 - Lucent V90+DSL WildWire Modem in use.
  19533. 04-20-1999 22:48:02.43 - Modem type: Lucent V90+DSL WildWire Modem
  19534. 04-20-1999 22:48:02.43 - Modem inf path: LTBLIZDF.INF
  19535. 04-20-1999 22:48:02.43 - Modem inf section: Modem_PNP_DSVD
  19536. 04-20-1999 22:48:02.57 - 115200,N,8,1
  19537. 04-20-1999 22:48:02.57 - 57600,N,8,1
  19538. 04-20-1999 22:48:02.57 - Initializing modem.
  19539. 04-20-1999 22:48:02.58 - Send: AT<cr>
  19540. 04-20-1999 22:48:02.58 - Recv: AT<cr>
  19541. 04-20-1999 22:48:02.58 - Recv: <cr><lf>OK<cr><lf> 
  19542. 04-20-1999 22:48:02.58 - Interpreted response: Ok 
  19543. 04-20-1999 22:48:02.58 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1<cr> 
  19544. 04-20-1999 22:48:03.11 - Recv: AT &F E0 &C1 &D2 V1 S0=0\V1<cr> 
  19545. 04-20-1999 22:48:03.11 - Recv: <cr><lf>OK<cr><lf> 
  19546. 04-20-1999 22:48:03.11 - Interpreted response: Ok 
  19547. 04-20-1999 22:48:03.11 - Send:  ATS7=60S30=0L0M1\N3%C1&K3B0B15B2N0\J1X4<cr> 
  19548. 04-20-1999 22:48:03.12 - Recv: <cr><lf>OK<cr><lf> 
  19549. 04-20-1999 22:48:03.12 - Interpreted response: Ok 
  19550. 04-20-1999 22:48:03.12 - Dialing.
  19551. 04-20-1999 22:48:03.12 - Send: ATDT;<cr> 
  19552. 04-20-1999 22:48:06.04 - Recv: <cr><lf>OK<cr><lf> 
  19553. 04-20-1999 22:48:06.04 - Interpreted response: Ok 
  19554. 04-20-1999 22:48:06.04 - Dialing.
  19555. 04-20-1999 22:48:06.04 - Send: ATDT#######<cr>
  19556. 04-20-1999 22:48:30.54 - Recv: <cr><lf>CONNECT 26400 V42bis<cr><lf> 
  19557. 04-20-1999 22:48:30.54 - Interpreted response: Connect 
  19558. 04-20-1999 22:48:30.54 - Connection established at 26400bps.  
  19559. 04-20-1999 22:48:30.54 - Error-control on.
  19560. 04-20-1999 22:48:30.54 - Data compression on.
  19561.  
  19562.  
  19563. Jay Hofmann                                     Email: jayh@iglou.com
  19564. Technical Support Team Leader               Voice: (502) 966-3848
  19565. IgLou Internet Services                            (800) 436-4456
  19566.  
  19567.  
  19568.  
  19569.  
  19570. -
  19571.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19572.  with "unsubscribe usr-tc" in the body of the message.
  19573.  For information on digests or retrieving files and old messages send
  19574.  "help" to the same address.  Do not use quotes in your message.
  19575.  
  19576.  
  19577. -------------------------------------------------------------------------------
  19578.  
  19579. From: Netlink Hardware admin <hw@netlinkcom.com>
  19580. Subject: Re: (usr-tc) tele com tests
  19581. Date: 22 Apr 1999 12:16:33 -0500 (CDT)
  19582.  
  19583.  
  19584. Were you able to view this article online, or do you have the printed
  19585. version? What URL?
  19586.  
  19587. I went to http://www.teledotcom.com but did not find this article.
  19588.  
  19589. Thanks,
  19590. Curt
  19591.  
  19592. On Thu, 22 Apr 1999, Brian wrote:
  19593.  
  19594. > 
  19595. > Anyone check out the April 19th issue of tele com?  They did tests on RAS
  19596. > boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel.
  19597. ><SNIP> 
  19598.  
  19599.  
  19600. -
  19601.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19602.  with "unsubscribe usr-tc" in the body of the message.
  19603.  For information on digests or retrieving files and old messages send
  19604.  "help" to the same address.  Do not use quotes in your message.
  19605.  
  19606.  
  19607. -------------------------------------------------------------------------------
  19608.  
  19609. From: "Sam Lowe" <slowe@universalcom.net>
  19610. Subject: Re: (usr-tc) tele com tests
  19611. Date: 22 Apr 1999 13:49:23 -0500
  19612.  
  19613. Here is the article:
  19614.  
  19615. http://www.data.com/issue/990421/ras.html
  19616.  
  19617. ----- Original Message -----
  19618. Sent: Thursday, April 22, 1999 12:16 PM
  19619.  
  19620.  
  19621. >
  19622. > Were you able to view this article online, or do you have the printed
  19623. > version? What URL?
  19624. >
  19625. > I went to http://www.teledotcom.com but did not find this article.
  19626. >
  19627. > Thanks,
  19628. > Curt
  19629. >
  19630. > On Thu, 22 Apr 1999, Brian wrote:
  19631. >
  19632. > >
  19633. > > Anyone check out the April 19th issue of tele com?  They did tests on
  19634. RAS
  19635. > > boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel.
  19636. > ><SNIP>
  19637. >
  19638. >
  19639. > -
  19640. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19641. >  with "unsubscribe usr-tc" in the body of the message.
  19642. >  For information on digests or retrieving files and old messages send
  19643. >  "help" to the same address.  Do not use quotes in your message.
  19644. >
  19645.  
  19646.  
  19647. -
  19648.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19649.  with "unsubscribe usr-tc" in the body of the message.
  19650.  For information on digests or retrieving files and old messages send
  19651.  "help" to the same address.  Do not use quotes in your message.
  19652.  
  19653.  
  19654. -------------------------------------------------------------------------------
  19655.  
  19656. From: Jeff Mcadams <jeffm@iglou.com>
  19657. Subject: (usr-tc) NETServer vs. Arc bus usage
  19658. Date: 22 Apr 1999 16:06:51 -0400 (EDT)
  19659.  
  19660. OK...have done some looking around...and I have an idea about my earlier
  19661. issue (where the HARC was loading so slowly on bootup)...
  19662.  
  19663. If I remember correctly, someone posted not to long ago a summary of
  19664. what busses were available in the mid-plane of the chassis...among them
  19665. were an ISA bus and a PCI bus (per slot?).  If I'm correct, the
  19666. NETServer I believe uses the ISA bus to communicate with its NIC card
  19667. and the HARC uses the PCI bus to communicate with its NIC card.  Since
  19668. I'm using a NETServer in the same slot that I had the HARC earlier, and
  19669. the HARC boots up normally in other chassis...I would suspect that the
  19670. HARC is possibly having trouble with the PCI bus on that slot?  At least
  19671. this seems reasonable.
  19672.  
  19673. Anyone have any thoughts on this?  I didn't get any responses to my
  19674. earlier post...would love to hear from some 3Com people about this
  19675. possibility.
  19676. -- 
  19677. Jeff McAdams                            Email: jeffm@iglou.com
  19678. Head Network Administrator              Voice: (502) 966-3848
  19679. IgLou Internet Services                        (800) 436-4456
  19680.  
  19681. -
  19682.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19683.  with "unsubscribe usr-tc" in the body of the message.
  19684.  For information on digests or retrieving files and old messages send
  19685.  "help" to the same address.  Do not use quotes in your message.
  19686.  
  19687.  
  19688. -------------------------------------------------------------------------------
  19689.  
  19690. From: Ricky Beam <jfbeam@beaker.interpath.net>
  19691. Subject: Re: (usr-tc) OK...this is a weird one...
  19692. Date: 22 Apr 1999 16:11:22 -0400 (EDT)
  19693.  
  19694. On Thu, 22 Apr 1999, Jeff Mcadams wrote:
  19695. >This is the thing I ran into before where it pauses about 45 seconds
  19696. >between each letter of "Loading kernel ... OK" during bootup...meaning
  19697. >the boot up process takes about 10 minutes.  Last time this happened to
  19698. >me I did the AT{FZ} thing during bootup to format and reflash the card
  19699. >with the image and it fixed it.  Down in Lexington yesterday, I didn't
  19700. >have a platform that I could run zmodem on (I was connected to the
  19701. >console with an old Wyse60 terminal), so I put the NETServers back in
  19702. >and bring the HiPer Arc back to Louisville to play with it some more
  19703. >here.
  19704.  
  19705. That sounds like a problem between the NIC and NAC.  I have seen the same
  19706. thing.  After some rather forceful reseating of the cards, it worked
  19707. just fine.  My bigest problem is/was having a netblazer plugged into the
  19708. consoles of the chassis.  If the netblazer port is not active, then the
  19709. ARC freezes during boot up -- looking at flow control?  None of the other
  19710. cards display this behavior (well, maybe the DSP card does.)
  19711.  
  19712. --Ricky
  19713.  
  19714.  
  19715.  
  19716. -
  19717.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19718.  with "unsubscribe usr-tc" in the body of the message.
  19719.  For information on digests or retrieving files and old messages send
  19720.  "help" to the same address.  Do not use quotes in your message.
  19721.  
  19722.  
  19723. -------------------------------------------------------------------------------
  19724.  
  19725. From: Greg Coffey <greg@coffey.com>
  19726. Subject: (usr-tc) Quad v.32 terbo Upgrade
  19727. Date: 22 Apr 1999 14:12:59 -0600
  19728.  
  19729. Can a v32terbo quad modem be upgraded firmware to v.34 or even v.90?  I
  19730. have five of them and they appear to be double sided.
  19731.  
  19732. Thanks,
  19733. Greg Coffey, CoffeyNet    Voice 307-234-5443   307-234-5446 Fax
  19734. ====================================================================
  19735. 142 S. Center St.          3Com v.90 56k $20 in Casper & Douglas
  19736. Casper, WY  82601       Local Internet for Casper, Rawlins, Douglas,
  19737. http://WWW.COFFEY.COM      Wheatland, Pinedale, Lander & Lusk, WY
  19738.  
  19739. -
  19740.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19741.  with "unsubscribe usr-tc" in the body of the message.
  19742.  For information on digests or retrieving files and old messages send
  19743.  "help" to the same address.  Do not use quotes in your message.
  19744.  
  19745.  
  19746. -------------------------------------------------------------------------------
  19747.  
  19748. From: "David Bachta" <David_Bachta@mw.3com.com>
  19749. Subject: Re: (usr-tc) HiperDSP Question
  19750. Date: 22 Apr 1999 15:31:22 -0500
  19751.  
  19752.  
  19753.  
  19754. Hi John,
  19755.  
  19756. Sounds like you have an E1 card.  The daughtercard adds the necessary hardware
  19757. (additional DSPs) to allow the HDSP to be used in an E1 environment.  The card
  19758. can still be used in a T1 environment, as long as you have T1/PRI code running
  19759. on it.
  19760.  
  19761. Regards,
  19762. David
  19763.  
  19764.  
  19765.  
  19766.  
  19767.  
  19768.  
  19769. "John Verreault" <verreaul@aei.ca> on 04/22/99 10:24:53 AM
  19770.  
  19771. Please respond to usr-tc@lists.xmission.com
  19772.  
  19773. cc:    (David Bachta/MW/US/3Com)
  19774.  
  19775.  
  19776.  
  19777.  
  19778. I have one DSP card with a daughtercard.
  19779.  
  19780. All of my other DSP cards do not have a daughtercard.
  19781.  
  19782. Question: What is the daughtercard for???
  19783.  
  19784. Thanks
  19785. John
  19786.  
  19787.  
  19788. -
  19789.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19790.  with "unsubscribe usr-tc" in the body of the message.
  19791.  For information on digests or retrieving files and old messages send
  19792.  "help" to the same address.  Do not use quotes in your message.
  19793.  
  19794.  
  19795.  
  19796.  
  19797.  
  19798.  
  19799.  
  19800.  
  19801. -
  19802.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19803.  with "unsubscribe usr-tc" in the body of the message.
  19804.  For information on digests or retrieving files and old messages send
  19805.  "help" to the same address.  Do not use quotes in your message.
  19806.  
  19807.  
  19808. -------------------------------------------------------------------------------
  19809.  
  19810. From: Mike Andrews <mandrews@termfrost.org>
  19811. Subject: Re: (usr-tc) OK...this is a weird one...
  19812. Date: 22 Apr 1999 16:52:27 -0400 (EDT)
  19813.  
  19814. On Thu, 22 Apr 1999, Ricky Beam wrote:
  19815.  
  19816. > just fine.  My bigest problem is/was having a netblazer plugged into the
  19817. > consoles of the chassis.  If the netblazer port is not active, then the
  19818. > ARC freezes during boot up -- looking at flow control?  None of the other
  19819. > cards display this behavior (well, maybe the DSP card does.)
  19820.  
  19821. This might not have anything to do with your problem (and I *really* doubt 
  19822. it's Jeff's problem), but try flipping dip switch 5 on the ARC.
  19823.  
  19824. Somewhere between ARC 4.0.x and 4.1.x releases, this dip switch became a
  19825. "ignore modem control signals" switch or something similar...  I'd cooked
  19826. up a custom 3-wire serial cable to connect the console port to a terminal
  19827. server and it stopped working around then.  It stopped working with 16 meg
  19828. NMC's too.  It still works on 4 meg NMC's, DSP's, Dual PRI's, and
  19829. NETservers, none of which seem to care about anything but transmit,
  19830. receive, and ground on the console.
  19831.  
  19832. It doesn't cause the card to lock up though, just stops the console from
  19833. printing almost everything...  so maybe this is something else.
  19834.  
  19835. By the way...
  19836.  
  19837. does anyone have a good RJ45-to-RJ45 cable to connect a 3com console port
  19838. to any other vendor's serial ports -- such as a Cisco aux port?  3com uses
  19839. one pinout, and Cisco, Xyplex, and Livingston/Lucent (and probably the
  19840. rest of the world) all use a different one.  On the "standard" pinout, the
  19841. middle pair are both ground, and the next pair out are transmit/receive,
  19842. so you could use an RJ11 cable if you didn't need modem control, and you
  19843. can do a null modem cable by just flipping a connector over at one end
  19844. (i.e. cisco console cables).  
  19845.  
  19846. But I can't even get 3com's RJ45->DB25 console cables connected to a Cisco
  19847. console cable with Cisco's DB25 adapter on it.  For some reason I've been
  19848. unable to get a working pinout despite tons of time with an RS232 breakout
  19849. box.  It should be really damn simple but I'm having a hard time.  
  19850. (brain... not... functioning...)
  19851.  
  19852.  
  19853. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  19854. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  19855. Microsoft operating system is like a dog without a brick tied to its head."
  19856.  
  19857.  
  19858. -
  19859.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19860.  with "unsubscribe usr-tc" in the body of the message.
  19861.  For information on digests or retrieving files and old messages send
  19862.  "help" to the same address.  Do not use quotes in your message.
  19863.  
  19864.  
  19865. -------------------------------------------------------------------------------
  19866.  
  19867. From: Scott Boggs <sboggs@unitedbank.net>
  19868. Subject: (usr-tc) HARC upgrade
  19869. Date: 22 Apr 1999 16:56:52 -0400
  19870.  
  19871. The HARC I got with the original chassis had 4.1.11 code.
  19872. I have the 4.1.59-6 code ready to load with TCM.
  19873. I am wondering about my current config and setup.
  19874. Will a new load blank my current settings? 
  19875. Example- Radius server ip, syslog server ip.
  19876. I also have a few static routes set up in the routing table.
  19877. Will those be safe?
  19878.  
  19879. Basically- does the process simply load the code, reboot, 
  19880. and start running again with new fixes and features?
  19881.  
  19882. Thanks,
  19883. Scott Boggs
  19884. United Bank
  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. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  19897. Subject: Re: (usr-tc) HARC upgrade
  19898. Date: 22 Apr 1999 16:50:49 -0500
  19899.  
  19900.  
  19901.  
  19902.      Scott:
  19903.  
  19904.      If you issue the command "save all" then all of your configuration will be
  19905. saved into NV-RAM, and will still be there after you reboot, or change code.
  19906.      I have been told that the Harc acts as if it has 3 memory areas (but this
  19907. is not necessarily the physical configuration).   There is  "active ram" where
  19908. things are actually done, then there are 2 areas of NV-RAM: one for the code,
  19909. and another for the configuration.  When you download new software it simply
  19910. replaces the software in the "NV-RAM for Code" area.   This is why you must
  19911. reboot a card after you download new code.  It must be moved from the NVRAM to
  19912. the "active" RAM, where it is then implemented.
  19913.      Many users download code during the day, and then issue the reboot command
  19914. during off hours, so as not to kick off too many End Users.
  19915.  
  19916.           Hope this helps.
  19917.  
  19918.  
  19919.                Todd      ;-}
  19920.  
  19921.  
  19922.  
  19923.  
  19924.  
  19925.  
  19926.  
  19927. Scott Boggs <sboggs@unitedbank.net> on 04/22/99 03:56:52 PM
  19928.  
  19929. Please respond to usr-tc@lists.xmission.com
  19930.  
  19931. cc:    (Todd Keister/MW/US/3Com)
  19932.  
  19933.  
  19934.  
  19935.  
  19936. The HARC I got with the original chassis had 4.1.11 code.
  19937. I have the 4.1.59-6 code ready to load with TCM.
  19938. I am wondering about my current config and setup.
  19939. Will a new load blank my current settings?
  19940. Example- Radius server ip, syslog server ip.
  19941. I also have a few static routes set up in the routing table.
  19942. Will those be safe?
  19943.  
  19944. Basically- does the process simply load the code, reboot,
  19945. and start running again with new fixes and features?
  19946.  
  19947. Thanks,
  19948. Scott Boggs
  19949. United Bank
  19950.  
  19951.  
  19952. -
  19953.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19954.  with "unsubscribe usr-tc" in the body of the message.
  19955.  For information on digests or retrieving files and old messages send
  19956.  "help" to the same address.  Do not use quotes in your message.
  19957.  
  19958.  
  19959.  
  19960.  
  19961.  
  19962.  
  19963.  
  19964.  
  19965. -
  19966.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19967.  with "unsubscribe usr-tc" in the body of the message.
  19968.  For information on digests or retrieving files and old messages send
  19969.  "help" to the same address.  Do not use quotes in your message.
  19970.  
  19971.  
  19972. -------------------------------------------------------------------------------
  19973.  
  19974. From: "John Verreault" <verreaul@aei.ca>
  19975. Subject: RE: (usr-tc) HiperDSP Question
  19976. Date: 22 Apr 1999 17:59:18 -0400
  19977.  
  19978. Thanks,
  19979. I had just figured that out. You have to SDL the T1 code for it to recognize
  19980. the card.
  19981.  
  19982. John
  19983.  
  19984. > -----Original Message-----
  19985. > From: owner-usr-tc@lists.xmission.com
  19986. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bachta
  19987. > Sent: Thursday, April 22, 1999 4:31 PM
  19988. > To: usr-tc@lists.xmission.com
  19989. > Subject: Re: (usr-tc) HiperDSP Question
  19990. >
  19991. >
  19992. >
  19993. >
  19994. > Hi John,
  19995. >
  19996. > Sounds like you have an E1 card.  The daughtercard adds the
  19997. > necessary hardware
  19998. > (additional DSPs) to allow the HDSP to be used in an E1
  19999. > environment.  The card
  20000. > can still be used in a T1 environment, as long as you have T1/PRI
  20001. > code running
  20002. > on it.
  20003. >
  20004. > Regards,
  20005. > David
  20006. >
  20007. >
  20008. >
  20009. >
  20010. >
  20011. >
  20012. > "John Verreault" <verreaul@aei.ca> on 04/22/99 10:24:53 AM
  20013. >
  20014. > Please respond to usr-tc@lists.xmission.com
  20015. >
  20016. > To:   usr-tc@lists.xmission.com
  20017. > cc:    (David Bachta/MW/US/3Com)
  20018. > Subject:  (usr-tc) HiperDSP Question
  20019. >
  20020. >
  20021. >
  20022. >
  20023. > I have one DSP card with a daughtercard.
  20024. >
  20025. > All of my other DSP cards do not have a daughtercard.
  20026. >
  20027. > Question: What is the daughtercard for???
  20028. >
  20029. > Thanks
  20030. > John
  20031. >
  20032. >
  20033. > -
  20034. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20035. >  with "unsubscribe usr-tc" in the body of the message.
  20036. >  For information on digests or retrieving files and old messages send
  20037. >  "help" to the same address.  Do not use quotes in your message.
  20038. >
  20039. >
  20040. >
  20041. >
  20042. >
  20043. >
  20044. >
  20045. >
  20046. > -
  20047. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20048. >  with "unsubscribe usr-tc" in the body of the message.
  20049. >  For information on digests or retrieving files and old messages send
  20050. >  "help" to the same address.  Do not use quotes in your message.
  20051. >
  20052.  
  20053.  
  20054. -
  20055.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20056.  with "unsubscribe usr-tc" in the body of the message.
  20057.  For information on digests or retrieving files and old messages send
  20058.  "help" to the same address.  Do not use quotes in your message.
  20059.  
  20060.  
  20061. -------------------------------------------------------------------------------
  20062.  
  20063. From: Ricky Beam <jfbeam@beaker.interpath.net>
  20064. Subject: Re: (usr-tc) OK...this is a weird one...
  20065. Date: 22 Apr 1999 21:01:09 -0400 (EDT)
  20066.  
  20067. On Thu, 22 Apr 1999, Mike Andrews wrote:
  20068. >This might not have anything to do with your problem (and I *really* doubt 
  20069. >it's Jeff's problem), but try flipping dip switch 5 on the ARC.
  20070.  
  20071. I started to suggest that to Jeff, but I doubt it would do anything.  In
  20072. my case, that made no difference at all.
  20073.  
  20074. >It doesn't cause the card to lock up though, just stops the console from
  20075. >printing almost everything...  so maybe this is something else.
  20076.  
  20077. It's not so much "locked up" but more hung waiting to transmit data to the
  20078. console.  It just stops doing what it's doing right there and waits for
  20079. the console to go active (hardware flow control) before continuing to
  20080. transmit data and complete the boot up seq.  I found that to be very
  20081. annoying at the time, but never took the time to point it out to 3Com.
  20082. (Being alpha code, there were muchmore important things to complain about.)
  20083.  
  20084. --Ricky
  20085.  
  20086.  
  20087.  
  20088. -
  20089.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20090.  with "unsubscribe usr-tc" in the body of the message.
  20091.  For information on digests or retrieving files and old messages send
  20092.  "help" to the same address.  Do not use quotes in your message.
  20093.  
  20094.  
  20095. -------------------------------------------------------------------------------
  20096.  
  20097. From: Randy Doran <RandyDoran@USA.net>
  20098. Subject: (usr-tc) 14 DSP, 1 ARC chassis does work!!!
  20099. Date: 23 Apr 1999 11:49:13 -0400
  20100.  
  20101.     My mistake,  one HiPerARC does handle 14 DSPs just fine.  It was just a
  20102. coincidence that my busy signals cleared up when I added the second ARCs to
  20103. each chassis.  It was only temporary and they returned.  It turned out to
  20104. be a Bell screw up, they added 8 new T1 PRIs to our hunt and didn't add any
  20105. additional paths to the group.  We had 51 PRIs and only 989 paths (should
  20106. be 1173.)  Since it was hunting roundRobin from the 5ESS switch the calls
  20107. filled up the 51 PRIs evenly until it reached 989 calls then we would get
  20108. busies.  There were still empty modems on every DSP so I couldn't pin point
  20109. the problem to any particular card.  I assumed it was that the ARCs
  20110. couldn't handle the load.  
  20111.     I want to use only one ARC per chassis because we have over 80 chassis in
  20112. our network.  At about $6K a pop that's a savings of about $480K!!!
  20113.  
  20114. At 05:39 PM 4/16/99 -0400, you wrote:
  20115. >I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code.
  20116. >We have 53 PRIs in the hunt group and it hunts round robin from the switch,
  20117. >i.e. it fills up the entire hunt group evenly.  I had one 14 PRI chassis
  20118. >with a single ARC in this hunt.  The calls filled up all 14 of those PRIs.
  20119. >But we started to get random regular busy signals on the hunt number when
  20120. >we were no where near filled up.  I added a second HiPerARC back to the
  20121. >chassis and the busy signals stopped.  My guess is that the ARC might not
  20122. >be able to handle too many incoming call setups all at once and it sends
  20123. >out a busy signal.  Some calls get through and then it eventually fills up.
  20124. > Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it
  20125. >can handle the load. just a guess.
  20126. >
  20127. > Randy Doran
  20128. > RAS-Network Engineer
  20129. > CyberGate e.spire Internet Services
  20130. >
  20131. >At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote:
  20132. >>As long as you do not use IPX - Hiper arc will support 14 DSPs
  20133. >>4.1.59 code 
  20134. >>krish
  20135. >>
  20136. >>-----------------------------------------
  20137. >>        \    T.S.V. Krishnan  \
  20138. >>         \      Network System Engineer \ ( : - : )
  20139. >>          \     3Com ............   \
  20140. >>        ----------------------------------------------/
  20141. >>tkrishna@bubba.ae.usr.com  
  20142. >>----------------------------/ http://interproc.ae.usr.com ----/
  20143. >>The Yadda Yadda Search - for simple anwers -
  20144. >http://interproc.ae.usr.com/tkb.html
  20145. >>-------------------------------------------------------------------------\
  20146. >>    Any Sufficiently advanced bug is indistinguishable for a feature.
  20147. >>                        - Rick Kulawiec
  20148. >>-------------------------------------------------------------------------/
  20149. >>
  20150. >>On Tue, 16 Feb 1999, Randy Cosby wrote:
  20151. >>
  20152. >>> Not really an answer, but do you still need 2 ARC's for a full chassis?  I
  20153. >>> thought with 4.1.72 and later, one ARC can handle a full chasis quite
  20154. >>> easily.  If not, please correct me, cause I'm about to add my 11th card
  20155. >with
  20156. >>> 4.1.59 :)
  20157. >>> 
  20158. >>> Randy
  20159. >>> 
  20160. >>> > -----Original Message-----
  20161. >>> > From: owner-usr-tc@lists.xmission.com
  20162. >>> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader
  20163. >>> > Sent: Tuesday, February 16, 1999 4:51 PM
  20164. >>> > To: usr-tc@lists.xmission.com
  20165. >>> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration
  20166. >>> >
  20167. >>> >
  20168. >>> > We are an ISP with dialin PPP only that is authenticated by Radius.
  20169. >>> > We have just purchase a 14 DSP, 2 ARC chassis.  Our experience
  20170. to-date is
  20171. >>> > with only 10 DSP, 2 ARC chassis.  Previously we have split a
  20172. >>> > single class C
  20173. >>> > between the 2 ARCs and have 121 IPs assigned to each.  Question: How to
  20174. >>> > combine parts of two class Cs to a single card. For example 120 address
  20175. >>> > from 1.2.3.xxx and 49 from 1.2.4.xxx.  I know I should be able to set up
  20176. >>> > ippool for each part of each class C, but I don't know if the ARC's
  20177. >>> > ethernet port needs to have an address from each class C or just one
  20178. >or if
  20179. >>> > it can be assigned an address from another class C completely.
  20180. >>> >
  20181. >>> >
  20182. >>> >
  20183. >>> >
  20184. >>> > -
  20185. >>> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20186. >>> >  with "unsubscribe usr-tc" in the body of the message.
  20187. >>> >  For information on digests or retrieving files and old messages send
  20188. >>> >  "help" to the same address.  Do not use quotes in your message.
  20189. >>> >
  20190. >>> 
  20191. >>> 
  20192. >>> -
  20193. >>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20194. >>>  with "unsubscribe usr-tc" in the body of the message.
  20195. >>>  For information on digests or retrieving files and old messages send
  20196. >>>  "help" to the same address.  Do not use quotes in your message.
  20197. >>> 
  20198. >>
  20199. >>-
  20200. >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20201. >> with "unsubscribe usr-tc" in the body of the message.
  20202. >> For information on digests or retrieving files and old messages send
  20203. >> "help" to the same address.  Do not use quotes in your message.
  20204. >>
  20205. >
  20206. >-
  20207. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20208. > with "unsubscribe usr-tc" in the body of the message.
  20209. > For information on digests or retrieving files and old messages send
  20210. > "help" to the same address.  Do not use quotes in your message.
  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: Brian <signal@shreve.net>
  20223. Subject: Re: (usr-tc) tele com tests
  20224. Date: 23 Apr 1999 11:10:58 -0500 (CDT)
  20225.  
  20226. On Thu, 22 Apr 1999, Netlink Hardware admin wrote:
  20227.  
  20228. > 
  20229. > Were you able to view this article online, or do you have the printed
  20230. > version? What URL?
  20231. > 
  20232. > I went to http://www.teledotcom.com but did not find this article.
  20233.  
  20234. I have the actual article entitled "Montoer RASs: Growing Pains?" by
  20235. David Newman.
  20236.  
  20237. Their maybe some info at www.data.com/issue/990421/ras.html
  20238.  
  20239.  
  20240.  
  20241.  
  20242. > 
  20243. > Thanks,
  20244. > Curt
  20245. > 
  20246. > On Thu, 22 Apr 1999, Brian wrote:
  20247. > 
  20248. > > 
  20249. > > Anyone check out the April 19th issue of tele com?  They did tests on RAS
  20250. > > boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel.
  20251. > ><SNIP> 
  20252. > 
  20253. > 
  20254. > -
  20255. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20256. >  with "unsubscribe usr-tc" in the body of the message.
  20257. >  For information on digests or retrieving files and old messages send
  20258. >  "help" to the same address.  Do not use quotes in your message.
  20259. > 
  20260.  
  20261. Brian Feeny (BF304)     signal@shreve.net   
  20262. 318-222-2638 x 109    http://www.shreve.net/~signal      
  20263. Network Administrator   ShreveNet Inc. (ASN 11881)           
  20264.  
  20265.  
  20266. -
  20267.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20268.  with "unsubscribe usr-tc" in the body of the message.
  20269.  For information on digests or retrieving files and old messages send
  20270.  "help" to the same address.  Do not use quotes in your message.
  20271.  
  20272.  
  20273. -------------------------------------------------------------------------------
  20274.  
  20275. From: Jeff Mcadams <jeffm@iglou.com>
  20276. Subject: Re: (usr-tc) MPIP, RIP and ping/traceroute
  20277. Date: 23 Apr 1999 14:01:41 -0400 (EDT)
  20278.  
  20279. Thus spake Robert von Bismarck
  20280. >I'm trying to set up my first MPIP connections with HiPerARC's
  20281.  
  20282. >I have some problems with RIP updates and IP routing. My gateway router
  20283. >seems to get a little confused with two entries in its RIP routing table. 
  20284.  
  20285. > Router# sh ip route rip
  20286. >[ deleted items]
  20287. >R    g.h.i.j [120/1] via a.r.c.1, 00:00:13, FastEthernet0/0
  20288. >    g.h.i.j [120/1] via a.r.c.2, 00:00:22, FastEthernet0/0
  20289. >Router# ping g.h.i.j
  20290.  
  20291. >Type escape sequence to abort.
  20292. >Sending 5, 100-byte ICMP Echoes to g.h.i.j, timeout is 2 seconds:
  20293. >!..!!
  20294. >Success rate is 60 percent (3/5), round-trip min/avg/max = 56/57/60 ms 
  20295.  
  20296. >Is there something special about MPIP, or is it simply lousy ?
  20297.  
  20298. Well...I don't think you're seeing any lousyness of MPIP here.  I think
  20299. you're just plain seeing MPIP not working at all.  Perhaps config isn't
  20300. quite right yet.  Couple of ideas off the top of my head...is the time
  20301. set on all the Arcs (via NTP) and synced up correctly?  (within a few
  20302. seconds of each other).  Is the server_state on in your MPIP server?  Is
  20303. your MPIP server set up to use itself as its own MPIP server?  Is your
  20304. MPIP server set up as a client of itself?  Is your MPIP server's client
  20305. table populated with all your MPIP client machines?  Do all your MPIP
  20306. client machines have the correct MPIP server configured?  Do all the
  20307. shared secrets match in these configurations?
  20308.  
  20309. These are the base things you need to have set up correctly for MPIP to
  20310. work.
  20311.  
  20312. >ARC3:
  20313. >SET NTP PRIMARY_SERVER a.b.c.d
  20314. >ENABLE NTP
  20315. >ADD MPIP CLIENT a.r.c.1 SHAREDSECRET CRYPT TYPE HIPER
  20316. >ADD MPIP CLIENT a.r.c.2 SHAREDSECRET CRYPT TYPE HIPER
  20317.  
  20318. Add:
  20319. set mpip server_state on
  20320. add mpip client <mpip server's ip> sharedsecret crypt type hiper
  20321.  
  20322. I *think* that should take care of it all.
  20323.  
  20324. >The ARC's are all in different subnets, I don't know if that matters...
  20325.  
  20326. Shouldn't.
  20327. -- 
  20328. Jeff McAdams                            Email: jeffm@iglou.com
  20329. Head Network Administrator              Voice: (502) 966-3848
  20330. IgLou Internet Services                        (800) 436-4456
  20331.  
  20332. -
  20333.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20334.  with "unsubscribe usr-tc" in the body of the message.
  20335.  For information on digests or retrieving files and old messages send
  20336.  "help" to the same address.  Do not use quotes in your message.
  20337.  
  20338.  
  20339. -------------------------------------------------------------------------------
  20340.  
  20341. From: "Robb Bryn" <rbryn@cape-fear.net>
  20342. Subject: (usr-tc) Total Control Performance on a 100Mps Switch...
  20343. Date: 23 Apr 1999 15:28:45 -0400
  20344.  
  20345. We recently tried to upgrade all of our Internet related equipment to 100Mps
  20346. and experienced severe performance degradation for our dialup users.  The
  20347. basic scenario is that we were saturating our 10Mpbs network with extraneous
  20348. net traffic so we decided to put all Internet related equip on an unmanaged
  20349. 10/100 Fast Ethernet Switch (the Dlink DES-1008).  All routers, a TC Hub
  20350. with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch.
  20351.  
  20352. What we found was that the TChub started failing to resolve DNS on a first
  20353. attempt (it was actually timing out), the second attempt always worked.
  20354. Alot of sites for our users stopped working (specifically allot of
  20355. shockwave/flash sites).  Mac users consistently got Socket broken messages.
  20356. All other machines on the switch were performing exceptionally well, the TC
  20357. unit just kinda died.  If we move it all back to a plain 10Mps non-switching
  20358. hub everything is beautiful again.
  20359.  
  20360. I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20361. normal. It's definitely not what I was expecting.  Anyone have similar
  20362. setups with switches?
  20363.  
  20364. Thanks
  20365. Robb Bryn
  20366.  
  20367.  
  20368. -
  20369.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20370.  with "unsubscribe usr-tc" in the body of the message.
  20371.  For information on digests or retrieving files and old messages send
  20372.  "help" to the same address.  Do not use quotes in your message.
  20373.  
  20374.  
  20375. -------------------------------------------------------------------------------
  20376.  
  20377. From: Dan Hollis <goemon@sasami.anime.net>
  20378. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20379. Date: 23 Apr 1999 12:38:19 -0700 (PDT)
  20380.  
  20381. On Fri, 23 Apr 1999, Robb Bryn wrote:
  20382. > I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20383. > normal. It's definitely not what I was expecting.  Anyone have similar
  20384. > setups with switches?
  20385.  
  20386. The TC doesnt like certain hubs and switches. For example it completely
  20387. brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20388. equipment has ever had problems with this hub, just the TC. I dont know
  20389. why the TC is so touchy although I suspect its buggy or completly broken 
  20390. 10/100 autodetect.
  20391.  
  20392. -Dan
  20393.  
  20394.  
  20395. -
  20396.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20397.  with "unsubscribe usr-tc" in the body of the message.
  20398.  For information on digests or retrieving files and old messages send
  20399.  "help" to the same address.  Do not use quotes in your message.
  20400.  
  20401.  
  20402. -------------------------------------------------------------------------------
  20403.  
  20404. From: Ronald Kushner <ron@glis.net>
  20405. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20406. Date: 23 Apr 1999 15:50:32 -0400
  20407.  
  20408.  
  20409.  
  20410. Dan Hollis wrote:
  20411. > 
  20412. > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20413. > > I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20414. > > normal. It's definitely not what I was expecting.  Anyone have similar
  20415. > > setups with switches?
  20416. > 
  20417. > The TC doesnt like certain hubs and switches. For example it completely
  20418. > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20419. > equipment has ever had problems with this hub, just the TC. I dont know
  20420. > why the TC is so touchy although I suspect its buggy or completly broken
  20421. > 10/100 autodetect.
  20422.  
  20423. Has anyone compiled a list of known good or known bad auto-detecting 10/100
  20424. switching hubs when used with a Total Control?
  20425.  
  20426. If not, readers can e-mail me off the list telling me about your experiences
  20427. with different switching hubs connected to the Total Control chassis and I
  20428. will post the results to the list.
  20429.  
  20430. -Ron
  20431. GLISnet, Inc.
  20432. +1 810/939.9885
  20433.  
  20434. -
  20435.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20436.  with "unsubscribe usr-tc" in the body of the message.
  20437.  For information on digests or retrieving files and old messages send
  20438.  "help" to the same address.  Do not use quotes in your message.
  20439.  
  20440.  
  20441. -------------------------------------------------------------------------------
  20442.  
  20443. From: "Jamie Orzechowski" <mhz@ripnet.com>
  20444. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20445. Date: 23 Apr 1999 15:48:32 -0400
  20446.  
  20447. same here ... I plugged in a new HARC to a Alteon AceDirectory switch which
  20448. was set to auto and it didn;t work at all I had to force 100mb/sec ...
  20449.  
  20450. ----- Original Message -----
  20451. Sent: Friday, April 23, 1999 3:38 PM
  20452.  
  20453.  
  20454. > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20455. > > I'll admit, I'm new to 10/100 switching technology and don't know if
  20456. this is
  20457. > > normal. It's definitely not what I was expecting.  Anyone have similar
  20458. > > setups with switches?
  20459. >
  20460. > The TC doesnt like certain hubs and switches. For example it completely
  20461. > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20462. > equipment has ever had problems with this hub, just the TC. I dont know
  20463. > why the TC is so touchy although I suspect its buggy or completly broken
  20464. > 10/100 autodetect.
  20465. >
  20466. > -Dan
  20467. >
  20468. >
  20469. > -
  20470. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20471. >  with "unsubscribe usr-tc" in the body of the message.
  20472. >  For information on digests or retrieving files and old messages send
  20473. >  "help" to the same address.  Do not use quotes in your message.
  20474. >
  20475. >
  20476.  
  20477.  
  20478. -
  20479.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20480.  with "unsubscribe usr-tc" in the body of the message.
  20481.  For information on digests or retrieving files and old messages send
  20482.  "help" to the same address.  Do not use quotes in your message.
  20483.  
  20484.  
  20485. -------------------------------------------------------------------------------
  20486.  
  20487. From: Curt Shambeau <curt@execpc.com>
  20488. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20489. Date: 23 Apr 1999 14:54:09 -0500 (CDT)
  20490.  
  20491. > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20492. > > I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20493. > > normal. It's definitely not what I was expecting.  Anyone have similar
  20494. > > setups with switches?
  20495.  
  20496. No problem when plugged into Bay Networks 350T/450T switches.
  20497.  
  20498. | Curtis V. Shambeau  |  curt@execpc.com  |  http://www.execpc.com/~curt |
  20499. |                Senior Vice President - Exec-PC, Inc.                   |
  20500.  
  20501.  
  20502. -
  20503.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20504.  with "unsubscribe usr-tc" in the body of the message.
  20505.  For information on digests or retrieving files and old messages send
  20506.  "help" to the same address.  Do not use quotes in your message.
  20507.  
  20508.  
  20509. -------------------------------------------------------------------------------
  20510.  
  20511. From: "Robb Bryn" <rbryn@cape-fear.net>
  20512. Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
  20513. Date: 23 Apr 1999 15:55:49 -0400
  20514.  
  20515. I don't know if the problem is the autodetect or not.  The Hub talks to the
  20516. rest of the network fine, the switch picks it up as 100Mps.
  20517.  
  20518. Is there a good way to test for packet loss from the HARC to another device
  20519. on the switch?
  20520.  
  20521. Thanks
  20522. Robb Bryn
  20523.  
  20524.  
  20525.  
  20526. > -----Original Message-----
  20527. > From: owner-usr-tc@lists.xmission.com
  20528. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski
  20529. > Sent: Friday, April 23, 1999 3:49 PM
  20530. > To: usr-tc@lists.xmission.com
  20531. > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20532. >
  20533. >
  20534. > same here ... I plugged in a new HARC to a Alteon
  20535. > AceDirectory switch which
  20536. > was set to auto and it didn;t work at all I had to force 100mb/sec ...
  20537. >
  20538. > ----- Original Message -----
  20539. > From: Dan Hollis <goemon@sasami.anime.net>
  20540. > To: <usr-tc@lists.xmission.com>
  20541. > Sent: Friday, April 23, 1999 3:38 PM
  20542. > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20543. >
  20544. >
  20545. > > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20546. > > > I'll admit, I'm new to 10/100 switching technology and
  20547. > don't know if
  20548. > this is
  20549. > > > normal. It's definitely not what I was expecting.  Anyone
  20550. > have similar
  20551. > > > setups with switches?
  20552. > >
  20553. > > The TC doesnt like certain hubs and switches. For example
  20554. > it completely
  20555. > > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20556. > > equipment has ever had problems with this hub, just the TC.
  20557. > I dont know
  20558. > > why the TC is so touchy although I suspect its buggy or
  20559. > completly broken
  20560. > > 10/100 autodetect.
  20561. > >
  20562. > > -Dan
  20563. > >
  20564. > >
  20565. > > -
  20566. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20567. > >  with "unsubscribe usr-tc" in the body of the message.
  20568. > >  For information on digests or retrieving files and old
  20569. > messages send
  20570. > >  "help" to the same address.  Do not use quotes in your message.
  20571. > >
  20572. > >
  20573. >
  20574. >
  20575. > -
  20576. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20577. >  with "unsubscribe usr-tc" in the body of the message.
  20578. >  For information on digests or retrieving files and old messages send
  20579. >  "help" to the same address.  Do not use quotes in your message.
  20580. >
  20581.  
  20582.  
  20583. -
  20584.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20585.  with "unsubscribe usr-tc" in the body of the message.
  20586.  For information on digests or retrieving files and old messages send
  20587.  "help" to the same address.  Do not use quotes in your message.
  20588.  
  20589.  
  20590. -------------------------------------------------------------------------------
  20591.  
  20592. From: Mike Andrews <mandrews@termfrost.org>
  20593. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20594. Date: 23 Apr 1999 16:13:51 -0400 (EDT)
  20595.  
  20596. On Fri, 23 Apr 1999, Dan Hollis wrote:
  20597.  
  20598. > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20599. > > I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20600. > > normal. It's definitely not what I was expecting.  Anyone have similar
  20601. > > setups with switches?
  20602. > 
  20603. > The TC doesnt like certain hubs and switches. For example it completely
  20604. > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20605. > equipment has ever had problems with this hub, just the TC. I dont know
  20606. > why the TC is so touchy although I suspect its buggy or completly broken 
  20607. > 10/100 autodetect.
  20608.  
  20609. How about a Cisco Catalyst 2924?  We were thinking of getting one...
  20610. anyone?
  20611.  
  20612.  
  20613. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  20614. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  20615. Microsoft operating system is like a dog without a brick tied to its head."
  20616.  
  20617.  
  20618. -
  20619.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20620.  with "unsubscribe usr-tc" in the body of the message.
  20621.  For information on digests or retrieving files and old messages send
  20622.  "help" to the same address.  Do not use quotes in your message.
  20623.  
  20624.  
  20625. -------------------------------------------------------------------------------
  20626.  
  20627. From: Jim Johnson <jim@perigee.net>
  20628. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20629. Date: 23 Apr 1999 16:19:49 -0400
  20630.  
  20631. How about a HP ProCurve 2224 10/100 switch.  We just ordered it!
  20632.  
  20633.  
  20634. Robb Bryn wrote:
  20635. > 
  20636. > We recently tried to upgrade all of our Internet related equipment to 100Mps
  20637. > and experienced severe performance degradation for our dialup users.  The
  20638. > basic scenario is that we were saturating our 10Mpbs network with extraneous
  20639. > net traffic so we decided to put all Internet related equip on an unmanaged
  20640. > 10/100 Fast Ethernet Switch (the Dlink DES-1008).  All routers, a TC Hub
  20641. > with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch.
  20642. > 
  20643. > What we found was that the TChub started failing to resolve DNS on a first
  20644. > attempt (it was actually timing out), the second attempt always worked.
  20645. > Alot of sites for our users stopped working (specifically allot of
  20646. > shockwave/flash sites).  Mac users consistently got Socket broken messages.
  20647. > All other machines on the switch were performing exceptionally well, the TC
  20648. > unit just kinda died.  If we move it all back to a plain 10Mps non-switching
  20649. > hub everything is beautiful again.
  20650. > 
  20651. > I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20652. > normal. It's definitely not what I was expecting.  Anyone have similar
  20653. > setups with switches?
  20654. > 
  20655. > Thanks
  20656. > Robb Bryn
  20657. > 
  20658. > -
  20659. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20660. >  with "unsubscribe usr-tc" in the body of the message.
  20661. >  For information on digests or retrieving files and old messages send
  20662. >  "help" to the same address.  Do not use quotes in your message.
  20663.  
  20664. -
  20665.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20666.  with "unsubscribe usr-tc" in the body of the message.
  20667.  For information on digests or retrieving files and old messages send
  20668.  "help" to the same address.  Do not use quotes in your message.
  20669.  
  20670.  
  20671. -------------------------------------------------------------------------------
  20672.  
  20673. From: "Randy Cosby" <dcosby@infowest.com>
  20674. Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
  20675. Date: 23 Apr 1999 14:22:24 -0600
  20676.  
  20677. HP 2424M 10/100 for me.  Great $200 rebate.  Hope it works :)
  20678.  
  20679. Randy
  20680.  
  20681.  
  20682. -----Original Message-----
  20683. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  20684. Sent: Friday, April 23, 1999 2:20 PM
  20685.  
  20686.  
  20687. How about a HP ProCurve 2224 10/100 switch.  We just ordered it!
  20688.  
  20689.  
  20690. Robb Bryn wrote:
  20691. >
  20692. > We recently tried to upgrade all of our Internet related equipment to
  20693. 100Mps
  20694. > and experienced severe performance degradation for our dialup users.  The
  20695. > basic scenario is that we were saturating our 10Mpbs network with
  20696. extraneous
  20697. > net traffic so we decided to put all Internet related equip on an
  20698. unmanaged
  20699. > 10/100 Fast Ethernet Switch (the Dlink DES-1008).  All routers, a TC Hub
  20700. > with Hiper Arc, DNS servers, mail servers, etc. all went on the same
  20701. switch.
  20702. >
  20703. > What we found was that the TChub started failing to resolve DNS on a first
  20704. > attempt (it was actually timing out), the second attempt always worked.
  20705. > Alot of sites for our users stopped working (specifically allot of
  20706. > shockwave/flash sites).  Mac users consistently got Socket broken
  20707. messages.
  20708. > All other machines on the switch were performing exceptionally well, the
  20709. TC
  20710. > unit just kinda died.  If we move it all back to a plain 10Mps
  20711. non-switching
  20712. > hub everything is beautiful again.
  20713. >
  20714. > I'll admit, I'm new to 10/100 switching technology and don't know if this
  20715. is
  20716. > normal. It's definitely not what I was expecting.  Anyone have similar
  20717. > setups with switches?
  20718. >
  20719. > Thanks
  20720. > Robb Bryn
  20721. >
  20722. > -
  20723. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20724. >  with "unsubscribe usr-tc" in the body of the message.
  20725. >  For information on digests or retrieving files and old messages send
  20726. >  "help" to the same address.  Do not use quotes in your message.
  20727.  
  20728. -
  20729.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20730.  with "unsubscribe usr-tc" in the body of the message.
  20731.  For information on digests or retrieving files and old messages send
  20732.  "help" to the same address.  Do not use quotes in your message.
  20733.  
  20734.  
  20735. -
  20736.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20737.  with "unsubscribe usr-tc" in the body of the message.
  20738.  For information on digests or retrieving files and old messages send
  20739.  "help" to the same address.  Do not use quotes in your message.
  20740.  
  20741.  
  20742. -------------------------------------------------------------------------------
  20743.  
  20744. From: <pferraro@wna-linknet.com>
  20745. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20746. Date: 23 Apr 1999 16:37:27 -0400 (EDT)
  20747.  
  20748.  
  20749.     We are running the Intel Express 220T and have not experienced any
  20750. problems...
  20751.  
  20752. ==============================================================================
  20753. Phillip Ferraro                WorldNet Access, Inc
  20754. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  20755. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  20756. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  20757. ==============================================================================
  20758.  
  20759. On Fri, 23 Apr 1999, Dan Hollis wrote:
  20760.  
  20761. > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20762. > > I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20763. > > normal. It's definitely not what I was expecting.  Anyone have similar
  20764. > > setups with switches?
  20765. > 
  20766. > The TC doesnt like certain hubs and switches. For example it completely
  20767. > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20768. > equipment has ever had problems with this hub, just the TC. I dont know
  20769. > why the TC is so touchy although I suspect its buggy or completly broken 
  20770. > 10/100 autodetect.
  20771. > 
  20772. > -Dan
  20773. > 
  20774. > 
  20775. > -
  20776. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20777. >  with "unsubscribe usr-tc" in the body of the message.
  20778. >  For information on digests or retrieving files and old messages send
  20779. >  "help" to the same address.  Do not use quotes in your message.
  20780. > 
  20781.  
  20782.  
  20783. -
  20784.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20785.  with "unsubscribe usr-tc" in the body of the message.
  20786.  For information on digests or retrieving files and old messages send
  20787.  "help" to the same address.  Do not use quotes in your message.
  20788.  
  20789.  
  20790. -------------------------------------------------------------------------------
  20791.  
  20792. From: "Sam Lowe" <slowe@universalcom.net>
  20793. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20794. Date: 23 Apr 1999 16:43:06 -0500
  20795.  
  20796. We use HP ProCurve switches and they work great.  No problems with the TC or
  20797. anything else we plug into them.
  20798.  
  20799. Samuel S. Lowe
  20800. Director, Data Network Services
  20801. UniversalCom, Inc.
  20802. slowe@universalcom.net
  20803.  
  20804. ----- Original Message -----
  20805. Sent: Friday, April 23, 1999 3:13 PM
  20806.  
  20807.  
  20808. >
  20809.  
  20810.  
  20811. -
  20812.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20813.  with "unsubscribe usr-tc" in the body of the message.
  20814.  For information on digests or retrieving files and old messages send
  20815.  "help" to the same address.  Do not use quotes in your message.
  20816.  
  20817.  
  20818. -------------------------------------------------------------------------------
  20819.  
  20820. From: Marcelo Souza <mpsouza@centroin.com.br>
  20821. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20822. Date: 23 Apr 1999 18:13:06 -0300 (EST)
  20823.  
  20824.  
  20825.     Try to find if the TC is trying to use a full duplex on a swtich
  20826. that doesn't support or is configured to half-duplex.
  20827.     If your swtich have a monitor software you could be able to see
  20828. what kind of error the port is showing.
  20829.     Here we have no problems with BayStack 350T.
  20830.  
  20831. - Marcelo 
  20832.  
  20833. On Fri, 23 Apr 1999, Robb Bryn wrote:
  20834.  
  20835. |We recently tried to upgrade all of our Internet related equipment to 100Mps
  20836. |and experienced severe performance degradation for our dialup users.  The
  20837. |basic scenario is that we were saturating our 10Mpbs network with extraneous
  20838. |net traffic so we decided to put all Internet related equip on an unmanaged
  20839. |10/100 Fast Ethernet Switch (the Dlink DES-1008).  All routers, a TC Hub
  20840. |with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch.
  20841. |
  20842. |What we found was that the TChub started failing to resolve DNS on a first
  20843. |attempt (it was actually timing out), the second attempt always worked.
  20844. |Alot of sites for our users stopped working (specifically allot of
  20845. |shockwave/flash sites).  Mac users consistently got Socket broken messages.
  20846. |All other machines on the switch were performing exceptionally well, the TC
  20847. |unit just kinda died.  If we move it all back to a plain 10Mps non-switching
  20848. |hub everything is beautiful again.
  20849. |
  20850. |I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20851. |normal. It's definitely not what I was expecting.  Anyone have similar
  20852. |setups with switches?
  20853. |
  20854. |Thanks
  20855. |Robb Bryn
  20856. |
  20857. |
  20858. |-
  20859. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20860. | with "unsubscribe usr-tc" in the body of the message.
  20861. | For information on digests or retrieving files and old messages send
  20862. | "help" to the same address.  Do not use quotes in your message.
  20863. |
  20864.  
  20865. - Marcelo
  20866.  
  20867.  
  20868. -
  20869.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20870.  with "unsubscribe usr-tc" in the body of the message.
  20871.  For information on digests or retrieving files and old messages send
  20872.  "help" to the same address.  Do not use quotes in your message.
  20873.  
  20874.  
  20875. -------------------------------------------------------------------------------
  20876.  
  20877. From: Brian <signal@shreve.net>
  20878. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20879. Date: 23 Apr 1999 17:05:19 -0500 (CDT)
  20880.  
  20881. On Fri, 23 Apr 1999, Jamie Orzechowski wrote:
  20882.  
  20883. > same here ... I plugged in a new HARC to a Alteon AceDirectory switch which
  20884. > was set to auto and it didn;t work at all I had to force 100mb/sec ...
  20885.  
  20886. Yes, I have seen the same with the Alteon AD2.  However, the Foundry
  20887. Serveriron and Fastiron products seem to get the autosensing down right
  20888. every time all *all* equipment.
  20889.  
  20890.  
  20891. > 
  20892. > ----- Original Message -----
  20893. > From: Dan Hollis <goemon@sasami.anime.net>
  20894. > To: <usr-tc@lists.xmission.com>
  20895. > Sent: Friday, April 23, 1999 3:38 PM
  20896. > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20897. > 
  20898. > 
  20899. > > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20900. > > > I'll admit, I'm new to 10/100 switching technology and don't know if
  20901. > this is
  20902. > > > normal. It's definitely not what I was expecting.  Anyone have similar
  20903. > > > setups with switches?
  20904. > >
  20905. > > The TC doesnt like certain hubs and switches. For example it completely
  20906. > > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  20907. > > equipment has ever had problems with this hub, just the TC. I dont know
  20908. > > why the TC is so touchy although I suspect its buggy or completly broken
  20909. > > 10/100 autodetect.
  20910. > >
  20911. > > -Dan
  20912. > >
  20913. > >
  20914. > > -
  20915. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20916. > >  with "unsubscribe usr-tc" in the body of the message.
  20917. > >  For information on digests or retrieving files and old messages send
  20918. > >  "help" to the same address.  Do not use quotes in your message.
  20919. > >
  20920. > >
  20921. > 
  20922. > 
  20923. > -
  20924. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20925. >  with "unsubscribe usr-tc" in the body of the message.
  20926. >  For information on digests or retrieving files and old messages send
  20927. >  "help" to the same address.  Do not use quotes in your message.
  20928. > 
  20929.  
  20930. Brian Feeny (BF304)     signal@shreve.net   
  20931. 318-222-2638 x 109    http://www.shreve.net/~signal      
  20932. Network Administrator   ShreveNet Inc. (ASN 11881)           
  20933.  
  20934.  
  20935. -
  20936.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20937.  with "unsubscribe usr-tc" in the body of the message.
  20938.  For information on digests or retrieving files and old messages send
  20939.  "help" to the same address.  Do not use quotes in your message.
  20940.  
  20941.  
  20942. -------------------------------------------------------------------------------
  20943.  
  20944. From: Brian <signal@shreve.net>
  20945. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  20946. Date: 23 Apr 1999 17:06:22 -0500 (CDT)
  20947.  
  20948. On Fri, 23 Apr 1999, Marcelo Souza wrote:
  20949.  
  20950. > 
  20951. >     Try to find if the TC is trying to use a full duplex on a swtich
  20952. > that doesn't support or is configured to half-duplex.
  20953.  
  20954. It would be great if you could get the duplex status of the tc hub from
  20955. the CLI..........and force it from the CLI, that would be good too.  I
  20956. hate having to rely 100% on auto-sensing.
  20957.  
  20958.  
  20959. >     If your swtich have a monitor software you could be able to see
  20960. > what kind of error the port is showing.
  20961. >     Here we have no problems with BayStack 350T.
  20962. > 
  20963. > - Marcelo 
  20964. > 
  20965. > On Fri, 23 Apr 1999, Robb Bryn wrote:
  20966. > 
  20967. > |We recently tried to upgrade all of our Internet related equipment to 100Mps
  20968. > |and experienced severe performance degradation for our dialup users.  The
  20969. > |basic scenario is that we were saturating our 10Mpbs network with extraneous
  20970. > |net traffic so we decided to put all Internet related equip on an unmanaged
  20971. > |10/100 Fast Ethernet Switch (the Dlink DES-1008).  All routers, a TC Hub
  20972. > |with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch.
  20973. > |
  20974. > |What we found was that the TChub started failing to resolve DNS on a first
  20975. > |attempt (it was actually timing out), the second attempt always worked.
  20976. > |Alot of sites for our users stopped working (specifically allot of
  20977. > |shockwave/flash sites).  Mac users consistently got Socket broken messages.
  20978. > |All other machines on the switch were performing exceptionally well, the TC
  20979. > |unit just kinda died.  If we move it all back to a plain 10Mps non-switching
  20980. > |hub everything is beautiful again.
  20981. > |
  20982. > |I'll admit, I'm new to 10/100 switching technology and don't know if this is
  20983. > |normal. It's definitely not what I was expecting.  Anyone have similar
  20984. > |setups with switches?
  20985. > |
  20986. > |Thanks
  20987. > |Robb Bryn
  20988. > |
  20989. > |
  20990. > |-
  20991. > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20992. > | with "unsubscribe usr-tc" in the body of the message.
  20993. > | For information on digests or retrieving files and old messages send
  20994. > | "help" to the same address.  Do not use quotes in your message.
  20995. > |
  20996. > 
  20997. > - Marcelo
  20998. > 
  20999. > 
  21000. > -
  21001. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21002. >  with "unsubscribe usr-tc" in the body of the message.
  21003. >  For information on digests or retrieving files and old messages send
  21004. >  "help" to the same address.  Do not use quotes in your message.
  21005. > 
  21006.  
  21007. Brian Feeny (BF304)     signal@shreve.net   
  21008. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21009. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21010.  
  21011.  
  21012. -
  21013.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21014.  with "unsubscribe usr-tc" in the body of the message.
  21015.  For information on digests or retrieving files and old messages send
  21016.  "help" to the same address.  Do not use quotes in your message.
  21017.  
  21018.  
  21019. -------------------------------------------------------------------------------
  21020.  
  21021. From: Stephen Amadei <amadei@dandy.net>
  21022. Subject: (usr-tc) Wisecoms anyone?
  21023. Date: 23 Apr 1999 17:16:18 -0400 (EDT)
  21024.  
  21025.  
  21026. Hello, 
  21027.  
  21028. I have a fairly big client who needs some modems to connect to our 
  21029. USR TC's (latest code, HiPer ARCs, half Quads/half DSPs).  They have had
  21030. intermittent connection problems, resulting in a lot of error 650 (the
  21031. computer you have dialed is not answering)... but they claimed to have
  21032. pulled off some 44Kb/s connections, too.  Anyone know of a 'magic' string
  21033. that will help out a Wisecom WS5614ES3 External modem?  Thanx in
  21034. advance...
  21035.  
  21036. BTW, my TCView script is now updated to 0.93 with some minor fixes and
  21037. some new features thanks to help by Dale Hege. 
  21038. http://www.dandy.net/~amadei
  21039.  
  21040.                     ----Steve
  21041. Stephen Amadei
  21042. Director of MIS
  21043. Dandy Connections, Inc.
  21044. Atlantic City, NJ
  21045.  
  21046.  
  21047. -
  21048.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21049.  with "unsubscribe usr-tc" in the body of the message.
  21050.  For information on digests or retrieving files and old messages send
  21051.  "help" to the same address.  Do not use quotes in your message.
  21052.  
  21053.  
  21054. -------------------------------------------------------------------------------
  21055.  
  21056. From: Marcelo Souza <mpsouza@centroin.com.br>
  21057. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  21058. Date: 23 Apr 1999 20:24:48 -0300 (EST)
  21059.  
  21060. On Fri, 23 Apr 1999, Brian wrote:
  21061.  
  21062. |>     Try to find if the TC is trying to use a full duplex on a swtich
  21063. |> that doesn't support or is configured to half-duplex.
  21064. |
  21065. |It would be great if you could get the duplex status of the tc hub from
  21066. |the CLI..........and force it from the CLI, that would be good too.  I
  21067. |hate having to rely 100% on auto-sensing.
  21068.  
  21069.     Yes. But I can force the switch port to change, monitor the
  21070. statistics on the console and chosse the best option.
  21071.  
  21072. - Marcelo
  21073.  
  21074.  
  21075. |>     If your swtich have a monitor software you could be able to see
  21076. |> what kind of error the port is showing.
  21077. |>     Here we have no problems with BayStack 350T.
  21078. |> 
  21079. |> - Marcelo 
  21080. |> 
  21081. |> On Fri, 23 Apr 1999, Robb Bryn wrote:
  21082. |> 
  21083. |> |We recently tried to upgrade all of our Internet related equipment to 100Mps
  21084. |> |and experienced severe performance degradation for our dialup users.  The
  21085. |> |basic scenario is that we were saturating our 10Mpbs network with extraneous
  21086. |> |net traffic so we decided to put all Internet related equip on an unmanaged
  21087. |> |10/100 Fast Ethernet Switch (the Dlink DES-1008).  All routers, a TC Hub
  21088. |> |with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch.
  21089. |> |
  21090. |> |What we found was that the TChub started failing to resolve DNS on a first
  21091. |> |attempt (it was actually timing out), the second attempt always worked.
  21092. |> |Alot of sites for our users stopped working (specifically allot of
  21093. |> |shockwave/flash sites).  Mac users consistently got Socket broken messages.
  21094. |> |All other machines on the switch were performing exceptionally well, the TC
  21095. |> |unit just kinda died.  If we move it all back to a plain 10Mps non-switching
  21096. |> |hub everything is beautiful again.
  21097. |> |
  21098. |> |I'll admit, I'm new to 10/100 switching technology and don't know if this is
  21099. |> |normal. It's definitely not what I was expecting.  Anyone have similar
  21100. |> |setups with switches?
  21101. |> |
  21102. |> |Thanks
  21103. |> |Robb Bryn
  21104. |> |
  21105. |> |
  21106. |> |-
  21107. |> | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21108. |> | with "unsubscribe usr-tc" in the body of the message.
  21109. |> | For information on digests or retrieving files and old messages send
  21110. |> | "help" to the same address.  Do not use quotes in your message.
  21111. |> |
  21112. |> 
  21113. |> - Marcelo
  21114. |> 
  21115. |> 
  21116. |> -
  21117. |>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21118. |>  with "unsubscribe usr-tc" in the body of the message.
  21119. |>  For information on digests or retrieving files and old messages send
  21120. |>  "help" to the same address.  Do not use quotes in your message.
  21121. |> 
  21122. |
  21123. |-----------------------------------------------------
  21124. |Brian Feeny (BF304)     signal@shreve.net   
  21125. |318-222-2638 x 109    http://www.shreve.net/~signal      
  21126. |Network Administrator   ShreveNet Inc. (ASN 11881)           
  21127. |
  21128. |
  21129. |-
  21130. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21131. | with "unsubscribe usr-tc" in the body of the message.
  21132. | For information on digests or retrieving files and old messages send
  21133. | "help" to the same address.  Do not use quotes in your message.
  21134. |
  21135.  
  21136. - Marcelo
  21137.  
  21138.  
  21139. -
  21140.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21141.  with "unsubscribe usr-tc" in the body of the message.
  21142.  For information on digests or retrieving files and old messages send
  21143.  "help" to the same address.  Do not use quotes in your message.
  21144.  
  21145.  
  21146. -------------------------------------------------------------------------------
  21147.  
  21148. From: <dns-admin@netsol.net>
  21149. Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
  21150. Date: 23 Apr 1999 18:40:51 -0700
  21151.  
  21152. Had it for 6 month, first one worked one weeks then died. After we had it
  21153. replaced, the newer unit is  working since.
  21154.  
  21155. Liping Chen
  21156.  
  21157. > -----Original Message-----
  21158. > From: owner-usr-tc@lists.xmission.com
  21159. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews
  21160. > Sent: Friday, April 23, 1999 1:14 PM
  21161. > To: usr-tc@lists.xmission.com
  21162. > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  21163. >
  21164. >
  21165. > On Fri, 23 Apr 1999, Dan Hollis wrote:
  21166. >
  21167. > > On Fri, 23 Apr 1999, Robb Bryn wrote:
  21168. > > > I'll admit, I'm new to 10/100 switching technology and
  21169. > don't know if this is
  21170. > > > normal. It's definitely not what I was expecting.  Anyone
  21171. > have similar
  21172. > > > setups with switches?
  21173. > >
  21174. > > The TC doesnt like certain hubs and switches. For example
  21175. > it completely
  21176. > > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  21177. > > equipment has ever had problems with this hub, just the TC.
  21178. > I dont know
  21179. > > why the TC is so touchy although I suspect its buggy or
  21180. > completly broken
  21181. > > 10/100 autodetect.
  21182. >
  21183. > How about a Cisco Catalyst 2924?  We were thinking of getting one...
  21184. > anyone?
  21185. >
  21186. >
  21187. > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital
  21188. > Crescent, Frankfort KY
  21189. > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A
  21190. > computer without a
  21191. > Microsoft operating system is like a dog without a brick tied
  21192. > to its head."
  21193. >
  21194. >
  21195. > -
  21196. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21197. >  with "unsubscribe usr-tc" in the body of the message.
  21198. >  For information on digests or retrieving files and old messages send
  21199. >  "help" to the same address.  Do not use quotes in your message.
  21200. >
  21201.  
  21202.  
  21203. -
  21204.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21205.  with "unsubscribe usr-tc" in the body of the message.
  21206.  For information on digests or retrieving files and old messages send
  21207.  "help" to the same address.  Do not use quotes in your message.
  21208.  
  21209.  
  21210. -------------------------------------------------------------------------------
  21211.  
  21212. From: jeff.binkley@asacomp.com (Jeff Binkley)
  21213. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch..
  21214. Date: 23 Apr 1999 23:18:00 -0500
  21215.  
  21216. -> On Fri, 23 Apr 1999, Robb Bryn wrote:
  21217. -> > I'll admit, I'm new to 10/100 switching technology and don't know if this
  21218. -> is > normal. It's definitely not what I was expecting.  Anyone have similar
  21219. -> > setups with switches?
  21220. ->
  21221. -> The TC doesnt like certain hubs and switches. For example it completely
  21222. -> brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other equipment
  21223. -> has ever had problems with this hub, just the TC. I dont know why the TC is
  21224. -> so touchy although I suspect its buggy or completly broken 10/100
  21225. -> autodetect.
  21226.  
  21227. We have one on a Bay Networks 28K (yes, I realize old technology) switch but it
  21228. works great.  No performance problems whatsoever.  HiperArc and NMC.
  21229.  
  21230. Jeff binkley
  21231. ASA Network Computing
  21232.  
  21233. -
  21234.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21235.  with "unsubscribe usr-tc" in the body of the message.
  21236.  For information on digests or retrieving files and old messages send
  21237.  "help" to the same address.  Do not use quotes in your message.
  21238.  
  21239.  
  21240. -------------------------------------------------------------------------------
  21241.  
  21242. From: jeff.binkley@asacomp.com (Jeff Binkley)
  21243. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch..
  21244. Date: 23 Apr 1999 23:20:00 -0500
  21245.  
  21246. -> same here ... I plugged in a new HARC to a Alteon AceDirectory switch which
  21247. -> was set to auto and it didn;t work at all I had to force 100mb/sec ...
  21248.  
  21249. Have HiperArc and Netservers connected to Bay Networks 28000 switches and
  21250. works in auto, 10k and 100k modes just fine.
  21251.  
  21252.  
  21253. Jeff binkley
  21254. ASA Network Computing
  21255.  
  21256. -
  21257.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21258.  with "unsubscribe usr-tc" in the body of the message.
  21259.  For information on digests or retrieving files and old messages send
  21260.  "help" to the same address.  Do not use quotes in your message.
  21261.  
  21262.  
  21263. -------------------------------------------------------------------------------
  21264.  
  21265. From: ISPCnsl001@aol.com
  21266. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  21267. Date: 24 Apr 1999 00:58:27 EDT
  21268.  
  21269. In a message dated 4/23/99 2:51:11 PM US Eastern Standard Time, 
  21270. mhz@ripnet.com writes:
  21271.  
  21272. > same here ... I plugged in a new HARC to a Alteon AceDirectory switch which
  21273. >  was set to auto and it didn;t work at all I had to force 100mb/sec ...
  21274.  
  21275. I saw the same problem on an anritsu 10/100/1000 switch.  Forcing 100 fixed 
  21276. it.  
  21277.  
  21278. -
  21279.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21280.  with "unsubscribe usr-tc" in the body of the message.
  21281.  For information on digests or retrieving files and old messages send
  21282.  "help" to the same address.  Do not use quotes in your message.
  21283.  
  21284.  
  21285. -------------------------------------------------------------------------------
  21286.  
  21287. From: K Mitchell <mitch@keyconn.net>
  21288. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  21289. Date: 24 Apr 1999 11:06:12 -0400
  21290.  
  21291. At 03:50 PM 4/23/99 -0400, you wrote:
  21292. >> The TC doesnt like certain hubs and switches. For example it completely
  21293. >> brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  21294. >> equipment has ever had problems with this hub, just the TC. I dont know
  21295. >> why the TC is so touchy although I suspect its buggy or completly broken
  21296. >> 10/100 autodetect.
  21297.  
  21298. Plugged my HiPer into a NetGear FS308 a couple of weeks ago and it's been
  21299. humming along nicely. Auto-detect picks up 100mbs from the ARC and 10mbs
  21300. from NMC.
  21301.  
  21302.  
  21303. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  21304. Keystone Connect                http://www.keyconn.net
  21305. Altoona, PA   814-941-5000         We Unlock the World
  21306.  
  21307.  
  21308. -
  21309.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21310.  with "unsubscribe usr-tc" in the body of the message.
  21311.  For information on digests or retrieving files and old messages send
  21312.  "help" to the same address.  Do not use quotes in your message.
  21313.  
  21314.  
  21315. -------------------------------------------------------------------------------
  21316.  
  21317. From: "Greg Owens" <gowens@magnolia-net.com>
  21318. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  21319. Date: 24 Apr 1999 10:35:48 -0500
  21320.  
  21321. We are about to install a CeLAN brand, model DuFastHUB-16As next
  21322. week....anyone using one of these successfully?
  21323. -----Original Message-----
  21324.  
  21325.  
  21326. >On Fri, 23 Apr 1999, Robb Bryn wrote:
  21327. >> I'll admit, I'm new to 10/100 switching technology and don't know if this
  21328. is
  21329. >> normal. It's definitely not what I was expecting.  Anyone have similar
  21330. >> setups with switches?
  21331. >
  21332. >The TC doesnt like certain hubs and switches. For example it completely
  21333. >brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  21334. >equipment has ever had problems with this hub, just the TC. I dont know
  21335. >why the TC is so touchy although I suspect its buggy or completly broken
  21336. >10/100 autodetect.
  21337. >
  21338. >-Dan
  21339. >
  21340. >
  21341. >-
  21342. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21343. > with "unsubscribe usr-tc" in the body of the message.
  21344. > For information on digests or retrieving files and old messages send
  21345. > "help" to the same address.  Do not use quotes in your message.
  21346. >
  21347.  
  21348.  
  21349. -
  21350.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21351.  with "unsubscribe usr-tc" in the body of the message.
  21352.  For information on digests or retrieving files and old messages send
  21353.  "help" to the same address.  Do not use quotes in your message.
  21354.  
  21355.  
  21356. -------------------------------------------------------------------------------
  21357.  
  21358. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  21359. Subject: Re: (usr-tc) Wisecoms anyone?
  21360. Date: 24 Apr 1999 12:07:05 -0500 (CDT)
  21361.  
  21362. On Fri, 23 Apr 1999, Stephen Amadei wrote:
  21363.  
  21364. > 
  21365. > Hello, 
  21366. > 
  21367. > I have a fairly big client who needs some modems to connect to our 
  21368. > USR TC's (latest code, HiPer ARCs, half Quads/half DSPs).  They have had
  21369. > intermittent connection problems, resulting in a lot of error 650 (the
  21370. > computer you have dialed is not answering)... but they claimed to have
  21371. > pulled off some 44Kb/s connections, too.  Anyone know of a 'magic' string
  21372. > that will help out a Wisecom WS5614ES3 External modem?  Thanx in
  21373.  
  21374. Never heard about these modems - Is this rockwell chipset or Lucent?
  21375. A lot depends upon whoes chipset the customer is using - Based on this 
  21376. info you also need to find out or get traces when the error occurs. 
  21377. Syslog, tap if possible would help a lot.
  21378.  
  21379. Also I suggest you open a ticket with support so that a tech can 
  21380. investigate and identify the problems.
  21381.  
  21382. regards
  21383.  
  21384. krish
  21385.  
  21386. > advance...
  21387. > 
  21388. > BTW, my TCView script is now updated to 0.93 with some minor fixes and
  21389. > some new features thanks to help by Dale Hege. 
  21390. > http://www.dandy.net/~amadei
  21391. > 
  21392. >                     ----Steve
  21393. > Stephen Amadei
  21394. > Director of MIS
  21395. > Dandy Connections, Inc.
  21396. > Atlantic City, NJ
  21397. > 
  21398. > 
  21399. > -
  21400. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21401. >  with "unsubscribe usr-tc" in the body of the message.
  21402. >  For information on digests or retrieving files and old messages send
  21403. >  "help" to the same address.  Do not use quotes in your message.
  21404. > 
  21405.  
  21406. -
  21407.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21408.  with "unsubscribe usr-tc" in the body of the message.
  21409.  For information on digests or retrieving files and old messages send
  21410.  "help" to the same address.  Do not use quotes in your message.
  21411.  
  21412.  
  21413. -------------------------------------------------------------------------------
  21414.  
  21415. From: Stephen Amadei <amadei@dandy.net>
  21416. Subject: Re: (usr-tc) Wisecoms anyone?
  21417. Date: 24 Apr 1999 16:46:15 -0400 (EDT)
  21418.  
  21419. On Sat, 24 Apr 1999, Tatai SV Krishnan wrote:
  21420.  
  21421. > Never heard about these modems - Is this rockwell chipset or Lucent?
  21422. > A lot depends upon whoes chipset the customer is using - Based on this 
  21423. > info you also need to find out or get traces when the error occurs. 
  21424. > Syslog, tap if possible would help a lot.
  21425.  
  21426. Well, this is part of my problem... I couldn't find anywhere on the
  21427. Wisecom webpages which describes the chipset... and my customer doesn't 
  21428. know either.
  21429.  
  21430.                     ----Steve
  21431. Stephen Amadei
  21432. Director of MIS
  21433. Dandy Connections, Inc.
  21434. Atlantic City, NJ
  21435.  
  21436.  
  21437. -
  21438.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21439.  with "unsubscribe usr-tc" in the body of the message.
  21440.  For information on digests or retrieving files and old messages send
  21441.  "help" to the same address.  Do not use quotes in your message.
  21442.  
  21443.  
  21444. -------------------------------------------------------------------------------
  21445.  
  21446. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  21447. Subject: Re: (usr-tc) Wisecoms anyone?
  21448. Date: 24 Apr 1999 17:14:52 -0500 (CDT)
  21449.  
  21450. On Sat, 24 Apr 1999, Stephen Amadei wrote:
  21451.  
  21452. > On Sat, 24 Apr 1999, Tatai SV Krishnan wrote:
  21453. > 
  21454. > > Never heard about these modems - Is this rockwell chipset or Lucent?
  21455. > > A lot depends upon whoes chipset the customer is using - Based on this 
  21456. > > info you also need to find out or get traces when the error occurs. 
  21457. > > Syslog, tap if possible would help a lot.
  21458. > 
  21459. > Well, this is part of my problem... I couldn't find anywhere on the
  21460. > Wisecom webpages which describes the chipset... and my customer doesn't 
  21461. > know either.
  21462.  
  21463. If the modem responds to the at commands - then all you need is to send a 
  21464. ati3
  21465. Based on that response we can say whether its lucent or rockwell.
  21466.  
  21467. krish
  21468.  
  21469. > 
  21470. >                     ----Steve
  21471. > Stephen Amadei
  21472. > Director of MIS
  21473. > Dandy Connections, Inc.
  21474. > Atlantic City, NJ
  21475. > 
  21476. > 
  21477. > -
  21478. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21479. >  with "unsubscribe usr-tc" in the body of the message.
  21480. >  For information on digests or retrieving files and old messages send
  21481. >  "help" to the same address.  Do not use quotes in your message.
  21482. > 
  21483.  
  21484. -
  21485.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21486.  with "unsubscribe usr-tc" in the body of the message.
  21487.  For information on digests or retrieving files and old messages send
  21488.  "help" to the same address.  Do not use quotes in your message.
  21489.  
  21490.  
  21491. -------------------------------------------------------------------------------
  21492.  
  21493. From: "G. Douglas Davidson" <douglas@city-net.com>
  21494. Subject: (usr-tc) PPP session start message problem
  21495. Date: 24 Apr 1999 22:12:07 -0400
  21496.  
  21497.  
  21498. --PART-BOUNDARY=.19904242212.ZM167051.city-net.com
  21499. Content-Description: Text
  21500. Content-Type: text/plain ; charset=iso-8859-1
  21501. X-Zm-Decoding-Hint: mimencode -q -u 
  21502. Content-Transfer-Encoding: quoted-printable
  21503.  
  21504. Hello,
  21505.  
  21506. I am having a heck of a time getting my HyperArc version 4.1.59_6 to outp=
  21507. ut the
  21508. PPP startup message.  I can see it set apparently correctly when I do a "=
  21509. show
  21510. ppp".  I am switching up form an older Netserver.  This message used to b=
  21511. e
  21512. produced by the "pppmsg" switch on that box.
  21513.  
  21514. Under Netserver I get:
  21515.  
  21516. PPP session from (209.176.114.196) to 206.102.159.78 beginning....~#=C0!}=
  21517. !}!} }
  21518.  
  21519. Under HyperArc I get:
  21520.  
  21521. ~#=C0!}!}!} }?}!}$}%=DC}"}&=FF=FF}%}&a=FA=C2u}'}"}(}"}1}$}%=DC}3}#} =D4=AB=
  21522. ~~#=C0!}!}"} }?
  21523.  
  21524. Persons with older scripting logins are having problems with this.  This =
  21525. only
  21526. occurs when the user selects the PPP option from within a Radius menu.  A=
  21527. uto
  21528. detection of PPP works fine.
  21529.  
  21530. Any help would be appreciated.
  21531.  
  21532. -- =
  21533.  
  21534. -----
  21535. G Douglas Davidson                      | CityNet, Inc.
  21536. douglas@city-net.com                    | Pittsburgh, PA
  21537. voice: 412.481.5406            | fax: 412.431.1315
  21538.  
  21539. --PART-BOUNDARY=.19904242212.ZM167051.city-net.com--
  21540.  
  21541.  
  21542. -
  21543.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21544.  with "unsubscribe usr-tc" in the body of the message.
  21545.  For information on digests or retrieving files and old messages send
  21546.  "help" to the same address.  Do not use quotes in your message.
  21547.  
  21548.  
  21549. -------------------------------------------------------------------------------
  21550.  
  21551. From: "G. Douglas Davidson" <douglas@city-net.com>
  21552. Subject: Re: (usr-tc) PPP session start message problem
  21553. Date: 25 Apr 1999 11:46:19 -0400
  21554.  
  21555.  
  21556. --PART-BOUNDARY=.19904251146.ZM234395.city-net.com
  21557. Content-Description: Text
  21558. Content-Type: text/plain ; charset=iso-8859-1
  21559. X-Zm-Decoding-Hint: mimencode -q -u 
  21560. Content-Transfer-Encoding: quoted-printable
  21561.  
  21562. On Apr 24, 10:12pm, G. Douglas Davidson wrote:
  21563. > Subject: (usr-tc) PPP session start message problem
  21564. >
  21565. > [ Text
  21566. >   Encoded with "quoted-printable" ] :
  21567. >
  21568. > Hello,
  21569. >
  21570. > I am having a heck of a time getting my HyperArc version 4.1.59_6 to ou=
  21571. tput
  21572. the
  21573. > PPP startup message.  I can see it set apparently correctly when I do a=
  21574.  "show
  21575. > ppp".  I am switching up form an older Netserver.  This message used to=
  21576.  be
  21577. > produced by the "pppmsg" switch on that box.
  21578. >
  21579. > Under Netserver I get:
  21580. >
  21581. > PPP session from (209.176.114.196) to 206.102.159.78 beginning....~#=C0=
  21582. !}!}!} }
  21583. >
  21584. > Under HyperArc I get:
  21585. >
  21586. > ~#=C0!}!}!} }?}!}$}%=DC}"}&=FF=FF}%}&a=FA=C2u}'}"}(}"}1}$}%=DC}3}#} =D4=
  21587. =AB~~#=C0!}!}"} }?
  21588. >
  21589. > Persons with older scripting logins are having problems with this.  Thi=
  21590. s only
  21591. > occurs when the user selects the PPP option from within a Radius menu. =
  21592.  Auto
  21593. > detection of PPP works fine.
  21594. >
  21595. > Any help would be appreciated.
  21596.  
  21597.  
  21598. enable authentication hint_assigned
  21599.  
  21600. Argh.
  21601.  
  21602. -- =
  21603.  
  21604. -----
  21605. G Douglas Davidson                      | CityNet, Inc.
  21606. douglas@city-net.com                    | Pittsburgh, PA
  21607. voice: 412.481.5406            | fax: 412.431.1315
  21608.  
  21609. --PART-BOUNDARY=.19904251146.ZM234395.city-net.com--
  21610.  
  21611.  
  21612. -
  21613.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21614.  with "unsubscribe usr-tc" in the body of the message.
  21615.  For information on digests or retrieving files and old messages send
  21616.  "help" to the same address.  Do not use quotes in your message.
  21617.  
  21618.  
  21619. -------------------------------------------------------------------------------
  21620.  
  21621. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  21622. Subject: Re: (usr-tc) PPP session start message problem
  21623. Date: 25 Apr 1999 13:23:38 -0500 (CDT)
  21624.  
  21625. On Sat, 24 Apr 1999, G. Douglas Davidson wrote:
  21626.  
  21627. > Hello,
  21628. > 
  21629. > I am having a heck of a time getting my HyperArc version 4.1.59_6 to outp=
  21630. > ut the
  21631. > PPP startup message.  I can see it set apparently correctly when I do a "=
  21632. > show
  21633. > ppp".  I am switching up form an older Netserver.  This message used to b=
  21634. > e
  21635. > produced by the "pppmsg" switch on that box.
  21636.  
  21637. To do this - you have to do the following
  21638.  
  21639. 1. Make sure that you have a IP pool, and that its a public ip pool.
  21640. 2. enable authe hint -on the hiper arc
  21641.  
  21642.  
  21643. Thats the would set up the message and when you dial you will see the 
  21644. message appear.
  21645.  
  21646. krish
  21647.  
  21648. > 
  21649. > Under Netserver I get:
  21650. > 
  21651. > PPP session from (209.176.114.196) to 206.102.159.78 beginning....~#=C0!}=
  21652. > !}!} }
  21653. > 
  21654. > Under HyperArc I get:
  21655. > 
  21656. > ~#=C0!}!}!} }?}!}$}%=DC}"}&=FF=FF}%}&a=FA=C2u}'}"}(}"}1}$}%=DC}3}#} =D4=AB=
  21657. > ~~#=C0!}!}"} }?
  21658. > 
  21659. > Persons with older scripting logins are having problems with this.  This =
  21660. > only
  21661. > occurs when the user selects the PPP option from within a Radius menu.  A=
  21662. > uto
  21663. > detection of PPP works fine.
  21664. > 
  21665. > Any help would be appreciated.
  21666. > 
  21667. > -- =
  21668. > 
  21669. > -----
  21670. > G Douglas Davidson                      | CityNet, Inc.
  21671. > douglas@city-net.com                    | Pittsburgh, PA
  21672. > voice: 412.481.5406            | fax: 412.431.1315
  21673. > 
  21674.  
  21675. -
  21676.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21677.  with "unsubscribe usr-tc" in the body of the message.
  21678.  For information on digests or retrieving files and old messages send
  21679.  "help" to the same address.  Do not use quotes in your message.
  21680.  
  21681.  
  21682. -------------------------------------------------------------------------------
  21683.  
  21684. From: "Jamie Orzechowski" <mhz@ripnet.com>
  21685. Subject: (usr-tc) Short or long haul??
  21686. Date: 26 Apr 1999 09:41:29 -0400
  21687.  
  21688. This is a multi-part message in MIME format.
  21689.  
  21690. ------=_NextPart_000_002C_01BE8FC8.F61428A0
  21691. Content-Type: text/plain;
  21692.     charset="iso-8859-1"
  21693. Content-Transfer-Encoding: quoted-printable
  21694.  
  21695. We are using PRI's and I was wondering which I should use?? Short or =
  21696. long haul and what DB should it be set to??  right now it's on DB26 and =
  21697. long haul ... are there any performance issues?
  21698.  
  21699. ------=_NextPart_000_002C_01BE8FC8.F61428A0
  21700. Content-Type: text/html;
  21701.     charset="iso-8859-1"
  21702. Content-Transfer-Encoding: quoted-printable
  21703.  
  21704. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  21705. <HTML><HEAD>
  21706. <META content=3D"text/html; charset=3Diso-8859-1" =
  21707. http-equiv=3DContent-Type>
  21708. <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
  21709. <STYLE></STYLE>
  21710. </HEAD>
  21711. <BODY bgColor=3D#ffffff>
  21712. <DIV><FONT size=3D2>We are using PRI's and I was wondering which I =
  21713. should use??=20
  21714. Short or long haul and what DB should it be set to??  right now =
  21715. it's on=20
  21716. DB26 and long haul ... are there any performance=20
  21717. issues?</FONT></DIV></BODY></HTML>
  21718.  
  21719. ------=_NextPart_000_002C_01BE8FC8.F61428A0--
  21720.  
  21721.  
  21722. -
  21723.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21724.  with "unsubscribe usr-tc" in the body of the message.
  21725.  For information on digests or retrieving files and old messages send
  21726.  "help" to the same address.  Do not use quotes in your message.
  21727.  
  21728.  
  21729. -------------------------------------------------------------------------------
  21730.  
  21731. From: Mike Andrews <mandrews@termfrost.org>
  21732. Subject: (usr-tc) cistron radius and VSA's
  21733. Date: 26 Apr 1999 11:10:12 -0400 (EDT)
  21734.  
  21735. I'm experimenting with the idea of switching to Cistron radius (beta16,
  21736. the latest), and I'm having problems with it not logging 3com VSA's
  21737. correctly.
  21738.  
  21739. I'm getting tons of "unknown attribute xxxx received" every time it gets
  21740. an accounting packet.
  21741.  
  21742. By throwing some debugging code in to see how it's parsing the dictionary
  21743. files, it appears to be putting the USR attributes in memory with 0x20000
  21744. appended to their values... for example:
  21745.  
  21746. ATTRIB_NMC      USR-Event-Id                            0xBFBE  integer
  21747.  
  21748. gets stored in memory as attribute "0x2bfbe".  But in the "unknown
  21749. attribute" message, the number there is 0x3bfbe instead.  So it's reading
  21750. the dictionary OK, and it's parsing the packet OK, but it's getting the
  21751. "vendor number" wrong by 1.  I'm not sure if this is a parser bug or a
  21752. dictionary problem or something else.
  21753.  
  21754.  
  21755.  
  21756. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  21757. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  21758. Microsoft operating system is like a dog without a brick tied to its head."
  21759.  
  21760.  
  21761. -
  21762.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21763.  with "unsubscribe usr-tc" in the body of the message.
  21764.  For information on digests or retrieving files and old messages send
  21765.  "help" to the same address.  Do not use quotes in your message.
  21766.  
  21767.  
  21768. -------------------------------------------------------------------------------
  21769.  
  21770. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  21771. Subject: Re: (usr-tc) cistron radius and VSA's
  21772. Date: 26 Apr 1999 10:40:48 -0500 (CDT)
  21773.  
  21774. On Mon, 26 Apr 1999, Mike Andrews wrote:
  21775.  
  21776. > I'm experimenting with the idea of switching to Cistron radius (beta16,
  21777. > the latest), and I'm having problems with it not logging 3com VSA's
  21778. > correctly.
  21779. > 
  21780. > I'm getting tons of "unknown attribute xxxx received" every time it gets
  21781. > an accounting packet.
  21782.  
  21783. If you get a trace of the packet - either using tcpdump or snoop - we can 
  21784. see what exactly the hiper arc sends.  If the hiper arc sends the packet 
  21785. correctly then should debug the Radius server.
  21786.  
  21787. krish
  21788.  
  21789. > 
  21790. > By throwing some debugging code in to see how it's parsing the dictionary
  21791. > files, it appears to be putting the USR attributes in memory with 0x20000
  21792. > appended to their values... for example:
  21793. > 
  21794. > ATTRIB_NMC      USR-Event-Id                            0xBFBE  integer
  21795. > 
  21796. > gets stored in memory as attribute "0x2bfbe".  But in the "unknown
  21797. > attribute" message, the number there is 0x3bfbe instead.  So it's reading
  21798. > the dictionary OK, and it's parsing the packet OK, but it's getting the
  21799. > "vendor number" wrong by 1.  I'm not sure if this is a parser bug or a
  21800. > dictionary problem or something else.
  21801. > 
  21802. > 
  21803. > 
  21804. > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  21805. > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  21806. > Microsoft operating system is like a dog without a brick tied to its head."
  21807. > 
  21808. > 
  21809. > -
  21810. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21811. >  with "unsubscribe usr-tc" in the body of the message.
  21812. >  For information on digests or retrieving files and old messages send
  21813. >  "help" to the same address.  Do not use quotes in your message.
  21814. > 
  21815.  
  21816. -
  21817.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21818.  with "unsubscribe usr-tc" in the body of the message.
  21819.  For information on digests or retrieving files and old messages send
  21820.  "help" to the same address.  Do not use quotes in your message.
  21821.  
  21822.  
  21823. -------------------------------------------------------------------------------
  21824.  
  21825. From: Greg Coffey <greg@coffey.com>
  21826. Subject: (usr-tc) Quad v.32 terbo Upgrade
  21827. Date: 26 Apr 1999 10:13:09 -0600
  21828.  
  21829. Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90?  I
  21830. have five of them and they appear to be double sided.  What software would
  21831. I need?
  21832.  
  21833. Thanks,
  21834. Greg Coffey, CoffeyNet    Voice 307-234-5443   307-234-5446 Fax
  21835. ====================================================================
  21836. 142 S. Center St.          3Com v.90 56k $20 in Casper & Douglas
  21837. Casper, WY  82601       Local Internet for Casper, Rawlins, Douglas,
  21838. http://WWW.COFFEY.COM      Wheatland, Pinedale, Lander & Lusk, WY
  21839.  
  21840. -
  21841.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21842.  with "unsubscribe usr-tc" in the body of the message.
  21843.  For information on digests or retrieving files and old messages send
  21844.  "help" to the same address.  Do not use quotes in your message.
  21845.  
  21846.  
  21847. -------------------------------------------------------------------------------
  21848.  
  21849. From: Mike Andrews <mandrews@termfrost.org>
  21850. Subject: Re: (usr-tc) cistron radius and VSA's
  21851. Date: 26 Apr 1999 12:20:21 -0400 (EDT)
  21852.  
  21853. On Mon, 26 Apr 1999, Tatai SV Krishnan wrote:
  21854.  
  21855. > On Mon, 26 Apr 1999, Mike Andrews wrote:
  21856. > 
  21857. > > I'm experimenting with the idea of switching to Cistron radius (beta16,
  21858. > > the latest), and I'm having problems with it not logging 3com VSA's
  21859. > > correctly.
  21860. > > 
  21861. > > I'm getting tons of "unknown attribute xxxx received" every time it gets
  21862. > > an accounting packet.
  21863. > 
  21864. > If you get a trace of the packet - either using tcpdump or snoop - we can 
  21865. > see what exactly the hiper arc sends.  If the hiper arc sends the packet 
  21866. > correctly then should debug the Radius server.
  21867.  
  21868. I already know it's a Radius server problem...  I have a hacked-up
  21869. Livingston Radius already doing the VSA's correctly.  I'm just trying
  21870. to switch from Livingston to Cistron.
  21871.  
  21872.  
  21873. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  21874. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  21875. Microsoft operating system is like a dog without a brick tied to its head."
  21876.  
  21877.  
  21878. -
  21879.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21880.  with "unsubscribe usr-tc" in the body of the message.
  21881.  For information on digests or retrieving files and old messages send
  21882.  "help" to the same address.  Do not use quotes in your message.
  21883.  
  21884.  
  21885. -------------------------------------------------------------------------------
  21886.  
  21887. From: Jeff Mcadams <jeffm@iglou.com>
  21888. Subject: Re: (usr-tc) Quad v.32 terbo Upgrade
  21889. Date: 26 Apr 1999 12:41:26 -0400 (EDT)
  21890.  
  21891. Thus spake Greg Coffey
  21892. >Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90?  
  21893.  
  21894. Yes.
  21895.  
  21896. >I have five of them and they appear to be double sided.  What software
  21897. >would I need?
  21898.  
  21899. Get the latest...5.9.9 I believe for double sided...5.10.9 is the
  21900. other...grab them both and TCM will figure it out for you on its own.
  21901. :)
  21902.  
  21903. And, if they aren't digital capable modems, v.90 isn't going to do much
  21904. good for you...(well...quads can do client side of x2 and v.90 I
  21905. believe).
  21906. -- 
  21907. Jeff McAdams                            Email: jeffm@iglou.com
  21908. Head Network Administrator              Voice: (502) 966-3848
  21909. IgLou Internet Services                        (800) 436-4456
  21910.  
  21911. -
  21912.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21913.  with "unsubscribe usr-tc" in the body of the message.
  21914.  For information on digests or retrieving files and old messages send
  21915.  "help" to the same address.  Do not use quotes in your message.
  21916.  
  21917.  
  21918. -------------------------------------------------------------------------------
  21919.  
  21920. From: David Bolen <db3l@ans.net>
  21921. Subject: Re: (usr-tc) Quad v.32 terbo Upgrade
  21922. Date: 26 Apr 1999 12:50:47 EDT
  21923.  
  21924. Jeff Mcadams <jeffm@iglou.com> writes:
  21925.  
  21926. > Thus spake Greg Coffey
  21927. > >Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90?  
  21928. > 
  21929. > Yes.
  21930.  
  21931. Hmm, I may be wrong, but I don't think that's true.  The quad modem
  21932. hardware changed back in '94 with the introduction of the V.34 cards
  21933. (double sided design originally, single sided later), so the existing
  21934. quad V.34/x2/V.90 code base won't run on the older V.32 quad hardware
  21935. platform.  And since the first code base to come out for the cards
  21936. back then was for V.34, anything that is limited to V.32 only is
  21937. likely to be the older hardware platform, as opposed to a quad card
  21938. that simply hadn't been upgraded enough.
  21939.  
  21940. -- David
  21941.  
  21942. /-----------------------------------------------------------------------\
  21943.  \               David Bolen              \  Internet: db3l@ans.net    /
  21944.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  21945.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  21946. \-----------------------------------------------------------------------/
  21947.  
  21948. -
  21949.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21950.  with "unsubscribe usr-tc" in the body of the message.
  21951.  For information on digests or retrieving files and old messages send
  21952.  "help" to the same address.  Do not use quotes in your message.
  21953.  
  21954.  
  21955. -------------------------------------------------------------------------------
  21956.  
  21957. From: Jeff Mcadams <jeffm@iglou.com>
  21958. Subject: Re: (usr-tc) Quad v.32 terbo Upgrade
  21959. Date: 26 Apr 1999 12:58:46 -0400 (EDT)
  21960.  
  21961. Thus spake David Bolen
  21962. >Jeff Mcadams <jeffm@iglou.com> writes:
  21963. >> Thus spake Greg Coffey
  21964. >> >Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90?  
  21965.  
  21966. >> Yes.
  21967.  
  21968. >Hmm, I may be wrong, but I don't think that's true.  
  21969.  
  21970. Hrmm...perhaps I'm wrong...I could've sworn I had some quads down there
  21971. silk-screened with v.32terbo on them, but going and looking, the only
  21972. ones I can find are the old dual cards (mixture of v.32terbo and v.34
  21973. cards in those).  And, yes, we still have some of the old dual modem
  21974. cards in service....:)....*with* 35 (yes, that's not a typo for 45) amp
  21975. power supplies.  :)  Last time Tom Goodman was down here he asked if he
  21976. could just touch them.  :)
  21977. -- 
  21978. Jeff McAdams                            Email: jeffm@iglou.com
  21979. Head Network Administrator              Voice: (502) 966-3848
  21980. IgLou Internet Services                        (800) 436-4456
  21981.  
  21982. -
  21983.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21984.  with "unsubscribe usr-tc" in the body of the message.
  21985.  For information on digests or retrieving files and old messages send
  21986.  "help" to the same address.  Do not use quotes in your message.
  21987.  
  21988.  
  21989. -------------------------------------------------------------------------------
  21990.  
  21991. From: Brian <signal@shreve.net>
  21992. Subject: Re: (usr-tc) Short or long haul??
  21993. Date: 26 Apr 1999 12:29:20 -0500 (CDT)
  21994.  
  21995. On Mon, 26 Apr 1999, Jamie Orzechowski wrote:
  21996.  
  21997. > We are using PRI's and I was wondering which I should use?? Short or
  21998. > long haul and what DB should it be set to??  right now it's on DB26
  21999. > and long haul ... are there any performance issues?
  22000. > 
  22001.  
  22002.  
  22003. I just select short haul nic, since its alot easier for me to think in
  22004. terms of feet than db :).
  22005.  
  22006. Brian
  22007.  
  22008. Brian Feeny (BF304)     signal@shreve.net   
  22009. 318-222-2638 x 109    http://www.shreve.net/~signal      
  22010. Network Administrator   ShreveNet Inc. (ASN 11881)           
  22011.  
  22012.  
  22013. -
  22014.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22015.  with "unsubscribe usr-tc" in the body of the message.
  22016.  For information on digests or retrieving files and old messages send
  22017.  "help" to the same address.  Do not use quotes in your message.
  22018.  
  22019.  
  22020. -------------------------------------------------------------------------------
  22021.  
  22022. From: "David Cartwright" <David_Cartwright@mw.3com.com>
  22023. Subject: (usr-tc) New 3Com ISP Home Page
  22024. Date: 26 Apr 1999 13:18:59 -0500
  22025.  
  22026. --0__=3vWwQc5HmcamoCbusgT7iIR0fIMcqkk1JF2VjqbxQwhZ871Bftum8o5s
  22027. Content-type: text/plain; charset=us-ascii
  22028. Content-Disposition: inline
  22029.  
  22030.  
  22031.  
  22032.  
  22033.  
  22034. 3Com Carrier CSO recently launched a new technical support web site for
  22035. ISPs!  The site contains a wide range of information and links to other
  22036. useful sites.  Whether you need to locate a V.90 troubleshooting guide,
  22037. a CLI Quick Reference Guide for HiPer ARC, find out if a product is Year
  22038. 2000 compliant, determine which versions of software code are compatible
  22039. or need answers to other technical support and service questions, you
  22040. can find the answer on the ISP Home Page.
  22041.  
  22042. The site also has links to other 3Com web-based services Knowledgebase
  22043. and Case Tracker.  3Com Knowledgebase where you can easily and quickly
  22044. access the self-service database to find solutions to help diagnose and
  22045. solve installation, configuration, and upgrade issues with 3Com
  22046. products.  It's a free, interactive self-service database of  technical
  22047. information to help you maximize the performance of your network
  22048. 24-hours a day, seven days a week.
  22049. ISPs with 3Com service contracts can access 3Com technical support case
  22050. information using 3Com Case Tracker.
  22051.  
  22052. The ISP Technical Support Home Page includes documentation, release
  22053. notes and configuration procedures for the following products:
  22054.  
  22055. HiPer Arc
  22056. HiPer DSP
  22057. NetServer
  22058. RADIUS
  22059. QUAD
  22060. NMC
  22061.  
  22062. Note: A service contract is required for some software and utilities.
  22063.  
  22064. To Access the ISP Technical Support Home Page?
  22065.  
  22066. Visit the web site: http://totalservice.3com.com/ then click on ISP Home
  22067. Page
  22068.  
  22069.  
  22070. To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forums -
  22071. http://totalservice.3com.com/forums/
  22072. To access the 3Com Knowledgebase - http://knowledgebase.3com.com
  22073. To access 3Com Carrier documentation - http://totalservice.3com.com/documents/
  22074. To view 3Com Carrier Service Offerings - http://totalservice.3com.com/services/
  22075.  
  22076.  
  22077. --0__=3vWwQc5HmcamoCbusgT7iIR0fIMcqkk1JF2VjqbxQwhZ871Bftum8o5s
  22078. Content-type: text/html; 
  22079.     name="att1.htm"
  22080. Content-Disposition: attachment; filename="att1.htm"
  22081. Content-transfer-encoding: base64
  22082. Content-Description: Internet HTML
  22083.  
  22084. PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv
  22085. L2VuIj4NCjxodG1sPg0KM0NvbSBDYXJyaWVyIENTTyByZWNlbnRseSBsYXVuY2hlZCBhIG5ldyB0
  22086. ZWNobmljYWwgc3VwcG9ydCB3ZWIgc2l0ZSBmb3INCklTUHMhJm5ic3A7IFRoZSBzaXRlIGNvbnRh
  22087. aW5zIGEgd2lkZSByYW5nZSBvZiBpbmZvcm1hdGlvbiBhbmQgbGlua3MgdG8NCm90aGVyIHVzZWZ1
  22088. bCBzaXRlcy4mbmJzcDsgV2hldGhlciB5b3UgbmVlZCB0byBsb2NhdGUgYSBWLjkwIHRyb3VibGVz
  22089. aG9vdGluZw0KZ3VpZGUsIGEgQ0xJIFF1aWNrIFJlZmVyZW5jZSBHdWlkZSBmb3IgSGlQZXIgQVJD
  22090. LCBmaW5kIG91dCBpZiBhIHByb2R1Y3QNCmlzIFllYXIgMjAwMCBjb21wbGlhbnQsIGRldGVybWlu
  22091. ZSB3aGljaCB2ZXJzaW9ucyBvZiBzb2Z0d2FyZSBjb2RlIGFyZSBjb21wYXRpYmxlDQpvciBuZWVk
  22092. IGFuc3dlcnMgdG8gb3RoZXIgdGVjaG5pY2FsIHN1cHBvcnQgYW5kIHNlcnZpY2UgcXVlc3Rpb25z
  22093. LCB5b3UgY2FuDQpmaW5kIHRoZSBhbnN3ZXIgb24gdGhlIElTUCBIb21lIFBhZ2UuDQo8cD5UaGUg
  22094. c2l0ZSBhbHNvIGhhcyBsaW5rcyB0byBvdGhlciAzQ29tIHdlYi1iYXNlZCBzZXJ2aWNlcyBLbm93
  22095. bGVkZ2ViYXNlDQphbmQgQ2FzZSBUcmFja2VyLiZuYnNwOyAzQ29tIEtub3dsZWRnZWJhc2Ugd2hl
  22096. cmUgeW91IGNhbiBlYXNpbHkgYW5kIHF1aWNrbHkNCmFjY2VzcyB0aGUgc2VsZi1zZXJ2aWNlIGRh
  22097. dGFiYXNlIHRvIGZpbmQgc29sdXRpb25zIHRvIGhlbHAgZGlhZ25vc2UgYW5kDQpzb2x2ZSBpbnN0
  22098. YWxsYXRpb24sIGNvbmZpZ3VyYXRpb24sIGFuZCB1cGdyYWRlIGlzc3VlcyB3aXRoIDNDb20gcHJv
  22099. ZHVjdHMuJm5ic3A7DQpJdCdzIGEgZnJlZSwgaW50ZXJhY3RpdmUgc2VsZi1zZXJ2aWNlIGRhdGFi
  22100. YXNlIG9mJm5ic3A7IHRlY2huaWNhbCBpbmZvcm1hdGlvbg0KdG8gaGVscCB5b3UgbWF4aW1pemUg
  22101. dGhlIHBlcmZvcm1hbmNlIG9mIHlvdXIgbmV0d29yayAyNC1ob3VycyBhIGRheSwgc2V2ZW4NCmRh
  22102. eXMgYSB3ZWVrLg0KPGJyPklTUHMgd2l0aCAzQ29tIHNlcnZpY2UgY29udHJhY3RzIGNhbiBhY2Nl
  22103. c3MgM0NvbSB0ZWNobmljYWwgc3VwcG9ydA0KY2FzZSBpbmZvcm1hdGlvbiB1c2luZyAzQ29tIENh
  22104. c2UgVHJhY2tlci4NCjxwPlRoZSBJU1AgVGVjaG5pY2FsIFN1cHBvcnQgSG9tZSBQYWdlIGluY2x1
  22105. ZGVzIGRvY3VtZW50YXRpb24sIHJlbGVhc2UNCm5vdGVzIGFuZA0KPGJyPmNvbmZpZ3VyYXRpb24g
  22106. cHJvY2VkdXJlcyBmb3IgdGhlIGZvbGxvd2luZyBwcm9kdWN0czoNCjxwPjxmb250IGNvbG9yPSIj
  22107. RkYwMDAwIj5IaVBlciBBcmM8L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPkhpUGVy
  22108. IERTUDwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+TmV0U2VydmVyPC9mb250Pg0K
  22109. PGJyPjxmb250IGNvbG9yPSIjRkYwMDAwIj5SQURJVVM8L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9
  22110. IiNGRjAwMDAiPlFVQUQ8L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPk5NQzwvZm9u
  22111. dD4NCjxwPjxmb250IGNvbG9yPSIjMDAwMDY2Ij5Ob3RlOiBBIHNlcnZpY2UgY29udHJhY3QgaXMg
  22112. cmVxdWlyZWQgZm9yIHNvbWUNCnNvZnR3YXJlIGFuZCB1dGlsaXRpZXMuPC9mb250Pg0KPHA+VG8g
  22113. QWNjZXNzIHRoZSBJU1AgVGVjaG5pY2FsIFN1cHBvcnQgSG9tZSBQYWdlPw0KPHA+VmlzaXQgdGhl
  22114. IHdlYnNpdGU6IDx1Pjxmb250IGNvbG9yPSIjMDAwMDY2Ij48QSBIUkVGPSJodHRwOi8vdG90YWxz
  22115. ZXJ2aWNlLjNjb20uY29tLyI+aHR0cDovL3RvdGFsc2VydmljZS4zY29tLmNvbS88L0E+PC9mb250
  22116. PjwvdT4NCnRoZW4gY2xpY2sgb24gSVNQIEhvbWUgUGFnZQ0KPGJyPiZuYnNwOw0KPGJyPiZuYnNw
  22117. Ow0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOzwvaHRtbD4N
  22118. Cg0K
  22119.  
  22120. --0__=3vWwQc5HmcamoCbusgT7iIR0fIMcqkk1JF2VjqbxQwhZ871Bftum8o5s--
  22121.  
  22122.  
  22123. -
  22124.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22125.  with "unsubscribe usr-tc" in the body of the message.
  22126.  For information on digests or retrieving files and old messages send
  22127.  "help" to the same address.  Do not use quotes in your message.
  22128.  
  22129.  
  22130. -------------------------------------------------------------------------------
  22131.  
  22132. From: "Walt Gnann" <wgnann@islc.net>
  22133. Subject: (usr-tc) HyperDSPs losing config
  22134. Date: 26 Apr 1999 19:36:18 -0400
  22135.  
  22136. NMC 5.5.5
  22137. HARC 4.1.59
  22138. HDSP 1.2.5
  22139.  
  22140. I've just added a few HyperDSPs (6 total) to a chasis and after the reboot
  22141. the configs for the T1s and modems were goofed.  They didn't go back to the
  22142. default, but added weird settings.  Reset modems and T1s to default, made my
  22143. corrections, saved the T1s and Modems to NVRAM then rebooted the chasis.
  22144. Same problem occurred.  After I configure the T1s and modems it will hold
  22145. those settings and operate properly until either the chasis is rebooted are
  22146. the cards are hardware resetted.  I don't think the DSPs are the
  22147. problem...I've taken these DSPs and put them in another chasis and they
  22148. worked normally.  So I'm down to the HARC or NMC as the culprit.  Any
  22149. suggestions?
  22150.  
  22151. Walt
  22152. Walter N. Gnann
  22153. ISLC, President
  22154. 843.770.1000
  22155. 843.770.1002 (fax)
  22156. wgnann@islc.net
  22157. http://www.islc.net
  22158. http://www.beaufortonline.com
  22159. http://www.beaufortcomputerclub.org
  22160.  
  22161.  
  22162.  
  22163. -
  22164.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22165.  with "unsubscribe usr-tc" in the body of the message.
  22166.  For information on digests or retrieving files and old messages send
  22167.  "help" to the same address.  Do not use quotes in your message.
  22168.  
  22169.  
  22170. -------------------------------------------------------------------------------
  22171.  
  22172. From: "David Bachta" <David_Bachta@mw.3com.com>
  22173. Subject: Re: (usr-tc) HyperDSPs losing config
  22174. Date: 26 Apr 1999 19:05:07 -0500
  22175.  
  22176.  
  22177.  
  22178. Hi Walt,
  22179.  
  22180. It sounds like 'auto-config' might be causing your problem.  To check if it is
  22181. enabled/disabled select the NMC card in TCM and choose Programmed Settings.
  22182. Choose 'Configuration Group' for the Parameter Group.  Set 'Auto Config on Card
  22183. Initialization' to disable.
  22184.  
  22185. Hope this helps.
  22186.  
  22187. Regards,
  22188. David
  22189.  
  22190.  
  22191.  
  22192.  
  22193. "Walt Gnann" <wgnann@islc.net> on 04/26/99 06:36:18 PM
  22194.  
  22195. Please respond to usr-tc@lists.xmission.com
  22196.  
  22197. Sent by:  "Walt Gnann" <wgnann@islc.net>
  22198.  
  22199.  
  22200. cc:    (David Bachta/MW/US/3Com)
  22201.  
  22202.  
  22203.  
  22204.  
  22205. NMC 5.5.5
  22206. HARC 4.1.59
  22207. HDSP 1.2.5
  22208.  
  22209. I've just added a few HyperDSPs (6 total) to a chasis and after the reboot
  22210. the configs for the T1s and modems were goofed.  They didn't go back to the
  22211. default, but added weird settings.  Reset modems and T1s to default, made my
  22212. corrections, saved the T1s and Modems to NVRAM then rebooted the chasis.
  22213. Same problem occurred.  After I configure the T1s and modems it will hold
  22214. those settings and operate properly until either the chasis is rebooted are
  22215. the cards are hardware resetted.  I don't think the DSPs are the
  22216. problem...I've taken these DSPs and put them in another chasis and they
  22217. worked normally.  So I'm down to the HARC or NMC as the culprit.  Any
  22218. suggestions?
  22219.  
  22220. Walt
  22221. Walter N. Gnann
  22222. ISLC, President
  22223. 843.770.1000
  22224. 843.770.1002 (fax)
  22225. wgnann@islc.net
  22226. http://www.islc.net
  22227. http://www.beaufortonline.com
  22228. http://www.beaufortcomputerclub.org
  22229.  
  22230.  
  22231.  
  22232. -
  22233.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22234.  with "unsubscribe usr-tc" in the body of the message.
  22235.  For information on digests or retrieving files and old messages send
  22236.  "help" to the same address.  Do not use quotes in your message.
  22237.  
  22238.  
  22239.  
  22240.  
  22241.  
  22242.  
  22243. -
  22244.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22245.  with "unsubscribe usr-tc" in the body of the message.
  22246.  For information on digests or retrieving files and old messages send
  22247.  "help" to the same address.  Do not use quotes in your message.
  22248.  
  22249.  
  22250. -------------------------------------------------------------------------------
  22251.  
  22252. From: Rick <rickyz@mindspring.com>
  22253. Subject: (usr-tc) Filters...
  22254. Date: 26 Apr 1999 20:41:32 -0400
  22255.  
  22256. All,
  22257. This filter thing is about confusing. I am just rying to create dynamic 
  22258. filters for people who have not paid up to restrict them from doing 
  22259. anything but access our Mail and authentication server, however, this 
  22260. doesn't appear to be working...the filters get applied, but they can still 
  22261. surf...what am I missing?
  22262.  
  22263. HiPer>> sh filter bess.in
  22264.  
  22265. RULES FOR FILTER /./bess.in SHOW PROTOCOLS: ALL
  22266. #filter
  22267. IP:
  22268. 10 ACCEPT src-addr=0.0.0.0/0;
  22269. 20 ACCEPT dst-addr=205.206.216.0/24;
  22270. 30 ACCEPT dst-addr=209.167.188.0/24;
  22271. 40 DENY;
  22272. HiPer>>
  22273. HiPer>> sh filter bess.out
  22274.  
  22275. RULES FOR FILTER /./bess.out SHOW PROTOCOLS: ALL
  22276. #filter
  22277. IP:
  22278. 10 ACCEPT src-addr=0.0.0.0/0;
  22279. 20 ACCEPT dst-addr=209.167.188.0/24;
  22280. 30 ACCEPT dst-addr=205.206.216.0/24;
  22281. 40 ACCEPT protocol = tcp;
  22282. 50 ACCEPT protocol = udp;
  22283. 60 DENY;
  22284.  
  22285. Also, What does the "AND" do here at the beginning of each line?
  22286.  
  22287. mail.in:
  22288.  
  22289. #filter
  22290. IP:
  22291. 010 AND dst-addr = 198.060.022.022/32;
  22292. 020 ACCEPT tcp-dst-port = 106;
  22293. 030 AND dst-addr = 198.060.022.022/32;
  22294. 040 ACCEPT tcp-dst-port = 109;
  22295. 050 AND dst-addr = 198.060.022.022/32;
  22296. 060 ACCEPT tcp-dst-port = 110;
  22297. 070 AND dst-addr = 198.060.022.022/32;
  22298. 080 ACCEPT tcp-dst-port = 143;
  22299. 090 AND dst-addr = 198.060.022.022/32;
  22300. 100 ACCEPT tcp-dst-port = 25;
  22301. 110 AND dst-addr = 198.060.022.022/32;
  22302. 120 ACCEPT udp-dst-port = 53;
  22303. 130 AND dst-addr = 198.060.022.002/32;
  22304. 140 ACCEPT udp-dst-port = 53;
  22305. 150 AND dst-addr = 198.060.022.000/26;
  22306. 160 ACCEPT tcp-dst-port = 80;
  22307. 170 AND dst-addr = 198.060.022.000/26;
  22308. 180 ACCEPT tcp-dst-port = 8000;
  22309. 190 AND dst-addr = 198.060.022.000/26;
  22310. 200 ACCEPT tcp-dst-port = 443;
  22311. 210 ACCEPT protocol = icmp;
  22312. 220 DENY;
  22313.  
  22314.  
  22315. mail.out:
  22316. #filter
  22317. IP:
  22318. 010 AND src-addr = 198.060.022.0/26;
  22319. 020 ACCEPT protocol = tcp;
  22320. 030 AND src-addr = 198.060.022.002/32;
  22321. 040 ACCEPT udp-src-port = 53;
  22322. 050 AND src-addr = 198.060.022.022/32;
  22323. 060 ACCEPT udp-src-port = 53;
  22324. 070 ACCEPT protocol = icmp;
  22325. 080 DENY;
  22326.  
  22327. Thanks in Advance,
  22328. RickyZ
  22329.  
  22330.  
  22331. -
  22332.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22333.  with "unsubscribe usr-tc" in the body of the message.
  22334.  For information on digests or retrieving files and old messages send
  22335.  "help" to the same address.  Do not use quotes in your message.
  22336.  
  22337.  
  22338. -------------------------------------------------------------------------------
  22339.  
  22340. From: Chairman of the Borg <list-total-control@L7.org>
  22341. Subject: (usr-tc) total control analog ninja needed
  22342. Date: 26 Apr 1999 17:53:34 -0700
  22343.  
  22344.  
  22345. Hey guys,
  22346.  
  22347. I've got a total control chassis here with major angst.
  22348. analog only .34 quad cards. the angst is cards with ports
  22349. that won't pick up, respond with garbage, etc. no error
  22350. lights, just borked communications. one card is perfect
  22351. but won't connect to anything at over 14.4, misc crap like
  22352. this. a couple people have said that most of this will sort
  22353. itself out with a reflash, so i'm going to try that before
  22354. i throw my hands up and ship it back. is there anyone on
  22355. this list that lives and breathes these that would be
  22356. willing to give me some pointers, etc? we sold off all
  22357. our old pop equipment and the guy is showing up wed to
  22358. pick it up, so if i don't get this sorted out by then
  22359. i'm in deep doo doo :/
  22360.  
  22361. thanks,
  22362. -dd
  22363.                                 \\\\\//                                    
  22364.        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  22365.        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  22366. +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  22367.            Plazma Networking Services / Level Seven inc.                
  22368.                 Connecting the World....                          
  22369.      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  22370.     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  22371. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  22372. ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  22373.  
  22374. -
  22375.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22376.  with "unsubscribe usr-tc" in the body of the message.
  22377.  For information on digests or retrieving files and old messages send
  22378.  "help" to the same address.  Do not use quotes in your message.
  22379.  
  22380.  
  22381. -------------------------------------------------------------------------------
  22382.  
  22383. From: Aaron Nabil <nabil@spiritone.com>
  22384. Subject: Re: (usr-tc) Short or long haul??
  22385. Date: 26 Apr 1999 18:06:46 -0700 (PDT)
  22386.  
  22387. Brian writes...
  22388. >On Mon, 26 Apr 1999, Jamie Orzechowski wrote:
  22389. >> We are using PRI's and I was wondering which I should use?? Short or
  22390. >> long haul and what DB should it be set to??  right now it's on DB26
  22391. >> and long haul ... are there any performance issues?
  22392. >
  22393. >I just select short haul nic, since its alot easier for me to think in
  22394. >terms of feet than db :).
  22395.  
  22396. And I just use CAT 1 in my network since its alot easier for me to have
  22397. just one type of cable around!  Doh!
  22398.   
  22399. The reason you see some T1 settings in feet instead of dB is beacuse they
  22400. are referring to a different types of interface.  Feet are refering to a
  22401. DSX-1 interface (ie, "short haul") and are a measure of the distance between
  22402. you and the DSX-1 interface.  For a T-1, ("long-haul") interface the number
  22403. is in dB because thats how you measure the loss from you to the next 
  22404. repeater.
  22405.  
  22406. The pulse masks and levels for DSX-1 and T-1 are different.  The only reason
  22407. they work at all when you mistakenly interconnect them or misconfigure your
  22408. interface is because modern T-1 receivers are extremely wide range and can
  22409. tolerate a lot of abuse.  To be explcit, setting an interface to DSX-1 and
  22410. measuring the distance in feet to the next repeater would not even come close
  22411. to being even an approximation of a correct configuration.
  22412.  
  22413. In case anyone was going to ask, the way you interconnect a DSX-1 device
  22414. with a T-1 line is a box called a CSU.  A CSU has two connectors, one is
  22415. a T-1 interface, the other a DSX-1 interface. 
  22416.  
  22417. To answer Jamie's question, if you are connecting to a metallic T1 (PRI) that
  22418. goes to a telco, select "long haul".  Start with a TLBO of -7.5 if you can't 
  22419. get a craft person to measure the level for you.  The only performance issue
  22420. is the bulk error rate on the span.
  22421.  
  22422. -- 
  22423. Aaron Nabil
  22424.  
  22425. -
  22426.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22427.  with "unsubscribe usr-tc" in the body of the message.
  22428.  For information on digests or retrieving files and old messages send
  22429.  "help" to the same address.  Do not use quotes in your message.
  22430.  
  22431.  
  22432. -------------------------------------------------------------------------------
  22433.  
  22434. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  22435. Subject: Re: (usr-tc) HyperDSPs losing config
  22436. Date: 26 Apr 1999 21:01:04 -0500 (CDT)
  22437.  
  22438. > NMC 5.5.5
  22439. > HARC 4.1.59
  22440. > HDSP 1.2.5
  22441. > 
  22442. > I've just added a few HyperDSPs (6 total) to a chasis and after the reboot
  22443. > the configs for the T1s and modems were goofed.  They didn't go back to the
  22444. > default, but added weird settings.  Reset modems and T1s to default, made my
  22445. > corrections, saved the T1s and Modems to NVRAM then rebooted the chasis.
  22446. > Same problem occurred.  After I configure the T1s and modems it will hold
  22447. > those settings and operate properly until either the chasis is rebooted are
  22448. > the cards are hardware resetted.  I don't think the DSPs are the
  22449. > problem...I've taken these DSPs and put them in another chasis and they
  22450. > worked normally.  So I'm down to the HARC or NMC as the culprit.  Any
  22451. > suggestions?
  22452.  
  22453. When you plug in a DSP card in a chassis with HiPer arc and NMC - the NMC 
  22454. sends 'chassis awarness' which tells the ARC about the card and tells it 
  22455. to own/disown the same.  When you put the DSP in a new/another chassis - 
  22456. the DSP worked good does not mean that the Problem is with the HiPer arc.
  22457.  
  22458. You must see who own the cards/slots and also make sure that the DPS 
  22459. settings in the T1/PRI side is setup correctly.
  22460.  
  22461. First here is what you need to do:
  22462.  
  22463. 1. Take a look at the hiper arc interfaces
  22464. List interface
  22465.  
  22466. Make sure that the hiper arc owns the cards.
  22467.  
  22468. 2. If the interfaces are 'up up' - no problems - but ifyou have
  22469.     interfaces 'up down'  there is aa problem
  22470.  
  22471. You must then check the interfaces - rebooting the hiper arc may clear 
  22472. the problem but the best bet would be to reboot the whole chassis or 
  22473. disable chassis awarness and start setting it up manually
  22474.  
  22475. krish
  22476.  
  22477. > 
  22478. > Walt
  22479. > -----------------------------------------------------
  22480. > Walter N. Gnann
  22481. > ISLC, President
  22482. > 843.770.1000
  22483. > 843.770.1002 (fax)
  22484. > wgnann@islc.net
  22485. > http://www.islc.net
  22486. > http://www.beaufortonline.com
  22487. > http://www.beaufortcomputerclub.org
  22488. > -----------------------------------------------------
  22489. > 
  22490. > 
  22491. > 
  22492. > -
  22493. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22494. >  with "unsubscribe usr-tc" in the body of the message.
  22495. >  For information on digests or retrieving files and old messages send
  22496. >  "help" to the same address.  Do not use quotes in your message.
  22497. > 
  22498.  
  22499. -
  22500.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22501.  with "unsubscribe usr-tc" in the body of the message.
  22502.  For information on digests or retrieving files and old messages send
  22503.  "help" to the same address.  Do not use quotes in your message.
  22504.  
  22505.  
  22506. -------------------------------------------------------------------------------
  22507.  
  22508. From: Brian <signal@shreve.net>
  22509. Subject: (usr-tc) beating a dead horse
  22510. Date: 26 Apr 1999 20:43:32 -0500 (CDT)
  22511.  
  22512.  
  22513. I understand this question has been beaten to death here, but I am still a
  22514. little vague.
  22515.  
  22516. With regards to AUTHENTICATION, I understand that setting the Primary
  22517. Server to your primary authentication server, and then setting the Primary
  22518. First Backup to your "backup" authentication server, and then setting the
  22519. RADIUS authentication algorithm to fallthrough, gives the effect that most
  22520. people want: it uses the primary, and then if the primary fails, it goes
  22521. to the secondary, and then if the primary comes back alive, it goes back
  22522. to the primary.
  22523.  
  22524. My question is, what about ACCOUNTING?  I have set:
  22525.  
  22526. The Primary Server Status is:              ENABLED
  22527. Primary Server is:                         208.206.76.58
  22528. Primary First Backup Server is:            208.206.76.5
  22529.  
  22530.  
  22531. yet, if the primary should fail, and accounting goes to the "primary first
  22532. backup", it wants to stay there.  How do I tell it to go back to the
  22533. primary if the primary goes back online?
  22534.  
  22535. Brian
  22536.  
  22537.  
  22538. Brian Feeny (BF304)     signal@shreve.net   
  22539. 318-222-2638 x 109    http://www.shreve.net/~signal      
  22540. Network Administrator   ShreveNet Inc. (ASN 11881)           
  22541.  
  22542.  
  22543. -
  22544.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22545.  with "unsubscribe usr-tc" in the body of the message.
  22546.  For information on digests or retrieving files and old messages send
  22547.  "help" to the same address.  Do not use quotes in your message.
  22548.  
  22549.  
  22550. -------------------------------------------------------------------------------
  22551.  
  22552. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  22553. Subject: Re: (usr-tc) total control analog ninja needed
  22554. Date: 26 Apr 1999 21:05:39 -0500 (CDT)
  22555.  
  22556. On Mon, 26 Apr 1999, Chairman of the Borg wrote:
  22557.  
  22558. > 
  22559. > Hey guys,
  22560. > 
  22561. > I've got a total control chassis here with major angst.
  22562. > analog only .34 quad cards. the angst is cards with ports
  22563. > that won't pick up, respond with garbage, etc. no error
  22564. > lights, just borked communications. one card is perfect
  22565. > but won't connect to anything at over 14.4, misc crap like
  22566. > this. a couple people have said that most of this will sort
  22567.  
  22568. Lot more information is required to find out what is the problem.
  22569.  
  22570. Are you using the Quads with NETServer/HiPer arc /Edgeserver ??
  22571.  
  22572. Are you having packet bus problems or modem connection problems?
  22573.  
  22574. Do you have a NMC in the chassis ?
  22575.  
  22576. This minimal info will help in identifing the problem.
  22577.  
  22578. krish
  22579.  
  22580.  
  22581. > itself out with a reflash, so i'm going to try that before
  22582. > i throw my hands up and ship it back. is there anyone on
  22583. > this list that lives and breathes these that would be
  22584. > willing to give me some pointers, etc? we sold off all
  22585. > our old pop equipment and the guy is showing up wed to
  22586. > pick it up, so if i don't get this sorted out by then
  22587. > i'm in deep doo doo :/
  22588. > 
  22589. > thanks,
  22590. > -dd
  22591. >                                 \\\\\//                                    
  22592. >        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  22593. >        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  22594. > +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  22595. >            Plazma Networking Services / Level Seven inc.                
  22596. >                 Connecting the World....                          
  22597. >      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  22598. >     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  22599. > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  22600. > ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  22601. > 
  22602. > -
  22603. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22604. >  with "unsubscribe usr-tc" in the body of the message.
  22605. >  For information on digests or retrieving files and old messages send
  22606. >  "help" to the same address.  Do not use quotes in your message.
  22607. > 
  22608.  
  22609. -
  22610.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22611.  with "unsubscribe usr-tc" in the body of the message.
  22612.  For information on digests or retrieving files and old messages send
  22613.  "help" to the same address.  Do not use quotes in your message.
  22614.  
  22615.  
  22616. -------------------------------------------------------------------------------
  22617.  
  22618. From: Mike Andrews <mandrews@termfrost.org>
  22619. Subject: (usr-tc) Re: cistron radius and VSA's
  22620. Date: 26 Apr 1999 21:53:33 -0400 (EDT)
  22621.  
  22622. On Mon, 26 Apr 1999, Mike Andrews wrote:
  22623.  
  22624. > I'm experimenting with the idea of switching to Cistron radius (beta16,
  22625. > the latest), and I'm having problems with it not logging 3com VSA's
  22626. > correctly.
  22627.  
  22628.  
  22629. Ignore this, I figured it out.  Cistron is *really* touchy about having
  22630. ATTRIB_NMC lines in more than one file, it seems....
  22631.  
  22632.  
  22633. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  22634. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  22635. Microsoft operating system is like a dog without a brick tied to its head."
  22636.  
  22637.  
  22638. -
  22639.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22640.  with "unsubscribe usr-tc" in the body of the message.
  22641.  For information on digests or retrieving files and old messages send
  22642.  "help" to the same address.  Do not use quotes in your message.
  22643.  
  22644.  
  22645. -------------------------------------------------------------------------------
  22646.  
  22647. From: Chairman of the Borg <list-total-control@L7.org>
  22648. Subject: Re: (usr-tc) total control analog ninja needed
  22649. Date: 26 Apr 1999 19:10:49 -0700
  22650.  
  22651. >> total control chassis / major angst / analog only
  22652. >> v.34 quad cards / ports that won't pick up
  22653. >> / respond with garbage, etc. / no error lights,
  22654.  
  22655. >Lot more information is required to find out what is the problem.
  22656. >Are you using the Quads with NETServer/HiPer arc /Edgeserver ??
  22657. >Are you having packet bus problems or modem connection problems?
  22658. >Do you have a NMC in the chassis ?
  22659. >This minimal info will help in identifing the problem.
  22660. >krish
  22661.  
  22662. sorry krish,
  22663.  
  22664. radius machine > cat5 > portmaster 2e-30 > serial cable > 4way cable >
  22665. analog rs-232 nic
  22666.  
  22667. chassis has 6 analog nics (with daughterboards) and 6 analog quadmodems in it.
  22668.  
  22669. dialing in with terminate and a usr 33.6, i get the following
  22670.  
  22671. port 01 : no answer / attach s0 (talk to modem directly) /atz <sits there>
  22672. port 02 : clean 33.6 connect
  22673. port 03 : clean 33.6 connect
  22674. port 04 : connects, ton of upper ascii garbage
  22675.  
  22676. port 05 : clean 14.4 connect
  22677. port 06 : clean 14.4 connect
  22678. port 07 : clean 14.4 connect
  22679. port 08 : clean 14.4 connect
  22680.  
  22681. port 09 : picks up and doesn't do anything else
  22682. port 10 : clean 33.6 connect
  22683. port 11 : connects, ton of upper ascii garbage
  22684. port 12 : no answer / attach s11 / atz <sits there>
  22685.  
  22686. port 13 : clean 33.6 connect
  22687. port 14 : clean 33.6 connect
  22688. port 15 : clean 33.6 connect
  22689. port 16 : connects, ton of upper ascii garbage
  22690.  
  22691. port 17 : no answer / attach s11 / atz <sits there>
  22692. port 18 : clean 33.6 connect
  22693. port 19 : clean 33.6 connect
  22694. port 20 : connects, ton of upper ascii garbage
  22695.  
  22696. port 21 : no answer / attach s11 / atz <sits there>
  22697. port 22 : clean 33.6 connect
  22698. port 23 : picks up and doesn't do anything else
  22699. port 24 : clean 33.6 connect
  22700.  
  22701. modem setup in portmaster is currently
  22702.  
  22703. borgmatrix-001.L7.net>show modem tcr
  22704.  
  22705.    Short Name: tcr
  22706.     Long Name: totalcontrol
  22707. Optimal Speed: 57600
  22708.          Type: User Defined
  22709.   Init Script:  Send Command                    Wait for Reply
  22710.                 ------------------------------  -----------------------------
  22711.                 AT&B1&H1&R2X7&A3S0=1&N0&W       OK
  22712.  
  22713.  
  22714. <sigh>
  22715. -dd
  22716.  
  22717.                                 \\\\\//                                    
  22718.        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  22719.        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  22720. +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  22721.            Plazma Networking Services / Level Seven inc.                
  22722.                 Connecting the World....                          
  22723.      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  22724.     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  22725. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  22726. ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  22727.  
  22728. -
  22729.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22730.  with "unsubscribe usr-tc" in the body of the message.
  22731.  For information on digests or retrieving files and old messages send
  22732.  "help" to the same address.  Do not use quotes in your message.
  22733.  
  22734.  
  22735. -------------------------------------------------------------------------------
  22736.  
  22737. From: Chairman of the Borg <list-total-control@L7.org>
  22738. Subject: (usr-tc) total control analog ninja needed
  22739. Date: 26 Apr 1999 23:02:11 -0700
  22740.  
  22741. okay,
  22742.  
  22743. we're deep into flashing these modems now (the screwed up total control
  22744. analog quadmodems)
  22745.  
  22746. so far the first 3 ports on the first card are fine and do what they are
  22747. supposed to.
  22748.  
  22749. port 4 gives us garbage till we smack a key, and it seems to still be
  22750. trying to handshake while the modem connecting to it is allready done.
  22751. ideas?
  22752.  
  22753. also, port 5, ati5 is giving me back this:
  22754.  
  22755. borgmatrix-001.L7.net> attach s4
  22756. Trying 207.12.41.6 ...
  22757. Connected - Escape character is '^]'.
  22758. ati5
  22759. USRobotics Analog Quad  NVRAM Settings...
  22760. Copyright, 1988-97, U.S. Robotics. All rights reserved.
  22761.  
  22762.    DIAL=TONE   B0  F1  X7
  22763.    BAUD=115200 PARITY=N  WORDLEN=8
  22764.  
  22765.    &A3  &B1  &G0  &H1  &I0  &K1  &L0  &M4  &N0  &P0  &R2  &S0
  22766.    &T4  &U0  &X0  &Y1  %N6  *U1=0  *U2=0  *U3=1  *V2=0  *X0=2048  *X1=2
  22767.  
  22768.    S00=001  S02=043  S03=013  S04=010  S05=008  S06=002  S07=060  S08=002
  22769.    S09=006  S10=007  S11=070  S12=050  S13=000  S15=000  S19=000  S21=010
  22770.    S22=017  S23=019  S24=150  S25=005  S26=001  S27=000  S28=008  S29=020
  22771.    S31=000  S32=009  S33=000  S34=000  S35=000  S36=000  S37=000  S38=000
  22772.    S39=011  S40=000  S41=000  S42=126  S43=200  S44=015  S46=255  S47=000
  22773.    S48=000  S49=016  S50=100  S51=000  S52=005  S53=000  S54=064  S55=000
  22774.    S56=000  S57=000  S58=000  S60=000  S61=000  S62=000  S63=000  S64=000
  22775.    S65=000  S66=000  S67=001  S68=000  S69=000  S70=000  S71=001  S72=000
  22776.    S73=001  S74=000  S75=000  S76=000  S77=000  S78=000  S79=000  S80=000
  22777.    S81=002  S82=012
  22778.  
  22779.    STORED PHONE #0:
  22780. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22781. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22782. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22783.                                                                   
  22784.                 #1:
  22785. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22786. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22787. ><
  22788.                                                                   
  22789.                 #2:
  22790. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22791. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22792.  
  22793.                                                                   
  22794.                 #3:
  22795. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  22796. =
  22797.  
  22798.                                                                   
  22799.  
  22800. OK
  22801.  
  22802.  
  22803. now a) shouldn't the port speed be 57,600? and i'm not sure what the deal
  22804. is wit the stored phone numbers, and i can't figure out how to set them to
  22805. nothing.
  22806.  
  22807. thanks to whomever sent me the faq's by the way :)
  22808. -dd
  22809.  
  22810.                                 \\\\\//                                    
  22811.        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  22812.        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  22813. +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  22814.            Plazma Networking Services / Level Seven inc.                
  22815.                 Connecting the World....                          
  22816.      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  22817.     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  22818. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  22819. ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  22820.  
  22821. -
  22822.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22823.  with "unsubscribe usr-tc" in the body of the message.
  22824.  For information on digests or retrieving files and old messages send
  22825.  "help" to the same address.  Do not use quotes in your message.
  22826.  
  22827.  
  22828. -------------------------------------------------------------------------------
  22829.  
  22830. From: Chairman of the Borg <list-total-control@L7.org>
  22831. Subject: Re: (usr-tc) total control analog ninja needed
  22832. Date: 26 Apr 1999 23:12:10 -0700
  22833.  
  22834.  
  22835. minor addendum
  22836.  
  22837. port 8 for some reason gives me nothing but a repeating upper asci capital
  22838. A with a tail thingy on top..
  22839.  
  22840. ideas?
  22841. -dd
  22842.  
  22843.                                 \\\\\//                                    
  22844.        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  22845.        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  22846. +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  22847.            Plazma Networking Services / Level Seven inc.                
  22848.                 Connecting the World....                          
  22849.      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  22850.     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  22851. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  22852. ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  22853.  
  22854. -
  22855.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22856.  with "unsubscribe usr-tc" in the body of the message.
  22857.  For information on digests or retrieving files and old messages send
  22858.  "help" to the same address.  Do not use quotes in your message.
  22859.  
  22860.  
  22861. -------------------------------------------------------------------------------
  22862.  
  22863. From: "Marshall Morgan" <marshall@netdoor.com>
  22864. Subject: (usr-tc) DSP Code Version/File - Release Date
  22865. Date: 27 Apr 1999 01:19:31 -0500
  22866.  
  22867. Webpage says:
  22868.  
  22869. hd010243.zip  1041337  1.2.43  04/20/1999
  22870.  
  22871. ftp says:
  22872.  
  22873. 04/20/99 09:05AM      1,041,337 hd010243.zip
  22874.  
  22875. ... but my old zip of the same version is different.
  22876.  
  22877. So how come it is a new date and file size but the version is the same??  All
  22878. that is different is the modification of the PDF included in the zipfile.  Seems
  22879. as though this could be confusing to some.
  22880.  
  22881. Marshall Morgan
  22882.  
  22883. Internet Doorway, Inc (aka NETDOOR)
  22884. http://www.netdoor.com
  22885.  
  22886. 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  22887.  
  22888.  
  22889. -
  22890.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22891.  with "unsubscribe usr-tc" in the body of the message.
  22892.  For information on digests or retrieving files and old messages send
  22893.  "help" to the same address.  Do not use quotes in your message.
  22894.  
  22895.  
  22896. -------------------------------------------------------------------------------
  22897.  
  22898. From: Scott Boggs <sboggs@unitedbank.net>
  22899. Subject: (usr-tc) required power supply
  22900. Date: 27 Apr 1999 08:20:21 -0400
  22901.  
  22902. I have a chassis with 1 NMC, 1 ARC, 8 DSPs
  22903. I am about to add another ARC and 2 more DSPs.
  22904. I have a 70 amp AC power supply,  a 3com tech told me
  22905. I would need to go to the 130 amp supply in order to 
  22906. add these cards and others down the road.
  22907. Anyone else had this type of problem?
  22908. If so, can I just pull the existing 70a and put a 130a in place?
  22909. Thanks,
  22910. Scott Boggs
  22911. United Bank - AccessUnited Internet
  22912.  
  22913.  
  22914.  
  22915. -
  22916.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22917.  with "unsubscribe usr-tc" in the body of the message.
  22918.  For information on digests or retrieving files and old messages send
  22919.  "help" to the same address.  Do not use quotes in your message.
  22920.  
  22921.  
  22922. -------------------------------------------------------------------------------
  22923.  
  22924. From: Rommel Wladimir de Lima <rommel@server2.eol.com.br>
  22925. Subject: Re: (usr-tc) Filters...
  22926. Date: 27 Apr 1999 09:48:20 -0300 (EST)
  22927.  
  22928. Hi
  22929.  
  22930.     I saw a message about usr-tc Filters and I will take the chance to
  22931. ask the solution to my problem as well. 
  22932.  
  22933.     I work at an ISP and we have a usr-tc with 4 E1 cards hiper dsp
  22934. and we would like to block attacks comming from dial in user. I've read
  22935. the manual but it doesn't explain clearly the point. My questions are:
  22936.  
  22937.     1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)?
  22938.         We've tried IP and IP-CALL and nothing worked
  22939.  
  22940.     2) Is the filter input_filter or output_filter?
  22941.         This is a bit confusing because it may be an input filter
  22942.         for the trafic comming from a dial-in user, but may be
  22943.         also an output trafic leaving the card.
  22944.  
  22945.     I did all the "cake receipt" to set up the filter in the tc, but
  22946. it didn't work.
  22947.     1) add TFTP client <client IP>
  22948.     2) tfpt <tc IP>
  22949.     3) add filter <filter>
  22950.     4) verify filter <filter>
  22951.     5) set interface <slot:x/mod[1-30] input_filter|output_filter
  22952. <filter> filter_access on
  22953.  
  22954.     Thank you in advance for the help.
  22955.  
  22956.  
  22957.  
  22958.  
  22959. -
  22960.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22961.  with "unsubscribe usr-tc" in the body of the message.
  22962.  For information on digests or retrieving files and old messages send
  22963.  "help" to the same address.  Do not use quotes in your message.
  22964.  
  22965.  
  22966. -------------------------------------------------------------------------------
  22967.  
  22968. From: Robert von Bismarck <rvb@petrel.ch>
  22969. Subject: RE: (usr-tc) MPIP, RIP and ping/traceroute
  22970. Date: 27 Apr 1999 14:58:54 +0200
  22971.  
  22972. Oooops... thanks for the tip... I forgot one of my ARC's in the server...
  22973. and the MLPPP connection began on that one ...
  22974.  
  22975. Now it works fine... I still have this memory leak/upgrade to take care of,
  22976. but that'll be next Sunday morning...
  22977.  
  22978. Robert
  22979.  
  22980.     -----Original Message-----
  22981.     From:    Jeff Mcadams [SMTP:jeffm@iglou.com]
  22982.     Sent:    vendredi, 23. avril 1999 20:02
  22983.     To:    usr-tc@lists.xmission.com
  22984.     Subject:    Re: (usr-tc) MPIP, RIP and ping/traceroute
  22985.  
  22986.     >ARC3:
  22987.     >SET NTP PRIMARY_SERVER a.b.c.d
  22988.     >ENABLE NTP
  22989.     >ADD MPIP CLIENT a.r.c.1 SHAREDSECRET CRYPT TYPE HIPER
  22990.     >ADD MPIP CLIENT a.r.c.2 SHAREDSECRET CRYPT TYPE HIPER
  22991.  
  22992.     Add:
  22993.     set mpip server_state on
  22994.     add mpip client <mpip server's ip> sharedsecret crypt type hiper
  22995.  
  22996.     I *think* that should take care of it all.
  22997.  
  22998.     >The ARC's are all in different subnets, I don't know if that
  22999. matters...
  23000.  
  23001.     Shouldn't.
  23002.     -- 
  23003.     Jeff McAdams                            Email: jeffm@iglou.com
  23004.     Head Network Administrator              Voice: (502) 966-3848
  23005.     IgLou Internet Services                        (800) 436-4456
  23006.  
  23007.     -
  23008.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23009.      with "unsubscribe usr-tc" in the body of the message.
  23010.      For information on digests or retrieving files and old messages
  23011. send
  23012.      "help" to the same address.  Do not use quotes in your message.
  23013.  
  23014. -
  23015.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23016.  with "unsubscribe usr-tc" in the body of the message.
  23017.  For information on digests or retrieving files and old messages send
  23018.  "help" to the same address.  Do not use quotes in your message.
  23019.  
  23020.  
  23021. -------------------------------------------------------------------------------
  23022.  
  23023. From: Robert von Bismarck <rvb@petrel.ch>
  23024. Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
  23025. Date: 27 Apr 1999 15:01:22 +0200
  23026.  
  23027. We use a cisco catalyst 2924XL (24 port 10/100 autosense) and it works
  23028. beautifully with the HiPerARC's. It even detects the 100Mb Full-Duplex
  23029. correctly...
  23030.  
  23031. Catalyst 1900 also works fine, is only a 10Mb switch with two 100Base-TX
  23032. ports though...
  23033.  
  23034. Robert
  23035.  
  23036.  
  23037.     -----Original Message-----
  23038.     From:    Ronald Kushner [SMTP:ron@glis.net]
  23039.     Sent:    vendredi, 23. avril 1999 21:51
  23040.     To:    usr-tc@lists.xmission.com
  23041.     Subject:    Re: (usr-tc) Total Control Performance on a 100Mps
  23042. Switch...
  23043.  
  23044.  
  23045.  
  23046.     Dan Hollis wrote:
  23047.     > 
  23048.     > On Fri, 23 Apr 1999, Robb Bryn wrote:
  23049.     > > I'll admit, I'm new to 10/100 switching technology and don't
  23050. know if this is
  23051.     > > normal. It's definitely not what I was expecting.  Anyone have
  23052. similar
  23053.     > > setups with switches?
  23054.     > 
  23055.     > The TC doesnt like certain hubs and switches. For example it
  23056. completely
  23057.     > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  23058.     > equipment has ever had problems with this hub, just the TC. I dont
  23059. know
  23060.     > why the TC is so touchy although I suspect its buggy or completly
  23061. broken
  23062.     > 10/100 autodetect.
  23063.  
  23064.     Has anyone compiled a list of known good or known bad auto-detecting
  23065. 10/100
  23066.     switching hubs when used with a Total Control?
  23067.  
  23068.     If not, readers can e-mail me off the list telling me about your
  23069. experiences
  23070.     with different switching hubs connected to the Total Control chassis
  23071. and I
  23072.     will post the results to the list.
  23073.  
  23074.     -Ron
  23075.     GLISnet, Inc.
  23076.     +1 810/939.9885
  23077.  
  23078.     -
  23079.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23080.      with "unsubscribe usr-tc" in the body of the message.
  23081.      For information on digests or retrieving files and old messages
  23082. send
  23083.      "help" to the same address.  Do not use quotes in your message.
  23084.  
  23085. -
  23086.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23087.  with "unsubscribe usr-tc" in the body of the message.
  23088.  For information on digests or retrieving files and old messages send
  23089.  "help" to the same address.  Do not use quotes in your message.
  23090.  
  23091.  
  23092. -------------------------------------------------------------------------------
  23093.  
  23094. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  23095. Subject: Re: (usr-tc) total control analog ninja needed
  23096. Date: 27 Apr 1999 09:30:34 -0500 (CDT)
  23097.  
  23098. On Mon, 26 Apr 1999, Chairman of the Borg wrote:
  23099. > 
  23100. > radius machine > cat5 > portmaster 2e-30 > serial cable > 4way cable >
  23101. > analog rs-232 nic
  23102. > 
  23103. > chassis has 6 analog nics (with daughterboards) and 6 analog quadmodems in it.
  23104. > 
  23105. > dialing in with terminate and a usr 33.6, i get the following
  23106. > 
  23107. > port 01 : no answer / attach s0 (talk to modem directly) /atz <sits there>
  23108. > port 02 : clean 33.6 connect
  23109. > port 03 : clean 33.6 connect
  23110. > port 04 : connects, ton of upper ascii garbage
  23111.  
  23112.  
  23113. Pull the modem and put dip switch 10 in the on position.  This will set 
  23114. the modem to factory default and cleary if there is any bad seetings.  I 
  23115. do see that you are sending the init string so the init string will set 
  23116. the modem to proper setting that your portmaster requires.
  23117.  
  23118. This should work
  23119.  
  23120. krish
  23121.  
  23122. > 
  23123. > port 05 : clean 14.4 connect
  23124. > port 06 : clean 14.4 connect
  23125. > port 07 : clean 14.4 connect
  23126. > port 08 : clean 14.4 connect
  23127. > 
  23128. > port 09 : picks up and doesn't do anything else
  23129. > port 10 : clean 33.6 connect
  23130. > port 11 : connects, ton of upper ascii garbage
  23131. > port 12 : no answer / attach s11 / atz <sits there>
  23132. > 
  23133. > port 13 : clean 33.6 connect
  23134. > port 14 : clean 33.6 connect
  23135. > port 15 : clean 33.6 connect
  23136. > port 16 : connects, ton of upper ascii garbage
  23137. > 
  23138. > port 17 : no answer / attach s11 / atz <sits there>
  23139. > port 18 : clean 33.6 connect
  23140. > port 19 : clean 33.6 connect
  23141. > port 20 : connects, ton of upper ascii garbage
  23142. > 
  23143. > port 21 : no answer / attach s11 / atz <sits there>
  23144. > port 22 : clean 33.6 connect
  23145. > port 23 : picks up and doesn't do anything else
  23146. > port 24 : clean 33.6 connect
  23147. > 
  23148. > modem setup in portmaster is currently
  23149. > 
  23150. > borgmatrix-001.L7.net>show modem tcr
  23151. > 
  23152. >    Short Name: tcr
  23153. >     Long Name: totalcontrol
  23154. > Optimal Speed: 57600
  23155. >          Type: User Defined
  23156. >   Init Script:  Send Command                    Wait for Reply
  23157. >                 ------------------------------  -----------------------------
  23158. >                 AT&B1&H1&R2X7&A3S0=1&N0&W       OK
  23159. > 
  23160. > 
  23161. > <sigh>
  23162. > -dd
  23163. > 
  23164. >                                 \\\\\//                                    
  23165. >        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  23166. >        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  23167. > +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  23168. >            Plazma Networking Services / Level Seven inc.                
  23169. >                 Connecting the World....                          
  23170. >      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  23171. >     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  23172. > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  23173. > ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  23174. > 
  23175.  
  23176. -
  23177.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23178.  with "unsubscribe usr-tc" in the body of the message.
  23179.  For information on digests or retrieving files and old messages send
  23180.  "help" to the same address.  Do not use quotes in your message.
  23181.  
  23182.  
  23183. -------------------------------------------------------------------------------
  23184.  
  23185. From: Marlo Montanaro <marlo@monmouth.com>
  23186. Subject: (usr-tc) Connecting to an NT Domain via TCHub
  23187. Date: 27 Apr 1999 10:59:40 -0400
  23188.  
  23189. Have a customer who wants his users to be able to click on one DUN =
  23190. shortcut on their desktop and automatically dial in to a TC Hub and =
  23191. authenticate into their NT domain.  His users are running both old and =
  23192. new versions of Win95 (a and b) as well as 98 and NT Workstation.
  23193.  
  23194. We have him currently configured to dial in and route through a =
  23195. proxy/firewall/router out to the Internet.  He now needs NT =
  23196. authentication also back to his local network as well.
  23197.  
  23198. We can dial into the TC Hub and authenticate as a PPP user with no =
  23199. problem.  We can get to the Internet with no problem.  The problem is NT =
  23200. domain authentication.
  23201.  
  23202. Can someone give us the TC Hub configuration as well as the config for =
  23203. Windows DUN?  Or at least a reference to the same.
  23204.  
  23205. Thanks,
  23206.  
  23207. MM=00=00
  23208.  
  23209. -
  23210.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23211.  with "unsubscribe usr-tc" in the body of the message.
  23212.  For information on digests or retrieving files and old messages send
  23213.  "help" to the same address.  Do not use quotes in your message.
  23214.  
  23215.  
  23216. -------------------------------------------------------------------------------
  23217.  
  23218. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  23219. Subject: RE: (usr-tc) Filters...
  23220. Date: 27 Apr 1999 10:14:55 -0500
  23221.  
  23222.  
  23223.  
  23224. |-----Original Message-----
  23225. |From: owner-usr-tc@lists.xmission.com
  23226. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick
  23227. |Sent: Monday, April 26, 1999 7:42 PM
  23228. |To: usr-tc@lists.xmission.com
  23229. |Subject: (usr-tc) Filters...
  23230. |
  23231. |
  23232. |All,
  23233. |This filter thing is about confusing. I am just rying to create dynamic
  23234. |filters for people who have not paid up to restrict them from doing
  23235. |anything but access our Mail and authentication server, however, this
  23236. |doesn't appear to be working...the filters get applied, but they can still
  23237. |surf...what am I missing?
  23238.  
  23239. Filter access turned on??
  23240.  
  23241. |HiPer>> sh filter bess.in
  23242. |
  23243. |RULES FOR FILTER /./bess.in SHOW PROTOCOLS: ALL
  23244. |#filter
  23245. |IP:
  23246. |10 ACCEPT src-addr=0.0.0.0/0;
  23247. No need for the above line..
  23248.  
  23249. |20 ACCEPT dst-addr=205.206.216.0/24;
  23250. |30 ACCEPT dst-addr=209.167.188.0/24;
  23251. |40 DENY;
  23252. |HiPer>>
  23253. |HiPer>> sh filter bess.out
  23254. |
  23255. |RULES FOR FILTER /./bess.out SHOW PROTOCOLS: ALL
  23256. |#filter
  23257. |IP:
  23258. |10 ACCEPT src-addr=0.0.0.0/0;
  23259. No need for the above line.
  23260. |20 ACCEPT dst-addr=209.167.188.0/24;
  23261. |30 ACCEPT dst-addr=205.206.216.0/24;
  23262. |40 ACCEPT protocol = tcp;
  23263. |50 ACCEPT protocol = udp;
  23264. |60 DENY;
  23265.  
  23266. Since this is an "output" filter, meaning out of the HARC into the user, you
  23267. should use src-addr not dst-addr here.
  23268.  
  23269. |Also, What does the "AND" do here at the beginning of each line?
  23270.  
  23271. The default filter action is to logic 'OR' the rules together. So in your above
  23272. filters if the data satisfies any line it passes. So in your output filter
  23273. (assuming you make it src and not dst) if the packet is tcp or udp it passes
  23274. reguardless of what address it came from. Use of the "AND" construct is required
  23275. there.
  23276.  
  23277. In the example below the writter uses AND to indicate that the line with the AND
  23278. and the following line are to be considered one rule. Both items must be matched
  23279. to make the line "TRUE".
  23280.  
  23281. From first looks your rules above will not work like you expect. The rules below
  23282. seem to have the correct syntax and will work. Maybe changing them with your IP
  23283. addresses is a better way to go..
  23284.  
  23285. The HARC manual covers the AND/OR idea and provides some sample filters. They are
  23286. good examples to work from.
  23287.  
  23288. -M
  23289.  
  23290.  
  23291. |mail.in:
  23292. |
  23293. |#filter
  23294. |IP:
  23295. |010 AND dst-addr = 198.060.022.022/32;
  23296. |020 ACCEPT tcp-dst-port = 106;
  23297. |030 AND dst-addr = 198.060.022.022/32;
  23298. |040 ACCEPT tcp-dst-port = 109;
  23299. -[SNIP!]-
  23300.  
  23301. -M
  23302.  
  23303.  
  23304. -
  23305.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23306.  with "unsubscribe usr-tc" in the body of the message.
  23307.  For information on digests or retrieving files and old messages send
  23308.  "help" to the same address.  Do not use quotes in your message.
  23309.  
  23310.  
  23311. -------------------------------------------------------------------------------
  23312.  
  23313. From: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
  23314. Subject: (usr-tc) RE: FS USR QUAD MODEM CARDS
  23315. Date: 27 Apr 1999 11:19:09 -0400
  23316.  
  23317. For Sale:
  23318.  
  23319. I have quantity (100) USR Quad Modem Cards in Stock
  23320. These are the analog/digital cards for the USR total control chassis.
  23321. USR part # 000793-04
  23322. $125 each min qty 5
  23323.  
  23324. Also: 
  23325.  
  23326. quantity (6) Netserver PRI T-1 card sets
  23327. USR part# 69-001393-00 Rev.1
  23328. $800.00 each
  23329.  
  23330. quantity (1) Dual T-1/E-1 NAC only
  23331. $500.00
  23332.  
  23333. If interested, please contact me via private e-mail
  23334.  
  23335. With Warmest Regards,
  23336. Andrew Shlensky
  23337. ****************************
  23338. PC Global, Incorporated 
  23339. (305) 667-2111 TEL
  23340. (305) 667-3636 FAX
  23341. URL:     http://www.pcglobal.net
  23342. E-MAIL: andrew@pcglobal.net
  23343. ICQ:       21219089    
  23344.  
  23345.  
  23346. -
  23347.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23348.  with "unsubscribe usr-tc" in the body of the message.
  23349.  For information on digests or retrieving files and old messages send
  23350.  "help" to the same address.  Do not use quotes in your message.
  23351.  
  23352.  
  23353. -------------------------------------------------------------------------------
  23354.  
  23355. From: Pete Ashdown <pashdown@xmission.com>
  23356. Subject: (usr-tc) stuck channels
  23357. Date: 27 Apr 1999 09:23:51 -0600 (MDT)
  23358.  
  23359. I have two separate cards with two stuck channels (both of them are channel
  23360. #8 coincidentally). I have repateadly reset them, flashed them, even
  23361. swapped them, but I can't get the channel to come back to life.  By "stuck"
  23362. I mean that they generate fast-busies.  Is this something that I should
  23363. contact my telco on, or has anyone found a cure?
  23364.  
  23365. -
  23366.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23367.  with "unsubscribe usr-tc" in the body of the message.
  23368.  For information on digests or retrieving files and old messages send
  23369.  "help" to the same address.  Do not use quotes in your message.
  23370.  
  23371.  
  23372. -------------------------------------------------------------------------------
  23373.  
  23374. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  23375. Subject: RE: (usr-tc) beating a dead horse
  23376. Date: 27 Apr 1999 10:24:47 -0500
  23377.  
  23378.  
  23379.  
  23380. |-----Original Message-----
  23381. |From: owner-usr-tc@lists.xmission.com
  23382. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  23383. |Sent: Monday, April 26, 1999 8:44 PM
  23384. |To: USRobotics TC Mailing List
  23385. |Subject: (usr-tc) beating a dead horse
  23386. |
  23387. |
  23388. |
  23389. |I understand this question has been beaten to death here, but I am still a
  23390. |little vague.
  23391. |
  23392. |With regards to AUTHENTICATION, I understand that setting the Primary
  23393. |Server to your primary authentication server, and then setting the Primary
  23394. |First Backup to your "backup" authentication server, and then setting the
  23395. |RADIUS authentication algorithm to fallthrough, gives the effect that most
  23396. |people want: it uses the primary, and then if the primary fails, it goes
  23397. |to the secondary, and then if the primary comes back alive, it goes back
  23398. |to the primary.
  23399. |
  23400. |My question is, what about ACCOUNTING?  I have set:
  23401. |
  23402. |The Primary Server Status is:              ENABLED
  23403. |Primary Server is:                         208.206.76.58
  23404. |Primary First Backup Server is:            208.206.76.5
  23405. |
  23406. |
  23407. |yet, if the primary should fail, and accounting goes to the "primary first
  23408. |backup", it wants to stay there.  How do I tell it to go back to the
  23409. |primary if the primary goes back online?
  23410. |
  23411.  
  23412. Here is your answer, straight from the 3KB Knowledge Base.
  23413.  
  23414. 3KB Solution: 1.0.21317967.2088893
  23415.  
  23416. Goal Total Control HiPer ARC - Making accounting fall back work just like
  23417. authentication algorithm "FALL_THROUGH"
  23418. Fact Total Control Chassis
  23419. Fact Total Control HiPer ARC
  23420. Fact Total Control HiPer ARC v 4.1.59-6
  23421. Fact Accounting
  23422. Fact RADIUS
  23423. Fact Engineering Release Code
  23424.  
  23425. Symptom Accounting server is switching to first backup and not returning to
  23426. primary server until backup goes down
  23427.  
  23428. Fix From HiPer ARC console issue the command:
  23429.  
  23430. HiPer>> "ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP"
  23431.  
  23432. This will cause the accounting to return to the primary server when it becomes
  23433. available.
  23434. Fact Search group - Total Control Remote Access Concentrator
  23435.  
  23436.  
  23437. -
  23438.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23439.  with "unsubscribe usr-tc" in the body of the message.
  23440.  For information on digests or retrieving files and old messages send
  23441.  "help" to the same address.  Do not use quotes in your message.
  23442.  
  23443.  
  23444. -------------------------------------------------------------------------------
  23445.  
  23446. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  23447. Subject: RE: (usr-tc) Filters...
  23448. Date: 27 Apr 1999 10:28:20 -0500
  23449.  
  23450.  
  23451.  
  23452. |-----Original Message-----
  23453. |From: owner-usr-tc@lists.xmission.com
  23454. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rommel Wladimir de
  23455. |Lima
  23456. |Sent: Tuesday, April 27, 1999 7:48 AM
  23457. |To: usr-tc@lists.xmission.com
  23458. |Subject: Re: (usr-tc) Filters...
  23459. |
  23460. |
  23461. |Hi
  23462. |
  23463. |    I saw a message about usr-tc Filters and I will take the chance to
  23464. |ask the solution to my problem as well.
  23465. |
  23466. |    I work at an ISP and we have a usr-tc with 4 E1 cards hiper dsp
  23467. |and we would like to block attacks comming from dial in user. I've read
  23468. |the manual but it doesn't explain clearly the point. My questions are:
  23469. |
  23470. |    1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)?
  23471. |
  23472.         We've tried IP and IP-CALL and nothing worked
  23473. IP:
  23474.  
  23475. |    2) Is the filter input_filter or output_filter?
  23476. |        This is a bit confusing because it may be an input filter
  23477. |        for the trafic comming from a dial-in user, but may be
  23478. |        also an output trafic leaving the card.
  23479. Filters on the HARC are always directional with respect to the interface. So data
  23480. from a user is going "IN" to the modem interface. Data to the user is going "OUT"
  23481. of the modem interface. From that you use an input filter to check data comming
  23482. from a user. The same rule apples for ethernet interfaces.
  23483.  
  23484.  
  23485. |    I did all the "cake receipt" to set up the filter in the tc, but
  23486. |it didn't work.
  23487. |    1) add TFTP client <client IP>
  23488. |    2) tfpt <tc IP>
  23489. |    3) add filter <filter>
  23490. |    4) verify filter <filter>
  23491. |    5) set interface <slot:x/mod[1-30] input_filter|output_filter
  23492. |<filter> filter_access on
  23493. |
  23494.  
  23495. It is possible your filter was applied, and was syntactically correct, but it
  23496. didnt block anything.
  23497.  
  23498. What was your exact filter?
  23499.  
  23500. -M
  23501.  
  23502.  
  23503. -
  23504.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23505.  with "unsubscribe usr-tc" in the body of the message.
  23506.  For information on digests or retrieving files and old messages send
  23507.  "help" to the same address.  Do not use quotes in your message.
  23508.  
  23509.  
  23510. -------------------------------------------------------------------------------
  23511.  
  23512. From: Brian <signal@shreve.net>
  23513. Subject: RE: (usr-tc) beating a dead horse
  23514. Date: 27 Apr 1999 10:41:24 -0500 (CDT)
  23515.  
  23516.  
  23517. Thanks, I will learn to use 3kb first from now on, it seems like that
  23518. knowledgbase is really getting alot of good tips in it.
  23519.  
  23520.  
  23521.  
  23522. On Tue, 27 Apr 1999, Mike Wronski wrote:
  23523.  
  23524. > 
  23525. > 
  23526. > |-----Original Message-----
  23527. > |From: owner-usr-tc@lists.xmission.com
  23528. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  23529. > |Sent: Monday, April 26, 1999 8:44 PM
  23530. > |To: USRobotics TC Mailing List
  23531. > |Subject: (usr-tc) beating a dead horse
  23532. > |
  23533. > |
  23534. > |
  23535. > |I understand this question has been beaten to death here, but I am still a
  23536. > |little vague.
  23537. > |
  23538. > |With regards to AUTHENTICATION, I understand that setting the Primary
  23539. > |Server to your primary authentication server, and then setting the Primary
  23540. > |First Backup to your "backup" authentication server, and then setting the
  23541. > |RADIUS authentication algorithm to fallthrough, gives the effect that most
  23542. > |people want: it uses the primary, and then if the primary fails, it goes
  23543. > |to the secondary, and then if the primary comes back alive, it goes back
  23544. > |to the primary.
  23545. > |
  23546. > |My question is, what about ACCOUNTING?  I have set:
  23547. > |
  23548. > |The Primary Server Status is:              ENABLED
  23549. > |Primary Server is:                         208.206.76.58
  23550. > |Primary First Backup Server is:            208.206.76.5
  23551. > |
  23552. > |
  23553. > |yet, if the primary should fail, and accounting goes to the "primary first
  23554. > |backup", it wants to stay there.  How do I tell it to go back to the
  23555. > |primary if the primary goes back online?
  23556. > |
  23557. > 
  23558. > Here is your answer, straight from the 3KB Knowledge Base.
  23559. > 
  23560. > 3KB Solution: 1.0.21317967.2088893
  23561. > 
  23562. > Goal Total Control HiPer ARC - Making accounting fall back work just like
  23563. > authentication algorithm "FALL_THROUGH"
  23564. > Fact Total Control Chassis
  23565. > Fact Total Control HiPer ARC
  23566. > Fact Total Control HiPer ARC v 4.1.59-6
  23567. > Fact Accounting
  23568. > Fact RADIUS
  23569. > Fact Engineering Release Code
  23570. > 
  23571. > Symptom Accounting server is switching to first backup and not returning to
  23572. > primary server until backup goes down
  23573. > 
  23574. > Fix From HiPer ARC console issue the command:
  23575. > 
  23576. > HiPer>> "ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP"
  23577. > 
  23578. > This will cause the accounting to return to the primary server when it becomes
  23579. > available.
  23580. > Fact Search group - Total Control Remote Access Concentrator
  23581. > 
  23582. > 
  23583. > -
  23584. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23585. >  with "unsubscribe usr-tc" in the body of the message.
  23586. >  For information on digests or retrieving files and old messages send
  23587. >  "help" to the same address.  Do not use quotes in your message.
  23588. > 
  23589.  
  23590. Brian Feeny (BF304)     signal@shreve.net   
  23591. 318-222-2638 x 109    http://www.shreve.net/~signal      
  23592. Network Administrator   ShreveNet Inc. (ASN 11881)           
  23593.  
  23594.  
  23595. -
  23596.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23597.  with "unsubscribe usr-tc" in the body of the message.
  23598.  For information on digests or retrieving files and old messages send
  23599.  "help" to the same address.  Do not use quotes in your message.
  23600.  
  23601.  
  23602. -------------------------------------------------------------------------------
  23603.  
  23604. From: Brian <signal@shreve.net>
  23605. Subject: RE: (usr-tc) beating a dead horse
  23606. Date: 27 Apr 1999 10:56:56 -0500 (CDT)
  23607.  
  23608.  
  23609. > 
  23610. > Here is your answer, straight from the 3KB Knowledge Base.
  23611. > 
  23612. > 3KB Solution: 1.0.21317967.2088893
  23613. > 
  23614. > Goal Total Control HiPer ARC - Making accounting fall back work just like
  23615. > authentication algorithm "FALL_THROUGH"
  23616. > Fact Total Control Chassis
  23617. > Fact Total Control HiPer ARC
  23618. > Fact Total Control HiPer ARC v 4.1.59-6
  23619. > Fact Accounting
  23620. > Fact RADIUS
  23621. > Fact Engineering Release Code
  23622. > 
  23623. > Symptom Accounting server is switching to first backup and not returning to
  23624. > primary server until backup goes down
  23625. > 
  23626. > Fix From HiPer ARC console issue the command:
  23627. > 
  23628. > HiPer>> "ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP"
  23629.             
  23630.  
  23631. FYI, the HiperARC expects:
  23632.  
  23633. ENABLE PRIORITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP
  23634.  
  23635. and not 
  23636.  
  23637. ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP
  23638.  
  23639. probably a typo in the hiperarc code.
  23640.  
  23641.  
  23642. > 
  23643. > This will cause the accounting to return to the primary server when it becomes
  23644. > available.
  23645. > Fact Search group - Total Control Remote Access Concentrator
  23646. > 
  23647. > 
  23648. > -
  23649. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23650. >  with "unsubscribe usr-tc" in the body of the message.
  23651. >  For information on digests or retrieving files and old messages send
  23652. >  "help" to the same address.  Do not use quotes in your message.
  23653. > 
  23654.  
  23655. Brian Feeny (BF304)     signal@shreve.net   
  23656. 318-222-2638 x 109    http://www.shreve.net/~signal      
  23657. Network Administrator   ShreveNet Inc. (ASN 11881)           
  23658.  
  23659.  
  23660. -
  23661.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23662.  with "unsubscribe usr-tc" in the body of the message.
  23663.  For information on digests or retrieving files and old messages send
  23664.  "help" to the same address.  Do not use quotes in your message.
  23665.  
  23666.  
  23667. -------------------------------------------------------------------------------
  23668.  
  23669. From: Chairman of the Borg <list-total-control@L7.org>
  23670. Subject: Re: (usr-tc) total control analog ninja needed
  23671. Date: 27 Apr 1999 09:22:41 -0700
  23672.  
  23673. ok,
  23674.  
  23675. after flashng we still have 2 wonky ports on the first 3 cards. one of them
  23676. sends back tons of upper ascii AAAAAA and the other with give a bit of
  23677. garbage on connect, then will hand over a prompt. (win 95 dun gags on it
  23678. though)
  23679. i can see this is going to be a fun road..
  23680. -dd
  23681.  
  23682.  
  23683. >On Mon, 26 Apr 1999, Chairman of the Borg wrote:
  23684. >> 
  23685. >> radius machine > cat5 > portmaster 2e-30 > serial cable > 4way cable >
  23686. >> analog rs-232 nic
  23687. >> 
  23688. >> chassis has 6 analog nics (with daughterboards) and 6 analog quadmodems
  23689. in it.
  23690. >> 
  23691. >> dialing in with terminate and a usr 33.6, i get the following
  23692. >> 
  23693. >> port 01 : no answer / attach s0 (talk to modem directly) /atz <sits there>
  23694. >> port 02 : clean 33.6 connect
  23695. >> port 03 : clean 33.6 connect
  23696. >> port 04 : connects, ton of upper ascii garbage
  23697. >
  23698. >
  23699. >Pull the modem and put dip switch 10 in the on position.  This will set 
  23700. >the modem to factory default and cleary if there is any bad seetings.  I 
  23701. >do see that you are sending the init string so the init string will set 
  23702. >the modem to proper setting that your portmaster requires.
  23703. >
  23704. >This should work
  23705. >
  23706. >krish
  23707. >
  23708. >> 
  23709. >> port 05 : clean 14.4 connect
  23710. >> port 06 : clean 14.4 connect
  23711. >> port 07 : clean 14.4 connect
  23712. >> port 08 : clean 14.4 connect
  23713. >> 
  23714. >> port 09 : picks up and doesn't do anything else
  23715. >> port 10 : clean 33.6 connect
  23716. >> port 11 : connects, ton of upper ascii garbage
  23717. >> port 12 : no answer / attach s11 / atz <sits there>
  23718. >> 
  23719. >> port 13 : clean 33.6 connect
  23720. >> port 14 : clean 33.6 connect
  23721. >> port 15 : clean 33.6 connect
  23722. >> port 16 : connects, ton of upper ascii garbage
  23723. >> 
  23724. >> port 17 : no answer / attach s11 / atz <sits there>
  23725. >> port 18 : clean 33.6 connect
  23726. >> port 19 : clean 33.6 connect
  23727. >> port 20 : connects, ton of upper ascii garbage
  23728. >> 
  23729. >> port 21 : no answer / attach s11 / atz <sits there>
  23730. >> port 22 : clean 33.6 connect
  23731. >> port 23 : picks up and doesn't do anything else
  23732. >> port 24 : clean 33.6 connect
  23733. >> 
  23734. >> modem setup in portmaster is currently
  23735. >> 
  23736. >> borgmatrix-001.L7.net>show modem tcr
  23737. >> 
  23738. >>    Short Name: tcr
  23739. >>     Long Name: totalcontrol
  23740. >> Optimal Speed: 57600
  23741. >>          Type: User Defined
  23742. >>   Init Script:  Send Command                    Wait for Reply
  23743. >>                 ------------------------------
  23744. >>                 AT&B1&H1&R2X7&A3S0=1&N0&W       OK
  23745. >> 
  23746. >> 
  23747. >> <sigh>
  23748. >> -dd
  23749. >> 
  23750. >>                                 \\\\\//                                    
  23751. >>        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  23752. >>        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  23753. >> +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  23754. >>            Plazma Networking Services / Level Seven inc.                
  23755. >>                 Connecting the World....                          
  23756. >>      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  23757. >>     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  23758. >> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  23759. >> ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  23760. >> 
  23761. >
  23762.                                 \\\\\//                                    
  23763.        \\|//       _\\|//_      |     |      _\\|//_       \\|//           
  23764.        (@ @)      (' 0-0 ')     (.) (.)     (' @-@ ')      (o-o)           
  23765. +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+    
  23766.            Plazma Networking Services / Level Seven inc.                
  23767.                 Connecting the World....                          
  23768.      http://www.plazma.net http://www.L7.net http://www.L7.org         /"\
  23769.     Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315    \ /
  23770. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+  X 
  23771. ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
  23772.  
  23773. -
  23774.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23775.  with "unsubscribe usr-tc" in the body of the message.
  23776.  For information on digests or retrieving files and old messages send
  23777.  "help" to the same address.  Do not use quotes in your message.
  23778.  
  23779.  
  23780. -------------------------------------------------------------------------------
  23781.  
  23782. From: Chris Peltier <cpeltier@netcarrier.com>
  23783. Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
  23784. Date: 23 Apr 1999 19:50:33 -0400
  23785.  
  23786.  
  23787.  
  23788. > How about a Cisco Catalyst 2924?  We were thinking of getting one...
  23789. > anyone?
  23790. > 
  23791. Cataylst 2924s and 2916s work just fine in our network.
  23792. It even works with the new enterprise software on these
  23793. switches (for physical LAN partitioning on the same unit).
  23794.  
  23795. -Chris 
  23796.  
  23797. -
  23798.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23799.  with "unsubscribe usr-tc" in the body of the message.
  23800.  For information on digests or retrieving files and old messages send
  23801.  "help" to the same address.  Do not use quotes in your message.
  23802.  
  23803.  
  23804. -------------------------------------------------------------------------------
  23805.  
  23806. From: K Mitchell <tech@keyconn.net>
  23807. Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
  23808. Date: 23 Apr 1999 16:55:14 -0400
  23809.  
  23810. At 03:50 PM 4/23/99 -0400, you wrote:
  23811. >> The TC doesnt like certain hubs and switches. For example it completely
  23812. >> brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other
  23813. >> equipment has ever had problems with this hub, just the TC. I dont know
  23814. >> why the TC is so touchy although I suspect its buggy or completly broken
  23815. >> 10/100 autodetect.
  23816.  
  23817. Plugged my HiPer into a NetGear FS308 a couple of weeks ago and it's been
  23818. humming along nicely. Auto-detect picks up 100mbs from the ARC and 10mbs
  23819. from NMC.
  23820.  
  23821.  
  23822. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23823. Keystone Connect                http://www.keyconn.net
  23824. Altoona, PA   814-941-5000         We Unlock the World
  23825.  
  23826. -
  23827.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23828.  with "unsubscribe usr-tc" in the body of the message.
  23829.  For information on digests or retrieving files and old messages send
  23830.  "help" to the same address.  Do not use quotes in your message.
  23831.  
  23832.  
  23833. -------------------------------------------------------------------------------
  23834.  
  23835. From: huix@990.net
  23836. Subject: (usr-tc) ISDN call debug
  23837. Date: 22 Apr 1999 02:13:36 -0000
  23838.  
  23839. Generated by Net Ease Web mail system!
  23840. ------net924747216-ease15216----
  23841. Content-Type: text/plain
  23842. Content-Transfer-Encoding: quoted-printable
  23843. X-MIME-Autoconverted: from 8bit to quoted-printable by slack.xmission.com id LAA10987
  23844.  
  23845. Hi,=20
  23846.  
  23847. I monitor PPP call use ppp ficility,
  23848.  
  23849. set ficility ppp loglevel verbose
  23850.  
  23851. I get call information and find ISDN
  23852. canot build MP during LCP phase,
  23853. who can tell me it is which end canot
  23854. accept MP option?
  23855.  
  23856.  
  23857.  
  23858.  
  23859. __________________________________________________
  23860. =BB=B6=D3=AD=CA=B9=D3=C3=BD=F0=C1=EA=C8=C8=CF=DF=C3=E2=B7=D1=B5=E7=D7=D3=D3=
  23861. =CA=BC=FE=CF=B5=CD=B3http://www.990.net
  23862. ------net924747216-ease15216----
  23863. Content-Type: text/plain; name="\isdn.txt"
  23864. Content-Disposition: attachment; filename="\isdn.txt"
  23865. Content-Transfer-Encoding: 8bit
  23866.  
  23867.  
  23868. At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_add_portal]: set add portal c
  23869. ondition call_id 503318028At 03:28:36, Facility "PPP", Level "COMMON":: [csm_drv
  23870. _state_change] bundle 15, link 20857464, state 1
  23871. At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_send_session_start_banner]: N
  23872. o user yet, don't have to send initial banner
  23873. At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_get_and_set_drv_control]: Dig
  23874. ital call,CCP flag 1
  23875. At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_get_and_set_drv_control]: Off
  23876. load, driver says YES
  23877. At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_set_drv_accm]:set rx accm fff
  23878. fffff tx accm ffffffff
  23879. At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_set_drv_accm]:set rx accm fff
  23880. fffff tx accm ffffffff
  23881. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_makereq] asking for MMRU: 15
  23882. 14
  23883. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  23884.  frame to L1
  23885. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23886. to L1
  23887. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23888. to L1
  23889. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23890. to L1
  23891. At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  23892. , ms_cmp_ret = 80
  23893. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23894. to L1
  23895. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_makereq] asking for MMRU: 15
  23896. 14
  23897. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23898.  with no COMP BIT SET
  23899. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23900.  with no COMP BIT SET
  23901. At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  23902. , ms_cmp_ret = 80
  23903. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23904. to L1
  23905. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23906.  with no COMP BIT SET
  23907. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23908. to L1
  23909. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23910. to L1
  23911. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23912. to L1
  23913. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23914. to L1
  23915. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23916. to L1
  23917. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23918.  with no COMP BIT SET
  23919. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23920. to L1
  23921. At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  23922. , ms_cmp_ret = 80
  23923. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23924. to L1
  23925. At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23926.  with no COMP BIT SET
  23927. At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  23928. , ms_cmp_ret = 80
  23929. At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23930. to L1
  23931. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23932. to L1
  23933. At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23934.  with no COMP BIT SET
  23935. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23936. to L1
  23937. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23938. to L1
  23939. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23940. to L1
  23941. At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23942.  with no COMP BIT SET
  23943. At 03:28:37, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  23944. , ms_cmp_ret = 80
  23945. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23946. to L1
  23947. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23948. to L1
  23949. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23950. to L1
  23951. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23952. to L1
  23953. At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23954.  with no COMP BIT SET
  23955. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23956. to L1
  23957. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23958. to L1
  23959. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23960. to L1
  23961. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23962. to L1
  23963. At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23964. to L1
  23965. At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23966.  with no COMP BIT SET
  23967. At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23968.  with no COMP BIT SET
  23969. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_chkreq]: remote asking for UN
  23970. IMP option: d, len: 3
  23971. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  23972.  frame to L1
  23973. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23974. to L1
  23975. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23976. to L1
  23977. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  23978.  frame to L1
  23979. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_open(LCP)]: PPP Connection Op
  23980. en
  23981. At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_set_drv_accm]:set rx accm 0 t
  23982. x accm 0
  23983. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23984.  with no COMP BIT SET
  23985. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23986. to L1
  23987. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23988.  with no COMP BIT SET
  23989. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23990.  with no COMP BIT SET
  23991. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23992. to L1
  23993. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  23994. to L1
  23995. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  23996.  with no COMP BIT SET
  23997. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  23998. , ms_cmp_ret = 80
  23999. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24000. to L1
  24001. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24002. to L1
  24003. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24004. to L1
  24005. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24006. to L1
  24007. At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_load_config]: LOCAL_IP_ADDR 0
  24008. xa4e00f4
  24009. At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_load_config]:NS addresses fro
  24010. m User Config  PRIM DNS 0, SEC DNS 0 , PRIM NBNS 0, PRIM NBNS 0
  24011. At 03:28:38, Facility "PPP", Level "VERBOSE":: [ppp_send_msg_to_td]: sending TUN
  24012. DISP_QUERY_REQ
  24013. At 03:28:38, Facility "PPP", Level "VERBOSE":: [ppp_process_main]: TD_QUERY_RSP
  24014. At 03:28:38, Facility "PPP", Level "VERBOSE":: [ppp_process_main]: No tunneling
  24015. protocol will be involved
  24016. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  24017.  frame to L1
  24018. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_open(PAP)]: PPP Connection Op
  24019. en
  24020. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_sendgetopt (IPCP)]
  24021. At 03:28:38, Facility "PPP", Level "COMMON"::   [psm_sendgetopt]: connection typ
  24022. e ConnChangeNormal
  24023. At 03:28:38, Facility "PPP", Level "UNUSUAL"::  [psm_sendgetopt]: profile id set
  24024.  to 2e004.
  24025. At 03:28:38, Facility "PPP", Level "UNUSUAL"::  [psm_sendgetopt]: connection id
  24026. set to 9c0000.
  24027. At 03:28:38, Facility "PPP", Level "UNUSUAL"::  [psm_sendgetopt]: connection typ
  24028. e set to dial in.
  24029. At 03:28:38, Facility "PPP", Level "UNUSUAL"::  [psm_sendgetopt]: number of opti
  24030. ons set to 2.
  24031. At 03:28:38, Facility "PPP", Level "UNUSUAL"::  [psm_sendgetopt]: Local Ip addre
  24032. ss set to 0xa4e00f4.
  24033. At 03:28:38, Facility "PPP", Level "UNUSUAL"::  [psm_sengetopt]: Remote IP addre
  24034. ss set to 0x0.
  24035. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [sendgetopt] Layer IPCP sent GetO
  24036. pt, new state = AWAITING_ADD_PORTAL
  24037. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_send_dns_req (IPCP)]
  24038. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_start] : Taking globally conf
  24039. igured NBNS - Primary 0 , Seconadry 0
  24040. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_rcvreq]: RX'd UNEXPECTED PKT(
  24041. IPCP): State: STARTING, CP code: Config Req
  24042. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  24043.  frame to L1
  24044. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  24045.  frame to L1
  24046. At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_get_option_rsp]: RETURN_STATU
  24047. S = 0
  24048. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [get_option_rsp] prot 1 notified,
  24049.  new state = ATTACHED
  24050. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [get_option_rsp] PDB CHAIN NOW LO
  24051. OKS LIKE THIS:
  24052. At 03:28:38, Facility "PPP", Level "UNUSUAL"::   Unsupported protocol 0
  24053. At 03:28:38, Facility "PPP", Level "UNUSUAL"::   IP, pdb 22882f8
  24054. At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_dns_ns_rsp]: DNS response, Pr
  24055. im a4e001e Sec a4a001e
  24056. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  24057.  frame to L1
  24058. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending
  24059.  frame to L1
  24060. At 03:28:38, Facility "PPP", Level "COMMON":: [psm_open(CCP)]: PPP Connection Op
  24061. en
  24062. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24063.  with no COMP BIT SET
  24064. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24065.  with no COMP BIT SET
  24066. At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24067. to L1
  24068. At 03:28:39, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24069. to L1
  24070. At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24071. to L1
  24072. At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24073. to L1
  24074. At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24075. to L1
  24076. At 03:28:40, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24077. , ms_cmp_ret = 80
  24078. At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24079. to L1
  24080. At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24081. to L1
  24082. At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24083. to L1
  24084. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24085. to L1
  24086. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24087. to L1
  24088. At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24089. , ms_cmp_ret = 80
  24090. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24091. to L1
  24092. At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24093. , ms_cmp_ret = 80
  24094. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24095. to L1
  24096. At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24097. , ms_cmp_ret = 80
  24098. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24099. to L1
  24100. At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24101. , ms_cmp_ret = 80
  24102. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24103. to L1
  24104. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24105. gotiate PRIM DNS
  24106. At 03:28:41, Facility "PPP", Level "VERBOSE":: Primary DNS addr rcvd : 0
  24107. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24108. gotiate PRIM NBNS
  24109. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24110. gotiate SEC DNS
  24111. At 03:28:41, Facility "PPP", Level "VERBOSE":: Secondary DNS addr rcvd : 0
  24112. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24113. gotiate SEC NBNS
  24114. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24115. to L1
  24116. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24117. gotiate PRIM DNS
  24118. At 03:28:41, Facility "PPP", Level "VERBOSE":: Primary DNS addr rcvd : 0
  24119. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24120. gotiate SEC DNS
  24121. At 03:28:41, Facility "PPP", Level "VERBOSE":: Secondary DNS addr rcvd : 0
  24122. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24123. to L1
  24124. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24125. to L1
  24126. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24127. to L1
  24128. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24129. to L1
  24130. At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24131. to L1
  24132. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24133. gotiate PRIM DNS
  24134. At 03:28:42, Facility "PPP", Level "VERBOSE":: Primary DNS addr rcvd : a4e001e
  24135. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne
  24136. gotiate SEC DNS
  24137. At 03:28:42, Facility "PPP", Level "VERBOSE":: Secondary DNS addr rcvd : a4a001e
  24138. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24139. to L1
  24140. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: switching on layer (I
  24141. PCP)
  24142. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: i = 0
  24143. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: option ACKed
  24144. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: i = 1
  24145. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: option ACKed
  24146. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: i = 2
  24147. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: option ACKed
  24148. At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: about to go open
  24149. At 03:28:42, Facility "PPP", Level "COMMON":: [psm_open(IPCP)]: PPP Connection O
  24150. pen
  24151. At 03:28:42, Facility "PPP", Level "COMMON":: [psm_open]: Add route to peer (a4e
  24152. 00f4) from host yuan
  24153. At 03:28:42, Facility "PPP", Level "COMMON":: [csm_fwdr_state_change] bundle 15,
  24154.  proto_type 1, state 1
  24155. At 03:28:42, Facility "PPP", Level "UNUSUAL":: [fwdr_state_change] prot 1, DRV_A
  24156. CTIVE
  24157. At 03:28:42, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: MPP sync estab
  24158. lished on seq #0.
  24159. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24160. to L1
  24161. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24162. to L1
  24163. At 03:28:42, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24164. , ms_cmp_ret = 80
  24165. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24166. to L1
  24167. At 03:28:43, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24168. to L1
  24169. At 03:28:43, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24170. to L1
  24171. At 03:28:43, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24172. to L1
  24173. At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24174. to L1
  24175. At 03:28:44, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24176. , ms_cmp_ret = 80
  24177. At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24178. to L1
  24179. At 03:28:44, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24180.  with no COMP BIT SET
  24181. At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24182. to L1
  24183. At 03:28:44, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24184.  with no COMP BIT SET
  24185. At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24186. to L1
  24187. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24188. to L1
  24189. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24190. to L1
  24191. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24192. to L1
  24193. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24194. to L1
  24195. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24196. to L1
  24197. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24198. to L1
  24199. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24200. to L1
  24201. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24202. to L1
  24203. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24204. to L1
  24205. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24206. to L1
  24207. At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24208.  with no COMP BIT SET
  24209. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24210. to L1
  24211. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24212. to L1
  24213. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24214. to L1
  24215. At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24216.  with no COMP BIT SET
  24217. At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24218.  with no COMP BIT SET
  24219. At 03:28:45, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24220. , ms_cmp_ret = 80
  24221. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24222. to L1
  24223. At 03:28:45, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24224. , ms_cmp_ret = 80
  24225. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24226. to L1
  24227. At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24228. to L1
  24229. At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24230.  with no COMP BIT SET
  24231. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24232. to L1
  24233. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24234. to L1
  24235. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24236. to L1
  24237. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24238. to L1
  24239. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24240. to L1
  24241. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24242. to L1
  24243. At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24244. to L1
  24245. At 03:28:47, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24246. , ms_cmp_ret = 80
  24247. At 03:28:47, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24248. to L1
  24249. At 03:28:47, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24250. , ms_cmp_ret = 80
  24251. At 03:28:47, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24252. to L1
  24253. At 03:28:47, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24254. etected...
  24255. At 03:28:47, Facility "PPP", Level "COMMON"::                      M = 14, first
  24256.  END seq = 12
  24257. At 03:28:47, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 1
  24258. 2, M = 14
  24259. At 03:28:47, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24260. At 03:28:47, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24261. to L1
  24262. At 03:28:48, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24263. etected...
  24264. At 03:28:48, Facility "PPP", Level "COMMON"::                      M = 18, first
  24265.  END seq = 16
  24266. At 03:28:48, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 1
  24267. 6, M = 18
  24268. At 03:28:48, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24269. to L1
  24270. At 03:28:50, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24271. etected...
  24272. At 03:28:50, Facility "PPP", Level "COMMON"::                      M = 1d, first
  24273.  END seq = 1a
  24274. At 03:28:50, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 1
  24275. a, M = 1d
  24276. At 03:28:50, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24277. At 03:28:50, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24278. to L1
  24279. At 03:28:51, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24280.  with no COMP BIT SET
  24281. At 03:28:51, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24282. to L1
  24283. At 03:28:51, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24284.  with no COMP BIT SET
  24285. At 03:28:51, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24286. to L1
  24287. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24288. to L1
  24289. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24290. to L1
  24291. At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24292.  with no COMP BIT SET
  24293. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24294. to L1
  24295. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24296. to L1
  24297. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24298. to L1
  24299. At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24300.  with no COMP BIT SET
  24301. At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24302.  with no COMP BIT SET
  24303. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24304. to L1
  24305. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24306. to L1
  24307. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24308. to L1
  24309. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24310. to L1
  24311. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24312. to L1
  24313. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24314. to L1
  24315. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24316. to L1
  24317. At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24318.  with no COMP BIT SET
  24319. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24320. to L1
  24321. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24322. to L1
  24323. At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24324. to L1
  24325. At 03:28:53, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24326. , ms_cmp_ret = 80
  24327. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24328. to L1
  24329. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24330. to L1
  24331. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24332. to L1
  24333. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24334. to L1
  24335. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24336. to L1
  24337. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24338. to L1
  24339. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24340. to L1
  24341. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24342. to L1
  24343. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24344. to L1
  24345. At 03:28:53, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24346. , ms_cmp_ret = 80
  24347. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24348. to L1
  24349. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24350. to L1
  24351. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24352. to L1
  24353. At 03:28:53, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24354. , ms_cmp_ret = 80
  24355. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24356. to L1
  24357. At 03:28:53, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24358. etected...
  24359. At 03:28:53, Facility "PPP", Level "COMMON"::                      M = 22, first
  24360.  END seq = 20
  24361. At 03:28:53, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2
  24362. 0, M = 22
  24363. At 03:28:53, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24364. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24365. to L1
  24366. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24367. to L1
  24368. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24369. to L1
  24370. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24371. to L1
  24372. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24373. to L1
  24374. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24375. to L1
  24376. At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24377. to L1
  24378. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24379.  with no COMP BIT SET
  24380. At 03:28:54, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24381. , ms_cmp_ret = 80
  24382. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24383. to L1
  24384. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24385.  with no COMP BIT SET
  24386. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24387. to L1
  24388. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24389. to L1
  24390. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24391.  with no COMP BIT SET
  24392. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24393.  with no COMP BIT SET
  24394. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24395. to L1
  24396. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24397. to L1
  24398. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24399. to L1
  24400. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24401. to L1
  24402. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24403.  with no COMP BIT SET
  24404. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24405.  with no COMP BIT SET
  24406. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24407. to L1
  24408. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24409. to L1
  24410. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24411.  with no COMP BIT SET
  24412. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24413. to L1
  24414. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24415. to L1
  24416. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24417. to L1
  24418. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24419. to L1
  24420. At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24421.  with no COMP BIT SET
  24422. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24423. to L1
  24424. At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24425. to L1
  24426. At 03:28:55, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24427.  with no COMP BIT SET
  24428. At 03:28:55, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24429.  with no COMP BIT SET
  24430. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24431. to L1
  24432. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24433. to L1
  24434. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24435. to L1
  24436. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24437. to L1
  24438. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24439. to L1
  24440. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24441. to L1
  24442. At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24443. etected...
  24444. At 03:28:55, Facility "PPP", Level "COMMON"::                      M = 27, first
  24445.  END seq = 24
  24446. At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2
  24447. 4, M = 27
  24448. At 03:28:55, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24449. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24450. to L1
  24451. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24452. to L1
  24453. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24454. to L1
  24455. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24456. to L1
  24457. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24458. to L1
  24459. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24460. to L1
  24461. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24462. to L1
  24463. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24464. to L1
  24465. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24466. to L1
  24467. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24468. to L1
  24469. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24470. to L1
  24471. At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24472. etected...
  24473. At 03:28:55, Facility "PPP", Level "COMMON"::                      M = 2c, first
  24474.  END seq = 2a
  24475. At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2
  24476. a, M = 2c
  24477. At 03:28:55, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24478. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24479. to L1
  24480. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24481. to L1
  24482. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24483. to L1
  24484. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24485. to L1
  24486. At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24487. to L1
  24488. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24489. to L1
  24490. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24491. to L1
  24492. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24493. to L1
  24494. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24495. to L1
  24496. At 03:28:56, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24497. etected...
  24498. At 03:28:56, Facility "PPP", Level "COMMON"::                      M = 30, first
  24499.  END seq = 2e
  24500. At 03:28:56, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2
  24501. e, M = 30
  24502. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24503. to L1
  24504. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24505. to L1
  24506. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24507. to L1
  24508. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24509. to L1
  24510. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24511. to L1
  24512. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24513. to L1
  24514. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24515. to L1
  24516. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24517. to L1
  24518. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24519. to L1
  24520. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24521. to L1
  24522. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24523. to L1
  24524. At 03:28:56, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24525. , ms_cmp_ret = 80
  24526. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24527. to L1
  24528. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24529. to L1
  24530. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24531. to L1
  24532. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24533. to L1
  24534. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24535. to L1
  24536. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24537. to L1
  24538. At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24539. to L1
  24540. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24541. to L1
  24542. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24543. to L1
  24544. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24545. to L1
  24546. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24547. to L1
  24548. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24549. to L1
  24550. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24551. to L1
  24552. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24553. to L1
  24554. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24555. to L1
  24556. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24557. to L1
  24558. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24559. to L1
  24560. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24561. to L1
  24562. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24563. to L1
  24564. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24565. to L1
  24566. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24567. to L1
  24568. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24569. to L1
  24570. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24571. to L1
  24572. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24573. to L1
  24574. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24575. to L1
  24576. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24577. to L1
  24578. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24579. to L1
  24580. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24581. to L1
  24582. At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24583. to L1
  24584. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24585. to L1
  24586. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24587. to L1
  24588. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24589. to L1
  24590. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24591. to L1
  24592. At 03:28:58, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24593. , ms_cmp_ret = 80
  24594. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24595. to L1
  24596. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24597. to L1
  24598. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24599. to L1
  24600. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24601. to L1
  24602. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24603. to L1
  24604. At 03:28:58, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24605. , ms_cmp_ret = 80
  24606. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24607. to L1
  24608. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24609. to L1
  24610. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24611. to L1
  24612. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24613. to L1
  24614. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24615. to L1
  24616. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24617. to L1
  24618. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24619. to L1
  24620. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24621. to L1
  24622. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24623. to L1
  24624. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24625. to L1
  24626. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24627. to L1
  24628. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24629. to L1
  24630. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24631. to L1
  24632. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24633. to L1
  24634. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24635. to L1
  24636. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24637. to L1
  24638. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24639. to L1
  24640. At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24641. to L1
  24642. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24643. to L1
  24644. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24645. to L1
  24646. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24647. to L1
  24648. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24649. to L1
  24650. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24651. to L1
  24652. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24653. to L1
  24654. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24655. to L1
  24656. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24657. to L1
  24658. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24659. to L1
  24660. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24661. to L1
  24662. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24663. to L1
  24664. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24665. , ms_cmp_ret = 80
  24666. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24667. to L1
  24668. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24669. , ms_cmp_ret = 80
  24670. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24671. to L1
  24672. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24673. to L1
  24674. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24675. to L1
  24676. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24677. to L1
  24678. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24679. to L1
  24680. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24681. , ms_cmp_ret = 80
  24682. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24683. to L1
  24684. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24685. to L1
  24686. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24687. to L1
  24688. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24689. to L1
  24690. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24691. to L1
  24692. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24693. to L1
  24694. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24695. to L1
  24696. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24697. to L1
  24698. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24699. to L1
  24700. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24701. to L1
  24702. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24703. etected...
  24704. At 03:28:59, Facility "PPP", Level "COMMON"::                      M = 34, first
  24705.  END seq = 32
  24706. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3
  24707. 2, M = 34
  24708. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24709. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24710. to L1
  24711. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24712. etected...
  24713. At 03:28:59, Facility "PPP", Level "COMMON"::                      M = 38, first
  24714.  END seq = 36
  24715. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3
  24716. 6, M = 38
  24717. At 03:28:59, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24718. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24719. to L1
  24720. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24721. to L1
  24722. At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24723. to L1
  24724. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24725. to L1
  24726. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24727. to L1
  24728. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24729. to L1
  24730. At 03:29:00, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24731.  with no COMP BIT SET
  24732. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24733. to L1
  24734. At 03:29:00, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24735. etected...
  24736. At 03:29:00, Facility "PPP", Level "COMMON"::                      M = 3c, first
  24737.  END seq = 3a
  24738. At 03:29:00, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3
  24739. a, M = 3c
  24740. At 03:29:00, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24741. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24742. to L1
  24743. At 03:29:00, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24744. , ms_cmp_ret = 80
  24745. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24746. to L1
  24747. At 03:29:00, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24748. , ms_cmp_ret = 80
  24749. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24750. to L1
  24751. At 03:29:00, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24752. , ms_cmp_ret = 80
  24753. At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24754. to L1
  24755. At 03:29:01, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24756. to L1
  24757. At 03:29:01, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24758. to L1
  24759. At 03:29:01, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24760. etected...
  24761. At 03:29:01, Facility "PPP", Level "COMMON"::                      M = 40, first
  24762.  END seq = 3e
  24763. At 03:29:01, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3
  24764. e, M = 40
  24765. At 03:29:01, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24766. to L1
  24767. At 03:29:01, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24768.  with no COMP BIT SET
  24769. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24770. , ms_cmp_ret = 80
  24771. At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24772. to L1
  24773. At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24774. to L1
  24775. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24776. , ms_cmp_ret = 80
  24777. At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24778. to L1
  24779. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24780. , ms_cmp_ret = 80
  24781. At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24782. to L1
  24783. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24784. etected...
  24785. At 03:29:02, Facility "PPP", Level "COMMON"::                      M = 43, first
  24786.  END seq = 42
  24787. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4
  24788. 2, M = 43
  24789. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24790. At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24791. to L1
  24792. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24793. etected...
  24794. At 03:29:02, Facility "PPP", Level "COMMON"::                      M = 47, first
  24795.  END seq = 45
  24796. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4
  24797. 5, M = 47
  24798. At 03:29:02, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24799. At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24800. to L1
  24801. At 03:29:03, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24802. , ms_cmp_ret = 80
  24803. At 03:29:03, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24804. to L1
  24805. At 03:29:03, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24806. , ms_cmp_ret = 80
  24807. At 03:29:03, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24808. to L1
  24809. At 03:29:04, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24810. , ms_cmp_ret = 80
  24811. At 03:29:04, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24812. to L1
  24813. At 03:29:04, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24814. , ms_cmp_ret = 80
  24815. At 03:29:04, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24816. to L1
  24817. At 03:29:04, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24818. , ms_cmp_ret = 80
  24819. At 03:29:04, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24820. to L1
  24821. At 03:29:04, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24822.  with no COMP BIT SET
  24823. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24824. to L1
  24825. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24826. to L1
  24827. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24828. to L1
  24829. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24830. to L1
  24831. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24832. to L1
  24833. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24834. etected...
  24835. At 03:29:05, Facility "PPP", Level "COMMON"::                      M = 4c, first
  24836.  END seq = 49
  24837. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4
  24838. 9, M = 4c
  24839. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24840. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24841. to L1
  24842. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24843. to L1
  24844. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24845. , ms_cmp_ret = 80
  24846. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24847. to L1
  24848. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24849. , ms_cmp_ret = 80
  24850. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24851. to L1
  24852. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24853. , ms_cmp_ret = 80
  24854. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24855. to L1
  24856. At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24857. , ms_cmp_ret = 80
  24858. At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24859. to L1
  24860. At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24861. to L1
  24862. At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24863. to L1
  24864. At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24865. to L1
  24866. At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24867. to L1
  24868. At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24869. to L1
  24870. At 03:29:06, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24871. etected...
  24872. At 03:29:06, Facility "PPP", Level "COMMON"::                      M = 50, first
  24873.  END seq = 4e
  24874. At 03:29:06, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4
  24875. e, M = 50
  24876. At 03:29:06, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24877. At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24878. to L1
  24879. At 03:29:07, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24880.  with no COMP BIT SET
  24881. At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24882. to L1
  24883. At 03:29:07, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24884. , ms_cmp_ret = 80
  24885. At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24886. to L1
  24887. At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24888. to L1
  24889. At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24890. to L1
  24891. At 03:29:08, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24892. , ms_cmp_ret = 80
  24893. At 03:29:08, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24894. to L1
  24895. At 03:29:09, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24896. to L1
  24897. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24898. , ms_cmp_ret = 80
  24899. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24900. to L1
  24901. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24902.  with no COMP BIT SET
  24903. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24904. to L1
  24905. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24906. , ms_cmp_ret = 80
  24907. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24908. to L1
  24909. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24910.  with no COMP BIT SET
  24911. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24912. , ms_cmp_ret = 80
  24913. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24914. to L1
  24915. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24916. , ms_cmp_ret = 80
  24917. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24918. to L1
  24919. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24920. etected...
  24921. At 03:29:10, Facility "PPP", Level "COMMON"::                      M = 54, first
  24922.  END seq = 52
  24923. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 5
  24924. 2, M = 54
  24925. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24926. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24927. to L1
  24928. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24929. etected...
  24930. At 03:29:10, Facility "PPP", Level "COMMON"::                      M = 58, first
  24931.  END seq = 56
  24932. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 5
  24933. 6, M = 58
  24934. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24935. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24936. to L1
  24937. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24938. to L1
  24939. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24940. to L1
  24941. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24942. to L1
  24943. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  24944. etected...
  24945. At 03:29:10, Facility "PPP", Level "COMMON"::                      M = 5e, first
  24946.  END seq = 5a
  24947. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 5
  24948. a, M = 5e
  24949. At 03:29:10, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  24950. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24951. to L1
  24952. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24953.  with no COMP BIT SET
  24954. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24955. to L1
  24956. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24957. to L1
  24958. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24959. to L1
  24960. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24961.  with no COMP BIT SET
  24962. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24963.  with no COMP BIT SET
  24964. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24965.  with no COMP BIT SET
  24966. At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24967.  with no COMP BIT SET
  24968. At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24969. to L1
  24970. At 03:29:11, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24971.  with no COMP BIT SET
  24972. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24973. to L1
  24974. At 03:29:11, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24975.  with no COMP BIT SET
  24976. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24977. to L1
  24978. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24979. to L1
  24980. At 03:29:11, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24981. , ms_cmp_ret = 80
  24982. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24983. to L1
  24984. At 03:29:11, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24985. , ms_cmp_ret = 80
  24986. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24987. to L1
  24988. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24989. to L1
  24990. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24991. to L1
  24992. At 03:29:11, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  24993. , ms_cmp_ret = 80
  24994. At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24995. to L1
  24996. At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  24997.  with no COMP BIT SET
  24998. At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  24999. to L1
  25000. At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25001. to L1
  25002. At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25003. to L1
  25004. At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  25005.  with no COMP BIT SET
  25006. At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  25007.  with no COMP BIT SET
  25008. At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd
  25009.  with no COMP BIT SET
  25010. At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25011. to L1
  25012. At 03:29:13, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25013. , ms_cmp_ret = 80
  25014. At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25015. to L1
  25016. At 03:29:13, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25017. , ms_cmp_ret = 80
  25018. At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25019. to L1
  25020. At 03:29:13, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25021. , ms_cmp_ret = 80
  25022. At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25023. to L1
  25024. At 03:29:13, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  25025. etected...
  25026. At 03:29:13, Facility "PPP", Level "COMMON"::                      M = 62, first
  25027.  END seq = 60
  25028. At 03:29:13, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6
  25029. 0, M = 62
  25030. At 03:29:13, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  25031. At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25032. to L1
  25033. At 03:29:14, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25034. , ms_cmp_ret = 80
  25035. At 03:29:14, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25036. to L1
  25037. At 03:29:14, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25038. , ms_cmp_ret = 80
  25039. At 03:29:14, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25040. to L1
  25041. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  25042. etected...
  25043. At 03:29:15, Facility "PPP", Level "COMMON"::                      M = 67, first
  25044.  END seq = 64
  25045. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6
  25046. 4, M = 67
  25047. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  25048. At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25049. to L1
  25050. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25051. , ms_cmp_ret = 80
  25052. At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25053. to L1
  25054. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  25055. etected...
  25056. At 03:29:15, Facility "PPP", Level "COMMON"::                      M = 6c, first
  25057.  END seq = 6a
  25058. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6
  25059. a, M = 6c
  25060. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  25061. At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25062. to L1
  25063. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  25064. etected...
  25065. At 03:29:15, Facility "PPP", Level "COMMON"::                      M = 70, first
  25066.  END seq = 6e
  25067. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6
  25068. e, M = 70
  25069. At 03:29:15, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25070. , ms_cmp_ret = 80
  25071. At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25072. to L1
  25073. At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25074. to L1
  25075. At 03:29:16, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25076. , ms_cmp_ret = 80
  25077. At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25078. to L1
  25079. At 03:29:16, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25080. , ms_cmp_ret = 80
  25081. At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25082. to L1
  25083. At 03:29:16, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS
  25084. , ms_cmp_ret = 80
  25085. At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25086. to L1
  25087. At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25088. to L1
  25089. At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25090. to L1
  25091. At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25092. to L1
  25093. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25094. to L1
  25095. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25096. to L1
  25097. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25098. to L1
  25099. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25100. to L1
  25101. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25102. to L1
  25103. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25104. to L1
  25105. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25106. to L1
  25107. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25108. to L1
  25109. At 03:29:17, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  25110. etected...
  25111. At 03:29:17, Facility "PPP", Level "COMMON"::                      M = 75, first
  25112.  END seq = 72
  25113. At 03:29:17, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 7
  25114. 2, M = 75
  25115. At 03:29:17, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  25116. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25117. to L1
  25118. At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25119. to L1
  25120. At 03:29:18, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame
  25121. to L1
  25122. At 03:29:18, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d
  25123. etected...
  25124. At 03:29:18, Facility "PPP", Level "COMMON"::                      M = 79, first
  25125.  END seq = 77
  25126. At 03:29:18, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 7
  25127. 7, M = 79
  25128. At 03:29:18, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)]
  25129.  
  25130. ------net924747216-ease15216------
  25131.  
  25132. -
  25133.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25134.  with "unsubscribe usr-tc" in the body of the message.
  25135.  For information on digests or retrieving files and old messages send
  25136.  "help" to the same address.  Do not use quotes in your message.
  25137.  
  25138.  
  25139. -------------------------------------------------------------------------------
  25140.  
  25141. From: Pete Ashdown <pashdown@xmission.com>
  25142. Subject: Re: (usr-tc) Accepting 2400bps modem connections on HDM
  25143. Date: 27 Apr 1999 11:41:17 -0600 (MDT)
  25144.  
  25145. Robert von Bismarck said once upon a time:
  25146. >
  25147. >Hi,
  25148. >
  25149. >What do I need to set up in an HDM to accept a pure 2400 bps (V.22bis)
  25150. >connection ?
  25151.  
  25152. You need to turn on 2400 bps in the "signal converter" section of the modem
  25153. settings via TCM.
  25154.  
  25155. -
  25156.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25157.  with "unsubscribe usr-tc" in the body of the message.
  25158.  For information on digests or retrieving files and old messages send
  25159.  "help" to the same address.  Do not use quotes in your message.
  25160.  
  25161.  
  25162. -------------------------------------------------------------------------------
  25163.  
  25164. From: Rick <rick@monmouth.com>
  25165. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  25166. Date: 20 Apr 1999 22:52:04 -0400
  25167.  
  25168. Krish, could you kindly add some well-deserved insight as to the
  25169. disable/disable topic regarding ppp offloading on the arc. I have been an
  25170. avid fan of yourself (without a doubt you devote more of your time and
  25171. effort then any other 3com employee) for the last few years and we have
  25172. experienced an increase in the amount ppp-negotiation failures in the last
  25173. month or two. We currently run 4.1.59-6 on the arc and 1.2.43 with the dsp
  25174. and your 3com literature expouses the use of 'enable ppp offloading' yet
  25175. the mailing list seems to suggest the opposite. I would appreciate any
  25176. thoughts yourself or Mike can add on this subject...
  25177.  
  25178. thanks
  25179.  
  25180. -
  25181.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25182.  with "unsubscribe usr-tc" in the body of the message.
  25183.  For information on digests or retrieving files and old messages send
  25184.  "help" to the same address.  Do not use quotes in your message.
  25185.  
  25186.  
  25187. -------------------------------------------------------------------------------
  25188.  
  25189. From: "Mike McHenry" <mmchen@minn.net>
  25190. Subject: (usr-tc) TC chassis not taking incoming calls on part of T1 span
  25191. Date: 19 Apr 1999 22:56:40 -0500
  25192.  
  25193.  
  25194. Hello all,
  25195.  
  25196. I have a problem that is driving me crazy and I am leaning towards hardware
  25197. failure. We have several TC chassis, each with one 386 T1 card, 12 Digital
  25198. Quad modem cards, 1 HiperArc card, 1 16 meg NMC card. Several weeks ago one
  25199. of the T1 cards starting acting up and would not accept incoming calls on
  25200. the SPAN 1. The card was sent to USR for repair and was not-so-promptly
  25201. returned to us with a note saying there was no problem found. There was also
  25202. a note saying that the card was reflashed to version 4.2.99 and that this
  25203. version was required for the card to function properly.
  25204.  
  25205. <RANT ON>
  25206. Now the first problem is 4.2.99 is not even available for download! 4.2.1 is
  25207. the latest code for the Channelized T1 card and has been stable for over a
  25208. year so I can't imagine why my card was reflashed to 4.2.99. This is not the
  25209. first faulty card that has been sent in for a RMA and sent back to me with a
  25210. note saying there was nothing wrong. My network of Total Control chassis is
  25211. falling apart and it is not even being repaired when I send it in!
  25212. <RANT OFF>
  25213.  
  25214. I have seen this problem three times, each time after an unplanned power
  25215. outage. About 20 modems on my chassis are not accepting any calls. The calls
  25216. are being routed in across the T1, I can verify this by swapping T1s. The
  25217. problem is definately NOT with the telco. The problem is also NOT with the
  25218. quad modems as I can swap modems back and forth and the same 20 positions in
  25219. the chassis will not take incoming calls. It is NOT a configuration issue
  25220. such as the common t1tdm setting or the answer packet bus only setting.
  25221.  
  25222. The Hiper ARC card is shown as the owner of all the cards in question when
  25223. doing a list chassis. The T1 channels are active and are not OOS. The packet
  25224. bus sessions appear to be up but I see no traffic on the affected channels,
  25225. see below for a partial copy of a list pbus sessions:
  25226.  
  25227. tc-2.minn.net> list pbus seSSIONS
  25228. Interface               Slot  Channel  Session  Rpkts   Spkts    PktSize
  25229. slot:2/mod:4              2       4       259     20575   18650   4096
  25230. slot:3/mod:1              3       1       512     62358   64852   4096
  25231. slot:3/mod:2              3       2       513     16674   14924   4096
  25232. slot:3/mod:3              3       3       514     0       0       4096
  25233. slot:3/mod:4              3       4       515     0       0       4096
  25234. slot:4/mod:1              4       1       768     0       0       4096
  25235. slot:4/mod:2              4       2       769     0       0       4096
  25236. slot:4/mod:3              4       3       770     0       0       4096
  25237. slot:4/mod:4              4       4       771     0       0       4096
  25238.  
  25239. I have tried power cycling the chassis, soft resets on the cards, hard
  25240. resets on the cards, reflashing all of the cards, reseating the cards,
  25241. checking the in house cabling, swapping cards with different chassis. In
  25242. every case the problem seems to follow the T1 card. All of the cards are
  25243. running the latest service patch code, 5.10.9 for the quads, 4.2.1 for the
  25244. T1 card, 4.1.59 for the Hiper ARC, 5.5.5 for the 16meg NMC. The settings on
  25245. the T1 card are correct, I have checked them about 30 times today and have
  25246. also reset them a few times to make sure the settings were taking correctly.
  25247.  
  25248. I have seen other people with very similar problems on this list, however I
  25249. have yet to find a solution in the archives. Am I overlooking something
  25250. here? I feel like I am bashing my head against a brick wall.
  25251.  
  25252. Of course I do NOT want to ship this card back to USR/3com and let them look
  25253. at it for another two weeks to tell me there is nothing wrong with it. I
  25254. tried to call today and explain that this card was sent in for repair and
  25255. was NOT repaired in the hopes that I could talk to an engineer to see why
  25256. the card was sent back when it still appears to be faulty. No go, I was not
  25257. allowed to talk to anyone as I do not have a service contract! Having a
  25258. chassis down for two weeks in unacceptable, having it down for another two
  25259. weeks because the problem wasn't fixed the first time is ludicrous!
  25260.  
  25261. At this point I am about ready to ship the whole damn chassis in for repair
  25262. and tell them the whole thing doesn't work! :) Either that or kick the thing
  25263. a few times. I am entirely unhappy with these pieces of equipment and their
  25264. reliability. I have probably spent 50-100 hours in the last year in dealing
  25265. with problems that should have never existed.
  25266.  
  25267. Any suggestions would be appreciated, sorry about the ranting :)
  25268.  
  25269. Mike McHenry
  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: Carl Litt <carl@execulink.com>
  25281. Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
  25282. Date: 27 Apr 1999 14:00:20 -0400 (EDT)
  25283.  
  25284.  
  25285. We had a problem with span 1 of a Dual-T1/PRI card last year.  When
  25286. I returned it for repair, it also came back with 4.2.99 and
  25287. a note that said "Reflashed with 4.2.99.  Must be used for Channellized
  25288. T1 operation".
  25289.  
  25290. I've mentioned this several times to 3Com tech support, but they
  25291. all think I'm stupid or something.
  25292.  
  25293. On Mon, 19 Apr 1999, Mike McHenry wrote:
  25294.  
  25295. > 
  25296. > Hello all,
  25297. > 
  25298. > I have a problem that is driving me crazy and I am leaning towards hardware
  25299. > failure. We have several TC chassis, each with one 386 T1 card, 12 Digital
  25300. > Quad modem cards, 1 HiperArc card, 1 16 meg NMC card. Several weeks ago one
  25301. > of the T1 cards starting acting up and would not accept incoming calls on
  25302. > the SPAN 1. The card was sent to USR for repair and was not-so-promptly
  25303. > returned to us with a note saying there was no problem found. There was also
  25304. > a note saying that the card was reflashed to version 4.2.99 and that this
  25305. > version was required for the card to function properly.
  25306. > 
  25307. > <RANT ON>
  25308. > Now the first problem is 4.2.99 is not even available for download! 4.2.1 is
  25309. > the latest code for the Channelized T1 card and has been stable for over a
  25310. > year so I can't imagine why my card was reflashed to 4.2.99. This is not the
  25311. > first faulty card that has been sent in for a RMA and sent back to me with a
  25312. > note saying there was nothing wrong. My network of Total Control chassis is
  25313. > falling apart and it is not even being repaired when I send it in!
  25314. > <RANT OFF>
  25315. > 
  25316. > I have seen this problem three times, each time after an unplanned power
  25317. > outage. About 20 modems on my chassis are not accepting any calls. The calls
  25318. > are being routed in across the T1, I can verify this by swapping T1s. The
  25319. > problem is definately NOT with the telco. The problem is also NOT with the
  25320. > quad modems as I can swap modems back and forth and the same 20 positions in
  25321. > the chassis will not take incoming calls. It is NOT a configuration issue
  25322. > such as the common t1tdm setting or the answer packet bus only setting.
  25323. > 
  25324. > The Hiper ARC card is shown as the owner of all the cards in question when
  25325. > doing a list chassis. The T1 channels are active and are not OOS. The packet
  25326. > bus sessions appear to be up but I see no traffic on the affected channels,
  25327. > see below for a partial copy of a list pbus sessions:
  25328. > 
  25329. > tc-2.minn.net> list pbus seSSIONS
  25330. > Interface               Slot  Channel  Session  Rpkts   Spkts    PktSize
  25331. > slot:2/mod:4              2       4       259     20575   18650   4096
  25332. > slot:3/mod:1              3       1       512     62358   64852   4096
  25333. > slot:3/mod:2              3       2       513     16674   14924   4096
  25334. > slot:3/mod:3              3       3       514     0       0       4096
  25335. > slot:3/mod:4              3       4       515     0       0       4096
  25336. > slot:4/mod:1              4       1       768     0       0       4096
  25337. > slot:4/mod:2              4       2       769     0       0       4096
  25338. > slot:4/mod:3              4       3       770     0       0       4096
  25339. > slot:4/mod:4              4       4       771     0       0       4096
  25340. > 
  25341. > I have tried power cycling the chassis, soft resets on the cards, hard
  25342. > resets on the cards, reflashing all of the cards, reseating the cards,
  25343. > checking the in house cabling, swapping cards with different chassis. In
  25344. > every case the problem seems to follow the T1 card. All of the cards are
  25345. > running the latest service patch code, 5.10.9 for the quads, 4.2.1 for the
  25346. > T1 card, 4.1.59 for the Hiper ARC, 5.5.5 for the 16meg NMC. The settings on
  25347. > the T1 card are correct, I have checked them about 30 times today and have
  25348. > also reset them a few times to make sure the settings were taking correctly.
  25349. > 
  25350. > I have seen other people with very similar problems on this list, however I
  25351. > have yet to find a solution in the archives. Am I overlooking something
  25352. > here? I feel like I am bashing my head against a brick wall.
  25353. > 
  25354. > Of course I do NOT want to ship this card back to USR/3com and let them look
  25355. > at it for another two weeks to tell me there is nothing wrong with it. I
  25356. > tried to call today and explain that this card was sent in for repair and
  25357. > was NOT repaired in the hopes that I could talk to an engineer to see why
  25358. > the card was sent back when it still appears to be faulty. No go, I was not
  25359. > allowed to talk to anyone as I do not have a service contract! Having a
  25360. > chassis down for two weeks in unacceptable, having it down for another two
  25361. > weeks because the problem wasn't fixed the first time is ludicrous!
  25362. > 
  25363. > At this point I am about ready to ship the whole damn chassis in for repair
  25364. > and tell them the whole thing doesn't work! :) Either that or kick the thing
  25365. > a few times. I am entirely unhappy with these pieces of equipment and their
  25366. > reliability. I have probably spent 50-100 hours in the last year in dealing
  25367. > with problems that should have never existed.
  25368. > 
  25369. > Any suggestions would be appreciated, sorry about the ranting :)
  25370. > 
  25371. > Mike McHenry
  25372. > 
  25373. > -
  25374. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25375. >  with "unsubscribe usr-tc" in the body of the message.
  25376. >  For information on digests or retrieving files and old messages send
  25377. >  "help" to the same address.  Do not use quotes in your message.
  25378. > 
  25379. > 
  25380.  
  25381.  
  25382. -
  25383.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25384.  with "unsubscribe usr-tc" in the body of the message.
  25385.  For information on digests or retrieving files and old messages send
  25386.  "help" to the same address.  Do not use quotes in your message.
  25387.  
  25388.  
  25389. -------------------------------------------------------------------------------
  25390.  
  25391. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  25392. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  25393. Date: 27 Apr 1999 13:32:41 -0500 (CDT)
  25394.  
  25395. On Tue, 20 Apr 1999, Rick wrote:
  25396.  
  25397. > Krish, could you kindly add some well-deserved insight as to the
  25398. > disable/disable topic regarding ppp offloading on the arc. I have been an
  25399. > avid fan of yourself (without a doubt you devote more of your time and
  25400. > effort then any other 3com employee) for the last few years and we have
  25401. > experienced an increase in the amount ppp-negotiation failures in the last
  25402. > month or two. We currently run 4.1.59-6 on the arc and 1.2.43 with the dsp
  25403. > and your 3com literature expouses the use of 'enable ppp offloading' yet
  25404. > the mailing list seems to suggest the opposite. I would appreciate any
  25405. > thoughts yourself or Mike can add on this subject...
  25406.  
  25407. 4.1.59 -6 is the hiper arc has lots of bug fixes and features.  1.2.43 
  25408. DSP code also has the similar packet bus fixes to operate with the ARC.  
  25409. In our testing here 1.2.43 (1.2.59 also has this ) had a problem with 
  25410. ISDN calls.  If ppp offloading was disabled then the DSP would present 
  25411. the call to the ARC as a analog call - not exactly like analog but would 
  25412. send async map information to the call.  Thus when the ISDN sync call has 
  25413. async map info - ISDN calls would not go through.
  25414.  
  25415. So in the release notes we had specified users to have the PPP offloading 
  25416. enabled to resolve the problem.  Also when PPP offloading is enabled - 
  25417. the DSP takes care of the PPP framing - Meaning the DSP would receive the 
  25418. PPP packet and strip the PPP header and present the data to the ARC. This 
  25419. is done in the hardware level thus its fast and takes care of the ppp 
  25420. framing over head on the ARC. 
  25421.  
  25422. When you disable ppp offloading - the ppp framing is done by the hiper 
  25423. arc at a software layer.  The net effect of ppp offloading enabled is 
  25424. that the users throughput is slightly higher.  On a fully loaded chassis 
  25425. with 14 DSP and calls on all the DSP cards the throughput with PPP 
  25426. offloading is better.
  25427.  
  25428. Now we received information from customers regarding users password 
  25429. getting corrupted.  Some of you had radius logs which showed that the 
  25430. users password was getting corrupted.
  25431.  
  25432. The users password from the showed that the last charecter of the 
  25433. password had some some control charecters like ]}#  etc.  This particular 
  25434. problem is not consistant and cannot be reproduced on demand.  Its random 
  25435. and there is really no co-relation between the users-modems and 
  25436. connection type.  
  25437.  
  25438. There is a case when the DSP is actually corrupting the packet and 
  25439. sending it to the hiper arc which is forwarded to the ARC to the Radius 
  25440. server.  Disabling ppp offloading on the ARC ( which means that the arc 
  25441. has to do the ppp framing ) does resolve the problem.
  25442.  
  25443.  
  25444. So there is a know issue with the DSP corrupting random packets -
  25445.  
  25446. Also by disabling ppp offloading ISDN calls may be affected.
  25447. DSP now has a ER code that fixes the ISDN problem - when ppp offloading 
  25448. is disabled.  However we are still debugging the problem with user 
  25449. password corruption.
  25450.  
  25451. This is is the issue.  
  25452.  
  25453. regards
  25454.  
  25455. krish
  25456.  
  25457.  
  25458. > 
  25459. > thanks
  25460. > 
  25461. > -
  25462. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25463. >  with "unsubscribe usr-tc" in the body of the message.
  25464. >  For information on digests or retrieving files and old messages send
  25465. >  "help" to the same address.  Do not use quotes in your message.
  25466. > 
  25467.  
  25468. -
  25469.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25470.  with "unsubscribe usr-tc" in the body of the message.
  25471.  For information on digests or retrieving files and old messages send
  25472.  "help" to the same address.  Do not use quotes in your message.
  25473.  
  25474.  
  25475. -------------------------------------------------------------------------------
  25476.  
  25477. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  25478. Subject: Re: (usr-tc) ISDN call debug
  25479. Date: 27 Apr 1999 13:35:09 -0500 (CDT)
  25480.  
  25481.  
  25482. On 22 Apr 1999 huix@990.net wrote:
  25483.  
  25484. > Hi,=20
  25485. > 
  25486. > I monitor PPP call use ppp ficility,
  25487. > 
  25488. > set ficility ppp loglevel verbose
  25489. > 
  25490. > I get call information and find ISDN
  25491. > canot build MP during LCP phase,
  25492. > who can tell me it is which end canot
  25493. > accept MP option?
  25494.  
  25495. Send a mon ppp trace - that is easy to debug.
  25496.  
  25497. krish
  25498.  
  25499.  
  25500. > 
  25501. > 
  25502. > 
  25503. > 
  25504. > __________________________________________________
  25505. > =BB=B6=D3=AD=CA=B9=D3=C3=BD=F0=C1=EA=C8=C8=CF=DF=C3=E2=B7=D1=B5=E7=D7=D3=D3=
  25506. > =CA=BC=FE=CF=B5=CD=B3http://www.990.net
  25507.  
  25508. -
  25509.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25510.  with "unsubscribe usr-tc" in the body of the message.
  25511.  For information on digests or retrieving files and old messages send
  25512.  "help" to the same address.  Do not use quotes in your message.
  25513.  
  25514.  
  25515. -------------------------------------------------------------------------------
  25516.  
  25517. From: Rommel Wladimir de Lima <rommel@server2.eol.com.br>
  25518. Subject: RE: (usr-tc) Filters...
  25519. Date: 27 Apr 1999 15:43:21 -0300 (EST)
  25520.  
  25521.  
  25522.  
  25523. On Tue, 27 Apr 1999, Mike Wronski wrote:
  25524.  
  25525. Thank you for your message.
  25526.  
  25527. > |
  25528. > |    1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)?
  25529. > |
  25530. >         We've tried IP and IP-CALL and nothing worked
  25531. > IP:
  25532. > 
  25533. > |    I did all the "cake receipt" to set up the filter in the tc, but
  25534. > |it didn't work.
  25535. > |    1) add TFTP client <client IP>
  25536. > |    2) tfpt <tc IP>
  25537. > |    3) add filter <filter>
  25538. > |    4) verify filter <filter>
  25539. > |    5) set interface <slot:x/mod[1-30] input_filter|output_filter
  25540. > |<filter> filter_access on
  25541. > |
  25542. > 
  25543. > It is possible your filter was applied, and was syntactically correct, but it
  25544. > didnt block anything.
  25545. > 
  25546. > What was your exact filter?
  25547.  
  25548. #filter
  25549. IP:
  25550. 010 REJECT tcp-dst-port=12345;
  25551. 020 REJECT tcp-dst-port=12346;
  25552. 030 REJECT tcp-dst-port=31337;
  25553. ...
  25554.  
  25555.     What I've done is basicly:
  25556.     - deny netbus attack;
  25557.     - deny BO attack;
  25558.     - deny IP spoofing;
  25559.      
  25560. Is it anything missing?
  25561.  
  25562. Greetings
  25563.  
  25564.  
  25565.  
  25566. -
  25567.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25568.  with "unsubscribe usr-tc" in the body of the message.
  25569.  For information on digests or retrieving files and old messages send
  25570.  "help" to the same address.  Do not use quotes in your message.
  25571.  
  25572.  
  25573. -------------------------------------------------------------------------------
  25574.  
  25575. From: Eric Forcey <eric@psnw.com>
  25576. Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
  25577. Date: 27 Apr 1999 11:31:33 -0700 (PDT)
  25578.  
  25579.  
  25580. Same thing happened to us, and I think that is why 4.2.99 was 
  25581. written.
  25582.  
  25583. I worked with support for well over 6 months on why the card was not 
  25584. accepting calls, or if it did it would only accept 1 or 2 calls then 
  25585. report busies.
  25586.  
  25587. It was finally escalated to engineering to look at and at that time they 
  25588. wrote the 4.2.99.
  25589.  
  25590. There is a way around flashing it to 4.2.99, as the problem is dealing 
  25591. with Jitter Attenuation. (this again is per the engineer that I dealt with).
  25592.  
  25593. He was able to get the card working fine with existing code by changing 
  25594. the Jitter from TX to Recvr, saving the settings, resetting, then 
  25595. changing it back. I wasn't about to do that on a continual basis.
  25596.  
  25597. After looking at the card again as I was writing this, are you positive 
  25598. on the numbering? I'm showing 4.3.99 is what was given to me and since 
  25599. that has happened (well over a year ago now) the card has performed 
  25600. without troubles.
  25601.  
  25602. -Eric
  25603.  
  25604.  
  25605.  
  25606. On Tue, 27 Apr 1999, Carl Litt wrote:
  25607.  
  25608. > 
  25609. > We had a problem with span 1 of a Dual-T1/PRI card last year.  When
  25610. > I returned it for repair, it also came back with 4.2.99 and
  25611. > a note that said "Reflashed with 4.2.99.  Must be used for Channellized
  25612. > T1 operation".
  25613. > 
  25614. > I've mentioned this several times to 3Com tech support, but they
  25615. > all think I'm stupid or something.
  25616. > 
  25617. > On Mon, 19 Apr 1999, Mike McHenry wrote:
  25618. > 
  25619. > > 
  25620. > > Hello all,
  25621. > > 
  25622. > > I have a problem that is driving me crazy and I am leaning towards hardware
  25623. > > failure. We have several TC chassis, each with one 386 T1 card, 12 Digital
  25624. > > Quad modem cards, 1 HiperArc card, 1 16 meg NMC card. Several weeks ago one
  25625. > > of the T1 cards starting acting up and would not accept incoming calls on
  25626. > > the SPAN 1. The card was sent to USR for repair and was not-so-promptly
  25627. > > returned to us with a note saying there was no problem found. There was also
  25628. > > a note saying that the card was reflashed to version 4.2.99 and that this
  25629. > > version was required for the card to function properly.
  25630. > > 
  25631. > > <RANT ON>
  25632. > > Now the first problem is 4.2.99 is not even available for download! 4.2.1 is
  25633. > > the latest code for the Channelized T1 card and has been stable for over a
  25634. > > year so I can't imagine why my card was reflashed to 4.2.99. This is not the
  25635. > > first faulty card that has been sent in for a RMA and sent back to me with a
  25636. > > note saying there was nothing wrong. My network of Total Control chassis is
  25637. > > falling apart and it is not even being repaired when I send it in!
  25638. > > <RANT OFF>
  25639. > > 
  25640. > > I have seen this problem three times, each time after an unplanned power
  25641. > > outage. About 20 modems on my chassis are not accepting any calls. The calls
  25642. > > are being routed in across the T1, I can verify this by swapping T1s. The
  25643. > > problem is definately NOT with the telco. The problem is also NOT with the
  25644. > > quad modems as I can swap modems back and forth and the same 20 positions in
  25645. > > the chassis will not take incoming calls. It is NOT a configuration issue
  25646. > > such as the common t1tdm setting or the answer packet bus only setting.
  25647. > > 
  25648. > > The Hiper ARC card is shown as the owner of all the cards in question when
  25649. > > doing a list chassis. The T1 channels are active and are not OOS. The packet
  25650. > > bus sessions appear to be up but I see no traffic on the affected channels,
  25651. > > see below for a partial copy of a list pbus sessions:
  25652. > > 
  25653. > > tc-2.minn.net> list pbus seSSIONS
  25654. > > Interface               Slot  Channel  Session  Rpkts   Spkts    PktSize
  25655. > > slot:2/mod:4              2       4       259     20575   18650   4096
  25656. > > slot:3/mod:1              3       1       512     62358   64852   4096
  25657. > > slot:3/mod:2              3       2       513     16674   14924   4096
  25658. > > slot:3/mod:3              3       3       514     0       0       4096
  25659. > > slot:3/mod:4              3       4       515     0       0       4096
  25660. > > slot:4/mod:1              4       1       768     0       0       4096
  25661. > > slot:4/mod:2              4       2       769     0       0       4096
  25662. > > slot:4/mod:3              4       3       770     0       0       4096
  25663. > > slot:4/mod:4              4       4       771     0       0       4096
  25664. > > 
  25665. > > I have tried power cycling the chassis, soft resets on the cards, hard
  25666. > > resets on the cards, reflashing all of the cards, reseating the cards,
  25667. > > checking the in house cabling, swapping cards with different chassis. In
  25668. > > every case the problem seems to follow the T1 card. All of the cards are
  25669. > > running the latest service patch code, 5.10.9 for the quads, 4.2.1 for the
  25670. > > T1 card, 4.1.59 for the Hiper ARC, 5.5.5 for the 16meg NMC. The settings on
  25671. > > the T1 card are correct, I have checked them about 30 times today and have
  25672. > > also reset them a few times to make sure the settings were taking correctly.
  25673. > > 
  25674. > > I have seen other people with very similar problems on this list, however I
  25675. > > have yet to find a solution in the archives. Am I overlooking something
  25676. > > here? I feel like I am bashing my head against a brick wall.
  25677. > > 
  25678. > > Of course I do NOT want to ship this card back to USR/3com and let them look
  25679. > > at it for another two weeks to tell me there is nothing wrong with it. I
  25680. > > tried to call today and explain that this card was sent in for repair and
  25681. > > was NOT repaired in the hopes that I could talk to an engineer to see why
  25682. > > the card was sent back when it still appears to be faulty. No go, I was not
  25683. > > allowed to talk to anyone as I do not have a service contract! Having a
  25684. > > chassis down for two weeks in unacceptable, having it down for another two
  25685. > > weeks because the problem wasn't fixed the first time is ludicrous!
  25686. > > 
  25687. > > At this point I am about ready to ship the whole damn chassis in for repair
  25688. > > and tell them the whole thing doesn't work! :) Either that or kick the thing
  25689. > > a few times. I am entirely unhappy with these pieces of equipment and their
  25690. > > reliability. I have probably spent 50-100 hours in the last year in dealing
  25691. > > with problems that should have never existed.
  25692. > > 
  25693. > > Any suggestions would be appreciated, sorry about the ranting :)
  25694. > > 
  25695. > > Mike McHenry
  25696. > > 
  25697. > > -
  25698. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25699. > >  with "unsubscribe usr-tc" in the body of the message.
  25700. > >  For information on digests or retrieving files and old messages send
  25701. > >  "help" to the same address.  Do not use quotes in your message.
  25702. > > 
  25703. > > 
  25704. > 
  25705. > 
  25706. > -
  25707. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25708. >  with "unsubscribe usr-tc" in the body of the message.
  25709. >  For information on digests or retrieving files and old messages send
  25710. >  "help" to the same address.  Do not use quotes in your message.
  25711. > 
  25712.  
  25713. -
  25714.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25715.  with "unsubscribe usr-tc" in the body of the message.
  25716.  For information on digests or retrieving files and old messages send
  25717.  "help" to the same address.  Do not use quotes in your message.
  25718.  
  25719.  
  25720. -------------------------------------------------------------------------------
  25721.  
  25722. From: Scott Trautman <scottt@corp.gdinet.com>
  25723. Subject: RE: (usr-tc) Connecting to an NT Domain via TCHub
  25724. Date: 27 Apr 1999 13:41:37 -0500
  25725.  
  25726. Need to have "Log onto network" checked in DUN.....
  25727.  
  25728. -
  25729.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25730.  with "unsubscribe usr-tc" in the body of the message.
  25731.  For information on digests or retrieving files and old messages send
  25732.  "help" to the same address.  Do not use quotes in your message.
  25733.  
  25734.  
  25735. -------------------------------------------------------------------------------
  25736.  
  25737. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  25738. Subject: RE: (usr-tc) Filters...
  25739. Date: 27 Apr 1999 13:44:39 -0500
  25740.  
  25741.  
  25742.  
  25743. |-----Original Message-----
  25744. |From: owner-usr-tc@lists.xmission.com
  25745. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rommel Wladimir de
  25746. |Lima
  25747. |Sent: Tuesday, April 27, 1999 1:43 PM
  25748. |To: usr-tc@lists.xmission.com
  25749. |Subject: RE: (usr-tc) Filters...
  25750. |
  25751. |
  25752. |
  25753. |
  25754. |On Tue, 27 Apr 1999, Mike Wronski wrote:
  25755. |
  25756. |Thank you for your message.
  25757. |
  25758. |> |
  25759. |> |    1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)?
  25760. |> |
  25761. |>         We've tried IP and IP-CALL and nothing worked
  25762. |> IP:
  25763. |>
  25764. |> |    I did all the "cake receipt" to set up the filter in the tc, but
  25765. |> |it didn't work.
  25766. |> |    1) add TFTP client <client IP>
  25767. |> |    2) tfpt <tc IP>
  25768. |> |    3) add filter <filter>
  25769. |> |    4) verify filter <filter>
  25770. |> |    5) set interface <slot:x/mod[1-30] input_filter|output_filter
  25771. |> |<filter> filter_access on
  25772. |> |
  25773. |>
  25774. |> It is possible your filter was applied, and was syntactically correct, but it
  25775. |> didnt block anything.
  25776. |>
  25777. |> What was your exact filter?
  25778. |
  25779. |#filter
  25780. |IP:
  25781. |010 REJECT tcp-dst-port=12345;
  25782. |020 REJECT tcp-dst-port=12346;
  25783. |030 REJECT tcp-dst-port=31337;
  25784. |...
  25785. |
  25786.  
  25787. The above is fine as an input filter.. Those tcp ports will be blocked. When you
  25788. look at the individual interfaces with "sh interface slot:x/mod:y" do you see the
  25789. filter name applied as an input filter? Also what version of HARC code are you
  25790. using?
  25791.  
  25792. BTW: BO can use any port.. Your not safe by blocking the default ports.
  25793.  
  25794. -M
  25795.  
  25796.  
  25797. -
  25798.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25799.  with "unsubscribe usr-tc" in the body of the message.
  25800.  For information on digests or retrieving files and old messages send
  25801.  "help" to the same address.  Do not use quotes in your message.
  25802.  
  25803.  
  25804. -------------------------------------------------------------------------------
  25805.  
  25806. From: Scott Trautman <scottt@corp.gdinet.com>
  25807. Subject: RE: (usr-tc) required power supply
  25808. Date: 27 Apr 1999 13:46:15 -0500
  25809.  
  25810. Another possibility (please check this out before taking this advice) is
  25811. putting another 70 in there.
  25812. You lose redundancy, but gain the extra horsepower....
  25813.  
  25814. SMT
  25815.  
  25816. > -----Original Message-----
  25817. > From: Scott Boggs [mailto:sboggs@unitedbank.net]
  25818. > Sent: Tuesday, April 27, 1999 7:20 AM
  25819. > To: USR-TC Mail list
  25820. > Subject: (usr-tc) required power supply
  25821. > 
  25822. > 
  25823. > I have a chassis with 1 NMC, 1 ARC, 8 DSPs
  25824. > I am about to add another ARC and 2 more DSPs.
  25825. > I have a 70 amp AC power supply,  a 3com tech told me
  25826. > I would need to go to the 130 amp supply in order to 
  25827. > add these cards and others down the road.
  25828. > Anyone else had this type of problem?
  25829. > If so, can I just pull the existing 70a and put a 130a in place?
  25830. > Thanks,
  25831. > Scott Boggs
  25832. > United Bank - AccessUnited Internet
  25833. > 
  25834. > 
  25835. > 
  25836. > -
  25837. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25838. >  with "unsubscribe usr-tc" in the body of the message.
  25839. >  For information on digests or retrieving files and old messages send
  25840. >  "help" to the same address.  Do not use quotes in your message.
  25841. > 
  25842.  
  25843. -
  25844.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25845.  with "unsubscribe usr-tc" in the body of the message.
  25846.  For information on digests or retrieving files and old messages send
  25847.  "help" to the same address.  Do not use quotes in your message.
  25848.  
  25849.  
  25850. -------------------------------------------------------------------------------
  25851.  
  25852. From: David Bolen <db3l@ans.net>
  25853. Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
  25854. Date: 27 Apr 1999 14:48:28 EDT
  25855.  
  25856. Eric Forcey <eric@psnw.com> writes:
  25857.  
  25858. > There is a way around flashing it to 4.2.99, as the problem is dealing 
  25859. > with Jitter Attenuation. (this again is per the engineer that I dealt with).
  25860. > 
  25861. > He was able to get the card working fine with existing code by changing 
  25862. > the Jitter from TX to Recvr, saving the settings, resetting, then 
  25863. > changing it back. I wasn't about to do that on a continual basis.
  25864.  
  25865. Yes, there was a problem in this regard in the 4.2.x series that
  25866. toggling the jitter attenuation could correct.  The card would
  25867. incorrectly latch AB bit patterns during a bootup (and or fall into
  25868. that mode) which would affect its ability to process calls.
  25869.  
  25870. The jitter attenuation toggling is just a workaround in that it gives
  25871. the AB bits as perceived by the card a "kick", but the underlying
  25872. problem isn't with the jitter attenuation itself. 
  25873.  
  25874. > After looking at the card again as I was writing this, are you positive 
  25875. > on the numbering? I'm showing 4.3.99 is what was given to me and since 
  25876. > that has happened (well over a year ago now) the card has performed 
  25877. > without troubles.
  25878.  
  25879. I'm not sure about 4.3.99 but 4.2.99 was originally built for us back
  25880. in 3/98 in response to this problem during TCS 3.1 testing (among
  25881. other items) off of a 4.2.1 base, and it did address this sort of
  25882. problem.  Hope they didn't reintroduce the problem in the 4.3.x series
  25883. :-) 
  25884.  
  25885. -- David
  25886.  
  25887. /-----------------------------------------------------------------------\
  25888.  \               David Bolen              \  Internet: db3l@ans.net    /
  25889.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  25890.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  25891. \-----------------------------------------------------------------------/
  25892.  
  25893. -
  25894.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25895.  with "unsubscribe usr-tc" in the body of the message.
  25896.  For information on digests or retrieving files and old messages send
  25897.  "help" to the same address.  Do not use quotes in your message.
  25898.  
  25899.  
  25900. -------------------------------------------------------------------------------
  25901.  
  25902. From: "Jason W." <jwatkins@iland.net>
  25903. Subject: (usr-tc) Dedicated Dial-Up
  25904. Date: 27 Apr 1999 16:45:58 -0500
  25905.  
  25906. We have 2 dedicated dial-up customers that
  25907. I'm having problems setting up properly.
  25908. We are using a USRTC, Quad modem cards,
  25909. and HiPer ARC.  I'm having their IP addresses
  25910. assigned to them via Radius, and 2 channels
  25911. of that CT1 are pulled out of the hunt and
  25912. have their own phone number.  The problem is
  25913. this.  I have an IP address pool set to use
  25914. 46 IP addresses, with a range of 123.123.123.1-
  25915. 123.123.123.46 The static IP addresses our
  25916. dedicated customers get are .47 and .48  With
  25917. this configuration since the interfaces they
  25918. connect to are in the modem_group all, the
  25919. USRTC thinks that when our dedicated customer
  25920. dials in that it uses 2 addresses from that IP
  25921. pool.  When that chassis is full users are
  25922. unable to connect to two ports because it already
  25923. thinks two addresses are being used..... confusing
  25924. eh??
  25925.  
  25926. So my question is this, could I delete
  25927. then re-create the modem_group all -those two
  25928. interfaces, and assign those two interfaces
  25929. their own IP address pool size (2), and create
  25930. their own modem_group?  Or am I making this 
  25931. WAY too hard on myself??? 
  25932.  
  25933. TIA
  25934. \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  25935. Jason Watkins, jwatkins@iland.net
  25936. I-Land NOC Technician
  25937. http://www.iland.net
  25938. \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  25939.  
  25940.  
  25941.  
  25942. -
  25943.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25944.  with "unsubscribe usr-tc" in the body of the message.
  25945.  For information on digests or retrieving files and old messages send
  25946.  "help" to the same address.  Do not use quotes in your message.
  25947.  
  25948.  
  25949. -------------------------------------------------------------------------------
  25950.  
  25951. From: Scott Trautman <scottt@corp.gdinet.com>
  25952. Subject: RE: (usr-tc) Dedicated Dial-Up
  25953. Date: 27 Apr 1999 17:00:42 -0500
  25954.  
  25955. Way too hard. Assign them static addresses in Radius completely out of your
  25956. pool.
  25957. Pool is for random assignment only. You'll only give yourself grief trying
  25958. to pick the pool.
  25959.  
  25960. SMT
  25961.  
  25962. > -----Original Message-----
  25963. > From: Jason W. [mailto:jwatkins@iland.net]
  25964. > Sent: Tuesday, April 27, 1999 4:46 PM
  25965. > To: usr-tc@lists.xmission.com
  25966. > Subject: (usr-tc) Dedicated Dial-Up
  25967. > 
  25968. > 
  25969. > We have 2 dedicated dial-up customers that
  25970. > I'm having problems setting up properly.
  25971. > We are using a USRTC, Quad modem cards,
  25972. > and HiPer ARC.  I'm having their IP addresses
  25973. > assigned to them via Radius, and 2 channels
  25974. > of that CT1 are pulled out of the hunt and
  25975. > have their own phone number.  The problem is
  25976. > this.  I have an IP address pool set to use
  25977. > 46 IP addresses, with a range of 123.123.123.1-
  25978. > 123.123.123.46 The static IP addresses our
  25979. > dedicated customers get are .47 and .48  With
  25980. > this configuration since the interfaces they
  25981. > connect to are in the modem_group all, the
  25982. > USRTC thinks that when our dedicated customer
  25983. > dials in that it uses 2 addresses from that IP
  25984. > pool.  When that chassis is full users are
  25985. > unable to connect to two ports because it already
  25986. > thinks two addresses are being used..... confusing
  25987. > eh??
  25988. > 
  25989. > So my question is this, could I delete
  25990. > then re-create the modem_group all -those two
  25991. > interfaces, and assign those two interfaces
  25992. > their own IP address pool size (2), and create
  25993. > their own modem_group?  Or am I making this 
  25994. > WAY too hard on myself??? 
  25995. > 
  25996. > TIA
  25997. > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  25998. > Jason Watkins, jwatkins@iland.net
  25999. > I-Land NOC Technician
  26000. > http://www.iland.net
  26001. > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26002. > 
  26003. > 
  26004. > 
  26005. > -
  26006. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26007. >  with "unsubscribe usr-tc" in the body of the message.
  26008. >  For information on digests or retrieving files and old messages send
  26009. >  "help" to the same address.  Do not use quotes in your message.
  26010. > 
  26011.  
  26012. -
  26013.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26014.  with "unsubscribe usr-tc" in the body of the message.
  26015.  For information on digests or retrieving files and old messages send
  26016.  "help" to the same address.  Do not use quotes in your message.
  26017.  
  26018.  
  26019. -------------------------------------------------------------------------------
  26020.  
  26021. From: "Jason W." <jwatkins@iland.net>
  26022. Subject: Re: (usr-tc) Dedicated Dial-Up
  26023. Date: 27 Apr 1999 17:27:30 -0500
  26024.  
  26025. I'm actually assigning their IP addresses via
  26026. Radius now.  What happens is that even though
  26027. I have the PI address set to 46 addresses,
  26028. when the dedicated customer dials in they
  26029. are basically a "default" user which is using
  26030. the "modem_group all" So the PI pool thinks
  26031. that the dedicated user is using a proper
  26032. IP address and increments the number of
  26033. addresses used by 2.  So if our USRTC is
  26034. almost full and 2 users try to dial into
  26035. the last available ports they cannot because
  26036. the PI pool thinks it has no more addresses
  26037. to assign...  Shouldn't the ARC be intuitive
  26038. enough to know that those addresses are
  26039. not part of the pool and thus not increment
  26040. the size of the used IP pool???
  26041.  
  26042.  
  26043. \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26044. Jason Watkins, jwatkins@iland.net
  26045. I-Land NOC Technician
  26046. http://www.iland.net
  26047. \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26048.  
  26049. ----- Original Message -----
  26050. Sent: Tuesday, April 27, 1999 5:00 PM
  26051.  
  26052.  
  26053. > Way too hard. Assign them static addresses in Radius completely out of
  26054. your
  26055. > pool.
  26056. > Pool is for random assignment only. You'll only give yourself grief trying
  26057. > to pick the pool.
  26058. >
  26059. > SMT
  26060. >
  26061. > > -----Original Message-----
  26062. > > From: Jason W. [mailto:jwatkins@iland.net]
  26063. > > Sent: Tuesday, April 27, 1999 4:46 PM
  26064. > > To: usr-tc@lists.xmission.com
  26065. > > Subject: (usr-tc) Dedicated Dial-Up
  26066. > >
  26067. > >
  26068. > > We have 2 dedicated dial-up customers that
  26069. > > I'm having problems setting up properly.
  26070. > > We are using a USRTC, Quad modem cards,
  26071. > > and HiPer ARC.  I'm having their IP addresses
  26072. > > assigned to them via Radius, and 2 channels
  26073. > > of that CT1 are pulled out of the hunt and
  26074. > > have their own phone number.  The problem is
  26075. > > this.  I have an IP address pool set to use
  26076. > > 46 IP addresses, with a range of 123.123.123.1-
  26077. > > 123.123.123.46 The static IP addresses our
  26078. > > dedicated customers get are .47 and .48  With
  26079. > > this configuration since the interfaces they
  26080. > > connect to are in the modem_group all, the
  26081. > > USRTC thinks that when our dedicated customer
  26082. > > dials in that it uses 2 addresses from that IP
  26083. > > pool.  When that chassis is full users are
  26084. > > unable to connect to two ports because it already
  26085. > > thinks two addresses are being used..... confusing
  26086. > > eh??
  26087. > >
  26088. > > So my question is this, could I delete
  26089. > > then re-create the modem_group all -those two
  26090. > > interfaces, and assign those two interfaces
  26091. > > their own IP address pool size (2), and create
  26092. > > their own modem_group?  Or am I making this
  26093. > > WAY too hard on myself???
  26094. > >
  26095. > > TIA
  26096. > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26097. > > Jason Watkins, jwatkins@iland.net
  26098. > > I-Land NOC Technician
  26099. > > http://www.iland.net
  26100. > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26101. > >
  26102. > >
  26103. > >
  26104. > > -
  26105. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26106. > >  with "unsubscribe usr-tc" in the body of the message.
  26107. > >  For information on digests or retrieving files and old messages send
  26108. > >  "help" to the same address.  Do not use quotes in your message.
  26109. > >
  26110. >
  26111. > -
  26112. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26113. >  with "unsubscribe usr-tc" in the body of the message.
  26114. >  For information on digests or retrieving files and old messages send
  26115. >  "help" to the same address.  Do not use quotes in your message.
  26116. >
  26117.  
  26118.  
  26119. -
  26120.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26121.  with "unsubscribe usr-tc" in the body of the message.
  26122.  For information on digests or retrieving files and old messages send
  26123.  "help" to the same address.  Do not use quotes in your message.
  26124.  
  26125.  
  26126. -------------------------------------------------------------------------------
  26127.  
  26128. From: "Jason W." <jwatkins@iland.net>
  26129. Subject: Re: (usr-tc) Dedicated Dial-Up
  26130. Date: 27 Apr 1999 17:38:42 -0500
  26131.  
  26132. Umm...Sorry about the PI instead of IP
  26133. stupid spell checker...
  26134.  
  26135.  
  26136. \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26137. Jason Watkins, jwatkins@iland.net
  26138. I-Land NOC Technician
  26139. http://www.iland.net
  26140. \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26141.  
  26142. ----- Original Message -----
  26143. Sent: Tuesday, April 27, 1999 5:27 PM
  26144.  
  26145.  
  26146. > I'm actually assigning their IP addresses via
  26147. > Radius now.  What happens is that even though
  26148. > I have the PI address set to 46 addresses,
  26149. > when the dedicated customer dials in they
  26150. > are basically a "default" user which is using
  26151. > the "modem_group all" So the PI pool thinks
  26152. > that the dedicated user is using a proper
  26153. > IP address and increments the number of
  26154. > addresses used by 2.  So if our USRTC is
  26155. > almost full and 2 users try to dial into
  26156. > the last available ports they cannot because
  26157. > the PI pool thinks it has no more addresses
  26158. > to assign...  Shouldn't the ARC be intuitive
  26159. > enough to know that those addresses are
  26160. > not part of the pool and thus not increment
  26161. > the size of the used IP pool???
  26162. >
  26163. >
  26164. > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26165. > Jason Watkins, jwatkins@iland.net
  26166. > I-Land NOC Technician
  26167. > http://www.iland.net
  26168. > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26169. >
  26170. > ----- Original Message -----
  26171. > From: Scott Trautman <scottt@corp.gdinet.com>
  26172. > To: <usr-tc@lists.xmission.com>
  26173. > Sent: Tuesday, April 27, 1999 5:00 PM
  26174. > Subject: RE: (usr-tc) Dedicated Dial-Up
  26175. >
  26176. >
  26177. > > Way too hard. Assign them static addresses in Radius completely out of
  26178. > your
  26179. > > pool.
  26180. > > Pool is for random assignment only. You'll only give yourself grief
  26181. trying
  26182. > > to pick the pool.
  26183. > >
  26184. > > SMT
  26185. > >
  26186. > > > -----Original Message-----
  26187. > > > From: Jason W. [mailto:jwatkins@iland.net]
  26188. > > > Sent: Tuesday, April 27, 1999 4:46 PM
  26189. > > > To: usr-tc@lists.xmission.com
  26190. > > > Subject: (usr-tc) Dedicated Dial-Up
  26191. > > >
  26192. > > >
  26193. > > > We have 2 dedicated dial-up customers that
  26194. > > > I'm having problems setting up properly.
  26195. > > > We are using a USRTC, Quad modem cards,
  26196. > > > and HiPer ARC.  I'm having their IP addresses
  26197. > > > assigned to them via Radius, and 2 channels
  26198. > > > of that CT1 are pulled out of the hunt and
  26199. > > > have their own phone number.  The problem is
  26200. > > > this.  I have an IP address pool set to use
  26201. > > > 46 IP addresses, with a range of 123.123.123.1-
  26202. > > > 123.123.123.46 The static IP addresses our
  26203. > > > dedicated customers get are .47 and .48  With
  26204. > > > this configuration since the interfaces they
  26205. > > > connect to are in the modem_group all, the
  26206. > > > USRTC thinks that when our dedicated customer
  26207. > > > dials in that it uses 2 addresses from that IP
  26208. > > > pool.  When that chassis is full users are
  26209. > > > unable to connect to two ports because it already
  26210. > > > thinks two addresses are being used..... confusing
  26211. > > > eh??
  26212. > > >
  26213. > > > So my question is this, could I delete
  26214. > > > then re-create the modem_group all -those two
  26215. > > > interfaces, and assign those two interfaces
  26216. > > > their own IP address pool size (2), and create
  26217. > > > their own modem_group?  Or am I making this
  26218. > > > WAY too hard on myself???
  26219. > > >
  26220. > > > TIA
  26221. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26222. > > > Jason Watkins, jwatkins@iland.net
  26223. > > > I-Land NOC Technician
  26224. > > > http://www.iland.net
  26225. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26226. > > >
  26227. > > >
  26228. > > >
  26229. > > > -
  26230. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26231. > > >  with "unsubscribe usr-tc" in the body of the message.
  26232. > > >  For information on digests or retrieving files and old messages send
  26233. > > >  "help" to the same address.  Do not use quotes in your message.
  26234. > > >
  26235. > >
  26236. > > -
  26237. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26238. > >  with "unsubscribe usr-tc" in the body of the message.
  26239. > >  For information on digests or retrieving files and old messages send
  26240. > >  "help" to the same address.  Do not use quotes in your message.
  26241. > >
  26242. >
  26243. >
  26244. > -
  26245. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26246. >  with "unsubscribe usr-tc" in the body of the message.
  26247. >  For information on digests or retrieving files and old messages send
  26248. >  "help" to the same address.  Do not use quotes in your message.
  26249. >
  26250.  
  26251.  
  26252. -
  26253.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26254.  with "unsubscribe usr-tc" in the body of the message.
  26255.  For information on digests or retrieving files and old messages send
  26256.  "help" to the same address.  Do not use quotes in your message.
  26257.  
  26258.  
  26259. -------------------------------------------------------------------------------
  26260.  
  26261. From: ISPCnsl001@aol.com
  26262. Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
  26263. Date: 27 Apr 1999 18:46:19 EDT
  26264.  
  26265. In a message dated 4/27/99 1:51:08 PM US Eastern Standard Time, db3l@ans.net 
  26266. writes:
  26267.  
  26268. > Yes, there was a problem in this regard in the 4.2.x series that
  26269. >  toggling the jitter attenuation could correct.  The card would
  26270. >  incorrectly latch AB bit patterns during a bootup (and or fall into
  26271. >  that mode) which would affect its ability to process calls.
  26272. >  
  26273. >  The jitter attenuation toggling is just a workaround in that it gives
  26274. >  the AB bits as perceived by the card a "kick", but the underlying
  26275. >  problem isn't with the jitter attenuation itself. 
  26276.  
  26277. The problem resides in the Hardware.  The lucent framer to be exact.  The ER 
  26278. code is a work around.
  26279.  
  26280. >  
  26281. >  > After looking at the card again as I was writing this, are you positive 
  26282. >  > on the numbering? I'm showing 4.3.99 is what was given to me and since 
  26283. >  > that has happened (well over a year ago now) the card has performed 
  26284. >  > without troubles.
  26285. >  
  26286. >  I'm not sure about 4.3.99 but 4.2.99 was originally built for us back
  26287. >  in 3/98 in response to this problem during TCS 3.1 testing (among
  26288. >  other items) off of a 4.2.1 base, and it did address this sort of
  26289. >  problem.  Hope they didn't reintroduce the problem in the 4.3.x series
  26290. >  
  26291.  
  26292.  
  26293. -
  26294.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26295.  with "unsubscribe usr-tc" in the body of the message.
  26296.  For information on digests or retrieving files and old messages send
  26297.  "help" to the same address.  Do not use quotes in your message.
  26298.  
  26299.  
  26300. -------------------------------------------------------------------------------
  26301.  
  26302. From: Aaron Nabil <nabil@spiritone.com>
  26303. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  26304. Date: 27 Apr 1999 16:45:19 -0700 (PDT)
  26305.  
  26306. Tatai SV Krishnan writes...
  26307. > . . .
  26308. >Now we received information from customers regarding users password 
  26309. >getting corrupted.  Some of you had radius logs which showed that the 
  26310. >users password was getting corrupted.
  26311. >
  26312. >The users password from the showed that the last charecter of the 
  26313. >password had some some control charecters like ]}#  etc.  This particular 
  26314. >problem is not consistant and cannot be reproduced on demand.
  26315.  
  26316. I don't think *I* said that, and I'm the one who (re-)reported it recently
  26317. and verified the workaround.
  26318.  
  26319. I can gaurantee we have at _least_ one user who this occurs for on
  26320. _every_ call.  We used that particular user to troubleshoot with and
  26321. to the try various possible fixes including disabling ppp offloading.
  26322.  
  26323. We tried capturing the session using a syslog tap as described in 
  26324. the documentation.  It didn't work, nothing was captured.
  26325.  
  26326. -- 
  26327. Aaron Nabil
  26328.  
  26329. -
  26330.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26331.  with "unsubscribe usr-tc" in the body of the message.
  26332.  For information on digests or retrieving files and old messages send
  26333.  "help" to the same address.  Do not use quotes in your message.
  26334.  
  26335.  
  26336. -------------------------------------------------------------------------------
  26337.  
  26338. From: Aaron Nabil <nabil@spiritone.com>
  26339. Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
  26340. Date: 27 Apr 1999 16:56:13 -0700 (PDT)
  26341.  
  26342. David Bolen writes...
  26343. >Eric Forcey <eric@psnw.com> writes:
  26344. >
  26345. >> There is a way around flashing it to 4.2.99, as the problem is dealing 
  26346. >> with Jitter Attenuation. (this again is per the engineer that I dealt with).
  26347. >> 
  26348. >> He was able to get the card working fine with existing code by changing 
  26349. >> the Jitter from TX to Recvr, saving the settings, resetting, then 
  26350. >> changing it back. I wasn't about to do that on a continual basis.
  26351. >
  26352. >Yes, there was a problem in this regard in the 4.2.x series that
  26353. >toggling the jitter attenuation could correct.  The card would
  26354. >incorrectly latch AB bit patterns during a bootup (and or fall into
  26355. >that mode) which would affect its ability to process calls.
  26356. >
  26357. >The jitter attenuation toggling is just a workaround in that it gives
  26358. >the AB bits as perceived by the card a "kick", but the underlying
  26359. >problem isn't with the jitter attenuation itself. 
  26360.  
  26361. The jitter attenuartion default is also set wrong, you want jitter 
  26362. attenuation on the receiver, not the transmitter.  So if you are going
  26363. to "flip" it, leave it at the rx setting.
  26364.  
  26365.  
  26366. -- 
  26367. Aaron Nabil
  26368.  
  26369. -
  26370.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26371.  with "unsubscribe usr-tc" in the body of the message.
  26372.  For information on digests or retrieving files and old messages send
  26373.  "help" to the same address.  Do not use quotes in your message.
  26374.  
  26375.  
  26376. -------------------------------------------------------------------------------
  26377.  
  26378. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  26379. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  26380. Date: 27 Apr 1999 19:55:36 -0500 (CDT)
  26381.  
  26382. On Tue, 27 Apr 1999, Aaron Nabil wrote:
  26383.  
  26384. > Tatai SV Krishnan writes...
  26385. > > . . .
  26386. > >Now we received information from customers regarding users password 
  26387. > >getting corrupted.  Some of you had radius logs which showed that the 
  26388. > >users password was getting corrupted.
  26389. > >
  26390. > >The users password from the showed that the last charecter of the 
  26391. > >password had some some control charecters like ]}#  etc.  This particular 
  26392. > >problem is not consistant and cannot be reproduced on demand.
  26393. > 
  26394. > I don't think *I* said that, and I'm the one who (re-)reported it recently
  26395. > and verified the workaround.
  26396. > 
  26397. > I can gaurantee we have at _least_ one user who this occurs for on
  26398. > _every_ call.  We used that particular user to troubleshoot with and
  26399. > to the try various possible fixes including disabling ppp offloading.
  26400.  
  26401. Here is my number 847-342-6345 - Call me when you have the user ready to 
  26402. dial.  I would need access to your hiper arc / or your user should be 
  26403. able to dial long distance to our chassis.  Call me when every you are 
  26404. ready, if you get to VM - you can call my cell (number is on the VM) else 
  26405. page me at
  26406.  
  26407. pager@bubba.ae.usr.com
  26408.  
  26409. Krish
  26410.  
  26411. > 
  26412. > We tried capturing the session using a syslog tap as described in 
  26413. > the documentation.  It didn't work, nothing was captured.
  26414. > 
  26415. > -- 
  26416. > Aaron Nabil
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26427.  with "unsubscribe usr-tc" in the body of the message.
  26428.  For information on digests or retrieving files and old messages send
  26429.  "help" to the same address.  Do not use quotes in your message.
  26430.  
  26431.  
  26432. -------------------------------------------------------------------------------
  26433.  
  26434. From: Brian <signal@shreve.net>
  26435. Subject: Re: (usr-tc) Dedicated Dial-Up
  26436. Date: 27 Apr 1999 20:16:45 -0500 (CDT)
  26437.  
  26438. On Tue, 27 Apr 1999, Jason W. wrote:
  26439.  
  26440. > I'm actually assigning their IP addresses via
  26441. > Radius now.  What happens is that even though
  26442. > I have the PI address set to 46 addresses,
  26443. > when the dedicated customer dials in they
  26444. > are basically a "default" user which is using
  26445. > the "modem_group all" So the PI pool thinks
  26446. > that the dedicated user is using a proper
  26447. > IP address and increments the number of
  26448. > addresses used by 2.  So if our USRTC is
  26449. > almost full and 2 users try to dial into
  26450. > the last available ports they cannot because
  26451. > the PI pool thinks it has no more addresses
  26452. > to assign...  Shouldn't the ARC be intuitive
  26453. > enough to know that those addresses are
  26454. > not part of the pool and thus not increment
  26455. > the size of the used IP pool???
  26456.  
  26457.  
  26458. show us the RADIUS config for the user.
  26459.  
  26460.  
  26461. > 
  26462. > 
  26463. > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26464. > Jason Watkins, jwatkins@iland.net
  26465. > I-Land NOC Technician
  26466. > http://www.iland.net
  26467. > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26468. > 
  26469. > ----- Original Message -----
  26470. > From: Scott Trautman <scottt@corp.gdinet.com>
  26471. > To: <usr-tc@lists.xmission.com>
  26472. > Sent: Tuesday, April 27, 1999 5:00 PM
  26473. > Subject: RE: (usr-tc) Dedicated Dial-Up
  26474. > 
  26475. > 
  26476. > > Way too hard. Assign them static addresses in Radius completely out of
  26477. > your
  26478. > > pool.
  26479. > > Pool is for random assignment only. You'll only give yourself grief trying
  26480. > > to pick the pool.
  26481. > >
  26482. > > SMT
  26483. > >
  26484. > > > -----Original Message-----
  26485. > > > From: Jason W. [mailto:jwatkins@iland.net]
  26486. > > > Sent: Tuesday, April 27, 1999 4:46 PM
  26487. > > > To: usr-tc@lists.xmission.com
  26488. > > > Subject: (usr-tc) Dedicated Dial-Up
  26489. > > >
  26490. > > >
  26491. > > > We have 2 dedicated dial-up customers that
  26492. > > > I'm having problems setting up properly.
  26493. > > > We are using a USRTC, Quad modem cards,
  26494. > > > and HiPer ARC.  I'm having their IP addresses
  26495. > > > assigned to them via Radius, and 2 channels
  26496. > > > of that CT1 are pulled out of the hunt and
  26497. > > > have their own phone number.  The problem is
  26498. > > > this.  I have an IP address pool set to use
  26499. > > > 46 IP addresses, with a range of 123.123.123.1-
  26500. > > > 123.123.123.46 The static IP addresses our
  26501. > > > dedicated customers get are .47 and .48  With
  26502. > > > this configuration since the interfaces they
  26503. > > > connect to are in the modem_group all, the
  26504. > > > USRTC thinks that when our dedicated customer
  26505. > > > dials in that it uses 2 addresses from that IP
  26506. > > > pool.  When that chassis is full users are
  26507. > > > unable to connect to two ports because it already
  26508. > > > thinks two addresses are being used..... confusing
  26509. > > > eh??
  26510. > > >
  26511. > > > So my question is this, could I delete
  26512. > > > then re-create the modem_group all -those two
  26513. > > > interfaces, and assign those two interfaces
  26514. > > > their own IP address pool size (2), and create
  26515. > > > their own modem_group?  Or am I making this
  26516. > > > WAY too hard on myself???
  26517. > > >
  26518. > > > TIA
  26519. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26520. > > > Jason Watkins, jwatkins@iland.net
  26521. > > > I-Land NOC Technician
  26522. > > > http://www.iland.net
  26523. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26524. > > >
  26525. > > >
  26526. > > >
  26527. > > > -
  26528. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26529. > > >  with "unsubscribe usr-tc" in the body of the message.
  26530. > > >  For information on digests or retrieving files and old messages send
  26531. > > >  "help" to the same address.  Do not use quotes in your message.
  26532. > > >
  26533. > >
  26534. > > -
  26535. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26536. > >  with "unsubscribe usr-tc" in the body of the message.
  26537. > >  For information on digests or retrieving files and old messages send
  26538. > >  "help" to the same address.  Do not use quotes in your message.
  26539. > >
  26540. > 
  26541. > 
  26542. > -
  26543. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26544. >  with "unsubscribe usr-tc" in the body of the message.
  26545. >  For information on digests or retrieving files and old messages send
  26546. >  "help" to the same address.  Do not use quotes in your message.
  26547. > 
  26548.  
  26549. Brian Feeny (BF304)     signal@shreve.net   
  26550. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26551. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26552.  
  26553.  
  26554. -
  26555.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26556.  with "unsubscribe usr-tc" in the body of the message.
  26557.  For information on digests or retrieving files and old messages send
  26558.  "help" to the same address.  Do not use quotes in your message.
  26559.  
  26560.  
  26561. -------------------------------------------------------------------------------
  26562.  
  26563. From: Brian <signal@shreve.net>
  26564. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  26565. Date: 27 Apr 1999 20:18:22 -0500 (CDT)
  26566.  
  26567. > We tried capturing the session using a syslog tap as described in 
  26568. > the documentation.  It didn't work, nothing was captured.
  26569.  
  26570.  
  26571. It may have been captured.  Check the facility that the ARC logs too, and
  26572. it may have gone there.  Thats what happens for me (TAP info is logged to
  26573. the arc's facility rather than the tap users facility).
  26574.  
  26575. I would say that this happens on the order of 100+ times a day, I don't
  26576. see why its not reproducable.
  26577.  
  26578.  
  26579. > 
  26580. > -- 
  26581. > Aaron Nabil
  26582. > 
  26583. > -
  26584. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26585. >  with "unsubscribe usr-tc" in the body of the message.
  26586. >  For information on digests or retrieving files and old messages send
  26587. >  "help" to the same address.  Do not use quotes in your message.
  26588. > 
  26589.  
  26590. Brian Feeny (BF304)     signal@shreve.net   
  26591. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26592. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26593.  
  26594.  
  26595. -
  26596.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26597.  with "unsubscribe usr-tc" in the body of the message.
  26598.  For information on digests or retrieving files and old messages send
  26599.  "help" to the same address.  Do not use quotes in your message.
  26600.  
  26601.  
  26602. -------------------------------------------------------------------------------
  26603.  
  26604. From: "Jason Watkins" <jwatkins@iland.net>
  26605. Subject: Re: (usr-tc) Dedicated Dial-Up
  26606. Date: 27 Apr 1999 20:27:55 -0500
  26607.  
  26608. We are currently using ESVA (getting ready to
  26609. implement Radiator) Below is a copy of the dedicated
  26610. user's entry in the users file.
  26611.  
  26612. user    Password = "UNIX",
  26613.         Sessions = 1
  26614.         User-Service-Type = Framed-User,
  26615.         Framed-Protocol = PPP,
  26616.         Framed-Address = 123.123.123.48,
  26617.         Framed-Netmask = 255.255.255.255,
  26618.         Framed-Routing = None,
  26619.         Framed-MTU = 1500
  26620.  
  26621.  
  26622. When he dials in he gets his static ip.  But for some
  26623. reason the HiPer ARC increments the ip pool by
  26624. one when he connects.  Thanks for all your help
  26625. people!
  26626.  
  26627.  
  26628. ----- Original Message -----
  26629. Sent: Tuesday, April 27, 1999 8:16 PM
  26630.  
  26631.  
  26632. > On Tue, 27 Apr 1999, Jason W. wrote:
  26633. >
  26634. > > I'm actually assigning their IP addresses via
  26635. > > Radius now.  What happens is that even though
  26636. > > I have the PI address set to 46 addresses,
  26637. > > when the dedicated customer dials in they
  26638. > > are basically a "default" user which is using
  26639. > > the "modem_group all" So the PI pool thinks
  26640. > > that the dedicated user is using a proper
  26641. > > IP address and increments the number of
  26642. > > addresses used by 2.  So if our USRTC is
  26643. > > almost full and 2 users try to dial into
  26644. > > the last available ports they cannot because
  26645. > > the PI pool thinks it has no more addresses
  26646. > > to assign...  Shouldn't the ARC be intuitive
  26647. > > enough to know that those addresses are
  26648. > > not part of the pool and thus not increment
  26649. > > the size of the used IP pool???
  26650. >
  26651. >
  26652. > show us the RADIUS config for the user.
  26653. >
  26654. >
  26655. > >
  26656. > >
  26657. > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26658. > > Jason Watkins, jwatkins@iland.net
  26659. > > I-Land NOC Technician
  26660. > > http://www.iland.net
  26661. > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26662. > >
  26663. > > ----- Original Message -----
  26664. > > From: Scott Trautman <scottt@corp.gdinet.com>
  26665. > > To: <usr-tc@lists.xmission.com>
  26666. > > Sent: Tuesday, April 27, 1999 5:00 PM
  26667. > > Subject: RE: (usr-tc) Dedicated Dial-Up
  26668. > >
  26669. > >
  26670. > > > Way too hard. Assign them static addresses in Radius completely out of
  26671. > > your
  26672. > > > pool.
  26673. > > > Pool is for random assignment only. You'll only give yourself grief
  26674. trying
  26675. > > > to pick the pool.
  26676. > > >
  26677. > > > SMT
  26678. > > >
  26679. > > > > -----Original Message-----
  26680. > > > > From: Jason W. [mailto:jwatkins@iland.net]
  26681. > > > > Sent: Tuesday, April 27, 1999 4:46 PM
  26682. > > > > To: usr-tc@lists.xmission.com
  26683. > > > > Subject: (usr-tc) Dedicated Dial-Up
  26684. > > > >
  26685. > > > >
  26686. > > > > We have 2 dedicated dial-up customers that
  26687. > > > > I'm having problems setting up properly.
  26688. > > > > We are using a USRTC, Quad modem cards,
  26689. > > > > and HiPer ARC.  I'm having their IP addresses
  26690. > > > > assigned to them via Radius, and 2 channels
  26691. > > > > of that CT1 are pulled out of the hunt and
  26692. > > > > have their own phone number.  The problem is
  26693. > > > > this.  I have an IP address pool set to use
  26694. > > > > 46 IP addresses, with a range of 123.123.123.1-
  26695. > > > > 123.123.123.46 The static IP addresses our
  26696. > > > > dedicated customers get are .47 and .48  With
  26697. > > > > this configuration since the interfaces they
  26698. > > > > connect to are in the modem_group all, the
  26699. > > > > USRTC thinks that when our dedicated customer
  26700. > > > > dials in that it uses 2 addresses from that IP
  26701. > > > > pool.  When that chassis is full users are
  26702. > > > > unable to connect to two ports because it already
  26703. > > > > thinks two addresses are being used..... confusing
  26704. > > > > eh??
  26705. > > > >
  26706. > > > > So my question is this, could I delete
  26707. > > > > then re-create the modem_group all -those two
  26708. > > > > interfaces, and assign those two interfaces
  26709. > > > > their own IP address pool size (2), and create
  26710. > > > > their own modem_group?  Or am I making this
  26711. > > > > WAY too hard on myself???
  26712. > > > >
  26713. > > > > TIA
  26714. > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26715. > > > > Jason Watkins, jwatkins@iland.net
  26716. > > > > I-Land NOC Technician
  26717. > > > > http://www.iland.net
  26718. > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26719. > > > >
  26720. > > > >
  26721. > > > >
  26722. > > > > -
  26723. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26724. > > > >  with "unsubscribe usr-tc" in the body of the message.
  26725. > > > >  For information on digests or retrieving files and old messages
  26726. send
  26727. > > > >  "help" to the same address.  Do not use quotes in your message.
  26728. > > > >
  26729. > > >
  26730. > > > -
  26731. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26732. > > >  with "unsubscribe usr-tc" in the body of the message.
  26733. > > >  For information on digests or retrieving files and old messages send
  26734. > > >  "help" to the same address.  Do not use quotes in your message.
  26735. > > >
  26736. > >
  26737. > >
  26738. > > -
  26739. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26740. > >  with "unsubscribe usr-tc" in the body of the message.
  26741. > >  For information on digests or retrieving files and old messages send
  26742. > >  "help" to the same address.  Do not use quotes in your message.
  26743. > >
  26744. >
  26745. > -----------------------------------------------------
  26746. > Brian Feeny (BF304)     signal@shreve.net
  26747. > 318-222-2638 x 109 http://www.shreve.net/~signal
  26748. > Network Administrator   ShreveNet Inc. (ASN 11881)
  26749. >
  26750. >
  26751. > -
  26752. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26753. >  with "unsubscribe usr-tc" in the body of the message.
  26754. >  For information on digests or retrieving files and old messages send
  26755. >  "help" to the same address.  Do not use quotes in your message.
  26756. >
  26757.  
  26758.  
  26759. -
  26760.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26761.  with "unsubscribe usr-tc" in the body of the message.
  26762.  For information on digests or retrieving files and old messages send
  26763.  "help" to the same address.  Do not use quotes in your message.
  26764.  
  26765.  
  26766. -------------------------------------------------------------------------------
  26767.  
  26768. From: Kevin Benton <s1kevin@tims.net>
  26769. Subject: (usr-tc) Answer Supervision on DSPs - BUG
  26770. Date: 27 Apr 1999 23:31:24 -0400 (EDT)
  26771.  
  26772. FYI for everyone...
  26773.  
  26774. (Krish - when you see this - please check to make sure it's in the bug
  26775. tracking system - worked with Fred Daneu, George Ebert, and Mohi in your
  26776. dept.)
  26777.  
  26778. After working with our local telco for three weeks, we found out that they
  26779. turned on NMD in the 5E which requires answer supervision to be done
  26780. properly.  Extensive testing proved that the DSP's do not do answer
  26781. supervision properly if DNIS is turned off.  If DNIS is turned on, then
  26782. answer supervision is done properly.  In the very same trunk group with
  26783. quads and dual t1 cards, we did not have this problem with DNIS turned
  26784. off.  This problem has already been reported to 3Com via two different
  26785. fronts, though it has not yet (as we can tell) made it to the weekly field
  26786. engineering reports.
  26787.  
  26788. Answer supervision is what allows the switch to know that the CPE has
  26789. received and accepted the call and is usually used for billing purposes.
  26790. NMD is a feature which if the other end does not answer (or in our case do
  26791. answer supervision), the switch takes the call back and then plays a
  26792. recorded message to the customer asking them if they want to have the
  26793. switch try to complete the call for them at a later time.
  26794.  
  26795. We are *STILL* having other compatability problems with the DSP's that
  26796. don't seem to be showing up in the quads.  More on this later.
  26797.  
  26798. Kevin Benton
  26799. Sr. Network Engineer
  26800. SOTA Technologies 
  26801.  
  26802. E-Mail:  s1kevin@tims.net
  26803. Web:     http://www.users.sota-oh.com/~s1kevin/
  26804. Unsolicited advertisements processing fee: $50 subject to change without notice
  26805.  
  26806.  
  26807. -
  26808.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26809.  with "unsubscribe usr-tc" in the body of the message.
  26810.  For information on digests or retrieving files and old messages send
  26811.  "help" to the same address.  Do not use quotes in your message.
  26812.  
  26813.  
  26814. -------------------------------------------------------------------------------
  26815.  
  26816. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  26817. Subject: Re: (usr-tc) Dedicated Dial-Up
  26818. Date: 28 Apr 1999 07:22:31 -0500 (CDT)
  26819.  
  26820. On Tue, 27 Apr 1999, Jason Watkins wrote:
  26821.  
  26822. > We are currently using ESVA (getting ready to
  26823. > implement Radiator) Below is a copy of the dedicated
  26824. > user's entry in the users file.
  26825. > 
  26826. > user    Password = "UNIX",
  26827. >         Sessions = 1
  26828. >         User-Service-Type = Framed-User,
  26829. >         Framed-Protocol = PPP,
  26830. >         Framed-Address = 123.123.123.48,
  26831. >         Framed-Netmask = 255.255.255.255,
  26832. >         Framed-Routing = None,
  26833. >         Framed-MTU = 1500
  26834. > 
  26835. > 
  26836. > When he dials in he gets his static ip.  But for some
  26837. > reason the HiPer ARC increments the ip pool by
  26838. > one when he connects.  Thanks for all your help
  26839. > people!
  26840. > 
  26841.  
  26842. Do you have hint assigned enabled?
  26843.  
  26844. krish
  26845.  
  26846. > 
  26847. > ----- Original Message -----
  26848. > From: Brian <signal@shreve.net>
  26849. > To: <usr-tc@lists.xmission.com>
  26850. > Sent: Tuesday, April 27, 1999 8:16 PM
  26851. > Subject: Re: (usr-tc) Dedicated Dial-Up
  26852. > 
  26853. > 
  26854. > > On Tue, 27 Apr 1999, Jason W. wrote:
  26855. > >
  26856. > > > I'm actually assigning their IP addresses via
  26857. > > > Radius now.  What happens is that even though
  26858. > > > I have the PI address set to 46 addresses,
  26859. > > > when the dedicated customer dials in they
  26860. > > > are basically a "default" user which is using
  26861. > > > the "modem_group all" So the PI pool thinks
  26862. > > > that the dedicated user is using a proper
  26863. > > > IP address and increments the number of
  26864. > > > addresses used by 2.  So if our USRTC is
  26865. > > > almost full and 2 users try to dial into
  26866. > > > the last available ports they cannot because
  26867. > > > the PI pool thinks it has no more addresses
  26868. > > > to assign...  Shouldn't the ARC be intuitive
  26869. > > > enough to know that those addresses are
  26870. > > > not part of the pool and thus not increment
  26871. > > > the size of the used IP pool???
  26872. > >
  26873. > >
  26874. > > show us the RADIUS config for the user.
  26875. > >
  26876. > >
  26877. > > >
  26878. > > >
  26879. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26880. > > > Jason Watkins, jwatkins@iland.net
  26881. > > > I-Land NOC Technician
  26882. > > > http://www.iland.net
  26883. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26884. > > >
  26885. > > > ----- Original Message -----
  26886. > > > From: Scott Trautman <scottt@corp.gdinet.com>
  26887. > > > To: <usr-tc@lists.xmission.com>
  26888. > > > Sent: Tuesday, April 27, 1999 5:00 PM
  26889. > > > Subject: RE: (usr-tc) Dedicated Dial-Up
  26890. > > >
  26891. > > >
  26892. > > > > Way too hard. Assign them static addresses in Radius completely out of
  26893. > > > your
  26894. > > > > pool.
  26895. > > > > Pool is for random assignment only. You'll only give yourself grief
  26896. > trying
  26897. > > > > to pick the pool.
  26898. > > > >
  26899. > > > > SMT
  26900. > > > >
  26901. > > > > > -----Original Message-----
  26902. > > > > > From: Jason W. [mailto:jwatkins@iland.net]
  26903. > > > > > Sent: Tuesday, April 27, 1999 4:46 PM
  26904. > > > > > To: usr-tc@lists.xmission.com
  26905. > > > > > Subject: (usr-tc) Dedicated Dial-Up
  26906. > > > > >
  26907. > > > > >
  26908. > > > > > We have 2 dedicated dial-up customers that
  26909. > > > > > I'm having problems setting up properly.
  26910. > > > > > We are using a USRTC, Quad modem cards,
  26911. > > > > > and HiPer ARC.  I'm having their IP addresses
  26912. > > > > > assigned to them via Radius, and 2 channels
  26913. > > > > > of that CT1 are pulled out of the hunt and
  26914. > > > > > have their own phone number.  The problem is
  26915. > > > > > this.  I have an IP address pool set to use
  26916. > > > > > 46 IP addresses, with a range of 123.123.123.1-
  26917. > > > > > 123.123.123.46 The static IP addresses our
  26918. > > > > > dedicated customers get are .47 and .48  With
  26919. > > > > > this configuration since the interfaces they
  26920. > > > > > connect to are in the modem_group all, the
  26921. > > > > > USRTC thinks that when our dedicated customer
  26922. > > > > > dials in that it uses 2 addresses from that IP
  26923. > > > > > pool.  When that chassis is full users are
  26924. > > > > > unable to connect to two ports because it already
  26925. > > > > > thinks two addresses are being used..... confusing
  26926. > > > > > eh??
  26927. > > > > >
  26928. > > > > > So my question is this, could I delete
  26929. > > > > > then re-create the modem_group all -those two
  26930. > > > > > interfaces, and assign those two interfaces
  26931. > > > > > their own IP address pool size (2), and create
  26932. > > > > > their own modem_group?  Or am I making this
  26933. > > > > > WAY too hard on myself???
  26934. > > > > >
  26935. > > > > > TIA
  26936. > > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26937. > > > > > Jason Watkins, jwatkins@iland.net
  26938. > > > > > I-Land NOC Technician
  26939. > > > > > http://www.iland.net
  26940. > > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
  26941. > > > > >
  26942. > > > > >
  26943. > > > > >
  26944. > > > > > -
  26945. > > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26946. > > > > >  with "unsubscribe usr-tc" in the body of the message.
  26947. > > > > >  For information on digests or retrieving files and old messages
  26948. > send
  26949. > > > > >  "help" to the same address.  Do not use quotes in your message.
  26950. > > > > >
  26951. > > > >
  26952. > > > > -
  26953. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26954. > > > >  with "unsubscribe usr-tc" in the body of the message.
  26955. > > > >  For information on digests or retrieving files and old messages send
  26956. > > > >  "help" to the same address.  Do not use quotes in your message.
  26957. > > > >
  26958. > > >
  26959. > > >
  26960. > > > -
  26961. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26962. > > >  with "unsubscribe usr-tc" in the body of the message.
  26963. > > >  For information on digests or retrieving files and old messages send
  26964. > > >  "help" to the same address.  Do not use quotes in your message.
  26965. > > >
  26966. > >
  26967. > > -----------------------------------------------------
  26968. > > Brian Feeny (BF304)     signal@shreve.net
  26969. > > 318-222-2638 x 109 http://www.shreve.net/~signal
  26970. > > Network Administrator   ShreveNet Inc. (ASN 11881)
  26971. > >
  26972. > >
  26973. > > -
  26974. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26975. > >  with "unsubscribe usr-tc" in the body of the message.
  26976. > >  For information on digests or retrieving files and old messages send
  26977. > >  "help" to the same address.  Do not use quotes in your message.
  26978. > >
  26979. > 
  26980. > 
  26981. > -
  26982. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26983. >  with "unsubscribe usr-tc" in the body of the message.
  26984. >  For information on digests or retrieving files and old messages send
  26985. >  "help" to the same address.  Do not use quotes in your message.
  26986. > 
  26987.  
  26988. -
  26989.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26990.  with "unsubscribe usr-tc" in the body of the message.
  26991.  For information on digests or retrieving files and old messages send
  26992.  "help" to the same address.  Do not use quotes in your message.
  26993.  
  26994.  
  26995. -------------------------------------------------------------------------------
  26996.  
  26997. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  26998. Subject: Re: (usr-tc) Answer Supervision on DSPs - BUG
  26999. Date: 28 Apr 1999 07:26:12 -0500 (CDT)
  27000.  
  27001. On Tue, 27 Apr 1999, Kevin Benton wrote:
  27002.  
  27003. > FYI for everyone...
  27004. > 
  27005. > (Krish - when you see this - please check to make sure it's in the bug
  27006. > tracking system - worked with Fred Daneu, George Ebert, and Mohi in your
  27007. > dept.)
  27008.  
  27009.  
  27010. Mohi has to escalate the case (if its not already done) - then a NSE from 
  27011. the DSP group has to identify the bug - thats when a bug is entered.
  27012.  
  27013. Send me the ticket number and will have a talk with Mohi - 
  27014.  
  27015. krish
  27016.  
  27017. > 
  27018. > After working with our local telco for three weeks, we found out that they
  27019. > turned on NMD in the 5E which requires answer supervision to be done
  27020. > properly.  Extensive testing proved that the DSP's do not do answer
  27021. > supervision properly if DNIS is turned off.  If DNIS is turned on, then
  27022. > answer supervision is done properly.  In the very same trunk group with
  27023. > quads and dual t1 cards, we did not have this problem with DNIS turned
  27024. > off.  This problem has already been reported to 3Com via two different
  27025. > fronts, though it has not yet (as we can tell) made it to the weekly field
  27026. > engineering reports.
  27027. > 
  27028. > Answer supervision is what allows the switch to know that the CPE has
  27029. > received and accepted the call and is usually used for billing purposes.
  27030. > NMD is a feature which if the other end does not answer (or in our case do
  27031. > answer supervision), the switch takes the call back and then plays a
  27032. > recorded message to the customer asking them if they want to have the
  27033. > switch try to complete the call for them at a later time.
  27034. > 
  27035. > We are *STILL* having other compatability problems with the DSP's that
  27036. > don't seem to be showing up in the quads.  More on this later.
  27037. > 
  27038. > Kevin Benton
  27039. > Sr. Network Engineer
  27040. > SOTA Technologies 
  27041. > 
  27042. > E-Mail:  s1kevin@tims.net
  27043. > Web:     http://www.users.sota-oh.com/~s1kevin/
  27044. > Unsolicited advertisements processing fee: $50 subject to change without notice
  27045. > 
  27046. > 
  27047. > -
  27048. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27049. >  with "unsubscribe usr-tc" in the body of the message.
  27050. >  For information on digests or retrieving files and old messages send
  27051. >  "help" to the same address.  Do not use quotes in your message.
  27052. > 
  27053.  
  27054. -
  27055.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27056.  with "unsubscribe usr-tc" in the body of the message.
  27057.  For information on digests or retrieving files and old messages send
  27058.  "help" to the same address.  Do not use quotes in your message.
  27059.  
  27060.  
  27061. -------------------------------------------------------------------------------
  27062.  
  27063. From: "Andre Gustavo de Carvalho Albuquerque" <gustavo@visualnet.com.br>
  27064. Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
  27065. Date: 28 Apr 1999 10:09:38 +0100
  27066.  
  27067.  
  27068. ----- Original Message -----=20
  27069. Sent: Wednesday, April 28, 1999 12:45 AM
  27070.  
  27071.  
  27072. > Tatai SV Krishnan writes...
  27073. ...
  27074. > I can gaurantee we have at _least_ one user who this occurs for on
  27075. > _every_ call.  We used that particular user to troubleshoot with and
  27076. > to the try various possible fixes including disabling ppp offloading.
  27077. >=20
  27078. > We tried capturing the session using a syslog tap as described in=20
  27079. > the documentation.  It didn't work, nothing was captured.
  27080. >=20
  27081.   I know it may seem quite obvious but have you started syslogd
  27082. with -r option?
  27083.  
  27084.   Regards,=20
  27085.      Gustavo Albuquerque
  27086.  
  27087.  
  27088. -
  27089.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27090.  with "unsubscribe usr-tc" in the body of the message.
  27091.  For information on digests or retrieving files and old messages send
  27092.  "help" to the same address.  Do not use quotes in your message.
  27093.  
  27094.  
  27095. -------------------------------------------------------------------------------
  27096.  
  27097. From: Beth Pullen <john1@execpc.com>
  27098. Subject: (usr-tc) DI5601 Connect Problems
  27099. Date: 27 Apr 1999 20:16:55 -0500
  27100.  
  27101. Dear Jeff,
  27102. I have had similar problems with my 5601 and my local ISP Execpc.com.
  27103. They apparently use Us Robotics hardware and modems.  Modem Blaster's
  27104. Tech-people have suggested to try the following fixes which I have not
  27105. had a chance to try myself yet.
  27106. +MS=12,1,300,56000,0,0
  27107. or
  27108. &F&C1&D2+MS=12,1,300,56000,0,0
  27109.  
  27110. good luck,
  27111. Let me know if it helps.
  27112. john1@execpc.com
  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: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
  27124. Subject: (usr-tc) FS: TOTAL CONTROL CHASSIS
  27125. Date: 28 Apr 1999 15:14:53 -0400
  27126.  
  27127.  
  27128. For Wednesday:
  27129. Just received in (1) Total Control Unit
  27130. (15) Quad Analog/Digital Modems with analog nic cards
  27131. Netserver Card w/ token ring nic
  27132. Net Management Card w/token ring nic
  27133. (2) AC PSU45 Cards
  27134. external fan tray
  27135. chassis
  27136.  
  27137. First $3,200 
  27138.  
  27139. Please private e-mail if you are interested.  Can ship immediately
  27140.  
  27141.  
  27142. DOA Warranty
  27143.  
  27144. Credit Cards accepted.
  27145.  
  27146. With Warmest Regards,
  27147. Andrew Shlensky
  27148. ****************************
  27149. PC Global, Incorporated 
  27150. (305) 667-2111 TEL
  27151. (305) 667-3636 FAX
  27152. URL:     http://www.pcglobal.net
  27153. E-MAIL: andrew@pcglobal.net
  27154. ICQ:       21219089    
  27155.  
  27156.  
  27157. -
  27158.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27159.  with "unsubscribe usr-tc" in the body of the message.
  27160.  For information on digests or retrieving files and old messages send
  27161.  "help" to the same address.  Do not use quotes in your message.
  27162.  
  27163.  
  27164. -------------------------------------------------------------------------------
  27165.  
  27166. From: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
  27167. Subject: (usr-tc) FS: TOTAL CONTROL CHASSIS
  27168. Date: 28 Apr 1999 15:57:13 -0400
  27169.  
  27170. OK Ill meet or beat anyones price on these.........
  27171.  
  27172.  
  27173.  
  27174.  
  27175.  
  27176. For Wednesday:
  27177. Just received in (1) Total Control Unit
  27178. (15) Quad Analog/Digital Modems with analog nic cards
  27179. Netserver Card w/ token ring nic
  27180. Net Management Card w/token ring nic
  27181. (2) AC PSU45 Cards
  27182. external fan tray
  27183. chassis
  27184.  
  27185.  
  27186. Please private e-mail if you are interested.  Can ship immediately
  27187.  
  27188.  
  27189. DOA Warranty
  27190.  
  27191. Credit Cards accepted.
  27192.  
  27193. With Warmest Regards,
  27194. Andrew Shlensky
  27195. ****************************
  27196. PC Global, Incorporated
  27197. (305) 667-2111 TEL
  27198. (305) 667-3636 FAX
  27199. URL:     http://www.pcglobal.net
  27200. E-MAIL: andrew@pcglobal.net
  27201. ICQ:       21219089
  27202.  
  27203.  
  27204.  
  27205. ____________ =95 The ISP-EQUIPMENT Discussion 4Sale/WTB List =95 ________=
  27206. ____
  27207. To Remove, Send An Email To: mailto:remove-isp-equipment@isp-equipment.co=
  27208. m
  27209. To Join, Send An Email To:   mailto:join-isp-equipment@isp-equipment.com
  27210.  
  27211.    Comdisco is a leading provider of equipment & services to emerging
  27212.   businesses. Secure new or used equipment from Comdisco via flexible
  27213. leasing options or purchase. http://www.comdisco.com/promo/isp_equip.cfm
  27214.  
  27215.  
  27216.  
  27217.  
  27218.  
  27219.  
  27220.  
  27221.  
  27222.  
  27223.  
  27224.  
  27225. -
  27226.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27227.  with "unsubscribe usr-tc" in the body of the message.
  27228.  For information on digests or retrieving files and old messages send
  27229.  "help" to the same address.  Do not use quotes in your message.
  27230.  
  27231.  
  27232. -------------------------------------------------------------------------------
  27233.  
  27234. From: Jeff Mcadams <jeffm@iglou.com>
  27235. Subject: (usr-tc) Pros and Cons
  27236. Date: 28 Apr 1999 16:03:25 -0400 (EDT)
  27237.  
  27238. OK, folks...here we go...
  27239.  
  27240. Let's here the pros and cons of event logging from NMC's via RADIUS, and
  27241. via SNMP traps (or perhaps even both?)
  27242.  
  27243. Let's start with general pros and cons of each...
  27244.  
  27245. Also, if anyone is doing logging through these methods (either or both),
  27246. and would like to contribute code, I'd be interested in looking through
  27247. some of that and perhaps making use of some.  :)  Or perhaps I can
  27248. contribute some expertise with other's in improving your code.
  27249.  
  27250. Anyway...I'm looking at some of the logging stuff with the NMC's and it
  27251. looks like there's quite a lot of information and I'm looking at trying
  27252. to find the best way to make that information available to our tech
  27253. support folks.
  27254. -- 
  27255. Jeff McAdams                            Email: jeffm@iglou.com
  27256. Head Network Administrator              Voice: (502) 966-3848
  27257. IgLou Internet Services                        (800) 436-4456
  27258.  
  27259. -
  27260.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27261.  with "unsubscribe usr-tc" in the body of the message.
  27262.  For information on digests or retrieving files and old messages send
  27263.  "help" to the same address.  Do not use quotes in your message.
  27264.  
  27265.  
  27266. -------------------------------------------------------------------------------
  27267.  
  27268. From: Brian <signal@shreve.net>
  27269. Subject: (usr-tc) VPN's revisited
  27270. Date: 28 Apr 1999 15:43:22 -0500 (CDT)
  27271.  
  27272.  
  27273. I posted a while back asking if anyone had gotten VPN functionality
  27274. between HiperARC->Linux, and it didn't seem anyone had tried it.
  27275.  
  27276. I have tried, but have been unsuccessfull.  The configuration I am using
  27277. is:
  27278.  
  27279. joeblow Auth-Type = "Unix-PW"
  27280.         Service-Type = "Framed-User",
  27281.         Framed-Protocol = "PPP",
  27282.         Framed-IP-Address = "255.255.255.254",
  27283.         Framed-Netmask = "255.255.255.255",
  27284.         Framed-MTU = "1500",
  27285.         Max-Channels = "1",
  27286.         Framed-Routing = "None",
  27287.         Framed-Compression = "Van-Jacobson-TCP-IP",
  27288.         Tunnel-Type = "PPTP",
  27289.         Tunnel-Server-Endpoint = "208.206.76.27"
  27290.  
  27291.  
  27292. The Tunnel Server Endpoint, is the IP of a linux box, running PPTPD, as
  27293. follows:
  27294.  
  27295. pptpd --localip 208.206.76.27 --remoteip 208.206.76.71 
  27296.  
  27297. (that remote ip, is the ip of the hiperarc the user is dialing into)
  27298.  
  27299. This all seems like it *should* work, but it doesn't.  I am going to try
  27300. and gather some debug info, but wanted to know if anyone had success with
  27301. this as of yet?
  27302.  
  27303.  
  27304. Brian Feeny (BF304)     signal@shreve.net   
  27305. 318-222-2638 x 109    http://www.shreve.net/~signal      
  27306. Network Administrator   ShreveNet Inc. (ASN 11881)           
  27307.  
  27308.  
  27309. -
  27310.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27311.  with "unsubscribe usr-tc" in the body of the message.
  27312.  For information on digests or retrieving files and old messages send
  27313.  "help" to the same address.  Do not use quotes in your message.
  27314.  
  27315.  
  27316. -------------------------------------------------------------------------------
  27317.  
  27318. From: zip-usrtc@ran.zipcon.net
  27319. Subject: (usr-tc) cheat sheet for command line config
  27320. Date: 28 Apr 1999 13:53:57 -0700
  27321.  
  27322. Does anyone know of a cheat sheet for command line config of the Hiper
  27323. ARC, DSP, and NMC?  I'm just about to bring online my first USR-TC.
  27324. Thanks for any info, Dan
  27325.  
  27326. -
  27327.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27328.  with "unsubscribe usr-tc" in the body of the message.
  27329.  For information on digests or retrieving files and old messages send
  27330.  "help" to the same address.  Do not use quotes in your message.
  27331.  
  27332.  
  27333. -------------------------------------------------------------------------------
  27334.  
  27335. From: "Angela A. Burford" <aratis@erie.net>
  27336. Subject: (usr-tc) stop acct. packets
  27337. Date: 28 Apr 1999 16:58:30 -0400 (EDT)
  27338.  
  27339.  
  27340.  
  27341. My HARC is running code version 4.1.78 and still presents the problem of
  27342. not sending stop accounting packets once in a while. Has this been fixed
  27343. in version 4.1.59-6, or any other version?
  27344.  
  27345. TIA
  27346. Angela
  27347.  
  27348.  
  27349. -
  27350.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27351.  with "unsubscribe usr-tc" in the body of the message.
  27352.  For information on digests or retrieving files and old messages send
  27353.  "help" to the same address.  Do not use quotes in your message.
  27354.  
  27355.  
  27356. -------------------------------------------------------------------------------
  27357.  
  27358. From: Scott Trautman <scottt@corp.gdinet.com>
  27359. Subject: (usr-tc) Netserver64 failure codes
  27360. Date: 28 Apr 1999 16:01:58 -0500
  27361.  
  27362. I get these messages in my syslog (sampling):
  27363.  
  27364. Apr 28 15:52:06 xxxxx S61 didn't get online!  status=-1, connect_fail=3,
  27365. link_fail=3
  27366. Apr 28 15:53:45 xxxxx S7 didn't get online!  status=-1, connect_fail=3,
  27367. link_fail=3
  27368. Apr 28 15:54:10 xxxxx S7 didn't get online!  status=-1, connect_fail=3,
  27369. link_fail=3
  27370. Apr 28 15:54:17 xxxxx S9 didn't get online!  status=-1, connect_fail=36,
  27371. link_fail=31
  27372. Apr 28 15:54:21 xxxxx S23 didn't get online!  status=-1, connect_fail=79,
  27373. link_fail=31
  27374. Apr 28 15:55:32 xxxxx S32 didn't get online!  status=-1, connect_fail=31,
  27375. link_fail=25
  27376. Apr 28 15:56:25 xxxxx S23 didn't get online!  status=-1, connect_fail=79,
  27377. link_fail=31
  27378.  
  27379. Over time have figured out that connect_fail=3, link_fail=3 can either mean
  27380. a user with a stinky modem, or our modem has gone mashuga. We basically look
  27381. for a pattern of failures on a port over time to identify bad modems on our
  27382. end.
  27383.  
  27384. Anyone ever seen a listing of these different codes and what they might
  27385. mean? I scoured 3Com's knowledgebase, the Netserver guide, nothing.
  27386.  
  27387. SMT
  27388.  
  27389. Scott Trautman           608-240-4638,4637fax
  27390. Global Dialog Internet   www.gdinet.com
  27391. 2810 Crossroads, STE LL2
  27392. Madison WI 53718 
  27393.  
  27394.  
  27395.  
  27396. -
  27397.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27398.  with "unsubscribe usr-tc" in the body of the message.
  27399.  For information on digests or retrieving files and old messages send
  27400.  "help" to the same address.  Do not use quotes in your message.
  27401.  
  27402.  
  27403. -------------------------------------------------------------------------------
  27404.  
  27405. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  27406. Subject: RE: (usr-tc) stop acct. packets
  27407. Date: 28 Apr 1999 16:08:21 -0500
  27408.  
  27409.  
  27410.  
  27411. |-----Original Message-----
  27412. |From: owner-usr-tc@lists.xmission.com
  27413. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Angela A. Burford
  27414. |Sent: Wednesday, April 28, 1999 3:59 PM
  27415. |To: usr-tc@lists.xmission.com
  27416. |Subject: (usr-tc) stop acct. packets
  27417. |
  27418. |
  27419. |
  27420. |
  27421. |My HARC is running code version 4.1.78 and still presents the problem of
  27422. |not sending stop accounting packets once in a while. Has this been fixed
  27423. |in version 4.1.59-6, or any other version?
  27424.  
  27425. Yes.. Fixed since 4.1.72...
  27426.  
  27427. -M
  27428.  
  27429.  
  27430. -
  27431.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27432.  with "unsubscribe usr-tc" in the body of the message.
  27433.  For information on digests or retrieving files and old messages send
  27434.  "help" to the same address.  Do not use quotes in your message.
  27435.  
  27436.  
  27437. -------------------------------------------------------------------------------
  27438.  
  27439. From: Ricky Beam <jfbeam@beaker.interpath.net>
  27440. Subject: Re: (usr-tc) cheat sheet for command line config
  27441. Date: 28 Apr 1999 17:12:02 -0400 (EDT)
  27442.  
  27443. On 28 Apr 1999 zip-usrtc@ran.zipcon.net wrote:
  27444. >Does anyone know of a cheat sheet for command line config of the Hiper
  27445. >ARC, DSP, and NMC?  I'm just about to bring online my first USR-TC.
  27446. >Thanks for any info, Dan
  27447.  
  27448. http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup
  27449.  
  27450. (until they get around to reclaiming the drive space :-))
  27451.  
  27452. --Ricky
  27453.  
  27454.  
  27455.  
  27456. -
  27457.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27458.  with "unsubscribe usr-tc" in the body of the message.
  27459.  For information on digests or retrieving files and old messages send
  27460.  "help" to the same address.  Do not use quotes in your message.
  27461.  
  27462.  
  27463. -------------------------------------------------------------------------------
  27464.  
  27465. From: Steve Rivera <sales@wrca.net>
  27466. Subject: (usr-tc) 3- Netserver 16I Plus
  27467. Date: 28 Apr 1999 17:15:24 -0400
  27468.  
  27469. 3 units avilable now. In NEW condition, complete in original box, with all
  27470. documentation. 
  27471. Including non-registered factroy warranty card.
  27472.  
  27473. They are the PLUS Version :)
  27474.  
  27475. Looking for buyers
  27476.  
  27477. Steve Rivera -  sales@wrca.net -  732-833-2111
  27478.     http://www.wrca.net
  27479. De-installed Net Hardware Wanted:
  27480. WTB: Cisco 2501, 2511, Ascend Max4000 Chassis, MXSL-16MOD-L56, 
  27481. '''''''''''''''''''''''''''''''''''''''''''''''
  27482.  
  27483.  
  27484.  
  27485.      
  27486.   
  27487.  
  27488.  
  27489.  
  27490.  
  27491. -
  27492.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27493.  with "unsubscribe usr-tc" in the body of the message.
  27494.  For information on digests or retrieving files and old messages send
  27495.  "help" to the same address.  Do not use quotes in your message.
  27496.  
  27497.  
  27498. -------------------------------------------------------------------------------
  27499.  
  27500. From: "Angela A. Burford" <aratis@erie.net>
  27501. Subject: RE: (usr-tc) stop acct. packets
  27502. Date: 29 Apr 1999 09:09:34 -0400 (EDT)
  27503.  
  27504. Just got the explanation of why stop accounting packets are not
  27505. working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!)
  27506. Usr got the version numbers mixed up!
  27507.  
  27508. Thanks for the help
  27509. Angela
  27510.  
  27511. On Wed, 28 Apr 1999, Mike Wronski wrote:
  27512.  
  27513. > |My HARC is running code version 4.1.78 and still presents the problem of
  27514. > |not sending stop accounting packets once in a while. Has this been fixed
  27515. > |in version 4.1.59-6, or any other version?
  27516. > 
  27517. > Yes.. Fixed since 4.1.72...
  27518. > 
  27519. > -M
  27520. > 
  27521. > 
  27522. > -
  27523. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27524. >  with "unsubscribe usr-tc" in the body of the message.
  27525. >  For information on digests or retrieving files and old messages send
  27526. >  "help" to the same address.  Do not use quotes in your message.
  27527. > 
  27528.  
  27529.  
  27530. -
  27531.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27532.  with "unsubscribe usr-tc" in the body of the message.
  27533.  For information on digests or retrieving files and old messages send
  27534.  "help" to the same address.  Do not use quotes in your message.
  27535.  
  27536.  
  27537. -------------------------------------------------------------------------------
  27538.  
  27539. From: <vanhalen@coredcs.com>
  27540. Subject: RE: (usr-tc) stop acct. packets
  27541. Date: 29 Apr 1999 08:23:18 -0500 (CDT)
  27542.  
  27543.  
  27544.  
  27545. On Thu, 29 Apr 1999, Angela A. Burford wrote:
  27546.  
  27547. > Just got the explanation of why stop accounting packets are not
  27548. > working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!)
  27549. > Usr got the version numbers mixed up!
  27550. > 
  27551. > Thanks for the help
  27552. > Angela
  27553. > 
  27554.  
  27555. Nope, that's their numbering scheme.
  27556.  
  27557.  
  27558. Steve
  27559.  
  27560.  
  27561. -
  27562.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27563.  with "unsubscribe usr-tc" in the body of the message.
  27564.  For information on digests or retrieving files and old messages send
  27565.  "help" to the same address.  Do not use quotes in your message.
  27566.  
  27567.  
  27568. -------------------------------------------------------------------------------
  27569.  
  27570. From: Jeff Mcadams <jeffm@iglou.com>
  27571. Subject: Re: (usr-tc) stop acct. packets
  27572. Date: 29 Apr 1999 09:27:53 -0400 (EDT)
  27573.  
  27574. Thus spake Angela A. Burford
  27575. >Just got the explanation of why stop accounting packets are not
  27576. >working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!)
  27577. >Usr got the version numbers mixed up!
  27578.  
  27579. No, they're not mixed up...screwed up, yes, but not mixed up.
  27580. Engineering Releases and Service Releases start at x.x.99 and count down
  27581. rather than up.  So, 4.1.78 is older than 4.1.72 which is itself older
  27582. than 4.1.59.  You *probably* should upgrade to 4.1.59 as there are quite
  27583. a few fixes in there from 4.1.72.
  27584. -- 
  27585. Jeff McAdams                            Email: jeffm@iglou.com
  27586. Head Network Administrator              Voice: (502) 966-3848
  27587. IgLou Internet Services                        (800) 436-4456
  27588.  
  27589. -
  27590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27591.  with "unsubscribe usr-tc" in the body of the message.
  27592.  For information on digests or retrieving files and old messages send
  27593.  "help" to the same address.  Do not use quotes in your message.
  27594.  
  27595.  
  27596. -------------------------------------------------------------------------------
  27597.  
  27598. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  27599. Subject: RE: (usr-tc) stop acct. packets
  27600. Date: 29 Apr 1999 09:19:18 -0500
  27601.  
  27602.  
  27603.  
  27604. |-----Original Message-----
  27605. |From: owner-usr-tc@lists.xmission.com
  27606. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Angela A. Burford
  27607. |Sent: Thursday, April 29, 1999 8:10 AM
  27608. |To: usr-tc@lists.xmission.com
  27609. |Subject: RE: (usr-tc) stop acct. packets
  27610. |
  27611. |
  27612. |Just got the explanation of why stop accounting packets are not
  27613. |working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!)
  27614. |Usr got the version numbers mixed up!
  27615.  
  27616. Not mixed up.. But Im not going into it here.. Its been beaten down already :).
  27617. If your still confused about the version numbers.. Search the archives..
  27618.  
  27619. -M
  27620.  
  27621.  
  27622.  
  27623.  
  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: "Angela A. Burford" <aratis@erie.net>
  27635. Subject: Re: (usr-tc) stop acct. packets
  27636. Date: 29 Apr 1999 11:13:09 -0400 (EDT)
  27637.  
  27638. I wish *all* their tech support people knew this! Good thing i have this
  27639. list...
  27640.  
  27641. angela
  27642.  
  27643. On Thu, 29 Apr 1999, Jeff Mcadams wrote:
  27644.  
  27645. > Thus spake Angela A. Burford
  27646. > >Just got the explanation of why stop accounting packets are not
  27647. > >working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!)
  27648. > >Usr got the version numbers mixed up!
  27649. > 
  27650. > No, they're not mixed up...screwed up, yes, but not mixed up.
  27651. > Engineering Releases and Service Releases start at x.x.99 and count down
  27652. > rather than up.  So, 4.1.78 is older than 4.1.72 which is itself older
  27653. > than 4.1.59.  You *probably* should upgrade to 4.1.59 as there are quite
  27654. > a few fixes in there from 4.1.72.
  27655. > -- 
  27656. > Jeff McAdams                            Email: jeffm@iglou.com
  27657. > Head Network Administrator              Voice: (502) 966-3848
  27658. > IgLou Internet Services                        (800) 436-4456
  27659. > 
  27660. > -
  27661. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27662. >  with "unsubscribe usr-tc" in the body of the message.
  27663. >  For information on digests or retrieving files and old messages send
  27664. >  "help" to the same address.  Do not use quotes in your message.
  27665. > 
  27666.  
  27667.  
  27668. -
  27669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27670.  with "unsubscribe usr-tc" in the body of the message.
  27671.  For information on digests or retrieving files and old messages send
  27672.  "help" to the same address.  Do not use quotes in your message.
  27673.  
  27674.  
  27675. -------------------------------------------------------------------------------
  27676.  
  27677. From: Robert von Bismarck <rvb@petrel.ch>
  27678. Subject: (usr-tc) HDSP uptime in TCM ?
  27679. Date: 29 Apr 1999 17:23:52 +0200
  27680.  
  27681. Is there a way to get the uptime of a HDSP in TCM ? I browsed through the
  27682. MIB but didn't find anything... I can get it through the CLI though...
  27683.  
  27684. Thanks
  27685.  
  27686. Robert
  27687.  
  27688.  
  27689. -
  27690.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27691.  with "unsubscribe usr-tc" in the body of the message.
  27692.  For information on digests or retrieving files and old messages send
  27693.  "help" to the same address.  Do not use quotes in your message.
  27694.  
  27695.  
  27696. -------------------------------------------------------------------------------
  27697.  
  27698. From: John Schmerold <john@katy.com>
  27699. Subject: Re: (usr-tc) cheat sheet for command line config
  27700. Date: 29 Apr 1999 10:47:37 -0500
  27701.  
  27702. Thanks.  I sure wish 3COM would offer this information.
  27703.  
  27704. At 04:12 PM 4/28/99 -0500, you wrote:
  27705. >On 28 Apr 1999 zip-usrtc@ran.zipcon.net wrote:
  27706. >>Does anyone know of a cheat sheet for command line config of the Hiper
  27707. >>ARC, DSP, and NMC?  I'm just about to bring online my first USR-TC.
  27708. >>Thanks for any info, Dan
  27709. >
  27710. >http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup
  27711. >
  27712. >(until they get around to reclaiming the drive space :-))
  27713. >
  27714. >--Ricky
  27715. >
  27716. >
  27717. >
  27718. >-
  27719. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27720. > with "unsubscribe usr-tc" in the body of the message.
  27721. > For information on digests or retrieving files and old messages send
  27722. > "help" to the same address.  Do not use quotes in your message.
  27723.  
  27724. John Schmerold
  27725. Katy Computer Systems, Inc.
  27726. 20 Meramec Station Rd
  27727. Valley Park, MO 63088
  27728. 314-316-9000 v
  27729. 314-316-9200 f
  27730. email:  john@katy.com
  27731.  
  27732. -
  27733.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27734.  with "unsubscribe usr-tc" in the body of the message.
  27735.  For information on digests or retrieving files and old messages send
  27736.  "help" to the same address.  Do not use quotes in your message.
  27737.  
  27738.  
  27739. -------------------------------------------------------------------------------
  27740.  
  27741. From: access1 <access1@simplyweb.net>
  27742. Subject: (usr-tc) WTB Total Control USR/3COM Server card EdgeServer Pro
  27743. Date: 29 Apr 1999 11:49:06 -0700
  27744.  
  27745. WTB USR/3COM's Server-on-a-card solution, the EdgeServer Pro for the
  27746. Total Conrtol Chassis, with or without NT 4.0.  Looking for surplus or
  27747. used unit at good price.  May consider older EdgeServer -non "Pro" model
  27748. if set up with 3rd party software to accomodate RADIUS and NT 4.0
  27749.  
  27750.  
  27751. -
  27752.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27753.  with "unsubscribe usr-tc" in the body of the message.
  27754.  For information on digests or retrieving files and old messages send
  27755.  "help" to the same address.  Do not use quotes in your message.
  27756.  
  27757.  
  27758. -------------------------------------------------------------------------------
  27759.  
  27760. From: Steve Rivera <sales@wrca.net>
  27761. Subject: Re: (usr-tc) WTB Total Control USR/3COM Server card EdgeServer
  27762. Date: 30 Apr 1999 10:10:09 -0400
  27763.  
  27764. I have a edgeserver acrd :) It is not a PRO series. Brand new in the box
  27765. with NT4.0
  27766. Asking $3500
  27767.  
  27768. At 11:49 AM 4/29/99 -0700, you wrote:
  27769. >WTB USR/3COM's Server-on-a-card solution, the EdgeServer Pro for the
  27770. >Total Conrtol Chassis, with or without NT 4.0.  Looking for surplus or
  27771. >used unit at good price.  May consider older EdgeServer -non "Pro" model
  27772. >if set up with 3rd party software to accomodate RADIUS and NT 4.0
  27773. >
  27774. >
  27775. >-
  27776. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27777. > with "unsubscribe usr-tc" in the body of the message.
  27778. > For information on digests or retrieving files and old messages send
  27779. > "help" to the same address.  Do not use quotes in your message.
  27780. >
  27781.  
  27782. -
  27783.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27784.  with "unsubscribe usr-tc" in the body of the message.
  27785.  For information on digests or retrieving files and old messages send
  27786.  "help" to the same address.  Do not use quotes in your message.
  27787.  
  27788.  
  27789. -------------------------------------------------------------------------------
  27790.  
  27791. From: "C Thompson" <cthompson@wingnet.net>
  27792. Subject: (usr-tc) USR TC w/Hiper ARC
  27793. Date: 30 Apr 1999 12:13:34 -0500
  27794.  
  27795. We are looking at the possiblity of selling one of our USR/3com Total 
  27796. Control racks.  Specs are as follows:
  27797.  
  27798. Rackmount chassis
  27799. Integrated fan tray
  27800. 1 70 amp PS
  27801. 1 Network Management Card with memory upgrade
  27802. 1 Dual PRI/T1 card
  27803. 12 digital/analog quad modem cards (48 ports)
  27804. X2/V.90 already in place and functional on hardware
  27805. 1 Hiper ARC card (relatively NEW)
  27806.  
  27807. Asking price = around $6995
  27808.  
  27809. Contact me if interested, or if you wish to register 
  27810. a bid.
  27811.  
  27812. We will implement your IP address on the NMC and/or 
  27813. HARC to make configuration easier once you receive 
  27814. the unit.
  27815.  
  27816.  
  27817.  
  27818. Craig Thompson
  27819. WingNET Internet Services,
  27820. P.O. Box 3000 // Cleveland, TN 37320-3000
  27821. 423-559-LINK (v)  423-559-5444 (f)
  27822. http://www.wingnet.net
  27823.  
  27824. Thought for the day:
  27825.     Hope deferred maketh the heart sick,
  27826.     but when the desire cometh, it is a tree of life. (Prov. 13:12)
  27827.  
  27828.  
  27829. -
  27830.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27831.  with "unsubscribe usr-tc" in the body of the message.
  27832.  For information on digests or retrieving files and old messages send
  27833.  "help" to the same address.  Do not use quotes in your message.
  27834.  
  27835.  
  27836. -------------------------------------------------------------------------------
  27837.  
  27838. From: MegaZone <megazone@megazone.org>
  27839. Subject: (usr-tc) Farewell
  27840. Date: 29 Apr 1999 16:25:17 -0700 (PDT)
  27841.  
  27842. I've been a member of this list (aka a nuisance) for several years now
  27843. - but I've decided to unsub.  I don't work directly with NASen
  27844. anymore, and I've been looking at my life and decided I'd rather do
  27845. other things with my time than keep up with everything in the NAS
  27846. world.  Days pass fast enough as it is. :-)
  27847.  
  27848. But I've enjoyed the exchanges here over these past years, and I
  27849. wanted to thank everyone for their opinions, help, and kindness.
  27850.  
  27851. Thanks, take care.
  27852.  
  27853. -MZ
  27854. -- 
  27855. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  27856. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  27857. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  27858. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  27859.  
  27860. -
  27861.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27862.  with "unsubscribe usr-tc" in the body of the message.
  27863.  For information on digests or retrieving files and old messages send
  27864.  "help" to the same address.  Do not use quotes in your message.
  27865.  
  27866.  
  27867. -------------------------------------------------------------------------------
  27868.  
  27869. From: David Bolen <db3l@ans.net>
  27870. Subject: (usr-tc) Moving on
  27871. Date: 30 Apr 1999 14:27:09 EDT
  27872.  
  27873. Originally I figured this might be too presumptuous to send to the
  27874. list at large, but then I figured it's been over three years of
  27875. communicating with many of the folks here (4 if you count the older
  27876. USRTC listserv list) so I figured a quick note couldn't hurt.
  27877.  
  27878. And then MegaZone went and beat me to the punch by a few minutes.
  27879. Sort of an interesting quirk of fate, although I guess Friday and end
  27880. of month is just a nice day :-)
  27881.  
  27882. For myself, I'm going to be moving on from ANS (never did get used to
  27883. thinking of us as UUNET :-)) to new and bigger things, which as it
  27884. happens won't involve NASen and dialup infrastructure, so I'll be
  27885. unsubscribing from this list.
  27886.  
  27887. I have to say that I think this list has shown itself to have one of
  27888. the highest signal to noise ratios of the various forums that I
  27889. follow, which has made it a pleasure to participate in as well as use
  27890. as a resource over the years.  And that's a credit to everyone
  27891. participating on the list.
  27892.  
  27893. So best of luck to everyone.  I may be stepping away from building the
  27894. dial infrastructure, but I'll likely be back on the consumer side, so
  27895. keep those networks running at peak performance!
  27896.  
  27897. -- David
  27898.  
  27899. /-----------------------------------------------------------------------\
  27900.  \               David Bolen              \  Internet: db3l@ans.net    /
  27901.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  27902.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  27903. \-----------------------------------------------------------------------/
  27904.  
  27905. -
  27906.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27907.  with "unsubscribe usr-tc" in the body of the message.
  27908.  For information on digests or retrieving files and old messages send
  27909.  "help" to the same address.  Do not use quotes in your message.
  27910.  
  27911.  
  27912. -------------------------------------------------------------------------------
  27913.  
  27914. From: Jesse Sipprell <jss@evcom.net>
  27915. Subject: (usr-tc) 3com VSA 0x9841
  27916. Date: 30 Apr 1999 16:19:19 -0400
  27917.  
  27918. Can anyone tell me what 3com/USR's 0x9841 VSA is?  My radius server keeps
  27919. getting an attribute with this value, yet I don't have it in my dictionary.
  27920.  
  27921. Thanks!
  27922.  
  27923. -- 
  27924. Jesse Sipprell
  27925. Technical Operations Director
  27926. Evolution Communications, Inc.
  27927. 800-496-4736 (ext 106)
  27928.  
  27929. * Finger jss@evcom.net for my PGP Public Key *
  27930.  
  27931. -
  27932.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27933.  with "unsubscribe usr-tc" in the body of the message.
  27934.  For information on digests or retrieving files and old messages send
  27935.  "help" to the same address.  Do not use quotes in your message.
  27936.  
  27937.  
  27938. -------------------------------------------------------------------------------
  27939.  
  27940. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  27941. Subject: Re: (usr-tc) 3com VSA 0x9841
  27942. Date: 30 Apr 1999 15:52:16 -0500 (CDT)
  27943.  
  27944.   MP-EDO-HIPER                    0x9841  string
  27945.  
  27946. krish
  27947.  
  27948. On Fri, 30 Apr 1999, Jesse Sipprell wrote:
  27949.  
  27950. > Can anyone tell me what 3com/USR's 0x9841 VSA is?  My radius server keeps
  27951. > getting an attribute with this value, yet I don't have it in my dictionary.
  27952. > 
  27953. > Thanks!
  27954. > 
  27955. > -- 
  27956. > Jesse Sipprell
  27957. > Technical Operations Director
  27958. > Evolution Communications, Inc.
  27959. > 800-496-4736 (ext 106)
  27960. > 
  27961. > * Finger jss@evcom.net for my PGP Public Key *
  27962. > 
  27963. > -
  27964. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27965. >  with "unsubscribe usr-tc" in the body of the message.
  27966. >  For information on digests or retrieving files and old messages send
  27967. >  "help" to the same address.  Do not use quotes in your message.
  27968. > 
  27969.  
  27970. -
  27971.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27972.  with "unsubscribe usr-tc" in the body of the message.
  27973.  For information on digests or retrieving files and old messages send
  27974.  "help" to the same address.  Do not use quotes in your message.
  27975.  
  27976.  
  27977. -------------------------------------------------------------------------------
  27978.  
  27979. From: "Al Huefner" <Al_Huefner@mw.3com.com>
  27980. Subject: Re: (usr-tc) Moving on
  27981. Date: 30 Apr 1999 16:23:49 -0500
  27982.  
  27983.  
  27984.  
  27985. David,  on behalf of 3Com, we wish you the best of luck and thanks for your
  27986. excellent support on this forum.  You have always been very helpful and very
  27987. professional.  We wish you the best in whatever you choose to do.  You will be
  27988. missed.  -
  27989.  
  27990. Al Huefner
  27991. VP Carrier Customer Services
  27992. 3Com Corporation
  27993.  
  27994.  
  27995.  
  27996.  
  27997.  
  27998. David Bolen <db3l@ans.net> on 04/30/99 01:27:09 PM
  27999.  
  28000. Please respond to usr-tc@lists.xmission.com
  28001.  
  28002. Sent by:  David Bolen <db3l@ans.net>
  28003.  
  28004.  
  28005. cc:    (Al Huefner/MW/US/3Com)
  28006.  
  28007.  
  28008.  
  28009.  
  28010. Originally I figured this might be too presumptuous to send to the
  28011. list at large, but then I figured it's been over three years of
  28012. communicating with many of the folks here (4 if you count the older
  28013. USRTC listserv list) so I figured a quick note couldn't hurt.
  28014.  
  28015. And then MegaZone went and beat me to the punch by a few minutes.
  28016. Sort of an interesting quirk of fate, although I guess Friday and end
  28017. of month is just a nice day :-)
  28018.  
  28019. For myself, I'm going to be moving on from ANS (never did get used to
  28020. thinking of us as UUNET :-)) to new and bigger things, which as it
  28021. happens won't involve NASen and dialup infrastructure, so I'll be
  28022. unsubscribing from this list.
  28023.  
  28024. I have to say that I think this list has shown itself to have one of
  28025. the highest signal to noise ratios of the various forums that I
  28026. follow, which has made it a pleasure to participate in as well as use
  28027. as a resource over the years.  And that's a credit to everyone
  28028. participating on the list.
  28029.  
  28030. So best of luck to everyone.  I may be stepping away from building the
  28031. dial infrastructure, but I'll likely be back on the consumer side, so
  28032. keep those networks running at peak performance!
  28033.  
  28034. -- David
  28035.  
  28036. /-----------------------------------------------------------------------\
  28037.  \               David Bolen              \  Internet: db3l@ans.net    /
  28038.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  28039.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  28040. \-----------------------------------------------------------------------/
  28041.  
  28042. -
  28043.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28044.  with "unsubscribe usr-tc" in the body of the message.
  28045.  For information on digests or retrieving files and old messages send
  28046.  "help" to the same address.  Do not use quotes in your message.
  28047.  
  28048.  
  28049.  
  28050.  
  28051.  
  28052.  
  28053. -
  28054.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28055.  with "unsubscribe usr-tc" in the body of the message.
  28056.  For information on digests or retrieving files and old messages send
  28057.  "help" to the same address.  Do not use quotes in your message.
  28058.  
  28059.  
  28060. -------------------------------------------------------------------------------
  28061.  
  28062. From: John Mies <jmies@advancenet.net>
  28063. Subject: (usr-tc) Does NOT support IP
  28064. Date: 30 Apr 1999 16:16:42 -0500
  28065.  
  28066. --=====================_16259550==_.ALT
  28067. Content-Type: text/plain; charset="us-ascii"
  28068.  
  28069. Anyone know what this message means?
  28070.  
  28071. New PPP Call received on interface slot:1/mod:10
  28072. PPP - Authentication Complete to spooky75.
  28073. Peer PPP at spooky75 Does NOT support IP, DISABLING.
  28074. (IPCP) Layer Down for Bundle 5885, Link 20829360, to spooky75.
  28075.  
  28076. I walked the customer through her TCP/IP settings blah blah and everything
  28077. should be OK on her side...she did have a weird external modem, tho...
  28078. --=====================_16259550==_.ALT
  28079. Content-Type: text/html; charset="us-ascii"
  28080.  
  28081. <html>
  28082. Anyone know what this message means?<br>
  28083. <br>
  28084. <font face="Helvetica, Helvetica">New PPP Call received on interface
  28085. slot:1/mod:10<br>
  28086. PPP - Authentication Complete to spooky75.<br>
  28087. Peer PPP at spooky75 Does NOT support IP, DISABLING.<br>
  28088. (IPCP) Layer Down for Bundle 5885, Link 20829360, to spooky75.<br>
  28089. <br>
  28090. </font>I walked the customer through her TCP/IP settings blah blah and
  28091. everything should be OK on her side...she did have a weird external
  28092. modem, tho...</html>
  28093.  
  28094. --=====================_16259550==_.ALT--
  28095.  
  28096. -
  28097.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28098.  with "unsubscribe usr-tc" in the body of the message.
  28099.  For information on digests or retrieving files and old messages send
  28100.  "help" to the same address.  Do not use quotes in your message.
  28101.  
  28102.  
  28103. -------------------------------------------------------------------------------
  28104.  
  28105. From: "Frank Basso" <frank@got.net>
  28106. Subject: Re: (usr-tc) Does NOT support IP
  28107. Date: 30 Apr 1999 16:30:35 -0700
  28108.  
  28109. This is a multi-part message in MIME format.
  28110.  
  28111. ------=_NextPart_000_00CA_01BE9326.C6250DB0
  28112. Content-Type: text/plain;
  28113.     charset="iso-8859-1"
  28114. Content-Transfer-Encoding: quoted-printable
  28115.  
  28116. Looks like a windows box sending you IPX or NetBEUI instead of TCP/IP
  28117.   ----- Original Message -----=20
  28118.   From: John Mies=20
  28119.   To: usr-tc@xmission.com=20
  28120.   Sent: Friday, April 30, 1999 2:16 PM
  28121.   Subject: (usr-tc) Does NOT support IP
  28122.  
  28123.  
  28124.   Anyone know what this message means?
  28125.  
  28126.   New PPP Call received on interface slot:1/mod:10
  28127.   PPP - Authentication Complete to spooky75.
  28128.   Peer PPP at spooky75 Does NOT support IP, DISABLING.
  28129.   (IPCP) Layer Down for Bundle 5885, Link 20829360, to spooky75.
  28130.  
  28131.   I walked the customer through her TCP/IP settings blah blah and =
  28132. everything should be OK on her side...she did have a weird external =
  28133. modem, tho...=20
  28134.  
  28135. ------=_NextPart_000_00CA_01BE9326.C6250DB0
  28136. Content-Type: text/html;
  28137.     charset="iso-8859-1"
  28138. Content-Transfer-Encoding: quoted-printable
  28139.  
  28140. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  28141. <HTML><HEAD>
  28142. <META content=3D"text/html; charset=3Diso-8859-1" =
  28143. http-equiv=3DContent-Type>
  28144. <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
  28145. <STYLE></STYLE>
  28146. </HEAD>
  28147. <BODY bgColor=3D#ffffff>
  28148. <DIV><FONT size=3D2>Looks like a windows box sending you IPX =
  28149. or NetBEUI=20
  28150. instead of TCP/IP</FONT></DIV>
  28151. <BLOCKQUOTE=20
  28152. style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
  28153. 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  28154.   <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  28155.   <DIV=20
  28156.   style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
  28157. black"><B>From:</B>=20
  28158.   <A href=3D"mailto:jmies@advancenet.net" =
  28159. title=3Djmies@advancenet.net>John Mies</A>=20
  28160.   </DIV>
  28161.   <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
  28162. href=3D"mailto:usr-tc@xmission.com"=20
  28163.   title=3Dusr-tc@xmission.com>usr-tc@xmission.com</A> </DIV>
  28164.   <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 30, 1999 =
  28165. 2:16=20
  28166. PM</DIV>
  28167.   <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) Does NOT =
  28168. support=20
  28169.   IP</DIV>
  28170.   <DIV><BR></DIV>Anyone know what this message means?<BR><BR><FONT=20
  28171.   face=3D"Helvetica, Helvetica">New PPP Call received on interface=20
  28172.   slot:1/mod:10<BR>PPP - Authentication Complete to spooky75.<BR>Peer =
  28173. PPP at=20
  28174.   spooky75 Does NOT support IP, DISABLING.<BR>(IPCP) Layer Down for =
  28175. Bundle 5885,=20
  28176.   Link 20829360, to spooky75.<BR><BR></FONT>I walked the customer =
  28177. through her=20
  28178.   TCP/IP settings blah blah and everything should be OK on her =
  28179. side...she did=20
  28180.   have a weird external modem, tho... </BLOCKQUOTE></BODY></HTML>
  28181.  
  28182. ------=_NextPart_000_00CA_01BE9326.C6250DB0--
  28183.  
  28184.  
  28185. -
  28186.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28187.  with "unsubscribe usr-tc" in the body of the message.
  28188.  For information on digests or retrieving files and old messages send
  28189.  "help" to the same address.  Do not use quotes in your message.
  28190.  
  28191.