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.199910 < prev    next >
Internet Message Format  |  1999-10-31  |  1MB
  1. From: Jim Johnson <jim@perigee.net>
  2. Subject: Re: (usr-tc) TCHub and routing
  3. Date: 01 Oct 1999 08:00:21 -0400
  4.  
  5.  
  6.  
  7. Make sure you:
  8.  
  9. DISABLE IP SOURCE_ADDRESS_FILTER
  10.  
  11. if you want the routing to actually **work** as opposed to just
  12. **showing up** in the routing table correctly.
  13.  
  14. -Jim
  15.  
  16. > Robb Bryn wrote:
  17. > 
  18. > I'm configuring my first routed subnet on the TCHub and can't quite
  19. > figure out what I'm doing wrong.
  20. > 
  21. > I have a Ascend P50 dialing in via ISDN with radius attributes of:
  22. >     Framed-Address = 208.150.95.241
  23. >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  24. > 
  25. > After connecting, I can ping the ether address of the TCHub
  26. > (208.133.28.51) from any of the subnet hosts can't ping anything past
  27. > it.   I can't ping any host on the subnet from the TCHub.  Below is
  28. > the output from the show ip network command.
  29. > 
  30. > 
  31. > HiPer>> show ip network test-ip-I4586
  32. > 
  33. > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  34. > Interface:                                 slot:14/mod:2
  35. > Network Address:                           208.150.95.241/H
  36. > Frame Type:                                PPP
  37. > Status:                                    ENABLED
  38. > Reconfigure Needed:                        FALSE
  39. > Mask:                                      255.255.255.255
  40. > Station:                                   0.0.0.0
  41. > Broadcast Algorithm:                       IETF
  42. > Max Reassembly Size:                       3464
  43. > IP Routing Protocol:                       NONE
  44. > IP Routing Metric:                         1
  45. > RIP Interface Export Metric:               0
  46. > IP RIP Routing Policies:
  47. > IP RIP Authentication Key:
  48. > HiPer>>
  49. > 
  50. > 
  51. > 
  52. > I'm pulling my hair out trying to figure out what I've done wrong.  A
  53. > kick in the right direction would be greatly appreciated.
  54. > 
  55. > 
  56. > 
  57. > Thanks,
  58. > 
  59. > Robb Bryn
  60.  
  61. -
  62.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  63.  with "unsubscribe usr-tc" in the body of the message.
  64.  For information on digests or retrieving files and old messages send
  65.  "help" to the same address.  Do not use quotes in your message.
  66.  
  67.  
  68. -------------------------------------------------------------------------------
  69.  
  70. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  71. Subject: RE: (usr-tc) TCHub and routing
  72. Date: 01 Oct 1999 09:25:22 -0300 
  73.  
  74.  
  75. I believe you'll also want to build static routes or have the ARC advertise
  76. the subnet using OSPF or RIPv2 if you want that subnet to be reachable from
  77. anywhere other than the ARC itself.
  78.  
  79. Matthew
  80.  
  81. On Friday, October 01, 1999 9:00 AM, Jim Johnson [SMTP:jim@perigee.net]
  82. wrote:
  83. > 
  84. > 
  85. > Make sure you:
  86. > 
  87. > DISABLE IP SOURCE_ADDRESS_FILTER
  88. > 
  89. > if you want the routing to actually **work** as opposed to just
  90. > **showing up** in the routing table correctly.
  91. > 
  92. > -Jim
  93. > 
  94. > > Robb Bryn wrote:
  95. > > 
  96. > > I'm configuring my first routed subnet on the TCHub and can't quite
  97. > > figure out what I'm doing wrong.
  98. > > 
  99. > > I have a Ascend P50 dialing in via ISDN with radius attributes of:
  100. > >     Framed-Address = 208.150.95.241
  101. > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  102. > > 
  103. > > After connecting, I can ping the ether address of the TCHub
  104. > > (208.133.28.51) from any of the subnet hosts can't ping anything past
  105. > > it.   I can't ping any host on the subnet from the TCHub.  Below is
  106. > > the output from the show ip network command.
  107. > > 
  108. > > 
  109. > > HiPer>> show ip network test-ip-I4586
  110. > > 
  111. > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  112. > > Interface:                                 slot:14/mod:2
  113. > > Network Address:                           208.150.95.241/H
  114. > > Frame Type:                                PPP
  115. > > Status:                                    ENABLED
  116. > > Reconfigure Needed:                        FALSE
  117. > > Mask:                                      255.255.255.255
  118. > > Station:                                   0.0.0.0
  119. > > Broadcast Algorithm:                       IETF
  120. > > Max Reassembly Size:                       3464
  121. > > IP Routing Protocol:                       NONE
  122. > > IP Routing Metric:                         1
  123. > > RIP Interface Export Metric:               0
  124. > > IP RIP Routing Policies:
  125. > > IP RIP Authentication Key:
  126. > > HiPer>>
  127. > > 
  128. > > 
  129. > > 
  130. > > I'm pulling my hair out trying to figure out what I've done wrong.  A
  131. > > kick in the right direction would be greatly appreciated.
  132. > > 
  133. > > 
  134. > > 
  135. > > Thanks,
  136. > > 
  137. > > Robb Bryn
  138. > 
  139. > -
  140. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  141. >  with "unsubscribe usr-tc" in the body of the message.
  142. >  For information on digests or retrieving files and old messages send
  143. >  "help" to the same address.  Do not use quotes in your message.
  144.  
  145.  
  146.  
  147. -
  148.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  149.  with "unsubscribe usr-tc" in the body of the message.
  150.  For information on digests or retrieving files and old messages send
  151.  "help" to the same address.  Do not use quotes in your message.
  152.  
  153.  
  154. -------------------------------------------------------------------------------
  155.  
  156. From: "Robb Bryn" <rbryn@cape-fear.net>
  157. Subject: RE: (usr-tc) TCHub and routing
  158. Date: 01 Oct 1999 08:43:07 -0400
  159.  
  160. I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).  How do I turn on
  161. RIPv2 on the arc?
  162.  
  163. Thanks
  164. Robb Bryn
  165.  
  166. > -----Original Message-----
  167. > From: owner-usr-tc@lists.xmission.com
  168. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  169. > Stainforth, Matthew
  170. > Sent: Friday, October 01, 1999 8:25 AM
  171. > To: 'usr-tc@lists.xmission.com'
  172. > Subject: RE: (usr-tc) TCHub and routing
  173. >
  174. >
  175. >
  176. > I believe you'll also want to build static routes or have the
  177. > ARC advertise
  178. > the subnet using OSPF or RIPv2 if you want that subnet to be
  179. > reachable from
  180. > anywhere other than the ARC itself.
  181. >
  182. > Matthew
  183. >
  184. > On Friday, October 01, 1999 9:00 AM, Jim Johnson
  185. > [SMTP:jim@perigee.net]
  186. > wrote:
  187. > >
  188. > >
  189. > > Make sure you:
  190. > >
  191. > > DISABLE IP SOURCE_ADDRESS_FILTER
  192. > >
  193. > > if you want the routing to actually **work** as opposed to just
  194. > > **showing up** in the routing table correctly.
  195. > >
  196. > > -Jim
  197. > >
  198. > > > Robb Bryn wrote:
  199. > > >
  200. > > > I'm configuring my first routed subnet on the TCHub and
  201. > can't quite
  202. > > > figure out what I'm doing wrong.
  203. > > >
  204. > > > I have a Ascend P50 dialing in via ISDN with radius attributes of:
  205. > > >     Framed-Address = 208.150.95.241
  206. > > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  207. > > >
  208. > > > After connecting, I can ping the ether address of the TCHub
  209. > > > (208.133.28.51) from any of the subnet hosts can't ping
  210. > anything past
  211. > > > it.   I can't ping any host on the subnet from the TCHub.
  212. >  Below is
  213. > > > the output from the show ip network command.
  214. > > >
  215. > > >
  216. > > > HiPer>> show ip network test-ip-I4586
  217. > > >
  218. > > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  219. > > > Interface:                                 slot:14/mod:2
  220. > > > Network Address:                           208.150.95.241/H
  221. > > > Frame Type:                                PPP
  222. > > > Status:                                    ENABLED
  223. > > > Reconfigure Needed:                        FALSE
  224. > > > Mask:                                      255.255.255.255
  225. > > > Station:                                   0.0.0.0
  226. > > > Broadcast Algorithm:                       IETF
  227. > > > Max Reassembly Size:                       3464
  228. > > > IP Routing Protocol:                       NONE
  229. > > > IP Routing Metric:                         1
  230. > > > RIP Interface Export Metric:               0
  231. > > > IP RIP Routing Policies:
  232. > > > IP RIP Authentication Key:
  233. > > > HiPer>>
  234. > > >
  235. > > >
  236. > > >
  237. > > > I'm pulling my hair out trying to figure out what I've
  238. > done wrong.  A
  239. > > > kick in the right direction would be greatly appreciated.
  240. > > >
  241. > > >
  242. > > >
  243. > > > Thanks,
  244. > > >
  245. > > > Robb Bryn
  246. > >
  247. > > -
  248. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  249. > >  with "unsubscribe usr-tc" in the body of the message.
  250. > >  For information on digests or retrieving files and old
  251. > messages send
  252. > >  "help" to the same address.  Do not use quotes in your message.
  253. >
  254. >
  255. >
  256. > -
  257. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  258. >  with "unsubscribe usr-tc" in the body of the message.
  259. >  For information on digests or retrieving files and old messages send
  260. >  "help" to the same address.  Do not use quotes in your message.
  261. >
  262.  
  263.  
  264. -
  265.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  266.  with "unsubscribe usr-tc" in the body of the message.
  267.  For information on digests or retrieving files and old messages send
  268.  "help" to the same address.  Do not use quotes in your message.
  269.  
  270.  
  271. -------------------------------------------------------------------------------
  272.  
  273. From: Jim Johnson <jim@perigee.net>
  274. Subject: Re: (usr-tc) TCHub and routing
  275. Date: 01 Oct 1999 09:05:02 -0400
  276.  
  277.  
  278. set ip network ip2 routing_protocol ripv2
  279.  
  280. Robb Bryn wrote:
  281. > 
  282. > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).  How do I turn on
  283. > RIPv2 on the arc?
  284. > 
  285. > Thanks
  286. > Robb Bryn
  287. > 
  288. > > -----Original Message-----
  289. > > From: owner-usr-tc@lists.xmission.com
  290. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  291. > > Stainforth, Matthew
  292. > > Sent: Friday, October 01, 1999 8:25 AM
  293. > > To: 'usr-tc@lists.xmission.com'
  294. > > Subject: RE: (usr-tc) TCHub and routing
  295. > >
  296. > >
  297. > >
  298. > > I believe you'll also want to build static routes or have the
  299. > > ARC advertise
  300. > > the subnet using OSPF or RIPv2 if you want that subnet to be
  301. > > reachable from
  302. > > anywhere other than the ARC itself.
  303. > >
  304. > > Matthew
  305. > >
  306. > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
  307. > > [SMTP:jim@perigee.net]
  308. > > wrote:
  309. > > >
  310. > > >
  311. > > > Make sure you:
  312. > > >
  313. > > > DISABLE IP SOURCE_ADDRESS_FILTER
  314. > > >
  315. > > > if you want the routing to actually **work** as opposed to just
  316. > > > **showing up** in the routing table correctly.
  317. > > >
  318. > > > -Jim
  319. > > >
  320. > > > > Robb Bryn wrote:
  321. > > > >
  322. > > > > I'm configuring my first routed subnet on the TCHub and
  323. > > can't quite
  324. > > > > figure out what I'm doing wrong.
  325. > > > >
  326. > > > > I have a Ascend P50 dialing in via ISDN with radius attributes of:
  327. > > > >     Framed-Address = 208.150.95.241
  328. > > > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  329. > > > >
  330. > > > > After connecting, I can ping the ether address of the TCHub
  331. > > > > (208.133.28.51) from any of the subnet hosts can't ping
  332. > > anything past
  333. > > > > it.   I can't ping any host on the subnet from the TCHub.
  334. > >  Below is
  335. > > > > the output from the show ip network command.
  336. > > > >
  337. > > > >
  338. > > > > HiPer>> show ip network test-ip-I4586
  339. > > > >
  340. > > > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  341. > > > > Interface:                                 slot:14/mod:2
  342. > > > > Network Address:                           208.150.95.241/H
  343. > > > > Frame Type:                                PPP
  344. > > > > Status:                                    ENABLED
  345. > > > > Reconfigure Needed:                        FALSE
  346. > > > > Mask:                                      255.255.255.255
  347. > > > > Station:                                   0.0.0.0
  348. > > > > Broadcast Algorithm:                       IETF
  349. > > > > Max Reassembly Size:                       3464
  350. > > > > IP Routing Protocol:                       NONE
  351. > > > > IP Routing Metric:                         1
  352. > > > > RIP Interface Export Metric:               0
  353. > > > > IP RIP Routing Policies:
  354. > > > > IP RIP Authentication Key:
  355. > > > > HiPer>>
  356. > > > >
  357. > > > >
  358. > > > >
  359. > > > > I'm pulling my hair out trying to figure out what I've
  360. > > done wrong.  A
  361. > > > > kick in the right direction would be greatly appreciated.
  362. > > > >
  363. > > > >
  364. > > > >
  365. > > > > Thanks,
  366. > > > >
  367. > > > > Robb Bryn
  368. > > >
  369. > > > -
  370. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  371. > > >  with "unsubscribe usr-tc" in the body of the message.
  372. > > >  For information on digests or retrieving files and old
  373. > > messages send
  374. > > >  "help" to the same address.  Do not use quotes in your message.
  375. > >
  376. > >
  377. > >
  378. > > -
  379. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  380. > >  with "unsubscribe usr-tc" in the body of the message.
  381. > >  For information on digests or retrieving files and old messages send
  382. > >  "help" to the same address.  Do not use quotes in your message.
  383. > >
  384. > 
  385. > -
  386. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  387. >  with "unsubscribe usr-tc" in the body of the message.
  388. >  For information on digests or retrieving files and old messages send
  389. >  "help" to the same address.  Do not use quotes in your message.
  390.  
  391. -
  392.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  393.  with "unsubscribe usr-tc" in the body of the message.
  394.  For information on digests or retrieving files and old messages send
  395.  "help" to the same address.  Do not use quotes in your message.
  396.  
  397.  
  398. -------------------------------------------------------------------------------
  399.  
  400. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  401. Subject: RE: (usr-tc) TCHub and routing
  402. Date: 01 Oct 1999 10:07:46 -0300 
  403.  
  404.  
  405. You'll also have to make sure your router is listening to ripv2 routing
  406. updates.
  407.  
  408. On Friday, October 01, 1999 10:05 AM, Jim Johnson [SMTP:jim@perigee.net]
  409. wrote:
  410. > 
  411. > set ip network ip2 routing_protocol ripv2
  412. > 
  413. > Robb Bryn wrote:
  414. > > 
  415. > > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).  How do I
  416. turn
  417. > > on
  418. > > RIPv2 on the arc?
  419. > > 
  420. > > Thanks
  421. > > Robb Bryn
  422. > > 
  423. > > > -----Original Message-----
  424. > > > From: owner-usr-tc@lists.xmission.com
  425. > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  426. > > > Stainforth, Matthew
  427. > > > Sent: Friday, October 01, 1999 8:25 AM
  428. > > > To: 'usr-tc@lists.xmission.com'
  429. > > > Subject: RE: (usr-tc) TCHub and routing
  430. > > >
  431. > > >
  432. > > >
  433. > > > I believe you'll also want to build static routes or have the
  434. > > > ARC advertise
  435. > > > the subnet using OSPF or RIPv2 if you want that subnet to be
  436. > > > reachable from
  437. > > > anywhere other than the ARC itself.
  438. > > >
  439. > > > Matthew
  440. > > >
  441. > > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
  442. > > > [SMTP:jim@perigee.net]
  443. > > > wrote:
  444. > > > >
  445. > > > >
  446. > > > > Make sure you:
  447. > > > >
  448. > > > > DISABLE IP SOURCE_ADDRESS_FILTER
  449. > > > >
  450. > > > > if you want the routing to actually **work** as opposed to just
  451. > > > > **showing up** in the routing table correctly.
  452. > > > >
  453. > > > > -Jim
  454. > > > >
  455. > > > > > Robb Bryn wrote:
  456. > > > > >
  457. > > > > > I'm configuring my first routed subnet on the TCHub and
  458. > > > can't quite
  459. > > > > > figure out what I'm doing wrong.
  460. > > > > >
  461. > > > > > I have a Ascend P50 dialing in via ISDN with radius attributes of:
  462. > > > > >     Framed-Address = 208.150.95.241
  463. > > > > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  464. > > > > >
  465. > > > > > After connecting, I can ping the ether address of the TCHub
  466. > > > > > (208.133.28.51) from any of the subnet hosts can't ping
  467. > > > anything past
  468. > > > > > it.   I can't ping any host on the subnet from the TCHub.
  469. > > >  Below is
  470. > > > > > the output from the show ip network command.
  471. > > > > >
  472. > > > > >
  473. > > > > > HiPer>> show ip network test-ip-I4586
  474. > > > > >
  475. > > > > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  476. > > > > > Interface:                                 slot:14/mod:2
  477. > > > > > Network Address:                           208.150.95.241/H
  478. > > > > > Frame Type:                                PPP
  479. > > > > > Status:                                    ENABLED
  480. > > > > > Reconfigure Needed:                        FALSE
  481. > > > > > Mask:                                      255.255.255.255
  482. > > > > > Station:                                   0.0.0.0
  483. > > > > > Broadcast Algorithm:                       IETF
  484. > > > > > Max Reassembly Size:                       3464
  485. > > > > > IP Routing Protocol:                       NONE
  486. > > > > > IP Routing Metric:                         1
  487. > > > > > RIP Interface Export Metric:               0
  488. > > > > > IP RIP Routing Policies:
  489. > > > > > IP RIP Authentication Key:
  490. > > > > > HiPer>>
  491. > > > > >
  492. > > > > >
  493. > > > > >
  494. > > > > > I'm pulling my hair out trying to figure out what I've
  495. > > > done wrong.  A
  496. > > > > > kick in the right direction would be greatly appreciated.
  497. > > > > >
  498. > > > > >
  499. > > > > >
  500. > > > > > Thanks,
  501. > > > > >
  502. > > > > > Robb Bryn
  503. > > > >
  504. > > > > -
  505. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  506. > > > >  with "unsubscribe usr-tc" in the body of the message.
  507. > > > >  For information on digests or retrieving files and old
  508. > > > messages send
  509. > > > >  "help" to the same address.  Do not use quotes in your message.
  510. > > >
  511. > > >
  512. > > >
  513. > > > -
  514. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  515. > > >  with "unsubscribe usr-tc" in the body of the message.
  516. > > >  For information on digests or retrieving files and old messages send
  517. > > >  "help" to the same address.  Do not use quotes in your message.
  518. > > >
  519. > > 
  520. > > -
  521. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  522. > >  with "unsubscribe usr-tc" in the body of the message.
  523. > >  For information on digests or retrieving files and old messages send
  524. > >  "help" to the same address.  Do not use quotes in your message.
  525. > 
  526. > -
  527. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  528. >  with "unsubscribe usr-tc" in the body of the message.
  529. >  For information on digests or retrieving files and old messages send
  530. >  "help" to the same address.  Do not use quotes in your message.
  531.  
  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: "Robb Bryn" <rbryn@cape-fear.net>
  544. Subject: RE: (usr-tc) TCHub and routing
  545. Date: 01 Oct 1999 09:36:25 -0400
  546.  
  547. How does this work if the Network changes each time they logon? The Network
  548. in question may be test-ip-I4586 on one logon and  test-ip-I4588 the next
  549. time?
  550.  
  551. Thanks
  552. Robb Bryn
  553.  
  554. > -----Original Message-----
  555. > From: owner-usr-tc@lists.xmission.com
  556. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  557. > Sent: Friday, October 01, 1999 9:05 AM
  558. > To: usr-tc@lists.xmission.com
  559. > Subject: Re: (usr-tc) TCHub and routing
  560. >
  561. >
  562. >
  563. > set ip network ip2 routing_protocol ripv2
  564. >
  565. > Robb Bryn wrote:
  566. > >
  567. > > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).
  568. > How do I turn on
  569. > > RIPv2 on the arc?
  570. > >
  571. > > Thanks
  572. > > Robb Bryn
  573. > >
  574. > > > -----Original Message-----
  575. > > > From: owner-usr-tc@lists.xmission.com
  576. > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  577. > > > Stainforth, Matthew
  578. > > > Sent: Friday, October 01, 1999 8:25 AM
  579. > > > To: 'usr-tc@lists.xmission.com'
  580. > > > Subject: RE: (usr-tc) TCHub and routing
  581. > > >
  582. > > >
  583. > > >
  584. > > > I believe you'll also want to build static routes or have the
  585. > > > ARC advertise
  586. > > > the subnet using OSPF or RIPv2 if you want that subnet to be
  587. > > > reachable from
  588. > > > anywhere other than the ARC itself.
  589. > > >
  590. > > > Matthew
  591. > > >
  592. > > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
  593. > > > [SMTP:jim@perigee.net]
  594. > > > wrote:
  595. > > > >
  596. > > > >
  597. > > > > Make sure you:
  598. > > > >
  599. > > > > DISABLE IP SOURCE_ADDRESS_FILTER
  600. > > > >
  601. > > > > if you want the routing to actually **work** as opposed to just
  602. > > > > **showing up** in the routing table correctly.
  603. > > > >
  604. > > > > -Jim
  605. > > > >
  606. > > > > > Robb Bryn wrote:
  607. > > > > >
  608. > > > > > I'm configuring my first routed subnet on the TCHub and
  609. > > > can't quite
  610. > > > > > figure out what I'm doing wrong.
  611. > > > > >
  612. > > > > > I have a Ascend P50 dialing in via ISDN with radius
  613. > attributes of:
  614. > > > > >     Framed-Address = 208.150.95.241
  615. > > > > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  616. > > > > >
  617. > > > > > After connecting, I can ping the ether address of the TCHub
  618. > > > > > (208.133.28.51) from any of the subnet hosts can't ping
  619. > > > anything past
  620. > > > > > it.   I can't ping any host on the subnet from the TCHub.
  621. > > >  Below is
  622. > > > > > the output from the show ip network command.
  623. > > > > >
  624. > > > > >
  625. > > > > > HiPer>> show ip network test-ip-I4586
  626. > > > > >
  627. > > > > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  628. > > > > > Interface:                                 slot:14/mod:2
  629. > > > > > Network Address:                           208.150.95.241/H
  630. > > > > > Frame Type:                                PPP
  631. > > > > > Status:                                    ENABLED
  632. > > > > > Reconfigure Needed:                        FALSE
  633. > > > > > Mask:                                      255.255.255.255
  634. > > > > > Station:                                   0.0.0.0
  635. > > > > > Broadcast Algorithm:                       IETF
  636. > > > > > Max Reassembly Size:                       3464
  637. > > > > > IP Routing Protocol:                       NONE
  638. > > > > > IP Routing Metric:                         1
  639. > > > > > RIP Interface Export Metric:               0
  640. > > > > > IP RIP Routing Policies:
  641. > > > > > IP RIP Authentication Key:
  642. > > > > > HiPer>>
  643. > > > > >
  644. > > > > >
  645. > > > > >
  646. > > > > > I'm pulling my hair out trying to figure out what I've
  647. > > > done wrong.  A
  648. > > > > > kick in the right direction would be greatly appreciated.
  649. > > > > >
  650. > > > > >
  651. > > > > >
  652. > > > > > Thanks,
  653. > > > > >
  654. > > > > > Robb Bryn
  655. > > > >
  656. >
  657.  
  658.  
  659. -
  660.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  661.  with "unsubscribe usr-tc" in the body of the message.
  662.  For information on digests or retrieving files and old messages send
  663.  "help" to the same address.  Do not use quotes in your message.
  664.  
  665.  
  666. -------------------------------------------------------------------------------
  667.  
  668. From: Jim Johnson <jim@perigee.net>
  669. Subject: Re: (usr-tc) TCHub and routing
  670. Date: 01 Oct 1999 09:56:50 -0400
  671.  
  672.  
  673. Not sure what you mean here, but if you have RIP enabled on the ARCs and
  674. RIP enabled on your routers they will see all the routes within a
  675. particular POP.  If you need to move the routes between your POPs, you
  676. will need to redistribute the RIP routes using a IGRP like OSPF between
  677. all of your core routers's so they see the routing updates.
  678.  
  679. This is a common subject in the list so you might want to check the
  680. archives.
  681.  
  682. -Jim
  683.  
  684. Robb Bryn wrote:
  685. > 
  686. > How does this work if the Network changes each time they logon? The Network
  687. > in question may be test-ip-I4586 on one logon and  test-ip-I4588 the next
  688. > time?
  689. > 
  690. > Thanks
  691. > Robb Bryn
  692. > 
  693. > > -----Original Message-----
  694. > > From: owner-usr-tc@lists.xmission.com
  695. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  696. > > Sent: Friday, October 01, 1999 9:05 AM
  697. > > To: usr-tc@lists.xmission.com
  698. > > Subject: Re: (usr-tc) TCHub and routing
  699. > >
  700. > >
  701. > >
  702. > > set ip network ip2 routing_protocol ripv2
  703. > >
  704. > > Robb Bryn wrote:
  705. > > >
  706. > > > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).
  707. > > How do I turn on
  708. > > > RIPv2 on the arc?
  709. > > >
  710. > > > Thanks
  711. > > > Robb Bryn
  712. > > >
  713. > > > > -----Original Message-----
  714. > > > > From: owner-usr-tc@lists.xmission.com
  715. > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  716. > > > > Stainforth, Matthew
  717. > > > > Sent: Friday, October 01, 1999 8:25 AM
  718. > > > > To: 'usr-tc@lists.xmission.com'
  719. > > > > Subject: RE: (usr-tc) TCHub and routing
  720. > > > >
  721. > > > >
  722. > > > >
  723. > > > > I believe you'll also want to build static routes or have the
  724. > > > > ARC advertise
  725. > > > > the subnet using OSPF or RIPv2 if you want that subnet to be
  726. > > > > reachable from
  727. > > > > anywhere other than the ARC itself.
  728. > > > >
  729. > > > > Matthew
  730. > > > >
  731. > > > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
  732. > > > > [SMTP:jim@perigee.net]
  733. > > > > wrote:
  734. > > > > >
  735. > > > > >
  736. > > > > > Make sure you:
  737. > > > > >
  738. > > > > > DISABLE IP SOURCE_ADDRESS_FILTER
  739. > > > > >
  740. > > > > > if you want the routing to actually **work** as opposed to just
  741. > > > > > **showing up** in the routing table correctly.
  742. > > > > >
  743. > > > > > -Jim
  744. > > > > >
  745. > > > > > > Robb Bryn wrote:
  746. > > > > > >
  747. > > > > > > I'm configuring my first routed subnet on the TCHub and
  748. > > > > can't quite
  749. > > > > > > figure out what I'm doing wrong.
  750. > > > > > >
  751. > > > > > > I have a Ascend P50 dialing in via ISDN with radius
  752. > > attributes of:
  753. > > > > > >     Framed-Address = 208.150.95.241
  754. > > > > > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  755. > > > > > >
  756. > > > > > > After connecting, I can ping the ether address of the TCHub
  757. > > > > > > (208.133.28.51) from any of the subnet hosts can't ping
  758. > > > > anything past
  759. > > > > > > it.   I can't ping any host on the subnet from the TCHub.
  760. > > > >  Below is
  761. > > > > > > the output from the show ip network command.
  762. > > > > > >
  763. > > > > > >
  764. > > > > > > HiPer>> show ip network test-ip-I4586
  765. > > > > > >
  766. > > > > > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  767. > > > > > > Interface:                                 slot:14/mod:2
  768. > > > > > > Network Address:                           208.150.95.241/H
  769. > > > > > > Frame Type:                                PPP
  770. > > > > > > Status:                                    ENABLED
  771. > > > > > > Reconfigure Needed:                        FALSE
  772. > > > > > > Mask:                                      255.255.255.255
  773. > > > > > > Station:                                   0.0.0.0
  774. > > > > > > Broadcast Algorithm:                       IETF
  775. > > > > > > Max Reassembly Size:                       3464
  776. > > > > > > IP Routing Protocol:                       NONE
  777. > > > > > > IP Routing Metric:                         1
  778. > > > > > > RIP Interface Export Metric:               0
  779. > > > > > > IP RIP Routing Policies:
  780. > > > > > > IP RIP Authentication Key:
  781. > > > > > > HiPer>>
  782. > > > > > >
  783. > > > > > >
  784. > > > > > >
  785. > > > > > > I'm pulling my hair out trying to figure out what I've
  786. > > > > done wrong.  A
  787. > > > > > > kick in the right direction would be greatly appreciated.
  788. > > > > > >
  789. > > > > > >
  790. > > > > > >
  791. > > > > > > Thanks,
  792. > > > > > >
  793. > > > > > > Robb Bryn
  794. > > > > >
  795. > >
  796. > 
  797. > -
  798. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  799. >  with "unsubscribe usr-tc" in the body of the message.
  800. >  For information on digests or retrieving files and old messages send
  801. >  "help" to the same address.  Do not use quotes in your message.
  802.  
  803. -
  804.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  805.  with "unsubscribe usr-tc" in the body of the message.
  806.  For information on digests or retrieving files and old messages send
  807.  "help" to the same address.  Do not use quotes in your message.
  808.  
  809.  
  810. -------------------------------------------------------------------------------
  811.  
  812. From: "Robb Bryn" <rbryn@cape-fear.net>
  813. Subject: RE: (usr-tc) UPDATE TCHub and routing UDDATE
  814. Date: 01 Oct 1999 10:15:46 -0400
  815.  
  816. I think I may have an underlying problem with the IP class I'm trying to use
  817. for the route.  Let me see if I have my logic right....
  818.  
  819.  
  820. I have a primary Class C that I use for this particular chassis
  821. (208.133.28.0/24) all 208.133.28.0 addresses work perfectly (routed subnets
  822. as well)  the IP pool I am using for dialups is 208.133.28.55/25 with 48
  823. ips.  I am using Radius to specify reserved IP's.
  824.  
  825. I just configured a standard (non sub netted) dialup from the new
  826. 208.150.95.0/24 class C (testing a theory on my problem with the subnet
  827. route I'm trying to add).  The single dialup is only able to access the
  828. arc's ip address of 208.133.28.51, all other addresses won't ping out.
  829.  
  830. My Cisco's Ethernet 0 is configured with 2 ip's 208.133.28.1 & 208.150.95.1
  831. RIP is enabled and working properly (I have other routers on the network
  832. that are using RIP successfully).  I can configure a Network workstation
  833. with an ip from the 208.150.95.0 network and it routes successfully through
  834. the Cisco.
  835.  
  836. So, I'm not sure now if it's a RIP issue or a Idiot config error.  Is there
  837. anything special I need to do to enable another Class C on the chassis?  I
  838. have enabled IP forwarding, I have enabled RIP routing.  When I do a "list
  839. ip routes" it shows up as :
  840. 208.150.95.15/H  LOCAL  208.150.95.15   1       slot:14/mod:17
  841.  
  842.  
  843. One last question.... where are the archives for this mailing list (so I can
  844. continue digging)?  I have watched and learned from everyone on this list (I
  845. greatly appreciate everyone's help).
  846.  
  847. Thanks
  848. Robb Bryn
  849.  
  850. > -----Original Message-----
  851. > From: owner-usr-tc@lists.xmission.com
  852. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  853. > Sent: Friday, October 01, 1999 9:05 AM
  854. > To: usr-tc@lists.xmission.com
  855. > Subject: Re: (usr-tc) TCHub and routing
  856. >
  857. >
  858. >
  859. > set ip network ip2 routing_protocol ripv2
  860. >
  861. > Robb Bryn wrote:
  862. > >
  863. > > I've disabled IP SOURCE_ADDRESS_FILTER allready (no luck).
  864. > How do I turn on
  865. > > RIPv2 on the arc?
  866. > >
  867. > > Thanks
  868. > > Robb Bryn
  869. > >
  870. > > > -----Original Message-----
  871. > > > From: owner-usr-tc@lists.xmission.com
  872. > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  873. > > > Stainforth, Matthew
  874. > > > Sent: Friday, October 01, 1999 8:25 AM
  875. > > > To: 'usr-tc@lists.xmission.com'
  876. > > > Subject: RE: (usr-tc) TCHub and routing
  877. > > >
  878. > > >
  879. > > >
  880. > > > I believe you'll also want to build static routes or have the
  881. > > > ARC advertise
  882. > > > the subnet using OSPF or RIPv2 if you want that subnet to be
  883. > > > reachable from
  884. > > > anywhere other than the ARC itself.
  885. > > >
  886. > > > Matthew
  887. > > >
  888. > > > On Friday, October 01, 1999 9:00 AM, Jim Johnson
  889. > > > [SMTP:jim@perigee.net]
  890. > > > wrote:
  891. > > > >
  892. > > > >
  893. > > > > Make sure you:
  894. > > > >
  895. > > > > DISABLE IP SOURCE_ADDRESS_FILTER
  896. > > > >
  897. > > > > if you want the routing to actually **work** as opposed to just
  898. > > > > **showing up** in the routing table correctly.
  899. > > > >
  900. > > > > -Jim
  901. > > > >
  902. > > > > > Robb Bryn wrote:
  903. > > > > >
  904. > > > > > I'm configuring my first routed subnet on the TCHub and
  905. > > > can't quite
  906. > > > > > figure out what I'm doing wrong.
  907. > > > > >
  908. > > > > > I have a Ascend P50 dialing in via ISDN with radius
  909. > attributes of:
  910. > > > > >     Framed-Address = 208.150.95.241
  911. > > > > >     Framed-Route = 208.150.95.240/29 208.150.95.241 1
  912. > > > > >
  913. > > > > > After connecting, I can ping the ether address of the TCHub
  914. > > > > > (208.133.28.51) from any of the subnet hosts can't ping
  915. > > > anything past
  916. > > > > > it.   I can't ping any host on the subnet from the TCHub.
  917. > > >  Below is
  918. > > > > > the output from the show ip network command.
  919. > > > > >
  920. > > > > >
  921. > > > > > HiPer>> show ip network test-ip-I4586
  922. > > > > >
  923. > > > > > SHOW IP  NETWORK test-ip-I4586 SETTINGS:
  924. > > > > > Interface:                                 slot:14/mod:2
  925. > > > > > Network Address:                           208.150.95.241/H
  926. > > > > > Frame Type:                                PPP
  927. > > > > > Status:                                    ENABLED
  928. > > > > > Reconfigure Needed:                        FALSE
  929. > > > > > Mask:                                      255.255.255.255
  930. > > > > > Station:                                   0.0.0.0
  931. > > > > > Broadcast Algorithm:                       IETF
  932. > > > > > Max Reassembly Size:                       3464
  933. > > > > > IP Routing Protocol:                       NONE
  934. > > > > > IP Routing Metric:                         1
  935. > > > > > RIP Interface Export Metric:               0
  936. > > > > > IP RIP Routing Policies:
  937. > > > > > IP RIP Authentication Key:
  938. > > > > > HiPer>>
  939. > > > > >
  940. > > > > >
  941. > > > > >
  942. > > > > > I'm pulling my hair out trying to figure out what I've
  943. > > > done wrong.  A
  944. > > > > > kick in the right direction would be greatly appreciated.
  945. > > > > >
  946. > > > > >
  947. > > > > >
  948. > > > > > Thanks,
  949. > > > > >
  950. > > > > > Robb Bryn
  951. > > > >
  952. > > > > -
  953. >
  954.  
  955.  
  956. -
  957.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  958.  with "unsubscribe usr-tc" in the body of the message.
  959.  For information on digests or retrieving files and old messages send
  960.  "help" to the same address.  Do not use quotes in your message.
  961.  
  962.  
  963. -------------------------------------------------------------------------------
  964.  
  965. From: Scott Trautman <scottt@corp.gdinet.com>
  966. Subject: (usr-tc) TimeZone Reality Check for ARC's
  967. Date: 01 Oct 1999 09:50:21 -0500 
  968.  
  969. ARC's only do GMT?
  970.  
  971. Time IS correct w/NTP, but could find nothing on setting TimeZone.
  972. Makes "list connections"'s look weird with the login times, but that's about
  973. it.
  974.  
  975. SMT
  976.  
  977. Scott M. Trautman               800-482-4638
  978. Global Dialog Internet          608-240-4638,4637fax
  979. 2810 Crossroads, STE LL2         scott@gdinet.com
  980. Madison WI 53718                    http://www.gdinet.com
  981.  
  982. -
  983.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  984.  with "unsubscribe usr-tc" in the body of the message.
  985.  For information on digests or retrieving files and old messages send
  986.  "help" to the same address.  Do not use quotes in your message.
  987.  
  988.  
  989. -------------------------------------------------------------------------------
  990.  
  991. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  992. Subject: RE: (usr-tc) TimeZone Reality Check for ARC's
  993. Date: 01 Oct 1999 10:05:57 -0500
  994.  
  995.  
  996.  
  997. |-----Original Message-----
  998. |From: owner-usr-tc@lists.xmission.com
  999. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman
  1000. |Sent: Friday, October 01, 1999 9:50 AM
  1001. |To: 'usr-tc@lists.xmission.com'
  1002. |Subject: (usr-tc) TimeZone Reality Check for ARC's
  1003. |
  1004. |
  1005. |ARC's only do GMT?
  1006. |
  1007. |Time IS correct w/NTP, but could find nothing on setting TimeZone.
  1008. |Makes "list connections"'s look weird with the login times, but that's about
  1009. |it.
  1010. |
  1011.  
  1012. You are correct sir.
  1013.  
  1014. -M
  1015.  
  1016.  
  1017. -
  1018.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1019.  with "unsubscribe usr-tc" in the body of the message.
  1020.  For information on digests or retrieving files and old messages send
  1021.  "help" to the same address.  Do not use quotes in your message.
  1022.  
  1023.  
  1024. -------------------------------------------------------------------------------
  1025.  
  1026. From: Jerry Wright <jwright@hyperserv.com>
  1027. Subject: Re: (usr-tc) Going nowhere fast...
  1028. Date: 01 Oct 1999 08:39:35 -0700
  1029.  
  1030. To those of you who thought routing might be a problem...
  1031.    Right on!
  1032.      It turns out that I had routing in the problem box set to "quiet". 
  1033. Both boxes are now set to "listen".  Hopefully this will fix the
  1034. problem.
  1035.                         --Jerry
  1036.  
  1037. -
  1038.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1039.  with "unsubscribe usr-tc" in the body of the message.
  1040.  For information on digests or retrieving files and old messages send
  1041.  "help" to the same address.  Do not use quotes in your message.
  1042.  
  1043.  
  1044. -------------------------------------------------------------------------------
  1045.  
  1046. From: "Max Gargani" <max@cgf.flashnet.it>
  1047. Subject: (usr-tc) OID for Hiper
  1048. Date: 01 Oct 1999 18:05:16 +0200
  1049.  
  1050. Hi all,
  1051.  
  1052. I'm new on this list. I'm looking for OID to check user connected to my
  1053. USR-TC Hiper with MRTG.
  1054.  
  1055. I found OID for normal TC and for Cisco AS5x00 but not for TC Hiper.
  1056.  
  1057. Any help?
  1058.  
  1059. Thanx in advance,
  1060. Max
  1061.  
  1062.  
  1063.  
  1064. -
  1065.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1066.  with "unsubscribe usr-tc" in the body of the message.
  1067.  For information on digests or retrieving files and old messages send
  1068.  "help" to the same address.  Do not use quotes in your message.
  1069.  
  1070.  
  1071. -------------------------------------------------------------------------------
  1072.  
  1073. From: Barry Yost <barry@zebra.net>
  1074. Subject: Re: (usr-tc) TCHub and routing
  1075. Date: 02 Oct 1999 00:35:12 +0600 (GMT)
  1076.  
  1077. I had a headache trying to set up the route as you have.
  1078. The easiest solution is to use host-based routing.
  1079. add a line Framed-Netmask=255.255.255.248,
  1080. to the RADIUS definition of the user.
  1081.  
  1082. Then the route should be advertized properly.
  1083.  
  1084. You should also follow the advise of the other replies to the list
  1085. enabling Ripv2 on the ARC if you haven't already done so, and make sure that
  1086. your core router is listening for that class C as well.
  1087.  
  1088. In cisco:
  1089.  
  1090. router rip
  1091. version 2
  1092. network 208.150.95.240
  1093. ^Z
  1094.  
  1095. (In my site's config, I also added passive-interface ser1/0 etc. for all of
  1096.  the non-POP interfaces so that rip updates won't be flowing around the
  1097.  network wasting traffic, nor accidentally getting picked up by a neighboring
  1098.  router that you don't want to pass routes to)
  1099.  
  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. From: Brian <signal@shreve.net>
  1111. Subject: Re: (usr-tc) Pipe 75 + Static IP + NAT
  1112. Date: 01 Oct 1999 13:56:28 -0500 (CDT)
  1113.  
  1114.  
  1115. on p50's you can't leave the lan adrs blank, it doesn't get it dynamically
  1116. from the connection like p75's do, at least thats my experience.
  1117.  
  1118.  
  1119. On Wed, 29 Sep 1999, Chad Scheiter wrote:
  1120.  
  1121. > Marius Strom wrote:
  1122. > 
  1123. > > I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a
  1124. > > HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I
  1125. > > enable it, it won't connect..  The pipe has been dialing into a Livingston
  1126. > > PM2e up until now, and when I modify the remote address and the phone
  1127. > > number to have it dial to our TC equipment, it won't do it.  I've gone and
  1128. > > disabled things such as STAC and all other compressions..  I did set the
  1129. > > Pipe to MP with BACP=Yes.
  1130. > >
  1131. > > Please let me know if you guys have had any success, and if you've got
  1132. > > success, let me know how I can have it too *chuckle*
  1133. > 
  1134. > Do you have the LAN Adrs, WAN Alias, or IF Adrs defined?  I left those blank
  1135. > and assign the static IP from radius. Otherwise you have to set reported IP
  1136. > on the TC to correspond with the LAN Adrs.  You should be able to just define
  1137. > the WAN Alias but I couldn't even get that to work between two ascends. What
  1138. > is mon ppp outputting?
  1139. > 
  1140. > 
  1141. > -
  1142. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1143. >  with "unsubscribe usr-tc" in the body of the message.
  1144. >  For information on digests or retrieving files and old messages send
  1145. >  "help" to the same address.  Do not use quotes in your message.
  1146. > 
  1147.  
  1148. Brian Feeny (BF304)     signal@shreve.net   
  1149. 318-222-2638 x 109    http://www.shreve.net/~signal      
  1150. Network Administrator   ShreveNet Inc. (ASN 11881)           
  1151.  
  1152.  
  1153. -
  1154.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1155.  with "unsubscribe usr-tc" in the body of the message.
  1156.  For information on digests or retrieving files and old messages send
  1157.  "help" to the same address.  Do not use quotes in your message.
  1158.  
  1159.  
  1160. -------------------------------------------------------------------------------
  1161.  
  1162. From: Jerry Wright <jwright@iaml.net>
  1163. Subject: Re: (usr-tc) Going nowhere fast...
  1164. Date: 01 Oct 1999 12:48:01 -0700
  1165.  
  1166. Well, now half our customers can go somewhere, half can't...   I'd be
  1167. willing to pay someone to walk me thru this...   (509) 765-9640.   They log
  1168. on, can't go anywhere.  ???
  1169.  
  1170. Jerry Wright wrote:
  1171.  
  1172. > To those of you who thought routing might be a problem...
  1173. >    Right on!
  1174. >      It turns out that I had routing in the problem box set to "quiet".
  1175. > Both boxes are now set to "listen".  Hopefully this will fix the
  1176. > problem.
  1177. >                         --Jerry
  1178.  
  1179.  
  1180. -
  1181.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1182.  with "unsubscribe usr-tc" in the body of the message.
  1183.  For information on digests or retrieving files and old messages send
  1184.  "help" to the same address.  Do not use quotes in your message.
  1185.  
  1186.  
  1187. -------------------------------------------------------------------------------
  1188.  
  1189. From: K Mitchell <mitch@keyconn.net>
  1190. Subject: Re: (usr-tc) OID for Hiper
  1191. Date: 01 Oct 1999 15:38:13 -0400
  1192.  
  1193. At 06:05 PM 10/1/99 +0200, "Max Gargani" <max@cgf.flashnet.it> wrote:
  1194. >Hi all,
  1195. >
  1196. >I'm new on this list. I'm looking for OID to check user connected to my
  1197. >USR-TC Hiper with MRTG.
  1198. >
  1199. >I found OID for normal TC and for Cisco AS5x00 but not for TC Hiper.
  1200.  
  1201. These are all for a 3Com Total Control HiPer chassis w/ DSP cards. I've
  1202. gone ahead and made them all generic. Also, all of mine include
  1203. Xsize[tch1]: 600
  1204. Ysize[tch1]: 200
  1205. to create graphs parger than default;
  1206.  
  1207. #Monitor modem useage. MaxBytes=# of available modems
  1208. #.....................................................................
  1209.  
  1210. Target[tch1]:
  1211. 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:public@ARC_IP
  1212. MaxBytes[tch1]: 69
  1213. Unscaled[tch1]:ymwd
  1214. Title[tch1]: Total Control Hub #1
  1215. PageTop[tch1]: <H1>Modem Utilization </H1>
  1216.  <TABLE>
  1217.    <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
  1218.    <TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
  1219.    <TR><TD>Interface:</TD><TD>HiPer DSP (2)</TD></TR>
  1220.    <TR><TD>Configuration:</TD><TD>ISDN, USR x2 and v.90 56k
  1221. protocols</TD></TR>
  1222.    <TR><TD>Capacity as configured:</TD>
  1223.        <TD><b>69 modems (23 per DSP)</b></TD></TR>
  1224.   </TABLE>
  1225. YLegend[tch1]:Modem Useage
  1226. Options[tch1]:gauge
  1227. Xsize[tch1]: 600
  1228. Ysize[tch1]: 200
  1229. ShortLegend[tch1]:Modems
  1230. Legend1[tch1]:Modem Utilization  
  1231. Legend2[tch1]:Modem Utilization  
  1232. LegendI[tch1]:  Utilization  
  1233. LegendO[tch1]:  Utilization  
  1234.  
  1235.  
  1236. #---------------------------------------------------------------
  1237.  
  1238. #Monitor NMC Operating Temp in Celsius
  1239. #---------------------------------------------------------------
  1240.  
  1241. Target[NMC-Temp]:
  1242. 1.3.6.1.4.1.429.1.2.2.5.0&1.3.6.1.4.1.429.1.2.2.5.0:public@NMC_IP
  1243. MaxBytes[NMC-Temp]: 100
  1244. Title[NMC-Temp]: HiPer NMC Temp
  1245. Xsize[NMC-Temp]: 600
  1246. Ysize[NMC-Temp]: 200
  1247. PageTop[NMC-Temp]: <H1>HiPer NMC Operating Temperature
  1248.  </H1>
  1249.  <TABLE>
  1250.    <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
  1251.    <TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
  1252.    <TR><TD>Interface:</TD><TD>HiPer NMC</TD></TR>
  1253.    <TR><TD>IP:</TD><TD>tc.nmc1.domain.net (0.0.0.0)</TD></TR>
  1254.    <TR><TD>Max Temp:</TD>
  1255.        <TD>100 deg Celsius</TD></TR>
  1256.   </TABLE>
  1257. Options[NMC-Temp]: gauge
  1258. YLegend[NMC-Temp]: Degrees Celsius
  1259. ShortLegend[NMC-Temp]: deg Celsius
  1260. Legend1[NMC-Temp]:Temperature in Celsius  
  1261. Legend2[NMC-Temp]:Temperature in Celsius  
  1262. LegendI[NMC-Temp]:  Temp  
  1263. LegendO[NMC-Temp]:  Temp  
  1264.  
  1265. #---------------------------------------------------------------
  1266.  
  1267. #Monitor ARC free memory
  1268. #---------------------------------------------------------------
  1269.  
  1270. Target[ARC-Memory]:
  1271. 1.3.6.1.4.1.429.4.3.1.3.0&1.3.6.1.4.1.429.4.3.1.3.0:public@ARC_IP
  1272. MaxBytes[ARC-Memory]: 65536
  1273. AbsMax[ARC-Memory]: 262144
  1274. Options[ARC-Memory]: gauge
  1275. Title[ARC-Memory]: ARC Memory
  1276. Xsize[ARC-Memory]: 600
  1277. Ysize[ARC-Memory]: 200
  1278. PageTop[ARC-Memory]: <H1>HiPer ARC Free Memory
  1279.  </H1>
  1280.  <TABLE>
  1281.    <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
  1282.    <TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
  1283.    <TR><TD>Interface:</TD><TD>HiPer ARC</TD></TR>
  1284.    <TR><TD>IP:</TD><TD>tc.arc1.domain.net (0.0.0.0)</TD></TR>
  1285.    <TR><TD>Max Memory:</TD>
  1286.        <TD>65536k</TD></TR>
  1287.   </TABLE>
  1288. YLegend[ARC-Memory]: Kbytes free
  1289. ShortLegend[ARC-Memory]: Kbytes free
  1290. LegendI[ARC-Memory]:  sys-mem:
  1291. LegendO[ARC-Memory]:  real-mem:
  1292. Legend1[ARC-Memory]:System Memory  
  1293. Legend2[ARC-Memory]:Real Memory  
  1294.  
  1295.  
  1296. #---------------------------------------------------------------
  1297.  
  1298. #Monitor ARC CPU demand
  1299. #---------------------------------------------------------------
  1300.  
  1301. Target[ARC-CPU]:
  1302. 1.3.6.1.4.1.429.4.3.1.13.0&1.3.6.1.4.1.429.4.3.1.14.0:public@ARC_IP
  1303. MaxBytes[ARC-CPU]: 100
  1304. AbsMax[ARC-CPU]: 25000
  1305. Title[ARC-CPU]: ARC CPU Load
  1306. Options[ARC-CPU]: gauge
  1307. Xsize[ARC-CPU]: 600
  1308. Ysize[ARC-CPU]: 200
  1309. PageTop[ARC-CPU]: <H1>HiPer ARC CPU Load
  1310.  </H1>
  1311.  <TABLE>
  1312.    <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR>
  1313.    <TR><TD>Maintainer:</TD><TD>Your ISP</TD></TR>
  1314.    <TR><TD>Interface:</TD><TD>HiPer ARC</TD></TR>
  1315.    <TR><TD>IP:</TD><TD>tc.arc1.domain.net (0.0.0.0)</TD></TR>
  1316.    <TR><TD>Max CPU:</TD>
  1317.        <TD>100%</TD></TR>
  1318.   </TABLE>
  1319. YLegend[ARC-CPU]: loadavg*100
  1320. ShortLegend[ARC-CPU]: loadavg*100
  1321. LegendI[ARC-CPU]:  1-min
  1322.  
  1323.  
  1324. #---------------------------------------------------------------
  1325.  
  1326. -- 
  1327. Kirk Mitchell-General Manager        mitch@keyconn.net
  1328. Keystone Connect                     Unlock Your World
  1329. Altoona, PA   814-941-5000      http://www.keyconn.net
  1330.  
  1331.  
  1332. -
  1333.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1334.  with "unsubscribe usr-tc" in the body of the message.
  1335.  For information on digests or retrieving files and old messages send
  1336.  "help" to the same address.  Do not use quotes in your message.
  1337.  
  1338.  
  1339. -------------------------------------------------------------------------------
  1340.  
  1341. From: mmm3@cornell.edu
  1342. Subject: RE: (usr-tc) TimeZone Reality Check for ARC's
  1343. Date: 01 Oct 1999 16:01:34 -0400
  1344.  
  1345. >|-----Original Message-----
  1346. >|From: owner-usr-tc@lists.xmission.com
  1347. >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman
  1348. >|Sent: Friday, October 01, 1999 9:50 AM
  1349. >|To: 'usr-tc@lists.xmission.com'
  1350. >|Subject: (usr-tc) TimeZone Reality Check for ARC's
  1351. >|
  1352. >|
  1353. >|ARC's only do GMT?
  1354. >|
  1355. >|Time IS correct w/NTP, but could find nothing on setting TimeZone.
  1356. >|Makes "list connections"'s look weird with the login times, but that's about
  1357. >|it.
  1358. >|
  1359. >
  1360. >You are correct sir.
  1361. >
  1362. >-M
  1363.  
  1364. Perhaps that could be put in the "Wish List"? The ability to set
  1365. the ARCs to one's own time zone? (Incidently, 3Com, why wasn't
  1366. that taken into consideration in the first place?)
  1367.  
  1368. *********************************************************
  1369. Michelle M. Mogil
  1370. N&CS, Network Operations Center
  1371. Rhodes Hall, Cornell University, Ithaca, NY 14853
  1372. vox: (607) 255-0516, fax: (607) 255-8420
  1373. email: mmm3@cornell.edu
  1374. **********************************************
  1375.  
  1376.  
  1377.  
  1378. -
  1379.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1380.  with "unsubscribe usr-tc" in the body of the message.
  1381.  For information on digests or retrieving files and old messages send
  1382.  "help" to the same address.  Do not use quotes in your message.
  1383.  
  1384.  
  1385. -------------------------------------------------------------------------------
  1386.  
  1387. From: Jeff Mcadams <jeffm@iglou.com>
  1388. Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  1389. Date: 01 Oct 1999 17:09:01 -0400
  1390.  
  1391. Thus spake mmm3@cornell.edu
  1392. >Perhaps that could be put in the "Wish List"? The ability to set
  1393. >the ARCs to one's own time zone? (Incidently, 3Com, why wasn't
  1394. >that taken into consideration in the first place?)
  1395.  
  1396. Indeed, this would be a nice thing to have, and shouldn't take too
  1397. terribly long to implement, but to be honest, it is purely a cosmetic
  1398. thing.  It doesn't affect funtionality of the system at all.
  1399. -- 
  1400. Jeff McAdams                            Email: jeffm@iglou.com
  1401. Head Network Administrator              Voice: (502) 966-3848
  1402. IgLou Internet Services                        (800) 436-4456
  1403.  
  1404. -
  1405.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1406.  with "unsubscribe usr-tc" in the body of the message.
  1407.  For information on digests or retrieving files and old messages send
  1408.  "help" to the same address.  Do not use quotes in your message.
  1409.  
  1410.  
  1411. -------------------------------------------------------------------------------
  1412.  
  1413. From: Dataheart <lists@dataheart.net>
  1414. Subject: Re: (usr-tc) Netserver problem
  1415. Date: 04 Oct 1999 16:45:25 +1000
  1416.  
  1417. ok,
  1418. I have re-flashed the card and still the same thing flashes 13 times then
  1419. flashes quickly then solid green and the loop is endless.
  1420. Ths console is also blank.
  1421.  
  1422. Any other ideas?
  1423.  
  1424. Thanks,
  1425. Aaron
  1426.  
  1427. Scott Trautman wrote:
  1428.  
  1429. > Anything on the console port? Bootup messages? (actually don't think you
  1430. > would see those if I recall correctly, just a login prompt when it is up...)
  1431. >
  1432. > Get out the pcsdl, source and re-upload it via serial cable. Hint: set your
  1433. > serial port to at least 57600 w/dip switches.
  1434. >
  1435. > Sounds like your flash got corrupted.
  1436. >
  1437. > Or send it back to 3Com and they'll do probably the same thing.
  1438. >
  1439. > SMT
  1440. >
  1441. > > -----Original Message-----
  1442. > > From: Dataheart [mailto:lists@dataheart.net]
  1443. > > Sent: Thursday, September 30, 1999 10:49 AM
  1444. > > To: usr-tc@lists.xmission.com
  1445. > > Subject: (usr-tc) Netserver problem
  1446. > >
  1447. > >
  1448. > > Well I'm just full of problems arent I :-D
  1449. > >
  1450. > > I have a Netserver card  that once powered up the rn/fl led
  1451. > > flashes green on
  1452. > > and off 13 times, then flashes quickly for a few seconds,
  1453. > > then goes solid green
  1454. > > for a while, then repeast the process.
  1455. > > Anyone know whats going on?
  1456. > >
  1457. > > Thanks,
  1458. > > Aaron
  1459. > >
  1460. > >
  1461. > > -
  1462. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1463. > >  with "unsubscribe usr-tc" in the body of the message.
  1464. > >  For information on digests or retrieving files and old messages send
  1465. > >  "help" to the same address.  Do not use quotes in your message.
  1466. > >
  1467. >
  1468. > -
  1469. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1470. >  with "unsubscribe usr-tc" in the body of the message.
  1471. >  For information on digests or retrieving files and old messages send
  1472. >  "help" to the same address.  Do not use quotes in your message.
  1473.  
  1474.  
  1475. -
  1476.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1477.  with "unsubscribe usr-tc" in the body of the message.
  1478.  For information on digests or retrieving files and old messages send
  1479.  "help" to the same address.  Do not use quotes in your message.
  1480.  
  1481.  
  1482. -------------------------------------------------------------------------------
  1483.  
  1484. From: Scott Trautman <scottt@corp.gdinet.com>
  1485. Subject: RE: (usr-tc) Netserver problem
  1486. Date: 04 Oct 1999 06:41:27 -0500 
  1487.  
  1488. Time to send it back to 3Com to have them look at it.
  1489. That would be my next step.
  1490.  
  1491. SMT
  1492.  
  1493. > -----Original Message-----
  1494. > From: Dataheart [mailto:lists@dataheart.net]
  1495. > Sent: Monday, October 04, 1999 1:45 AM
  1496. > To: usr-tc@lists.xmission.com
  1497. > Subject: Re: (usr-tc) Netserver problem
  1498. > 
  1499. > 
  1500. > ok,
  1501. > I have re-flashed the card and still the same thing flashes 
  1502. > 13 times then
  1503. > flashes quickly then solid green and the loop is endless.
  1504. > Ths console is also blank.
  1505. > 
  1506. > Any other ideas?
  1507. > 
  1508. > Thanks,
  1509. > Aaron
  1510. > 
  1511. > Scott Trautman wrote:
  1512. > 
  1513. > > Anything on the console port? Bootup messages? (actually 
  1514. > don't think you
  1515. > > would see those if I recall correctly, just a login prompt 
  1516. > when it is up...)
  1517. > >
  1518. > > Get out the pcsdl, source and re-upload it via serial 
  1519. > cable. Hint: set your
  1520. > > serial port to at least 57600 w/dip switches.
  1521. > >
  1522. > > Sounds like your flash got corrupted.
  1523. > >
  1524. > > Or send it back to 3Com and they'll do probably the same thing.
  1525. > >
  1526. > > SMT
  1527. > >
  1528. > > > -----Original Message-----
  1529. > > > From: Dataheart [mailto:lists@dataheart.net]
  1530. > > > Sent: Thursday, September 30, 1999 10:49 AM
  1531. > > > To: usr-tc@lists.xmission.com
  1532. > > > Subject: (usr-tc) Netserver problem
  1533. > > >
  1534. > > >
  1535. > > > Well I'm just full of problems arent I :-D
  1536. > > >
  1537. > > > I have a Netserver card  that once powered up the rn/fl led
  1538. > > > flashes green on
  1539. > > > and off 13 times, then flashes quickly for a few seconds,
  1540. > > > then goes solid green
  1541. > > > for a while, then repeast the process.
  1542. > > > Anyone know whats going on?
  1543. > > >
  1544. > > > Thanks,
  1545. > > > Aaron
  1546. > > >
  1547. > > >
  1548. > > > -
  1549. > > >  To unsubscribe to usr-tc, send an email to 
  1550. > "majordomo@xmission.com"
  1551. > > >  with "unsubscribe usr-tc" in the body of the message.
  1552. > > >  For information on digests or retrieving files and old 
  1553. > messages send
  1554. > > >  "help" to the same address.  Do not use quotes in your message.
  1555. > > >
  1556. > >
  1557. > > -
  1558. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1559. > >  with "unsubscribe usr-tc" in the body of the message.
  1560. > >  For information on digests or retrieving files and old 
  1561. > messages send
  1562. > >  "help" to the same address.  Do not use quotes in your message.
  1563. > 
  1564. > 
  1565. > -
  1566. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1567. >  with "unsubscribe usr-tc" in the body of the message.
  1568. >  For information on digests or retrieving files and old messages send
  1569. >  "help" to the same address.  Do not use quotes in your message.
  1570. > 
  1571.  
  1572. -
  1573.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1574.  with "unsubscribe usr-tc" in the body of the message.
  1575.  For information on digests or retrieving files and old messages send
  1576.  "help" to the same address.  Do not use quotes in your message.
  1577.  
  1578.  
  1579. -------------------------------------------------------------------------------
  1580.  
  1581. From: Marty Elliott <marty@2assetrecovery.com>
  1582. Subject: Re: (usr-tc) Netserver problem
  1583. Date: 04 Oct 1999 06:06:09 -0700
  1584.  
  1585. The thing's hosed Aaron.  Replacement enroute FedEx today.  
  1586.  
  1587. Grrr
  1588.  
  1589. Marty
  1590.  
  1591.  
  1592. At 04:45 PM 10/4/99 +1000, you wrote:
  1593. >ok,
  1594. >I have re-flashed the card and still the same thing flashes 13 times then
  1595. >flashes quickly then solid green and the loop is endless.
  1596. >Ths console is also blank.
  1597. >
  1598. >Any other ideas?
  1599. >
  1600. >Thanks,
  1601. >Aaron
  1602. >
  1603. >Scott Trautman wrote:
  1604. >
  1605. >> Anything on the console port? Bootup messages? (actually don't think you
  1606. >> would see those if I recall correctly, just a login prompt when it is up...)
  1607. >>
  1608. >> Get out the pcsdl, source and re-upload it via serial cable. Hint: set your
  1609. >> serial port to at least 57600 w/dip switches.
  1610. >>
  1611. >> Sounds like your flash got corrupted.
  1612. >>
  1613. >> Or send it back to 3Com and they'll do probably the same thing.
  1614. >>
  1615. >> SMT
  1616. >>
  1617. >> > -----Original Message-----
  1618. >> > From: Dataheart [mailto:lists@dataheart.net]
  1619. >> > Sent: Thursday, September 30, 1999 10:49 AM
  1620. >> > To: usr-tc@lists.xmission.com
  1621. >> > Subject: (usr-tc) Netserver problem
  1622. >> >
  1623. >> >
  1624. >> > Well I'm just full of problems arent I :-D
  1625. >> >
  1626. >> > I have a Netserver card  that once powered up the rn/fl led
  1627. >> > flashes green on
  1628. >> > and off 13 times, then flashes quickly for a few seconds,
  1629. >> > then goes solid green
  1630. >> > for a while, then repeast the process.
  1631. >> > Anyone know whats going on?
  1632. >> >
  1633. >> > Thanks,
  1634. >> > Aaron
  1635. >> >
  1636. >> >
  1637. >> > -
  1638. >> >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1639. >> >  with "unsubscribe usr-tc" in the body of the message.
  1640. >> >  For information on digests or retrieving files and old messages send
  1641. >> >  "help" to the same address.  Do not use quotes in your message.
  1642. >> >
  1643. >>
  1644. >> -
  1645. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1646. >>  with "unsubscribe usr-tc" in the body of the message.
  1647. >>  For information on digests or retrieving files and old messages send
  1648. >>  "help" to the same address.  Do not use quotes in your message.
  1649. >
  1650. >
  1651. >-
  1652. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1653. > with "unsubscribe usr-tc" in the body of the message.
  1654. > For information on digests or retrieving files and old messages send
  1655. > "help" to the same address.  Do not use quotes in your message.
  1656.  
  1657.  
  1658. -
  1659.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1660.  with "unsubscribe usr-tc" in the body of the message.
  1661.  For information on digests or retrieving files and old messages send
  1662.  "help" to the same address.  Do not use quotes in your message.
  1663.  
  1664.  
  1665. -------------------------------------------------------------------------------
  1666.  
  1667. From: mmm3@cornell.edu
  1668. Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  1669. Date: 04 Oct 1999 09:26:12 -0400
  1670.  
  1671. >Thus spake mmm3@cornell.edu
  1672. >>Perhaps that could be put in the "Wish List"? The ability to set
  1673. >>the ARCs to one's own time zone? (Incidently, 3Com, why wasn't
  1674. >>that taken into consideration in the first place?)
  1675. >
  1676. >Indeed, this would be a nice thing to have, and shouldn't take too
  1677. >terribly long to implement, but to be honest, it is purely a cosmetic
  1678. >thing.  It doesn't affect funtionality of the system at all.
  1679.  
  1680. Not completely a cosmetic thing since I sometimes use it to track
  1681. problems. It's just easier to be able to check the time in one's own
  1682. time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
  1683.  
  1684. *********************************************************
  1685. Michelle M. Mogil
  1686. N&CS, Network Operations Center
  1687. Rhodes Hall, Cornell University, Ithaca, NY 14853
  1688. vox: (607) 255-0516, fax: (607) 255-8420
  1689. email: mmm3@cornell.edu
  1690. **********************************************
  1691.  
  1692.  
  1693.  
  1694. -
  1695.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1696.  with "unsubscribe usr-tc" in the body of the message.
  1697.  For information on digests or retrieving files and old messages send
  1698.  "help" to the same address.  Do not use quotes in your message.
  1699.  
  1700.  
  1701. -------------------------------------------------------------------------------
  1702.  
  1703. From: Jeff Mcadams <jeffm@iglou.com>
  1704. Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  1705. Date: 04 Oct 1999 09:31:32 -0400
  1706.  
  1707. Thus spake mmm3@cornell.edu
  1708. >>Thus spake mmm3@cornell.edu
  1709. >>>Perhaps that could be put in the "Wish List"? The ability to set the
  1710. >>>ARCs to one's own time zone? (Incidently, 3Com, why wasn't that taken
  1711. >>>into consideration in the first place?)
  1712.  
  1713. >>Indeed, this would be a nice thing to have, and shouldn't take too
  1714. >>terribly long to implement, but to be honest, it is purely a cosmetic
  1715. >>thing.  It doesn't affect funtionality of the system at all.
  1716.  
  1717. >Not completely a cosmetic thing since I sometimes use it to track
  1718. >problems. It's just easier to be able to check the time in one's own
  1719.            ^^^^^^^^^^^^^^^^
  1720. Like I said...its a cosmetic thing.  ;)
  1721.  
  1722. >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
  1723. -- 
  1724. Jeff McAdams                            Email: jeffm@iglou.com
  1725. Head Network Administrator              Voice: (502) 966-3848
  1726. IgLou Internet Services                        (800) 436-4456
  1727.  
  1728. -
  1729.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1730.  with "unsubscribe usr-tc" in the body of the message.
  1731.  For information on digests or retrieving files and old messages send
  1732.  "help" to the same address.  Do not use quotes in your message.
  1733.  
  1734.  
  1735. -------------------------------------------------------------------------------
  1736.  
  1737. From: Jim Johnson <jim@perigee.net>
  1738. Subject: (usr-tc) HDM Uptime
  1739. Date: 04 Oct 1999 11:38:09 -0400
  1740.  
  1741.  
  1742.  
  1743. Due to the hanging DSP bug in the HDMs which takes out two ports
  1744. (arghhh..), we are monitoring our failure statistics via SNMP looking
  1745. for these problems.  We automatically capture and email the call failure
  1746. statistics every morning for all HDMs. 
  1747.  
  1748. This morning I noticed that all of the statistics on one HDM had been
  1749. zeroed out during thr prior day.  This concerns me as I would imagine
  1750. the card must have rebooted itself in order to reset these counters. 
  1751. (True?)
  1752.  
  1753. I am sure there must an uptime stat for each HDM which I can get using
  1754. TCM, but I did not see it when I looked around some.  Can someone tell
  1755. me how to get the HDM uptime so I can know exactly when this card reset
  1756. itself. Also, does this happen to other folks periodically or is this
  1757. card getting ready to go bad?
  1758.  
  1759. FInally, we had our telco change our hunting from first available B
  1760. channel to a circular hunt and this seems to have dramtically reduced
  1761. the number of occurrences of the hung DSP problem.  
  1762.  
  1763. -Jim
  1764.  
  1765. -
  1766.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1767.  with "unsubscribe usr-tc" in the body of the message.
  1768.  For information on digests or retrieving files and old messages send
  1769.  "help" to the same address.  Do not use quotes in your message.
  1770.  
  1771.  
  1772. -------------------------------------------------------------------------------
  1773.  
  1774. From: jeff.binkley@asacomp.com (Jeff Binkley)
  1775. Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  1776. Date: 04 Oct 1999 12:19:00 -0500
  1777.  
  1778. -> Thus spake mmm3@cornell.edu
  1779. -> >>Thus spake mmm3@cornell.edu
  1780. -> >>>Perhaps that could be put in the "Wish List"? The ability to set the
  1781. -> >>>ARCs to one's own time zone? (Incidently, 3Com, why wasn't that taken
  1782. -> >>>into consideration in the first place?)
  1783. ->
  1784. -> >>Indeed, this would be a nice thing to have, and shouldn't take too
  1785. -> >>terribly long to implement, but to be honest, it is purely a cosmetic
  1786. -> >>thing.  It doesn't affect funtionality of the system at all.
  1787. ->
  1788. -> >Not completely a cosmetic thing since I sometimes use it to track
  1789. -> >problems. It's just easier to be able to check the time in one's own
  1790. -> ^^^^^^^^^^^^^^^^
  1791. -> Like I said...its a cosmetic thing.  ;)
  1792. ->
  1793. -> >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
  1794.  
  1795. Jeff,
  1796.  
  1797. Not exactly.  If you are using this with an enterprise management system
  1798. which aggregates SNMP traps, there could be a problem with some of the
  1799. devices reporting local time and some reporting GMT time.  The fact that
  1800. most network devices allow for a timezone offset would lend credence
  1801. to this.
  1802.  
  1803. Jeff Binkley
  1804. ASA Network Computing
  1805.  
  1806. -
  1807.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1808.  with "unsubscribe usr-tc" in the body of the message.
  1809.  For information on digests or retrieving files and old messages send
  1810.  "help" to the same address.  Do not use quotes in your message.
  1811.  
  1812.  
  1813. -------------------------------------------------------------------------------
  1814.  
  1815. From: Horace Demmink <horace@pathwaynet.com>
  1816. Subject: (usr-tc) Dual channel ISDN problem.
  1817. Date: 04 Oct 1999 12:44:38 -0400 (EDT)
  1818.  
  1819.  
  1820. I have been trying to figure out a problem that one of my customers has
  1821. been having. They are dialing up with a 3COM NetBuilder to our TC
  1822. equipment. The first channel comes up fine, but the second one will not
  1823. come up. The NetBuilder attempts to bring it up, fails, and waits a few
  1824. seconds before trying again. ISDN is $.08 per call in this area so they
  1825. are racking up quite a bill. I have never seen this before with any other
  1826. customer, and as far as I know they are the only ones with a 3COM
  1827. NetBuilder, so I am assuming that it is a problem or misconfiguration with
  1828. their router. Is anyone else familiar with these things? Thanks very much
  1829. in advance for any help or advice anyone can offer.
  1830.  
  1831. We are running:
  1832.  
  1833. ARC 4.2.32-1
  1834. DSP 2.0.81
  1835.  
  1836. Here is the relevant section of their radius entry:
  1837.  
  1838. username        Auth-Type = System
  1839.                 Service-Type = Framed,
  1840.                 Framed-IP-Address = xxx.xxx.xxx.xxx,
  1841.                 Framed-IP-Netmask = 255.255.255.255,
  1842.                 Framed-Protocol = PPP,
  1843.                 Framed-Route = "yyy.yyy.yyy.yyy/30 0.0.0.0 1",
  1844.                 Framed-Routing = None,
  1845.                 Framed-MTU = 1500,
  1846.                 Idle-Timeout = 0,
  1847.                 Port-Limit = 2,
  1848.                 Framed-Compression = Van-Jacobson-TCP-IP
  1849.  
  1850.  
  1851. And the following is about a minutes worth of a dump of a monitor ppp from
  1852. the arc:
  1853.  
  1854. Decode tracing started, press ESCAPE to stop; press X for hex tracing.
  1855.  
  1856. Incoming PPP Data on interface: slot:15/mod:20 
  1857.     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  1858.  
  1859. Outgoing PPP Data on interface: slot:15/mod:20 
  1860.     LCP        ECHO_RPLY         c4 56 fa 71 
  1861.  
  1862. Incoming PPP Data on interface: slot:15/mod:20 
  1863.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1864.  
  1865. Outgoing PPP Data on interface: slot:15/mod:20 
  1866.     LCP        ECHO_RPLY         c4 56 fa 71 
  1867.  
  1868. Incoming PPP Data on interface: slot:15/mod:20 
  1869.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1870.  
  1871. Outgoing PPP Data on interface: slot:15/mod:20 
  1872.     LCP        ECHO_RPLY         c4 56 fa 71 
  1873.  
  1874. Outgoing PPP Data on interface: slot:15/mod:21 
  1875.     PAP        ACK               
  1876. Incoming PPP Data on interface: slot:15/mod:20 
  1877.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1878.  
  1879. Outgoing PPP Data on interface: slot:15/mod:20 
  1880.     LCP        ECHO_RPLY         c4 56 fa 71 
  1881.  
  1882. Incoming PPP Data on interface: slot:15/mod:20 
  1883.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1884.  
  1885. Outgoing PPP Data on interface: slot:15/mod:20 
  1886.     LCP        ECHO_RPLY         c4 56 fa 71 
  1887.  
  1888. Outgoing PPP Data on interface: slot:15/mod:21 
  1889.     PAP        ACK               
  1890. Incoming PPP Data on interface: slot:15/mod:20 
  1891.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1892.  
  1893. Outgoing PPP Data on interface: slot:15/mod:20 
  1894.     LCP        ECHO_RPLY         c4 56 fa 71 
  1895.  
  1896. Incoming PPP Data on interface: slot:15/mod:20 
  1897.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1898.  
  1899. Outgoing PPP Data on interface: slot:15/mod:20 
  1900.     LCP        ECHO_RPLY         c4 56 fa 71 
  1901.  
  1902. Incoming PPP Data on interface: slot:15/mod:20 
  1903.     LCP        ECHO_REQ          00 cc f7 cf 18 d8 2e c9 
  1904.  
  1905. Outgoing PPP Data on interface: slot:15/mod:20 
  1906.     LCP        ECHO_RPLY         c4 56 fa 71 
  1907.  
  1908. Outgoing PPP Data on interface: slot:15/mod:21 
  1909.     PAP        ACK               
  1910. Incoming PPP Data on interface: slot:15/mod:20 
  1911.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1912.  
  1913. Outgoing PPP Data on interface: slot:15/mod:20 
  1914.     LCP        ECHO_RPLY         c4 56 fa 71 
  1915.  
  1916. Incoming PPP Data on interface: slot:15/mod:20 
  1917.     LCP        ECHO_REQ          00 cc f7 cf 50 68 6f 6e 
  1918.  
  1919. Outgoing PPP Data on interface: slot:15/mod:20 
  1920.     LCP        ECHO_RPLY         c4 56 fa 71 
  1921.  
  1922. Incoming PPP Data on interface: slot:15/mod:20 
  1923.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1924.  
  1925. Outgoing PPP Data on interface: slot:15/mod:20 
  1926.     LCP        ECHO_RPLY         c4 56 fa 71 
  1927.  
  1928. Outgoing PPP Data on interface: slot:15/mod:21 
  1929.     PAP        ACK               
  1930. Incoming PPP Data on interface: slot:15/mod:20 
  1931.     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  1932.  
  1933. Outgoing PPP Data on interface: slot:15/mod:20 
  1934.     LCP        ECHO_RPLY         c4 56 fa 71 
  1935.  
  1936. Incoming PPP Data on interface: slot:15/mod:20 
  1937.     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  1938.  
  1939. Outgoing PPP Data on interface: slot:15/mod:20 
  1940.     LCP        ECHO_RPLY         c4 56 fa 71 
  1941.  
  1942. Incoming PPP Data on interface: slot:15/mod:20 
  1943.     LCP        ECHO_REQ          00 cc f7 cf 65 6c 64 20 
  1944.  
  1945. Outgoing PPP Data on interface: slot:15/mod:20 
  1946.     LCP        ECHO_RPLY         c4 56 fa 71 
  1947.  
  1948. Outgoing PPP Data on interface: slot:15/mod:21 
  1949.     PAP        ACK               
  1950. Incoming PPP Data on interface: slot:15/mod:20 
  1951.     LCP        ECHO_REQ          00 cc f7 cf 00 2e c8 68 
  1952.  
  1953. Outgoing PPP Data on interface: slot:15/mod:20 
  1954.     LCP        ECHO_RPLY         c4 56 fa 71 
  1955.  
  1956. Incoming PPP Data on interface: slot:15/mod:20 
  1957.     LCP        ECHO_REQ          00 cc f7 cf 54 48 49 53 
  1958.  
  1959. Outgoing PPP Data on interface: slot:15/mod:20 
  1960.     LCP        ECHO_RPLY         c4 56 fa 71 
  1961.  
  1962. Incoming PPP Data on interface: slot:15/mod:20 
  1963.     LCP        ECHO_REQ          00 cc f7 cf 6e 64 20 4a 
  1964.  
  1965. Outgoing PPP Data on interface: slot:15/mod:20 
  1966.     LCP        ECHO_RPLY         c4 56 fa 71 
  1967.  
  1968. Incoming PPP Data on interface: slot:15/mod:20 
  1969.     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  1970.  
  1971. Outgoing PPP Data on interface: slot:15/mod:20 
  1972.     LCP        ECHO_RPLY         c4 56 fa 71 
  1973.  
  1974. Outgoing PPP Data on interface: slot:15/mod:21 
  1975.     PAP        ACK               
  1976. Incoming PPP Data on interface: slot:15/mod:20 
  1977.     LCP        ECHO_REQ          00 cc f7 cf 81 d8 2e c9 
  1978.  
  1979. Outgoing PPP Data on interface: slot:15/mod:20 
  1980.     LCP        ECHO_RPLY         c4 56 fa 71 
  1981.  
  1982. Incoming PPP Data on interface: slot:15/mod:20 
  1983.     LCP        ECHO_REQ          00 cc f7 cf 39 36 36 3b 
  1984.  
  1985. Outgoing PPP Data on interface: slot:15/mod:20 
  1986.     LCP        ECHO_RPLY         c4 56 fa 71 
  1987.  
  1988. Incoming PPP Data on interface: slot:15/mod:20 
  1989.     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  1990.  
  1991. Outgoing PPP Data on interface: slot:15/mod:20 
  1992.     LCP        ECHO_RPLY         c4 56 fa 71 
  1993.  
  1994. Outgoing PPP Data on interface: slot:15/mod:21 
  1995.     PAP        ACK               
  1996. Incoming PPP Data on interface: slot:15/mod:20 
  1997.     LCP        ECHO_REQ          00 cc f7 cf 69 d8 2e c1 
  1998.  
  1999. Outgoing PPP Data on interface: slot:15/mod:20 
  2000.     LCP        ECHO_RPLY         c4 56 fa 71 
  2001. Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
  2002.  
  2003. -- 
  2004. Horace Demmink
  2005. PathWay Computing
  2006.  
  2007.  
  2008.  
  2009. -
  2010.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2011.  with "unsubscribe usr-tc" in the body of the message.
  2012.  For information on digests or retrieving files and old messages send
  2013.  "help" to the same address.  Do not use quotes in your message.
  2014.  
  2015.  
  2016. -------------------------------------------------------------------------------
  2017.  
  2018. From: Jeff Mcadams <jeffm@iglou.com>
  2019. Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  2020. Date: 04 Oct 1999 13:13:59 -0400
  2021.  
  2022. Thus spake Jeff Binkley
  2023. >-> >Not completely a cosmetic thing since I sometimes use it to track
  2024. >-> >problems. It's just easier to be able to check the time in one's own
  2025. >-> ^^^^^^^^^^^^^^^^
  2026. >-> Like I said...its a cosmetic thing.  ;)
  2027.  
  2028. >-> >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
  2029.  
  2030. >Not exactly.  If you are using this with an enterprise management system
  2031. >which aggregates SNMP traps, there could be a problem with some of the
  2032. >devices reporting local time and some reporting GMT time.  The fact that
  2033. >most network devices allow for a timezone offset would lend credence
  2034. >to this.
  2035.  
  2036. Well, I would hope that in SNMP traps, the data would be in GMT and not
  2037. in a human-readable, and unbelievably-hard-to-reliably-parse format.
  2038. Converting and display the SNMP trap timestamp information in a human
  2039. readable format and timezone of the viewer should be the job of the
  2040. enterprise management system, certainly not of the SNMP agent.
  2041. -- 
  2042. Jeff McAdams                            Email: jeffm@iglou.com
  2043. Head Network Administrator              Voice: (502) 966-3848
  2044. IgLou Internet Services                        (800) 436-4456
  2045.  
  2046. -
  2047.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2048.  with "unsubscribe usr-tc" in the body of the message.
  2049.  For information on digests or retrieving files and old messages send
  2050.  "help" to the same address.  Do not use quotes in your message.
  2051.  
  2052.  
  2053. -------------------------------------------------------------------------------
  2054.  
  2055. From: Ahmed Saeed <Ahmed.Saeed@widener.edu>
  2056. Subject: RE: (usr-tc) Netserver problem
  2057. Date: 04 Oct 1999 13:48:17 -0400 (EDT)
  2058.  
  2059. the dip switch 5 needs to be turned down to reflash code.
  2060.  
  2061.  
  2062. On Mon, 4 Oct 1999, Scott Trautman wrote:
  2063.  
  2064. > Time to send it back to 3Com to have them look at it.
  2065. > That would be my next step.
  2066. > 
  2067. > SMT
  2068. > 
  2069. > > -----Original Message-----
  2070. > > From: Dataheart [mailto:lists@dataheart.net]
  2071. > > Sent: Monday, October 04, 1999 1:45 AM
  2072. > > To: usr-tc@lists.xmission.com
  2073. > > Subject: Re: (usr-tc) Netserver problem
  2074. > > 
  2075. > > 
  2076. > > ok,
  2077. > > I have re-flashed the card and still the same thing flashes 
  2078. > > 13 times then
  2079. > > flashes quickly then solid green and the loop is endless.
  2080. > > Ths console is also blank.
  2081. > > 
  2082. > > Any other ideas?
  2083. > > 
  2084. > > Thanks,
  2085. > > Aaron
  2086. > > 
  2087. > > Scott Trautman wrote:
  2088. > > 
  2089. > > > Anything on the console port? Bootup messages? (actually 
  2090. > > don't think you
  2091. > > > would see those if I recall correctly, just a login prompt 
  2092. > > when it is up...)
  2093. > > >
  2094. > > > Get out the pcsdl, source and re-upload it via serial 
  2095. > > cable. Hint: set your
  2096. > > > serial port to at least 57600 w/dip switches.
  2097. > > >
  2098. > > > Sounds like your flash got corrupted.
  2099. > > >
  2100. > > > Or send it back to 3Com and they'll do probably the same thing.
  2101. > > >
  2102. > > > SMT
  2103. > > >
  2104. > > > > -----Original Message-----
  2105. > > > > From: Dataheart [mailto:lists@dataheart.net]
  2106. > > > > Sent: Thursday, September 30, 1999 10:49 AM
  2107. > > > > To: usr-tc@lists.xmission.com
  2108. > > > > Subject: (usr-tc) Netserver problem
  2109. > > > >
  2110. > > > >
  2111. > > > > Well I'm just full of problems arent I :-D
  2112. > > > >
  2113. > > > > I have a Netserver card  that once powered up the rn/fl led
  2114. > > > > flashes green on
  2115. > > > > and off 13 times, then flashes quickly for a few seconds,
  2116. > > > > then goes solid green
  2117. > > > > for a while, then repeast the process.
  2118. > > > > Anyone know whats going on?
  2119. > > > >
  2120. > > > > Thanks,
  2121. > > > > Aaron
  2122. > > > >
  2123. > > > >
  2124. > > > > -
  2125. > > > >  To unsubscribe to usr-tc, send an email to 
  2126. > > "majordomo@xmission.com"
  2127. > > > >  with "unsubscribe usr-tc" in the body of the message.
  2128. > > > >  For information on digests or retrieving files and old 
  2129. > > messages send
  2130. > > > >  "help" to the same address.  Do not use quotes in your message.
  2131. > > > >
  2132. > > >
  2133. > > > -
  2134. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2135. > > >  with "unsubscribe usr-tc" in the body of the message.
  2136. > > >  For information on digests or retrieving files and old 
  2137. > > messages send
  2138. > > >  "help" to the same address.  Do not use quotes in your message.
  2139. > > 
  2140. > > 
  2141. > > -
  2142. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2143. > >  with "unsubscribe usr-tc" in the body of the message.
  2144. > >  For information on digests or retrieving files and old messages send
  2145. > >  "help" to the same address.  Do not use quotes in your message.
  2146. > > 
  2147. > 
  2148. > -
  2149. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2150. >  with "unsubscribe usr-tc" in the body of the message.
  2151. >  For information on digests or retrieving files and old messages send
  2152. >  "help" to the same address.  Do not use quotes in your message.
  2153. > 
  2154.  
  2155. -
  2156.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2157.  with "unsubscribe usr-tc" in the body of the message.
  2158.  For information on digests or retrieving files and old messages send
  2159.  "help" to the same address.  Do not use quotes in your message.
  2160.  
  2161.  
  2162. -------------------------------------------------------------------------------
  2163.  
  2164. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  2165. Subject: RE: (usr-tc) TimeZone Reality Check for ARC's (THREAD ENDER)
  2166. Date: 04 Oct 1999 13:14:00 -0500
  2167.  
  2168. To put an end to this thread. HARC 5.0 has TZ configurable for cosmetic reasons..
  2169. And I do believe that Jeff is correct here. The TIMESTAMP should always be in
  2170. GMT. The receiver is responsible for correcting for local display.
  2171.  
  2172. -M
  2173.  
  2174.  
  2175. |-----Original Message-----
  2176. |From: owner-usr-tc@lists.xmission.com
  2177. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  2178. |Sent: Monday, October 04, 1999 12:14 PM
  2179. |To: usr-tc@lists.xmission.com
  2180. |Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  2181. |
  2182. |
  2183. |Thus spake Jeff Binkley
  2184. |>-> >Not completely a cosmetic thing since I sometimes use it to track
  2185. |>-> >problems. It's just easier to be able to check the time in one's own
  2186. |>-> ^^^^^^^^^^^^^^^^
  2187. |>-> Like I said...its a cosmetic thing.  ;)
  2188. |
  2189. |>-> >time zone rather than to keep mentally subtracting 5. I'm lazy. 8-)
  2190. |
  2191. |>Not exactly.  If you are using this with an enterprise management system
  2192. |>which aggregates SNMP traps, there could be a problem with some of the
  2193. |>devices reporting local time and some reporting GMT time.  The fact that
  2194. |>most network devices allow for a timezone offset would lend credence
  2195. |>to this.
  2196. |
  2197. |Well, I would hope that in SNMP traps, the data would be in GMT and not
  2198. |in a human-readable, and unbelievably-hard-to-reliably-parse format.
  2199. |Converting and display the SNMP trap timestamp information in a human
  2200. |readable format and timezone of the viewer should be the job of the
  2201. |enterprise management system, certainly not of the SNMP agent.
  2202. |--
  2203. |Jeff McAdams                            Email: jeffm@iglou.com
  2204. |Head Network Administrator              Voice: (502) 966-3848
  2205. |IgLou Internet Services                        (800) 436-4456
  2206. |
  2207. |-
  2208. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2209. | with "unsubscribe usr-tc" in the body of the message.
  2210. | For information on digests or retrieving files and old messages send
  2211. | "help" to the same address.  Do not use quotes in your message.
  2212. |
  2213.  
  2214.  
  2215. -
  2216.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2217.  with "unsubscribe usr-tc" in the body of the message.
  2218.  For information on digests or retrieving files and old messages send
  2219.  "help" to the same address.  Do not use quotes in your message.
  2220.  
  2221.  
  2222. -------------------------------------------------------------------------------
  2223.  
  2224. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  2225. Subject: RE: (usr-tc) Dual channel ISDN problem.
  2226. Date: 04 Oct 1999 13:13:58 -0500
  2227.  
  2228.  
  2229.  
  2230. |-----Original Message-----
  2231. |From: owner-usr-tc@lists.xmission.com
  2232. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Horace Demmink
  2233. |Sent: Monday, October 04, 1999 11:45 AM
  2234. |To: usr-tc@lists.xmission.com
  2235. |Subject: (usr-tc) Dual channel ISDN problem.
  2236. |
  2237. |
  2238. |
  2239. |I have been trying to figure out a problem that one of my customers has
  2240. |been having. They are dialing up with a 3COM NetBuilder to our TC
  2241. |equipment. The first channel comes up fine, but the second one will not
  2242. |come up. The NetBuilder attempts to bring it up, fails, and waits a few
  2243. |seconds before trying again. ISDN is $.08 per call in this area so they
  2244. |are racking up quite a bill. I have never seen this before with any other
  2245. |customer, and as far as I know they are the only ones with a 3COM
  2246. |NetBuilder, so I am assuming that it is a problem or misconfiguration with
  2247. |their router. Is anyone else familiar with these things? Thanks very much
  2248. |in advance for any help or advice anyone can offer.
  2249. |
  2250. |We are running:
  2251. |
  2252. |ARC 4.2.32-1
  2253. |DSP 2.0.81
  2254. |
  2255. |Here is the relevant section of their radius entry:
  2256. |
  2257. |username        Auth-Type = System
  2258. |                Service-Type = Framed,
  2259. |                Framed-IP-Address = xxx.xxx.xxx.xxx,
  2260. |                Framed-IP-Netmask = 255.255.255.255,
  2261. |                Framed-Protocol = PPP,
  2262. |                Framed-Route = "yyy.yyy.yyy.yyy/30 0.0.0.0 1",
  2263. |                Framed-Routing = None,
  2264. |                Framed-MTU = 1500,
  2265. |                Idle-Timeout = 0,
  2266. |                Port-Limit = 2,
  2267. |                Framed-Compression = Van-Jacobson-TCP-IP
  2268. |
  2269. |
  2270. |And the following is about a minutes worth of a dump of a monitor ppp from
  2271. |the arc:
  2272. |
  2273. |Decode tracing started, press ESCAPE to stop; press X for hex tracing.
  2274. |
  2275. |Incoming PPP Data on interface: slot:15/mod:20
  2276. |    LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68
  2277.  
  2278. Your PPP trace is of the channel that is already up and is of now use for
  2279. debugging this problem. What needs to be seen is the LCP seesion through IPCP on
  2280. the first channel and then the PPP trace of the second channel failing..
  2281.  
  2282. -M
  2283.  
  2284.  
  2285. -
  2286.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2287.  with "unsubscribe usr-tc" in the body of the message.
  2288.  For information on digests or retrieving files and old messages send
  2289.  "help" to the same address.  Do not use quotes in your message.
  2290.  
  2291.  
  2292. -------------------------------------------------------------------------------
  2293.  
  2294. From: Ahmed Saeed <Ahmed.Saeed@widener.edu>
  2295. Subject: Re: (usr-tc) Dual channel ISDN problem.
  2296. Date: 04 Oct 1999 14:11:46 -0400 (EDT)
  2297.  
  2298. Horace, 
  2299.  
  2300. The ppp traces indicate that the NetBuilder is sending LCP Echo request 
  2301. packets to determine link quality. Also, these packets can be used for 
  2302. loop back mechanism.
  2303.  
  2304. In each case, the hiper arc is sending the correct packets. This is not 
  2305. the case. 
  2306.  
  2307. For ISDN to terminate, LCP extensions need to be configured and 
  2308. exchanged. 
  2309. If you do not see these PPP LCP packets and the link is already down 
  2310. before this level, then the issue needs to be debugged from the modem 
  2311. level. 
  2312.  
  2313. Kindly post the mon ppp traces - if any -
  2314.  
  2315. Ahmed 
  2316.  
  2317. On Mon, 4 Oct 1999, Horace Demmink wrote:
  2318.  
  2319. > 
  2320. > I have been trying to figure out a problem that one of my customers has
  2321. > been having. They are dialing up with a 3COM NetBuilder to our TC
  2322. > equipment. The first channel comes up fine, but the second one will not
  2323. > come up. The NetBuilder attempts to bring it up, fails, and waits a few
  2324. > seconds before trying again. ISDN is $.08 per call in this area so they
  2325. > are racking up quite a bill. I have never seen this before with any other
  2326. > customer, and as far as I know they are the only ones with a 3COM
  2327. > NetBuilder, so I am assuming that it is a problem or misconfiguration with
  2328. > their router. Is anyone else familiar with these things? Thanks very much
  2329. > in advance for any help or advice anyone can offer.
  2330. > 
  2331. > We are running:
  2332. > 
  2333. > ARC 4.2.32-1
  2334. > DSP 2.0.81
  2335. > 
  2336. > Here is the relevant section of their radius entry:
  2337. > 
  2338. > username        Auth-Type = System
  2339. >                 Service-Type = Framed,
  2340. >                 Framed-IP-Address = xxx.xxx.xxx.xxx,
  2341. >                 Framed-IP-Netmask = 255.255.255.255,
  2342. >                 Framed-Protocol = PPP,
  2343. >                 Framed-Route = "yyy.yyy.yyy.yyy/30 0.0.0.0 1",
  2344. >                 Framed-Routing = None,
  2345. >                 Framed-MTU = 1500,
  2346. >                 Idle-Timeout = 0,
  2347. >                 Port-Limit = 2,
  2348. >                 Framed-Compression = Van-Jacobson-TCP-IP
  2349. > 
  2350. > 
  2351. > And the following is about a minutes worth of a dump of a monitor ppp from
  2352. > the arc:
  2353. > 
  2354. > Decode tracing started, press ESCAPE to stop; press X for hex tracing.
  2355. > 
  2356. > Incoming PPP Data on interface: slot:15/mod:20 
  2357. >     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  2358. > 
  2359. > Outgoing PPP Data on interface: slot:15/mod:20 
  2360. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2361. > 
  2362. > Incoming PPP Data on interface: slot:15/mod:20 
  2363. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2364. > 
  2365. > Outgoing PPP Data on interface: slot:15/mod:20 
  2366. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2367. > 
  2368. > Incoming PPP Data on interface: slot:15/mod:20 
  2369. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2370. > 
  2371. > Outgoing PPP Data on interface: slot:15/mod:20 
  2372. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2373. > 
  2374. > Outgoing PPP Data on interface: slot:15/mod:21 
  2375. >     PAP        ACK               
  2376. > Incoming PPP Data on interface: slot:15/mod:20 
  2377. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2378. > 
  2379. > Outgoing PPP Data on interface: slot:15/mod:20 
  2380. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2381. > 
  2382. > Incoming PPP Data on interface: slot:15/mod:20 
  2383. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2384. > 
  2385. > Outgoing PPP Data on interface: slot:15/mod:20 
  2386. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2387. > 
  2388. > Outgoing PPP Data on interface: slot:15/mod:21 
  2389. >     PAP        ACK               
  2390. > Incoming PPP Data on interface: slot:15/mod:20 
  2391. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2392. > 
  2393. > Outgoing PPP Data on interface: slot:15/mod:20 
  2394. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2395. > 
  2396. > Incoming PPP Data on interface: slot:15/mod:20 
  2397. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2398. > 
  2399. > Outgoing PPP Data on interface: slot:15/mod:20 
  2400. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2401. > 
  2402. > Incoming PPP Data on interface: slot:15/mod:20 
  2403. >     LCP        ECHO_REQ          00 cc f7 cf 18 d8 2e c9 
  2404. > 
  2405. > Outgoing PPP Data on interface: slot:15/mod:20 
  2406. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2407. > 
  2408. > Outgoing PPP Data on interface: slot:15/mod:21 
  2409. >     PAP        ACK               
  2410. > Incoming PPP Data on interface: slot:15/mod:20 
  2411. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2412. > 
  2413. > Outgoing PPP Data on interface: slot:15/mod:20 
  2414. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2415. > 
  2416. > Incoming PPP Data on interface: slot:15/mod:20 
  2417. >     LCP        ECHO_REQ          00 cc f7 cf 50 68 6f 6e 
  2418. > 
  2419. > Outgoing PPP Data on interface: slot:15/mod:20 
  2420. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2421. > 
  2422. > Incoming PPP Data on interface: slot:15/mod:20 
  2423. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2424. > 
  2425. > Outgoing PPP Data on interface: slot:15/mod:20 
  2426. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2427. > 
  2428. > Outgoing PPP Data on interface: slot:15/mod:21 
  2429. >     PAP        ACK               
  2430. > Incoming PPP Data on interface: slot:15/mod:20 
  2431. >     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  2432. > 
  2433. > Outgoing PPP Data on interface: slot:15/mod:20 
  2434. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2435. > 
  2436. > Incoming PPP Data on interface: slot:15/mod:20 
  2437. >     LCP        ECHO_REQ          00 cc f7 cf 00 00 00 00 
  2438. > 
  2439. > Outgoing PPP Data on interface: slot:15/mod:20 
  2440. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2441. > 
  2442. > Incoming PPP Data on interface: slot:15/mod:20 
  2443. >     LCP        ECHO_REQ          00 cc f7 cf 65 6c 64 20 
  2444. > 
  2445. > Outgoing PPP Data on interface: slot:15/mod:20 
  2446. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2447. > 
  2448. > Outgoing PPP Data on interface: slot:15/mod:21 
  2449. >     PAP        ACK               
  2450. > Incoming PPP Data on interface: slot:15/mod:20 
  2451. >     LCP        ECHO_REQ          00 cc f7 cf 00 2e c8 68 
  2452. > 
  2453. > Outgoing PPP Data on interface: slot:15/mod:20 
  2454. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2455. > 
  2456. > Incoming PPP Data on interface: slot:15/mod:20 
  2457. >     LCP        ECHO_REQ          00 cc f7 cf 54 48 49 53 
  2458. > 
  2459. > Outgoing PPP Data on interface: slot:15/mod:20 
  2460. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2461. > 
  2462. > Incoming PPP Data on interface: slot:15/mod:20 
  2463. >     LCP        ECHO_REQ          00 cc f7 cf 6e 64 20 4a 
  2464. > 
  2465. > Outgoing PPP Data on interface: slot:15/mod:20 
  2466. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2467. > 
  2468. > Incoming PPP Data on interface: slot:15/mod:20 
  2469. >     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  2470. > 
  2471. > Outgoing PPP Data on interface: slot:15/mod:20 
  2472. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2473. > 
  2474. > Outgoing PPP Data on interface: slot:15/mod:21 
  2475. >     PAP        ACK               
  2476. > Incoming PPP Data on interface: slot:15/mod:20 
  2477. >     LCP        ECHO_REQ          00 cc f7 cf 81 d8 2e c9 
  2478. > 
  2479. > Outgoing PPP Data on interface: slot:15/mod:20 
  2480. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2481. > 
  2482. > Incoming PPP Data on interface: slot:15/mod:20 
  2483. >     LCP        ECHO_REQ          00 cc f7 cf 39 36 36 3b 
  2484. > 
  2485. > Outgoing PPP Data on interface: slot:15/mod:20 
  2486. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2487. > 
  2488. > Incoming PPP Data on interface: slot:15/mod:20 
  2489. >     LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68 
  2490. > 
  2491. > Outgoing PPP Data on interface: slot:15/mod:20 
  2492. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2493. > 
  2494. > Outgoing PPP Data on interface: slot:15/mod:21 
  2495. >     PAP        ACK               
  2496. > Incoming PPP Data on interface: slot:15/mod:20 
  2497. >     LCP        ECHO_REQ          00 cc f7 cf 69 d8 2e c1 
  2498. > 
  2499. > Outgoing PPP Data on interface: slot:15/mod:20 
  2500. >     LCP        ECHO_RPLY         c4 56 fa 71 
  2501. > Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
  2502. > 
  2503. > -- 
  2504. > Horace Demmink
  2505. > PathWay Computing
  2506. > 
  2507. > 
  2508. > 
  2509. > -
  2510. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2511. >  with "unsubscribe usr-tc" in the body of the message.
  2512. >  For information on digests or retrieving files and old messages send
  2513. >  "help" to the same address.  Do not use quotes in your message.
  2514. > 
  2515.  
  2516. -
  2517.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2518.  with "unsubscribe usr-tc" in the body of the message.
  2519.  For information on digests or retrieving files and old messages send
  2520.  "help" to the same address.  Do not use quotes in your message.
  2521.  
  2522.  
  2523. -------------------------------------------------------------------------------
  2524.  
  2525. From: Daniel Mpolokoso <daniel@zamnet.zm>
  2526. Subject: (usr-tc) HiPer DSP and E1/R2
  2527. Date: 04 Oct 1999 14:16:31 +0200
  2528.  
  2529. Hi,
  2530.  
  2531. I've been battling for a week trying to get HiPer DSP version 2.0.19 to
  2532. interface with our telco's switch. They are using basic E1 R2 signaling as
  2533. per ITU-T standards. I'd be grateful for anyone out there using E1 R2
  2534. signaling to give me pointers as to what version of software I should be
  2535. running and examples of typical configurations.
  2536.  
  2537. Thanks,
  2538.  
  2539.  
  2540. Daniel.
  2541. Daniel Mpolokoso - Technical Manager,           Email:  daniel@zamnet.zm
  2542. ZAMNET Communication Systems Limited,           Phone: +260 - 1 - 772516
  2543. P.O. Box 38299, Lusaka, Zambia.                 Fax:   +260 - 1 - 224775
  2544.  
  2545. -
  2546.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2547.  with "unsubscribe usr-tc" in the body of the message.
  2548.  For information on digests or retrieving files and old messages send
  2549.  "help" to the same address.  Do not use quotes in your message.
  2550.  
  2551.  
  2552. -------------------------------------------------------------------------------
  2553.  
  2554. From: "Brian Hitchcock" <brianh@kcweb.net>
  2555. Subject: (usr-tc) Simple question
  2556. Date: 29 Sep 1999 12:33:35 -0500
  2557.  
  2558. I have what I am sure is a very simple question for most of you to answer.
  2559. But what is the command to change the IP address of the NET0 interface?
  2560.  
  2561. Brian Hitchcock
  2562. KC Web
  2563.  
  2564. -
  2565.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2566.  with "unsubscribe usr-tc" in the body of the message.
  2567.  For information on digests or retrieving files and old messages send
  2568.  "help" to the same address.  Do not use quotes in your message.
  2569.  
  2570.  
  2571. -------------------------------------------------------------------------------
  2572.  
  2573. From: Mike Andrews <mandrews@bit0.com>
  2574. Subject: Re: (usr-tc) TimeZone Reality Check for ARC's
  2575. Date: 04 Oct 1999 15:38:12 -0400 (EDT)
  2576.  
  2577. On Mon, 4 Oct 1999, Jeff Binkley wrote:
  2578.  
  2579. > Not exactly.  If you are using this with an enterprise management system
  2580. > which aggregates SNMP traps, there could be a problem with some of the
  2581. > devices reporting local time and some reporting GMT time.  The fact that
  2582. > most network devices allow for a timezone offset would lend credence
  2583. > to this.
  2584.  
  2585. The NMC sends almost all of the traps, and it has a timezone (and daylight
  2586. time) setting.
  2587.  
  2588. I haven't seen the ARC send any traps, except for some OSPF ones that I
  2589. ended up turning off anyway because they weren't useful...
  2590.  
  2591.  
  2592. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  2593. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  2594. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  2595. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  2596.  
  2597.  
  2598.  
  2599. -
  2600.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2601.  with "unsubscribe usr-tc" in the body of the message.
  2602.  For information on digests or retrieving files and old messages send
  2603.  "help" to the same address.  Do not use quotes in your message.
  2604.  
  2605.  
  2606. -------------------------------------------------------------------------------
  2607.  
  2608. From: Mike Andrews <mandrews@bit0.com>
  2609. Subject: RE: (usr-tc) TimeZone Reality Check for ARC's (THREAD ENDER)
  2610. Date: 04 Oct 1999 15:40:20 -0400 (EDT)
  2611.  
  2612. What else is new in 5.0?  (You just KNEW you were gonna get asked that :)
  2613. I'm guessing it won't be out for quite a while...  but I'm mildly curious.
  2614.  
  2615.  
  2616. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  2617. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  2618. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  2619. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  2620.  
  2621. On Mon, 4 Oct 1999, Mike Wronski wrote:
  2622.  
  2623. > To put an end to this thread. HARC 5.0 has TZ configurable for cosmetic reasons..
  2624. > And I do believe that Jeff is correct here. The TIMESTAMP should always be in
  2625. > GMT. The receiver is responsible for correcting for local display.
  2626.  
  2627.  
  2628. -
  2629.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2630.  with "unsubscribe usr-tc" in the body of the message.
  2631.  For information on digests or retrieving files and old messages send
  2632.  "help" to the same address.  Do not use quotes in your message.
  2633.  
  2634.  
  2635. -------------------------------------------------------------------------------
  2636.  
  2637. From: <vanhalen@coredcs.com>
  2638. Subject: (usr-tc) Disable "Press Return for More" in Netserver?
  2639. Date: 04 Oct 1999 16:22:02 -0500 (CDT)
  2640.  
  2641. Hello-
  2642.  
  2643. Is there a way with a netserver based card to disable the page breaks?  I
  2644. know how to do it on a Hiperarc based chassis but not the older ones.  Any
  2645. help?
  2646.  
  2647.  
  2648. -
  2649.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2650.  with "unsubscribe usr-tc" in the body of the message.
  2651.  For information on digests or retrieving files and old messages send
  2652.  "help" to the same address.  Do not use quotes in your message.
  2653.  
  2654.  
  2655. -------------------------------------------------------------------------------
  2656.  
  2657. From: Jeff Mcadams <jeffm@iglou.com>
  2658. Subject: Re: (usr-tc) Disable "Press Return for More" in Netserver?
  2659. Date: 04 Oct 1999 19:01:56 -0400
  2660.  
  2661. Thus spake vanhalen@coredcs.com
  2662. >Is there a way with a netserver based card to disable the page breaks?  I
  2663. >know how to do it on a Hiperarc based chassis but not the older ones.  Any
  2664. >help?
  2665.  
  2666. Nope, can't do it on the NETServers.  It was hard-coded on page length.
  2667. Rather annoying, but dat's the way it is.
  2668. -- 
  2669. Jeff McAdams                            Email: jeffm@iglou.com
  2670. Head Network Administrator              Voice: (502) 966-3848
  2671. IgLou Internet Services                        (800) 436-4456
  2672.  
  2673. -
  2674.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2675.  with "unsubscribe usr-tc" in the body of the message.
  2676.  For information on digests or retrieving files and old messages send
  2677.  "help" to the same address.  Do not use quotes in your message.
  2678.  
  2679.  
  2680. -------------------------------------------------------------------------------
  2681.  
  2682. From: "Brett Murphy" <me@murf.net>
  2683. Subject: Re: (usr-tc) Simple question
  2684. Date: 05 Oct 1999 09:09:06 +1000
  2685.  
  2686. Netserver, from console
  2687. set password <your_password>
  2688. set prompt your_prompt>
  2689. set domain your_domain.com.au
  2690. set namesvc dns
  2691. set nameserver 202.3.4.5  (your DNS)
  2692. set sysname your_sysname
  2693. set net0 address 202.7.6.5 (your netserver IP address)
  2694. set net0 netmask 255.255.255.0 (your netmask)
  2695. set gateway 202.7.6.1  (your gateway)
  2696. set modem density all 4   (4 for quad cards)
  2697. set modem startslot 2   (start at slot 2 if you have a dual pri card or T1)
  2698. set modem s1-s56 active  (this is for 14 quad cards)
  2699. set all message ^first line of message^second line of message^^
  2700. set accounting 202.7.6.2 (radius accounting server)
  2701. set authentic 202.7.6.3  (radius auth server)
  2702. set alternate 202.7.6.4 (backup radius auth server)
  2703. set assigned 202.9.8.1 (starting ip pool address for PPP logins)
  2704. set secret your_radius_secret
  2705. set all security on  (this allows console based login as well as PAP/etc)
  2706. set snmp on 
  2707. save all
  2708. reboot
  2709.  
  2710.  
  2711.  
  2712. All the best,
  2713. Brett Murphy
  2714. Technical Manager, Alphalink (Australia) PTY LTD
  2715. ph: +61 3 9486-8844  fax: +61 3 9486-6822
  2716. email: me@murf.net
  2717.  
  2718. The contents of this email message may not be quoted,
  2719. copied, reproduced or published in part or in whole,
  2720. without the written authorization of Brett Murphy,
  2721. Director, Alphalink (Australia) Pty Ltd.
  2722. -----Original Message-----
  2723.  
  2724.  
  2725. >I have what I am sure is a very simple question for most of you to answer.
  2726. >But what is the command to change the IP address of the NET0 interface?
  2727. >
  2728. >Brian Hitchcock
  2729. >KC Web
  2730. >
  2731. >-
  2732. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2733. > with "unsubscribe usr-tc" in the body of the message.
  2734. > For information on digests or retrieving files and old messages send
  2735. > "help" to the same address.  Do not use quotes in your message.
  2736. >
  2737.  
  2738.  
  2739. -
  2740.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2741.  with "unsubscribe usr-tc" in the body of the message.
  2742.  For information on digests or retrieving files and old messages send
  2743.  "help" to the same address.  Do not use quotes in your message.
  2744.  
  2745.  
  2746. -------------------------------------------------------------------------------
  2747.  
  2748. From: Dataheart List Email <lists@dataheart.net>
  2749. Subject: (usr-tc) Netserver Code
  2750. Date: 04 Oct 1999 23:25:03 +1000 (EST)
  2751.  
  2752. Hi,
  2753.  
  2754. Recently I decided to upgrade the firmware on me netserver card, I was send the code by the 3com technitian but it appears to be the wrong one? The code from the 3com tech starts with Li while TCM prompts me for Le code? can someone please send me the Le code?
  2755.  
  2756. Thanks,
  2757. Aaron
  2758.  
  2759. -
  2760.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2761.  with "unsubscribe usr-tc" in the body of the message.
  2762.  For information on digests or retrieving files and old messages send
  2763.  "help" to the same address.  Do not use quotes in your message.
  2764.  
  2765.  
  2766. -------------------------------------------------------------------------------
  2767.  
  2768. From: Horace Demmink <horace@pathwaynet.com>
  2769. Subject: RE: (usr-tc) Dual channel ISDN problem.
  2770. Date: 05 Oct 1999 12:43:42 -0400 (EDT)
  2771.  
  2772. On Mon, 4 Oct 1999, Mike Wronski wrote:
  2773.  
  2774. > 
  2775. > |And the following is about a minutes worth of a dump of a monitor ppp from
  2776. > |the arc:
  2777. > |
  2778. > |Decode tracing started, press ESCAPE to stop; press X for hex tracing.
  2779. > |
  2780. > |Incoming PPP Data on interface: slot:15/mod:20
  2781. > |    LCP        ECHO_REQ          00 cc f7 cf d8 2e c8 68
  2782. > 
  2783. > Your PPP trace is of the channel that is already up and is of now use for
  2784. > debugging this problem. What needs to be seen is the LCP seesion through IPCP on
  2785. > the first channel and then the PPP trace of the second channel failing..
  2786. > 
  2787.  
  2788. Hmm, how do I go about getting this info?
  2789.  
  2790. -- 
  2791. Horace Demmink
  2792. PathWay Computing
  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. From: <dciresi@defunct.ae.usr.com>
  2805. Subject: Re: (usr-tc) Netserver Code
  2806. Date: 05 Oct 1999 11:57:42 -0500 (CDT)
  2807.  
  2808. Netserver revisions used to distinguish between ISDN/non-ISDN(or ethernet)
  2809. versions.  All versions now contain ISDN support.  The "LI" version of
  2810. code will load and run just fine on your Netserver, provided you have 16M
  2811. RAM and 4M flash.
  2812.  
  2813. Dominic
  2814.  
  2815. On Mon, 4 Oct 1999, Dataheart List Email wrote:
  2816.  
  2817. > Hi,
  2818. > 
  2819. > Recently I decided to upgrade the firmware on me netserver card, I was send the code by the 3com technitian but it appears to be the wrong one? The code from the 3com tech starts with Li while TCM prompts me for Le code? can someone please send me the Le code?
  2820. > 
  2821. > Thanks,
  2822. > Aaron
  2823. > 
  2824. > -
  2825. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2826. >  with "unsubscribe usr-tc" in the body of the message.
  2827. >  For information on digests or retrieving files and old messages send
  2828. >  "help" to the same address.  Do not use quotes in your message.
  2829. > 
  2830.  
  2831.  
  2832. -
  2833.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2834.  with "unsubscribe usr-tc" in the body of the message.
  2835.  For information on digests or retrieving files and old messages send
  2836.  "help" to the same address.  Do not use quotes in your message.
  2837.  
  2838.  
  2839. -------------------------------------------------------------------------------
  2840.  
  2841. From: "Ryan Hilliard" <hilliard@twoalpha.net>
  2842. Subject: (usr-tc) Unusual sysolg messages...
  2843. Date: 05 Oct 1999 13:14:51 -0600
  2844.  
  2845. We just started really looking at our syslog files, and have noticed that
  2846. almost everytime a user logs in, we get this error about 5 to 15 times in a
  2847. row, and then no more.  Can anyone tell me why?  Everything seems to work
  2848. just fine despite the messages.
  2849.  
  2850. At 12:43:49, Facility "IP", Level "UNUSUAL":: Sent Dest Unreachable (code =
  2851. 3) ICMP to XXX.XXX.XXX.XXX
  2852.  
  2853. Ryan Hilliard
  2854. TwoAlpha Internet Administrator
  2855. www.twoalpha.net
  2856. 406-628-1500
  2857.  
  2858.  
  2859.  
  2860. -
  2861.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2862.  with "unsubscribe usr-tc" in the body of the message.
  2863.  For information on digests or retrieving files and old messages send
  2864.  "help" to the same address.  Do not use quotes in your message.
  2865.  
  2866.  
  2867. -------------------------------------------------------------------------------
  2868.  
  2869. From: Marcelo Souza <mpsouza@centroin.com.br>
  2870. Subject: Re: (usr-tc) HiPer DSP and E1/R2
  2871. Date: 05 Oct 1999 18:50:12 -0200 (EDT)
  2872.  
  2873. Hi Daniel,
  2874.  
  2875. On Mon, 4 Oct 1999, Daniel Mpolokoso wrote:
  2876.  
  2877. |I've been battling for a week trying to get HiPer DSP version 2.0.19 to
  2878. |interface with our telco's switch. They are using basic E1 R2 signaling as
  2879. |per ITU-T standards. I'd be grateful for anyone out there using E1 R2
  2880. |signaling to give me pointers as to what version of software I should be
  2881. |running and examples of typical configurations.
  2882.  
  2883.     Here we're running the version 2.0.10, for E1 R2 signaling on
  2884. DSPs. As I know, this is the latest version for E1R2. 
  2885.     The 2.0.19, is for T1 lines.
  2886.  
  2887. - Marcelo
  2888.  
  2889. |------------------------------------------------------------------------
  2890. |Daniel Mpolokoso - Technical Manager,           Email:  daniel@zamnet.zm
  2891. |ZAMNET Communication Systems Limited,           Phone: +260 - 1 - 772516
  2892. |P.O. Box 38299, Lusaka, Zambia.                 Fax:   +260 - 1 - 224775
  2893. |
  2894. |-
  2895. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2896. | with "unsubscribe usr-tc" in the body of the message.
  2897. | For information on digests or retrieving files and old messages send
  2898. | "help" to the same address.  Do not use quotes in your message.
  2899. |
  2900.  
  2901. - Marcelo
  2902.  
  2903.  
  2904.  
  2905. -
  2906.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2907.  with "unsubscribe usr-tc" in the body of the message.
  2908.  For information on digests or retrieving files and old messages send
  2909.  "help" to the same address.  Do not use quotes in your message.
  2910.  
  2911.  
  2912. -------------------------------------------------------------------------------
  2913.  
  2914. From: GTI x2 Tech <x2@apollo.gti.net>
  2915. Subject: (usr-tc) Microsoft VPN problems via TC
  2916. Date: 05 Oct 1999 16:57:34 -0400 (EDT)
  2917.  
  2918.  
  2919.  
  2920. Objective:  To promote awareness of Microsoft Virtual Private Networking
  2921. (VPN) problems experienced with USR Total Control Manager Terminal
  2922. Servers.
  2923.  
  2924. Test Equipment for Experiment #1:
  2925.  
  2926.         VPN Server: Microsoft NT 4.0 (SP5) Server  100base-T Ethernet
  2927.         VPN Client: Windows 98  Standard Modem 33.6 kbps
  2928.  
  2929.         Environment:
  2930.  
  2931. a)      An NT user account was created with logon locally services rights.
  2932. b)      MS-VPN and Remote Access (RAS) was configured for remote        
  2933.         connectivity and VPN with 1 available network.
  2934. c)      Private class-c IPs were assigned to the VPN network for
  2935.         dynamically assigned addressing of remote clients.
  2936. d)      Network Domain was configured and named XYZ
  2937. e)      Win 98 machine was configured for Dial-up Networking including
  2938.         Dial-up adapter, TCP/IP and Microsoft Virtual Private Networking
  2939.         Dial-up adapter, and VPN Networking.
  2940. f)      Win 98 domain (workgroup) was set to XYZ. Dialup networking
  2941.  
  2942. Test Results: (Livingston Port Master 2e)
  2943.  
  2944.                 Using the standard Dial-up networking in Windows 98, I
  2945. established an Internet connection to GTI using the analog Livingston Port
  2946. Master 2e.  I verified my connectivity by the use of such utilities as
  2947. ping, traceroute and standard http, FTP and Telnet protocols. At that
  2948. point I launched the VPN Dialup networking connection to the VPN server.
  2949. The VPN server verified and authenticated my account and logged me in. I
  2950. then ran a netstat utility to display my current Internet IP as well as
  2951. the newly assigned private class-c IP provided by the VPN server.  I could
  2952. then go into Network Neighborhood and access every machine belonging to
  2953. the XYZ domain, based on my account privileges previously configured
  2954. at the VPN server user account manager.
  2955.  
  2956. Test Results: (USR Total Control)
  2957.  
  2958.                 Using the identical environments as above, I changed the
  2959. dial-up node number to connect to the USR Total Control Terminal Server.  
  2960. The VPN authenticated my user account and logged me in, but there was
  2961. absolutely NO connectively to the XYZ domain and the Internet connection
  2962. completely stalled.
  2963.  
  2964. Hypothesis:
  2965.    
  2966.                 I believe the USR units are prohibiting the use of VPN
  2967. somehow. Clients should be able to pass VPN packets regardless of what
  2968. dialup they use. The Livingston 2e does not have a problem with VPN at
  2969. all, so it looks like the USR is mis-configured somehow.
  2970.  
  2971. Any insight would be appriciated.
  2972.  
  2973.  
  2974.  
  2975. -
  2976.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2977.  with "unsubscribe usr-tc" in the body of the message.
  2978.  For information on digests or retrieving files and old messages send
  2979.  "help" to the same address.  Do not use quotes in your message.
  2980.  
  2981.  
  2982. -------------------------------------------------------------------------------
  2983.  
  2984. From: Laszlo Vecsey <master@internexus.net>
  2985. Subject: (usr-tc) hiperarc and multicast
  2986. Date: 05 Oct 1999 17:15:03 -0400 (EDT)
  2987.  
  2988. I have multicast available on my network, through a Cisco router. Will the
  2989. hiperarc route multicast to dialup users, natively? Or does each dialup
  2990. user have to run a program like 'mTunnel' or use another method to set up
  2991. a unique tunnel, like with mrouted.
  2992.  
  2993. lv.
  2994.  
  2995.  
  2996.  
  2997. -
  2998.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2999.  with "unsubscribe usr-tc" in the body of the message.
  3000.  For information on digests or retrieving files and old messages send
  3001.  "help" to the same address.  Do not use quotes in your message.
  3002.  
  3003.  
  3004. -------------------------------------------------------------------------------
  3005.  
  3006. From: "David Bachta" <David_Bachta@mw.3com.com>
  3007. Subject: Re: (usr-tc) HiPer DSP and E1/R2
  3008. Date: 05 Oct 1999 16:24:40 -0500
  3009.  
  3010.  
  3011.  
  3012. Hi Daniel,
  3013.  
  3014. You will need an E1/R2 version of Hiper DSP code.  The filename is in the format
  3015. of HR******.DMF, where the *s are the version number.   The HE******.DMF files
  3016. are for E1/PRI and the HD******.DMF files are for T1/PRI.  The R2 code is not
  3017. generally available yet but there are beta and engineering releases that some
  3018. customers have been using.
  3019.  
  3020. Your best bet is to call your local support team for assistance at :
  3021.  
  3022.      South Africa        0800-995014
  3023.  
  3024. Hope this helps...
  3025.  
  3026. Regards,
  3027. David
  3028.  
  3029.  
  3030.  
  3031.  
  3032.  
  3033. Daniel Mpolokoso <daniel@zamnet.zm> on 10/04/99 07:16:31 AM
  3034.  
  3035. Please respond to usr-tc@lists.xmission.com
  3036.  
  3037. Sent by:  Daniel Mpolokoso <daniel@zamnet.zm>
  3038.  
  3039.  
  3040. cc:    (David Bachta/MW/US/3Com)
  3041.  
  3042.  
  3043.  
  3044.  
  3045. Hi,
  3046.  
  3047. I've been battling for a week trying to get HiPer DSP version 2.0.19 to
  3048. interface with our telco's switch. They are using basic E1 R2 signaling as
  3049. per ITU-T standards. I'd be grateful for anyone out there using E1 R2
  3050. signaling to give me pointers as to what version of software I should be
  3051. running and examples of typical configurations.
  3052.  
  3053. Thanks,
  3054.  
  3055.  
  3056. Daniel.
  3057. Daniel Mpolokoso - Technical Manager,           Email:  daniel@zamnet.zm
  3058. ZAMNET Communication Systems Limited,           Phone: +260 - 1 - 772516
  3059. P.O. Box 38299, Lusaka, Zambia.                 Fax:   +260 - 1 - 224775
  3060.  
  3061. -
  3062.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3063.  with "unsubscribe usr-tc" in the body of the message.
  3064.  For information on digests or retrieving files and old messages send
  3065.  "help" to the same address.  Do not use quotes in your message.
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072. -
  3073.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3074.  with "unsubscribe usr-tc" in the body of the message.
  3075.  For information on digests or retrieving files and old messages send
  3076.  "help" to the same address.  Do not use quotes in your message.
  3077.  
  3078.  
  3079. -------------------------------------------------------------------------------
  3080.  
  3081. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  3082. Subject: RE: (usr-tc) hiperarc and multicast
  3083. Date: 05 Oct 1999 16:32:13 -0500
  3084.  
  3085. HARC supports IGMP. Your cisco should be set up properly to talk IGMP as well..
  3086. You will need to use PIM.
  3087. Clients dialing in can then request a stream via IGMP and the HARC will then
  3088. forward the MCast packets to them.
  3089. There is a manual section in the 4.1 manual regarding multicast support. No
  3090. special software is required by the client..
  3091.  
  3092.  
  3093. -M
  3094.  
  3095.  
  3096. |-----Original Message-----
  3097. |From: owner-usr-tc@lists.xmission.com
  3098. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Laszlo Vecsey
  3099. |Sent: Tuesday, October 05, 1999 4:15 PM
  3100. |To: usr-tc@xmission.com
  3101. |Subject: (usr-tc) hiperarc and multicast
  3102. |
  3103. |
  3104. |I have multicast available on my network, through a Cisco router. Will the
  3105. |hiperarc route multicast to dialup users, natively? Or does each dialup
  3106. |user have to run a program like 'mTunnel' or use another method to set up
  3107. |a unique tunnel, like with mrouted.
  3108. |
  3109. |lv.
  3110. |
  3111. |
  3112. |
  3113. |-
  3114. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3115. | with "unsubscribe usr-tc" in the body of the message.
  3116. | For information on digests or retrieving files and old messages send
  3117. | "help" to the same address.  Do not use quotes in your message.
  3118. |
  3119.  
  3120.  
  3121. -
  3122.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3123.  with "unsubscribe usr-tc" in the body of the message.
  3124.  For information on digests or retrieving files and old messages send
  3125.  "help" to the same address.  Do not use quotes in your message.
  3126.  
  3127.  
  3128. -------------------------------------------------------------------------------
  3129.  
  3130. From: Dataheart <lists@dataheart.net>
  3131. Subject: (usr-tc) Slow Busy on Dual PRI NAC
  3132. Date: 06 Oct 1999 14:16:38 +1000
  3133.  
  3134. Greetings,
  3135.  
  3136. I have a wierd problem that I am unable to resolve, it goes a little
  3137. something like this.
  3138. I have a Total Control Chassis, It all appears to be configured
  3139. correctly
  3140. but when I dial into it, the line goes quies for about 10 seconds then a
  3141.  
  3142. busy signal.
  3143. I have followed the enable Debug routein but even then the Call control
  3144. call
  3145. stats show no dialins even after several attempts this got me thinking
  3146. that
  3147. it was a telco problem that was until I enabled Display Call Control
  3148. Debug
  3149. Info and then whenever I dialed in I got this on the console;
  3150.  
  3151. :uccu_get_new_uccb: attach uccb to head of list. tcid: 0x1e ucid:
  3152. 0x0000001e
  3153. uccu_get_new_uccb: ALLOC tcid: 0x1e ucid: 0x0000001e, allocated = 1,
  3154. dsl_id=1
  3155. sfn:ucc_null,evt:20-SETUP_IND,tcid:0x1e,ucid:0x0000001e
  3156. ucc_setup_in_call: tcid: 0x1e, CRV: 38 (0x26)
  3157. DNIS nums:2 cl type override nums:0
  3158. ucc_setup_in_call: ANI (calling_phnum) ><, len = 0, err = 0x31
  3159. ucc_setup_in_call: Info buffer allocated
  3160. GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=3 bitmap=80
  3161. GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=2 bitmap=0
  3162. GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=1 bitmap=0
  3163. GetDS0SlotMapByte: mdm_id=0 span=1 ds0=32 octet=0 bitmap=0
  3164.  
  3165. uccu_get_tncid_uccb: tcid = 0x1e, position in uccb list = 0, dsl = 1
  3166. sfn:ucc_s8_go_null,evt:15-CLEAR_IND,tcid:0x1e,ucid:0x0000001e
  3167. uccu_releasing uccb: DE-ALLOC: tcid = 0x0, ucid = 0x0000001e
  3168. uccu_release_uccb: Info buffer released
  3169. uccidm_release_ds0: span = 1, ds0 = 32
  3170. uccu_release_bchs: DE-ALLOC ucid: 0x0000001e
  3171.  
  3172. The first 1/2 happens when I dial then after the space is when it sends
  3173. me
  3174. the busy signal?
  3175. Any Ideas?
  3176.  
  3177. Thanks,
  3178. Aaron
  3179.  
  3180.  
  3181.  
  3182. -
  3183.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3184.  with "unsubscribe usr-tc" in the body of the message.
  3185.  For information on digests or retrieving files and old messages send
  3186.  "help" to the same address.  Do not use quotes in your message.
  3187.  
  3188.  
  3189. -------------------------------------------------------------------------------
  3190.  
  3191. From: "Jamie Orzechowski" <mhz@ripnet.com>
  3192. Subject: (usr-tc) Filter
  3193. Date: 06 Oct 1999 10:00:36 -0400
  3194.  
  3195. I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  3196. to one specific site.
  3197.  
  3198. We would like have filter so that any late payment people will still be able
  3199. to login but they will be redirected to a website informing them that their
  3200. bill is due.
  3201.  
  3202. would also like the filter to not allow any traffic other than HTTP.
  3203.  
  3204. any ideas?
  3205.  
  3206.  
  3207. -
  3208.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3209.  with "unsubscribe usr-tc" in the body of the message.
  3210.  For information on digests or retrieving files and old messages send
  3211.  "help" to the same address.  Do not use quotes in your message.
  3212.  
  3213.  
  3214. -------------------------------------------------------------------------------
  3215.  
  3216. From: Charles Sprickman <spork@inch.com>
  3217. Subject: Re: (usr-tc) Filter
  3218. Date: 06 Oct 1999 10:31:02 -0400 (EDT)
  3219.  
  3220. On Wed, 6 Oct 1999, Jamie Orzechowski wrote:
  3221.  
  3222. > I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  3223. > to one specific site.
  3224.  
  3225. This is something the ARC can't do, but it is possible...
  3226.  
  3227. > We would like have filter so that any late payment people will still be able
  3228. > to login but they will be redirected to a website informing them that their
  3229. > bill is due.
  3230.  
  3231. There was a discussion about this very thing some time back.  Basically
  3232. you will need to set your delinquent customers up in such a way that they
  3233. will receive a different default route.  Point that route to a FreeBSD box
  3234. running ipfilter with the transproxy module and run squid on it. 
  3235.  
  3236. That's the skinny.  It's possible, but I've not done it, so I don't have
  3237. details.  If there's any Cisco route-map smarties on the list, they can
  3238. probably find a way to do this without an extra machine at your pop...
  3239.  
  3240. > would also like the filter to not allow any traffic other than HTTP.
  3241.  
  3242. You could also redirect 25 and 110 to the box and have dummy smtp/pop
  3243. servers that supply errors stating that "your account is past due, please
  3244. call billing @ xxx-xxx".  A nice starting point is "dpop" which is a dummy
  3245. popper.  Altavista should turn up it's location.
  3246.  
  3247. Charles
  3248.  
  3249. > any ideas?
  3250. > 
  3251. > 
  3252. > -
  3253. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3254. >  with "unsubscribe usr-tc" in the body of the message.
  3255. >  For information on digests or retrieving files and old messages send
  3256. >  "help" to the same address.  Do not use quotes in your message.
  3257. > 
  3258.  
  3259.  
  3260. -
  3261.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3262.  with "unsubscribe usr-tc" in the body of the message.
  3263.  For information on digests or retrieving files and old messages send
  3264.  "help" to the same address.  Do not use quotes in your message.
  3265.  
  3266.  
  3267. -------------------------------------------------------------------------------
  3268.  
  3269. From: "Network Administrator" <netadmin@seidata.com>
  3270. Subject: (usr-tc) Quad cards not answering analog calls
  3271. Date: 06 Oct 1999 11:41:41 -0500
  3272.  
  3273. This is a multi-part message in MIME format.
  3274.  
  3275. ------=_NextPart_000_000B_01BF0FEF.C1E95D00
  3276. Content-Type: text/plain;
  3277.     charset="iso-8859-1"
  3278. Content-Transfer-Encoding: quoted-printable
  3279.  
  3280. I am using the v.34 analog/digital Quad cards (v.5.6.7) with the =
  3281. Netserver card. I had six existing cards using the same version of =
  3282. software. I recently added 8 new lines to this box and two quad cards. =
  3283. The quads will not answer incoming calls. I have checked each modem =
  3284. individually as well as tried other cards and re-flashed the code to the =
  3285. cards. If anyone has any idea what may be the problem, please reply.
  3286.  
  3287.  
  3288. -Cheryl
  3289. Seidata Network Services, Inc.
  3290. http://www.seidata.com
  3291.  
  3292.  
  3293. ------=_NextPart_000_000B_01BF0FEF.C1E95D00
  3294. Content-Type: text/html;
  3295.     charset="iso-8859-1"
  3296. Content-Transfer-Encoding: quoted-printable
  3297.  
  3298. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  3299. <HTML><HEAD>
  3300. <META content=3D"text/html; charset=3Diso-8859-1" =
  3301. http-equiv=3DContent-Type>
  3302. <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
  3303. <STYLE></STYLE>
  3304. </HEAD>
  3305. <BODY bgColor=3D#ffffff>
  3306. <DIV><FONT face=3DArial size=3D2>I am using the v.34 analog/digital Quad =
  3307. cards=20
  3308. (v.5.6.7) with the Netserver card. I had six existing cards using the =
  3309. same=20
  3310. version of software. I recently added 8 new lines to this box and two =
  3311. quad=20
  3312. cards. The quads will not answer incoming calls. I have checked each =
  3313. modem=20
  3314. individually as well as tried other cards and re-flashed the code to the =
  3315. cards.=20
  3316. If anyone has any idea what may be the problem, please =
  3317. reply.</FONT></DIV>
  3318. <DIV> </DIV>
  3319. <DIV> </DIV>
  3320. <DIV><FONT face=3DArial size=3D2>-Cheryl</FONT></DIV>
  3321. <DIV><FONT face=3DArial size=3D2>Seidata Network Services, =
  3322. Inc.</FONT></DIV>
  3323. <DIV><FONT face=3DArial size=3D2><A=20
  3324. href=3D"http://www.seidata.com">http://www.seidata.com</A></FONT></DIV>
  3325. <DIV> </DIV></BODY></HTML>
  3326.  
  3327. ------=_NextPart_000_000B_01BF0FEF.C1E95D00--
  3328.  
  3329.  
  3330. -
  3331.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3332.  with "unsubscribe usr-tc" in the body of the message.
  3333.  For information on digests or retrieving files and old messages send
  3334.  "help" to the same address.  Do not use quotes in your message.
  3335.  
  3336.  
  3337. -------------------------------------------------------------------------------
  3338.  
  3339. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  3340. Subject: RE: (usr-tc) Quad cards not answering analog calls
  3341. Date: 06 Oct 1999 12:45:29 -0300 
  3342.  
  3343.  
  3344. I assume you are using POTS lines.  If you have the Line Interface =
  3345. Options
  3346. for the modem set to nic rather than pritdm or t1tdm that should be all =
  3347. you
  3348. have to do to in order to make the modem pick up the line.
  3349.  
  3350. On Wednesday, October 06, 1999 1:42 PM, Network Administrator
  3351. [SMTP:netadmin@seidata.com] wrote:
  3352. > I am using the v.34 analog/digital Quad cards (v.5.6.7) with the =
  3353. Netserver
  3354. > card. I had six existing cards using the same version of software. I
  3355. recently
  3356. > added 8 new lines to this box and two quad cards. The quads will not
  3357. answer
  3358. > incoming calls. I have checked each modem individually as well as =
  3359. tried
  3360. other
  3361. > cards and re-flashed the code to the cards. If anyone has any idea =
  3362. what
  3363. may
  3364. > be the problem, please reply.
  3365. > =A0
  3366. > =A0
  3367. > -Cheryl
  3368. > Seidata Network Services, Inc.
  3369. > <http://www.seidata.com>
  3370. > =A0
  3371.  
  3372.  
  3373.  
  3374. -
  3375.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3376.  with "unsubscribe usr-tc" in the body of the message.
  3377.  For information on digests or retrieving files and old messages send
  3378.  "help" to the same address.  Do not use quotes in your message.
  3379.  
  3380.  
  3381. -------------------------------------------------------------------------------
  3382.  
  3383. From: Steve McConnell <stevem@emji.net>
  3384. Subject: (usr-tc) pri dsp d-channel problem
  3385. Date: 06 Oct 1999 13:28:12 -0400
  3386.  
  3387. I have a new PRI (new DSP card for that matter) installed in an existing
  3388. chassis.
  3389.  
  3390. I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
  3391. getting no calls being terminated on my equipment.
  3392.  
  3393. When I pull up a com session into the DSP and do a display d-chan  , I get
  3394.  
  3395. span1> display d-chan
  3396.    Span1 D-channel Operational is:  DOWN
  3397.  
  3398. software:
  3399. Software Version   2.0.19
  3400. Regulatory Version 1.0
  3401.  
  3402. Other than this all looks fine, it is supposedly configed the same as an
  3403. existing circuit which is working fine.
  3404. My DSPs are configged the same way. Sprint has dispatched a tech and says
  3405. that all is fine as far as they can see.
  3406.  Is it possible that I have missed a setting somewhere that would cause
  3407. this same reaction?
  3408.  
  3409.  
  3410.  
  3411. steve
  3412.  
  3413.  
  3414. Steve McConnell                                  
  3415. EMJI 
  3416. 919-303-3217
  3417. 888-258-8959
  3418.  
  3419.  
  3420. -
  3421.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3422.  with "unsubscribe usr-tc" in the body of the message.
  3423.  For information on digests or retrieving files and old messages send
  3424.  "help" to the same address.  Do not use quotes in your message.
  3425.  
  3426.  
  3427. -------------------------------------------------------------------------------
  3428.  
  3429. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  3430. Subject: RE: (usr-tc) pri dsp d-channel problem
  3431. Date: 06 Oct 1999 14:35:12 -0300 
  3432.  
  3433.  
  3434. If I remember correctly, I saw the same thing when I had the primary switch
  3435. type set wrong on the card.  There are not many things to verify for a PRI
  3436. though - framing, coding, switch type, and NFAS settings if you use it.
  3437.  
  3438. On Wednesday, October 06, 1999 2:28 PM, Steve McConnell
  3439. [SMTP:stevem@emji.net] wrote:
  3440. > I have a new PRI (new DSP card for that matter) installed in an existing
  3441. > chassis.
  3442. > 
  3443. > I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
  3444. > getting no calls being terminated on my equipment.
  3445. > 
  3446. > When I pull up a com session into the DSP and do a display d-chan  , I get
  3447. > 
  3448. > span1> display d-chan
  3449. >    Span1 D-channel Operational is:  DOWN
  3450. > 
  3451. > software:
  3452. > Software Version   2.0.19
  3453. > Regulatory Version 1.0
  3454. > 
  3455. > Other than this all looks fine, it is supposedly configed the same as an
  3456. > existing circuit which is working fine.
  3457. > My DSPs are configged the same way. Sprint has dispatched a tech and says
  3458. > that all is fine as far as they can see.
  3459. >  Is it possible that I have missed a setting somewhere that would cause
  3460. > this same reaction?
  3461. > 
  3462. > 
  3463. > 
  3464. > steve
  3465. > 
  3466. > 
  3467. > Steve McConnell                                  
  3468. > EMJI 
  3469. > 919-303-3217
  3470. > 888-258-8959
  3471. > 
  3472. > 
  3473. > -
  3474. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3475. >  with "unsubscribe usr-tc" in the body of the message.
  3476. >  For information on digests or retrieving files and old messages send
  3477. >  "help" to the same address.  Do not use quotes in your message.
  3478.  
  3479.  
  3480.  
  3481. -
  3482.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3483.  with "unsubscribe usr-tc" in the body of the message.
  3484.  For information on digests or retrieving files and old messages send
  3485.  "help" to the same address.  Do not use quotes in your message.
  3486.  
  3487.  
  3488. -------------------------------------------------------------------------------
  3489.  
  3490. From: Steve McConnell <stevem@emji.net>
  3491. Subject: Re: (usr-tc) pri dsp d-channel problem
  3492. Date: 06 Oct 1999 13:50:35 -0400
  3493.  
  3494. Never mind.
  3495.  
  3496. Losers at sprint did not have the d-channel turned on. 
  3497.  
  3498. For a week, I have been calling them every single day, sometimes hourly,
  3499. checking on the ticket, asking to speak to provisioning (because I was
  3500. pretty sure this was the problem) telling them the D-channel was not turned
  3501. on.
  3502.  
  3503. So today I waste the entire day sitting here waiting for sprint to dispatch
  3504. a tech to come ourt and look (for the 4th time) at the circuit (never mind
  3505. that I freaking told them it was a d-channel/provisioning problem)
  3506.  
  3507. Unbelievable.
  3508.  
  3509. Thanks matthew for the fast response.
  3510.  
  3511. Works like a dream now...
  3512.  
  3513. steve
  3514.  
  3515. --On Wednesday, October 06, 1999, 1:28 PM -0400 Steve McConnell
  3516. <stevem@emji.net> wrote:
  3517.  
  3518. > I have a new PRI (new DSP card for that matter) installed in an existing
  3519. > chassis.
  3520. > 
  3521. > I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
  3522. > getting no calls being terminated on my equipment.
  3523. > 
  3524. > When I pull up a com session into the DSP and do a display d-chan  , I get
  3525. > 
  3526. > span1> display d-chan
  3527. >    Span1 D-channel Operational is:  DOWN
  3528. > 
  3529. > software:
  3530. > Software Version   2.0.19
  3531. > Regulatory Version 1.0
  3532. > 
  3533. > Other than this all looks fine, it is supposedly configed the same as an
  3534. > existing circuit which is working fine.
  3535. > My DSPs are configged the same way. Sprint has dispatched a tech and says
  3536. > that all is fine as far as they can see.
  3537. >  Is it possible that I have missed a setting somewhere that would cause
  3538. > this same reaction?
  3539. > 
  3540. > 
  3541. > 
  3542. > steve
  3543. > 
  3544. > 
  3545. > Steve McConnell                                  
  3546. > EMJI 
  3547. > 919-303-3217
  3548. > 888-258-8959
  3549. > 
  3550. > 
  3551. > -
  3552. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3553. >  with "unsubscribe usr-tc" in the body of the message.
  3554. >  For information on digests or retrieving files and old messages send
  3555. >  "help" to the same address.  Do not use quotes in your message.
  3556.  
  3557.  
  3558.  
  3559. Steve McConnell                                  
  3560. EMJI 
  3561. 919-303-3217
  3562. 888-258-8959
  3563.  
  3564.  
  3565. -
  3566.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3567.  with "unsubscribe usr-tc" in the body of the message.
  3568.  For information on digests or retrieving files and old messages send
  3569.  "help" to the same address.  Do not use quotes in your message.
  3570.  
  3571.  
  3572. -------------------------------------------------------------------------------
  3573.  
  3574. From: "Network Administrator" <netadmin@seidata.com>
  3575. Subject: Re: (usr-tc) Quad cards not answering analog calls
  3576. Date: 06 Oct 1999 15:03:06 -0500
  3577.  
  3578. Hey thanks. that did the trick.
  3579.  
  3580. ----- Original Message -----
  3581. Sent: Wednesday, October 06, 1999 10:45 AM
  3582.  
  3583.  
  3584. >
  3585. > I assume you are using POTS lines.  If you have the Line Interface Options
  3586. > for the modem set to nic rather than pritdm or t1tdm that should be all
  3587. you
  3588. > have to do to in order to make the modem pick up the line.
  3589. >
  3590. > On Wednesday, October 06, 1999 1:42 PM, Network Administrator
  3591. > [SMTP:netadmin@seidata.com] wrote:
  3592. > > I am using the v.34 analog/digital Quad cards (v.5.6.7) with the
  3593. Netserver
  3594. > > card. I had six existing cards using the same version of software. I
  3595. > recently
  3596. > > added 8 new lines to this box and two quad cards. The quads will not
  3597. > answer
  3598. > > incoming calls. I have checked each modem individually as well as tried
  3599. > other
  3600. > > cards and re-flashed the code to the cards. If anyone has any idea what
  3601. > may
  3602. > > be the problem, please reply.
  3603. > >
  3604. > >
  3605. > > -Cheryl
  3606. > > Seidata Network Services, Inc.
  3607. > > <http://www.seidata.com>
  3608. > >
  3609. >
  3610. >
  3611. >
  3612. > -
  3613. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3614. >  with "unsubscribe usr-tc" in the body of the message.
  3615. >  For information on digests or retrieving files and old messages send
  3616. >  "help" to the same address.  Do not use quotes in your message.
  3617. >
  3618.  
  3619.  
  3620. -
  3621.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3622.  with "unsubscribe usr-tc" in the body of the message.
  3623.  For information on digests or retrieving files and old messages send
  3624.  "help" to the same address.  Do not use quotes in your message.
  3625.  
  3626.  
  3627. -------------------------------------------------------------------------------
  3628.  
  3629. From: Dataheart <lists@dataheart.net>
  3630. Subject: Re: (usr-tc) pri dsp d-channel problem
  3631. Date: 07 Sep 1999 17:47:15 +1000
  3632.  
  3633. You know I had the exact same problem with my telco yesterday.
  3634.  
  3635. Thanks,
  3636. Aaron
  3637.  
  3638. Steve McConnell wrote:
  3639.  
  3640. > Never mind.
  3641. >
  3642. > Losers at sprint did not have the d-channel turned on.
  3643. >
  3644. > For a week, I have been calling them every single day, sometimes hourly,
  3645. > checking on the ticket, asking to speak to provisioning (because I was
  3646. > pretty sure this was the problem) telling them the D-channel was not turned
  3647. > on.
  3648. >
  3649. > So today I waste the entire day sitting here waiting for sprint to dispatch
  3650. > a tech to come ourt and look (for the 4th time) at the circuit (never mind
  3651. > that I freaking told them it was a d-channel/provisioning problem)
  3652. >
  3653. > Unbelievable.
  3654. >
  3655. > Thanks matthew for the fast response.
  3656. >
  3657. > Works like a dream now...
  3658. >
  3659. > steve
  3660. >
  3661. > --On Wednesday, October 06, 1999, 1:28 PM -0400 Steve McConnell
  3662. > <stevem@emji.net> wrote:
  3663. >
  3664. > > I have a new PRI (new DSP card for that matter) installed in an existing
  3665. > > chassis.
  3666. > >
  3667. > > I am getting a LPBK/D-Chan red alarm on the new span. So I am obviously
  3668. > > getting no calls being terminated on my equipment.
  3669. > >
  3670. > > When I pull up a com session into the DSP and do a display d-chan  , I get
  3671. > >
  3672. > > span1> display d-chan
  3673. > >    Span1 D-channel Operational is:  DOWN
  3674. > >
  3675. > > software:
  3676. > > Software Version   2.0.19
  3677. > > Regulatory Version 1.0
  3678. > >
  3679. > > Other than this all looks fine, it is supposedly configed the same as an
  3680. > > existing circuit which is working fine.
  3681. > > My DSPs are configged the same way. Sprint has dispatched a tech and says
  3682. > > that all is fine as far as they can see.
  3683. > >  Is it possible that I have missed a setting somewhere that would cause
  3684. > > this same reaction?
  3685. > >
  3686. > >
  3687. > >
  3688. > > steve
  3689. > >
  3690. > >
  3691. > > Steve McConnell
  3692. > > EMJI
  3693. > > 919-303-3217
  3694. > > 888-258-8959
  3695. > >
  3696. > >
  3697. > > -
  3698. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3699. > >  with "unsubscribe usr-tc" in the body of the message.
  3700. > >  For information on digests or retrieving files and old messages send
  3701. > >  "help" to the same address.  Do not use quotes in your message.
  3702. >
  3703. > Steve McConnell
  3704. > EMJI
  3705. > 919-303-3217
  3706. > 888-258-8959
  3707. >
  3708. > -
  3709. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3710. >  with "unsubscribe usr-tc" in the body of the message.
  3711. >  For information on digests or retrieving files and old messages send
  3712. >  "help" to the same address.  Do not use quotes in your message.
  3713.  
  3714.  
  3715. -
  3716.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3717.  with "unsubscribe usr-tc" in the body of the message.
  3718.  For information on digests or retrieving files and old messages send
  3719.  "help" to the same address.  Do not use quotes in your message.
  3720.  
  3721.  
  3722. -------------------------------------------------------------------------------
  3723.  
  3724. From: "Startup Suppliers Ltd." <startnet@arcc.or.ke>
  3725. Subject: Re: (usr-tc) Filter
  3726. Date: 07 Oct 1999 11:20:57 +0300 (EAT)
  3727.  
  3728. I am interested in this too, please forward response to me.
  3729.  
  3730. Okeyo
  3731.  
  3732.  
  3733. At 10:00 AM 10/6/99 -0400, you wrote:
  3734. >I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  3735. >to one specific site.
  3736. >
  3737. >We would like have filter so that any late payment people will still be able
  3738. >to login but they will be redirected to a website informing them that their
  3739. >bill is due.
  3740. >
  3741. >would also like the filter to not allow any traffic other than HTTP.
  3742. >
  3743. >any ideas?
  3744. >
  3745. >
  3746. >-
  3747. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3748. > with "unsubscribe usr-tc" in the body of the message.
  3749. > For information on digests or retrieving files and old messages send
  3750. > "help" to the same address.  Do not use quotes in your message.
  3751. >
  3752. >
  3753.  
  3754.  
  3755. -
  3756.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3757.  with "unsubscribe usr-tc" in the body of the message.
  3758.  For information on digests or retrieving files and old messages send
  3759.  "help" to the same address.  Do not use quotes in your message.
  3760.  
  3761.  
  3762. -------------------------------------------------------------------------------
  3763.  
  3764. From: Aaron Nabil <nabil@spiritone.com>
  3765. Subject: (usr-tc) USR vs Ascend (3com vs Lucent?) 
  3766. Date: 07 Oct 1999 04:46:38 -0700 (PDT)
  3767.  
  3768.  
  3769. One of my client ISP's has both USR hiperdsp's and Ascend
  3770. MAX's.  I've noticed that the Max's seem to perform better
  3771. (ratio of successful connects, number of dropped connections)
  3772. than the USR's, even when connecting to USR modems.
  3773.  
  3774. About 2am this morning I had a flash of insight and drove
  3775. into my office (I have a well-equipped home lab, but needed
  3776. access to a 4-wire interface.  Not much traffic at 2am, and
  3777. no trouble finding a parking space downtown.)  It was worth
  3778. the trip, I think I hit pay dirt.
  3779.  
  3780. What I tested was the level the server (ISP) modem was 
  3781. transmitting at.  I was surprised to see that is was at -10dbm,
  3782. which is quite hot.  Beacuse of the way digital lines are
  3783. coded, higher power levels have worse s/n ratios, there 
  3784. aren't at many quantitization bits available at higher powers.
  3785.  
  3786. I plugged in my laptop, fired up tcm, and looked at the hiperdsp
  3787. config.  It was set for -11dbm.  Hmmm.  I set it for -15, and yup,
  3788. I get -14 when I measure it.  An off by one error someplace, no
  3789. doubt.  But it gets better.
  3790.  
  3791. I call into our Max's and measured the level they were sending.  Only
  3792. -14dbm, much lower power, more what I was expecting.  Telnet in 
  3793. and check to see what they are set to, -13dbm, another off by one, but
  3794. this time in the opposite direction!
  3795.  
  3796. Here's a summary:
  3797.             Configured for        Actually sends
  3798. USR HiperDSP        -11dbm            -10dbm
  3799. Ascend Max        -13dbm            -14dbm
  3800.  
  3801. I don't have any scripts in place that monitor failure ratios, but
  3802. if someone does I'd be interested if they could set half their modems
  3803. to -15dbm (for an output of -14dbm) and see what effect that has.
  3804.  
  3805.  
  3806. -- 
  3807. Aaron Nabil
  3808.  
  3809. -
  3810.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3811.  with "unsubscribe usr-tc" in the body of the message.
  3812.  For information on digests or retrieving files and old messages send
  3813.  "help" to the same address.  Do not use quotes in your message.
  3814.  
  3815.  
  3816. -------------------------------------------------------------------------------
  3817.  
  3818. From: Aaron Nabil <nabil@spiritone.com>
  3819. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  3820. Date: 07 Oct 1999 05:41:10 -0700 (PDT)
  3821.  
  3822.  
  3823. Aaron Nabil writes...
  3824. >Here's a summary:
  3825. >            Configured for        Actually sends
  3826. >USR HiperDSP        -11dbm            -10dbm
  3827. >Ascend Max        -13dbm            -14dbm
  3828.  
  3829. One more entry for the above table:
  3830. USR HiperDSP        -15dbm            -14dbm
  3831.  
  3832. And some even more interesting results!
  3833.  
  3834. The above tests were made with 14.4k connections, I figured
  3835. that would be an old enough protocol not to have any power
  3836. negotiation sequences.  I retested with 33.6k, and here's
  3837. what I got.  Note that I'm listing the _median_ power,
  3838. occasionally it would pick a notch higher or lower.
  3839.  
  3840. 33.6k connections:
  3841.  
  3842.             Configured for        Median power
  3843. USR HiperDSP        -11dbm            -12dbm
  3844. USR HiperDSP        -15dbm            -16dbm
  3845. Ascend Max        -13dbm            -16dbm
  3846.  
  3847.     
  3848. This seems like even more evidence that setting the USR 
  3849. to -15dbm might be worth a try. 
  3850.  
  3851. I'll be looking at 56k next, but the results aren't as meaningful,
  3852. there isn't a direct correllation between power and s/n in v.90.
  3853.  
  3854.  
  3855. -- 
  3856. Aaron Nabil
  3857.  
  3858. -
  3859.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3860.  with "unsubscribe usr-tc" in the body of the message.
  3861.  For information on digests or retrieving files and old messages send
  3862.  "help" to the same address.  Do not use quotes in your message.
  3863.  
  3864.  
  3865. -------------------------------------------------------------------------------
  3866.  
  3867. From: Aaron Nabil <nabil@spiritone.com>
  3868. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  3869. Date: 07 Oct 1999 06:35:56 -0700 (PDT)
  3870.  
  3871.  
  3872. Considering the number of requests I've gotten in the last two hours,
  3873. I think the'll be plenty of guinia pigs, er, helpful 3com owners
  3874. testing the -15dbm setting for me.
  3875.  
  3876. Here's the instructions (at least this works on my TCS 3.6)
  3877. >
  3878. >>Where in TCM do you change these levels.  I will change them on a couple of
  3879. >>DSPs and see what happens.
  3880. >
  3881. >Select the modems.  Configure/Programmed settings.  Select the
  3882. >modems you want to change.  Under Line Interface Options,
  3883. >change Transmit Level.
  3884.  
  3885. -- 
  3886. Aaron Nabil
  3887.  
  3888. -
  3889.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3890.  with "unsubscribe usr-tc" in the body of the message.
  3891.  For information on digests or retrieving files and old messages send
  3892.  "help" to the same address.  Do not use quotes in your message.
  3893.  
  3894.  
  3895. -------------------------------------------------------------------------------
  3896.  
  3897. From: Aaron Nabil <nabil@spiritone.com>
  3898. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  3899. Date: 07 Oct 1999 06:39:37 -0700 (PDT)
  3900.  
  3901. Aaron Nabil writes...
  3902. > . . .
  3903. >            Configured for        Median power
  3904. >USR HiperDSP        -11dbm            -12dbm
  3905. >USR HiperDSP        -15dbm            -16dbm
  3906. >Ascend Max        -13dbm            -16dbm
  3907. >
  3908. >I'll be looking at 56k next, but the results aren't as meaningful,
  3909. >there isn't a direct correllation between power and s/n in v.90.
  3910.  
  3911. I tested V.90, it always gets about -16.5dbm independant of the
  3912. settings or box, which is both expected and reasonable.
  3913.  
  3914.  
  3915. -- 
  3916. Aaron Nabil
  3917.  
  3918. -
  3919.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3920.  with "unsubscribe usr-tc" in the body of the message.
  3921.  For information on digests or retrieving files and old messages send
  3922.  "help" to the same address.  Do not use quotes in your message.
  3923.  
  3924.  
  3925. -------------------------------------------------------------------------------
  3926.  
  3927. From: Brian <signal@shreve.net>
  3928. Subject: (usr-tc) NMC Command Reference
  3929. Date: 07 Oct 1999 09:57:03 -0500 (CDT)
  3930.  
  3931.  
  3932.  
  3933. I am trying to get a handle on the Command Reference to use with HiperNMC
  3934. 6.x.  I don't see a HiperNMC 6.x command reference on TotalService.  What
  3935. I do see is:
  3936.  
  3937. NMC version 5.0 parameter reference
  3938. HiPer NMC Parameter Reference Errata Sheet 
  3939. HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2 
  3940.  
  3941.  
  3942. That being said, are those the 3 files I should look at, or does a
  3943. "HiperNMC version 6.0 parameter reference" exist somewhere?  I am assuming
  3944. you just go about using the 5.0 parameter reference with a few changes
  3945. documented in the erattas...........
  3946.  
  3947. Brian
  3948.  
  3949. Brian Feeny (BF304)     signal@shreve.net   
  3950. 318-222-2638 x 109    http://www.shreve.net/~signal      
  3951. Network Administrator   ShreveNet Inc. (ASN 11881)           
  3952.  
  3953.  
  3954. -
  3955.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3956.  with "unsubscribe usr-tc" in the body of the message.
  3957.  For information on digests or retrieving files and old messages send
  3958.  "help" to the same address.  Do not use quotes in your message.
  3959.  
  3960.  
  3961. -------------------------------------------------------------------------------
  3962.  
  3963. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  3964. Subject: RE: (usr-tc) Filter
  3965. Date: 07 Oct 1999 10:09:02 -0500
  3966.  
  3967. The HiPer ARC filters are just that filters. There is no support for redirecting
  3968. traffic via filter. If your trying to do adult content filtering via something
  3969. like xSTOP or similar than you should be using the IEA feauture that allows you
  3970. to set a default route on a per user basis. The new default route would point to
  3971. your content filtering device..
  3972.  
  3973. -M
  3974.  
  3975.  
  3976. |-----Original Message-----
  3977. |From: owner-usr-tc@lists.xmission.com
  3978. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
  3979. |Ltd.
  3980. |Sent: Thursday, October 07, 1999 3:21 AM
  3981. |To: usr-tc@lists.xmission.com
  3982. |Subject: Re: (usr-tc) Filter
  3983. |
  3984. |
  3985. |I am interested in this too, please forward response to me.
  3986. |
  3987. |Okeyo
  3988. |
  3989. |
  3990. |At 10:00 AM 10/6/99 -0400, you wrote:
  3991. |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  3992. |>to one specific site.
  3993. |>
  3994. |>We would like have filter so that any late payment people will still be able
  3995. |>to login but they will be redirected to a website informing them that their
  3996. |>bill is due.
  3997. |>
  3998. |>would also like the filter to not allow any traffic other than HTTP.
  3999. |>
  4000. |>any ideas?
  4001. |>
  4002. |>
  4003. |>-
  4004. |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4005. |> with "unsubscribe usr-tc" in the body of the message.
  4006. |> For information on digests or retrieving files and old messages send
  4007. |> "help" to the same address.  Do not use quotes in your message.
  4008. |>
  4009. |>
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4022.  with "unsubscribe usr-tc" in the body of the message.
  4023.  For information on digests or retrieving files and old messages send
  4024.  "help" to the same address.  Do not use quotes in your message.
  4025.  
  4026.  
  4027. -------------------------------------------------------------------------------
  4028.  
  4029. From: Richard Lorbieski <richard@alpha1.net>
  4030. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  4031. Date: 07 Oct 1999 10:36:19 -0500
  4032.  
  4033. Where in the TCM do you set the dbm levels? I looked everwhere on the
  4034. DSP config settings.
  4035.  
  4036. Aaron Nabil wrote:
  4037. > 
  4038. > One of my client ISP's has both USR hiperdsp's and Ascend
  4039. > MAX's.  I've noticed that the Max's seem to perform better
  4040. > (ratio of successful connects, number of dropped connections)
  4041. > than the USR's, even when connecting to USR modems.
  4042. > 
  4043. > About 2am this morning I had a flash of insight and drove
  4044. > into my office (I have a well-equipped home lab, but needed
  4045. > access to a 4-wire interface.  Not much traffic at 2am, and
  4046. > no trouble finding a parking space downtown.)  It was worth
  4047. > the trip, I think I hit pay dirt.
  4048. > 
  4049. > What I tested was the level the server (ISP) modem was
  4050. > transmitting at.  I was surprised to see that is was at -10dbm,
  4051. > which is quite hot.  Beacuse of the way digital lines are
  4052. > coded, higher power levels have worse s/n ratios, there
  4053. > aren't at many quantitization bits available at higher powers.
  4054. > 
  4055. > I plugged in my laptop, fired up tcm, and looked at the hiperdsp
  4056. > config.  It was set for -11dbm.  Hmmm.  I set it for -15, and yup,
  4057. > I get -14 when I measure it.  An off by one error someplace, no
  4058. > doubt.  But it gets better.
  4059. > 
  4060. > I call into our Max's and measured the level they were sending.  Only
  4061. > -14dbm, much lower power, more what I was expecting.  Telnet in
  4062. > and check to see what they are set to, -13dbm, another off by one, but
  4063. > this time in the opposite direction!
  4064. > 
  4065. > Here's a summary:
  4066. >                         Configured for          Actually sends
  4067. > USR HiperDSP            -11dbm                  -10dbm
  4068. > Ascend Max              -13dbm                  -14dbm
  4069. > 
  4070. > I don't have any scripts in place that monitor failure ratios, but
  4071. > if someone does I'd be interested if they could set half their modems
  4072. > to -15dbm (for an output of -14dbm) and see what effect that has.
  4073. > 
  4074. > --
  4075. > Aaron Nabil
  4076. > 
  4077. > -
  4078. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4079. >  with "unsubscribe usr-tc" in the body of the message.
  4080. >  For information on digests or retrieving files and old messages send
  4081. >  "help" to the same address.  Do not use quotes in your message.
  4082.  
  4083. -- 
  4084.  
  4085. Richard Lorbieski - richard@alpha1.net
  4086. Chief Technical Officer - Senior System Administrator
  4087. Alpha1 Internet  http://www.alpha1.net
  4088. 409.731.8236  - 877.4.alpha1 (877.425.7421)
  4089.  
  4090. -
  4091.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4092.  with "unsubscribe usr-tc" in the body of the message.
  4093.  For information on digests or retrieving files and old messages send
  4094.  "help" to the same address.  Do not use quotes in your message.
  4095.  
  4096.  
  4097. -------------------------------------------------------------------------------
  4098.  
  4099. From: Brian <signal@shreve.net>
  4100. Subject: RE: (usr-tc) Filter
  4101. Date: 07 Oct 1999 10:44:41 -0500 (CDT)
  4102.  
  4103. On Thu, 7 Oct 1999, Mike Wronski wrote:
  4104.  
  4105. > The HiPer ARC filters are just that filters. There is no support for redirecting
  4106. > traffic via filter. If your trying to do adult content filtering via something
  4107. > like xSTOP or similar than you should be using the IEA feauture that allows you
  4108. > to set a default route on a per user basis. The new default route would point to
  4109. > your content filtering device..
  4110.  
  4111. Just a note here so that anyone trying this knows:  The content filter has
  4112. to be 1 hop away from the ARC.  You can't have an ARC in a remote POP, IEA
  4113. direct someone to a content filter back at your noc.  It would be very
  4114. cool however if this was implemented.
  4115.  
  4116. One way to accomplish this, that others have done.  Is to set the users IP
  4117. to a private network, like 192.168.1.x, then route that network to a box.
  4118. Put some ipchains rules in place so that the box accepts all port 80
  4119. destinations.......similar to what you would do for a squid box, something
  4120. like:
  4121.  
  4122. /sbin/ipchains -A input -j ACCEPT -i lo
  4123. /sbin/ipchains -A input -j ACCEPT -p tcp -d 208.206.76.44 80 
  4124. /sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
  4125.  
  4126. Then you run a webserver on this content box, and you setup apache to
  4127. listen on all destinations, even can use rewrite rules to rewrite their
  4128. urls if you want, and take them to your billing page.
  4129.  
  4130. Brian
  4131.  
  4132.  
  4133. > 
  4134. > -M
  4135. > 
  4136. > 
  4137. > |-----Original Message-----
  4138. > |From: owner-usr-tc@lists.xmission.com
  4139. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
  4140. > |Ltd.
  4141. > |Sent: Thursday, October 07, 1999 3:21 AM
  4142. > |To: usr-tc@lists.xmission.com
  4143. > |Subject: Re: (usr-tc) Filter
  4144. > |
  4145. > |
  4146. > |I am interested in this too, please forward response to me.
  4147. > |
  4148. > |Okeyo
  4149. > |
  4150. > |
  4151. > |At 10:00 AM 10/6/99 -0400, you wrote:
  4152. > |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4153. > |>to one specific site.
  4154. > |>
  4155. > |>We would like have filter so that any late payment people will still be able
  4156. > |>to login but they will be redirected to a website informing them that their
  4157. > |>bill is due.
  4158. > |>
  4159. > |>would also like the filter to not allow any traffic other than HTTP.
  4160. > |>
  4161. > |>any ideas?
  4162. > |>
  4163. > |>
  4164. > |>-
  4165. > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4166. > |> with "unsubscribe usr-tc" in the body of the message.
  4167. > |> For information on digests or retrieving files and old messages send
  4168. > |> "help" to the same address.  Do not use quotes in your message.
  4169. > |>
  4170. > |>
  4171. > |
  4172. > |
  4173. > |-
  4174. > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4175. > | with "unsubscribe usr-tc" in the body of the message.
  4176. > | For information on digests or retrieving files and old messages send
  4177. > | "help" to the same address.  Do not use quotes in your message.
  4178. > |
  4179. > 
  4180. > 
  4181. > -
  4182. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4183. >  with "unsubscribe usr-tc" in the body of the message.
  4184. >  For information on digests or retrieving files and old messages send
  4185. >  "help" to the same address.  Do not use quotes in your message.
  4186. > 
  4187.  
  4188. Brian Feeny (BF304)     signal@shreve.net   
  4189. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4190. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4191.  
  4192.  
  4193. -
  4194.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4195.  with "unsubscribe usr-tc" in the body of the message.
  4196.  For information on digests or retrieving files and old messages send
  4197.  "help" to the same address.  Do not use quotes in your message.
  4198.  
  4199.  
  4200. -------------------------------------------------------------------------------
  4201.  
  4202. From: Dataheart <lists@dataheart.net>
  4203. Subject: Re: (usr-tc) Filter
  4204. Date: 08 Sep 1999 01:48:51 +1000
  4205.  
  4206. One thing you could do would be to write a script that changes that particular
  4207. users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  4208. and using the route-map feature in your cisco(if you have a cisco) for forward
  4209. all traffic on that 192.168 network to A web site say
  4210. http://outoftime.yourdomain.com/ and with that same access list you could deny
  4211. all other traffic.
  4212.  
  4213. NOTE: I have never implemented this, but I like the idea of informing the user
  4214. that they are out of time so I will do it within the coming weeks.
  4215.  
  4216. Thanks,
  4217. Aaron
  4218.  
  4219. Jamie Orzechowski wrote:
  4220.  
  4221. > I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4222. > to one specific site.
  4223. >
  4224. > We would like have filter so that any late payment people will still be able
  4225. > to login but they will be redirected to a website informing them that their
  4226. > bill is due.
  4227. >
  4228. > would also like the filter to not allow any traffic other than HTTP.
  4229. >
  4230. > any ideas?
  4231. >
  4232. > -
  4233. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4234. >  with "unsubscribe usr-tc" in the body of the message.
  4235. >  For information on digests or retrieving files and old messages send
  4236. >  "help" to the same address.  Do not use quotes in your message.
  4237.  
  4238.  
  4239. -
  4240.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4241.  with "unsubscribe usr-tc" in the body of the message.
  4242.  For information on digests or retrieving files and old messages send
  4243.  "help" to the same address.  Do not use quotes in your message.
  4244.  
  4245.  
  4246. -------------------------------------------------------------------------------
  4247.  
  4248. From: Dataheart <lists@dataheart.net>
  4249. Subject: Re: (usr-tc) Filter
  4250. Date: 08 Oct 1999 02:20:06 +1000
  4251.  
  4252. I got my date right now.
  4253.  
  4254. Even easier if you have a cisco router.
  4255. 123.123.123.123 is the ip of the virtual web site where your out of time message is.
  4256.  
  4257. write a script to on out of time set FRAMED-IP-ADDRESS to a 192.168 addresss and put
  4258. this in your cisco.
  4259.  
  4260.         route-map outoftime-redirect permit 10
  4261.          match ip address 110
  4262.          set ip next-hop 123.123.123.123
  4263.         !
  4264.         !
  4265.         access-list 110 deny tcp 192.168.0.0 255.255.0.0 eq www any
  4266.         access-list 110 deny tcp any any
  4267.         !
  4268.         !
  4269.         interface Ethernet0
  4270.          ip policy route-map outoftime-redirect
  4271.         !
  4272.  
  4273. This should work.
  4274.  
  4275. Thanks,
  4276. Aaron
  4277.  
  4278.  
  4279. Brian wrote:
  4280.  
  4281. > On Thu, 7 Oct 1999, Mike Wronski wrote:
  4282. >
  4283. > > The HiPer ARC filters are just that filters. There is no support for redirecting
  4284. > > traffic via filter. If your trying to do adult content filtering via something
  4285. > > like xSTOP or similar than you should be using the IEA feauture that allows you
  4286. > > to set a default route on a per user basis. The new default route would point to
  4287. > > your content filtering device..
  4288. >
  4289. > Just a note here so that anyone trying this knows:  The content filter has
  4290. > to be 1 hop away from the ARC.  You can't have an ARC in a remote POP, IEA
  4291. > direct someone to a content filter back at your noc.  It would be very
  4292. > cool however if this was implemented.
  4293. >
  4294. > One way to accomplish this, that others have done.  Is to set the users IP
  4295. > to a private network, like 192.168.1.x, then route that network to a box.
  4296. > Put some ipchains rules in place so that the box accepts all port 80
  4297. > destinations.......similar to what you would do for a squid box, something
  4298. > like:
  4299. >
  4300. > /sbin/ipchains -A input -j ACCEPT -i lo
  4301. > /sbin/ipchains -A input -j ACCEPT -p tcp -d 208.206.76.44 80
  4302. > /sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
  4303. >
  4304. > Then you run a webserver on this content box, and you setup apache to
  4305. > listen on all destinations, even can use rewrite rules to rewrite their
  4306. > urls if you want, and take them to your billing page.
  4307. >
  4308. > Brian
  4309. >
  4310. > >
  4311. > > -M
  4312. > >
  4313. > >
  4314. > > |-----Original Message-----
  4315. > > |From: owner-usr-tc@lists.xmission.com
  4316. > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
  4317. > > |Ltd.
  4318. > > |Sent: Thursday, October 07, 1999 3:21 AM
  4319. > > |To: usr-tc@lists.xmission.com
  4320. > > |Subject: Re: (usr-tc) Filter
  4321. > > |
  4322. > > |
  4323. > > |I am interested in this too, please forward response to me.
  4324. > > |
  4325. > > |Okeyo
  4326. > > |
  4327. > > |
  4328. > > |At 10:00 AM 10/6/99 -0400, you wrote:
  4329. > > |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4330. > > |>to one specific site.
  4331. > > |>
  4332. > > |>We would like have filter so that any late payment people will still be able
  4333. > > |>to login but they will be redirected to a website informing them that their
  4334. > > |>bill is due.
  4335. > > |>
  4336. > > |>would also like the filter to not allow any traffic other than HTTP.
  4337. > > |>
  4338. > > |>any ideas?
  4339. > > |>
  4340. > > |>
  4341. > > |>-
  4342. > > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4343. > > |> with "unsubscribe usr-tc" in the body of the message.
  4344. > > |> For information on digests or retrieving files and old messages send
  4345. > > |> "help" to the same address.  Do not use quotes in your message.
  4346. > > |>
  4347. > > |>
  4348. > > |
  4349. > > |
  4350. > > |-
  4351. > > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4352. > > | with "unsubscribe usr-tc" in the body of the message.
  4353. > > | For information on digests or retrieving files and old messages send
  4354. > > | "help" to the same address.  Do not use quotes in your message.
  4355. > > |
  4356. > >
  4357. > >
  4358. > > -
  4359. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4360. > >  with "unsubscribe usr-tc" in the body of the message.
  4361. > >  For information on digests or retrieving files and old messages send
  4362. > >  "help" to the same address.  Do not use quotes in your message.
  4363. > >
  4364. >
  4365. > -----------------------------------------------------
  4366. > Brian Feeny (BF304)     signal@shreve.net
  4367. > 318-222-2638 x 109      http://www.shreve.net/~signal
  4368. > Network Administrator   ShreveNet Inc. (ASN 11881)
  4369. >
  4370. > -
  4371. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4372. >  with "unsubscribe usr-tc" in the body of the message.
  4373. >  For information on digests or retrieving files and old messages send
  4374. >  "help" to the same address.  Do not use quotes in your message.
  4375.  
  4376.  
  4377. -
  4378.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4379.  with "unsubscribe usr-tc" in the body of the message.
  4380.  For information on digests or retrieving files and old messages send
  4381.  "help" to the same address.  Do not use quotes in your message.
  4382.  
  4383.  
  4384. -------------------------------------------------------------------------------
  4385.  
  4386. From: eric@dol.net
  4387. Subject: Re: (usr-tc) Filter
  4388. Date: 07 Oct 1999 10:33:39 -0600
  4389.  
  4390. This assumes the customer uses a web browser. What happens in this case then the 
  4391. customer only uses email?
  4392.  
  4393.  
  4394.  
  4395. At 01:48 AM 9/8/99 +1000, you wrote:
  4396. >One thing you could do would be to write a script that changes that particular
  4397. >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  4398. >and using the route-map feature in your cisco(if you have a cisco) for forward
  4399. >all traffic on that 192.168 network to A web site say
  4400. >http://outoftime.yourdomain.com/ and with that same access list you could deny
  4401. >all other traffic.
  4402. >
  4403. >NOTE: I have never implemented this, but I like the idea of informing the user
  4404. >that they are out of time so I will do it within the coming weeks.
  4405. >
  4406. >Thanks,
  4407. >Aaron
  4408. >
  4409. >Jamie Orzechowski wrote:
  4410. >
  4411. >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4412. >> to one specific site.
  4413. >>
  4414. >> We would like have filter so that any late payment people will still be able
  4415. >> to login but they will be redirected to a website informing them that their
  4416. >> bill is due.
  4417. >>
  4418. >> would also like the filter to not allow any traffic other than HTTP.
  4419. >>
  4420. >> any ideas?
  4421. >>
  4422. >> -
  4423. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4424. >>  with "unsubscribe usr-tc" in the body of the message.
  4425. >>  For information on digests or retrieving files and old messages send
  4426. >>  "help" to the same address.  Do not use quotes in your message.
  4427. >
  4428. >
  4429. >-
  4430. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4431. > with "unsubscribe usr-tc" in the body of the message.
  4432. > For information on digests or retrieving files and old messages send
  4433. > "help" to the same address.  Do not use quotes in your message.
  4434. >Delaware Online!.........The SMART Choice!  
  4435. With 56K V.90 & X2 & Flex Modems 
  4436. Phone : 302-762-0375                
  4437. Fax:     302-762-3462        
  4438. Failure is NOT an option...
  4439.  
  4440.  
  4441.  
  4442. -
  4443.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4444.  with "unsubscribe usr-tc" in the body of the message.
  4445.  For information on digests or retrieving files and old messages send
  4446.  "help" to the same address.  Do not use quotes in your message.
  4447.  
  4448.  
  4449. -------------------------------------------------------------------------------
  4450.  
  4451. From: Brian <signal@shreve.net>
  4452. Subject: Re: (usr-tc) Filter
  4453. Date: 07 Oct 1999 11:38:01 -0500 (CDT)
  4454.  
  4455.  
  4456.  
  4457. You would still need the ip chains rules I would think however, since the
  4458. TCPIP header of the packet is still going to have a different destination
  4459. IP in it than 123.123.123.123.  The ipchains rules would intercept all
  4460. destinations.
  4461.  
  4462.  
  4463. On Fri, 8 Oct 1999, Dataheart wrote:
  4464.  
  4465. > I got my date right now.
  4466. > 
  4467. > Even easier if you have a cisco router.
  4468. > 123.123.123.123 is the ip of the virtual web site where your out of time message is.
  4469. > 
  4470. > write a script to on out of time set FRAMED-IP-ADDRESS to a 192.168 addresss and put
  4471. > this in your cisco.
  4472. > 
  4473. >         route-map outoftime-redirect permit 10
  4474. >          match ip address 110
  4475. >          set ip next-hop 123.123.123.123
  4476. >         !
  4477. >         !
  4478. >         access-list 110 deny tcp 192.168.0.0 255.255.0.0 eq www any
  4479. >         access-list 110 deny tcp any any
  4480. >         !
  4481. >         !
  4482. >         interface Ethernet0
  4483. >          ip policy route-map outoftime-redirect
  4484. >         !
  4485. > 
  4486. > This should work.
  4487. > 
  4488. > Thanks,
  4489. > Aaron
  4490. > 
  4491. > 
  4492. > Brian wrote:
  4493. > 
  4494. > > On Thu, 7 Oct 1999, Mike Wronski wrote:
  4495. > >
  4496. > > > The HiPer ARC filters are just that filters. There is no support for redirecting
  4497. > > > traffic via filter. If your trying to do adult content filtering via something
  4498. > > > like xSTOP or similar than you should be using the IEA feauture that allows you
  4499. > > > to set a default route on a per user basis. The new default route would point to
  4500. > > > your content filtering device..
  4501. > >
  4502. > > Just a note here so that anyone trying this knows:  The content filter has
  4503. > > to be 1 hop away from the ARC.  You can't have an ARC in a remote POP, IEA
  4504. > > direct someone to a content filter back at your noc.  It would be very
  4505. > > cool however if this was implemented.
  4506. > >
  4507. > > One way to accomplish this, that others have done.  Is to set the users IP
  4508. > > to a private network, like 192.168.1.x, then route that network to a box.
  4509. > > Put some ipchains rules in place so that the box accepts all port 80
  4510. > > destinations.......similar to what you would do for a squid box, something
  4511. > > like:
  4512. > >
  4513. > > /sbin/ipchains -A input -j ACCEPT -i lo
  4514. > > /sbin/ipchains -A input -j ACCEPT -p tcp -d 208.206.76.44 80
  4515. > > /sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
  4516. > >
  4517. > > Then you run a webserver on this content box, and you setup apache to
  4518. > > listen on all destinations, even can use rewrite rules to rewrite their
  4519. > > urls if you want, and take them to your billing page.
  4520. > >
  4521. > > Brian
  4522. > >
  4523. > > >
  4524. > > > -M
  4525. > > >
  4526. > > >
  4527. > > > |-----Original Message-----
  4528. > > > |From: owner-usr-tc@lists.xmission.com
  4529. > > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Startup Suppliers
  4530. > > > |Ltd.
  4531. > > > |Sent: Thursday, October 07, 1999 3:21 AM
  4532. > > > |To: usr-tc@lists.xmission.com
  4533. > > > |Subject: Re: (usr-tc) Filter
  4534. > > > |
  4535. > > > |
  4536. > > > |I am interested in this too, please forward response to me.
  4537. > > > |
  4538. > > > |Okeyo
  4539. > > > |
  4540. > > > |
  4541. > > > |At 10:00 AM 10/6/99 -0400, you wrote:
  4542. > > > |>I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4543. > > > |>to one specific site.
  4544. > > > |>
  4545. > > > |>We would like have filter so that any late payment people will still be able
  4546. > > > |>to login but they will be redirected to a website informing them that their
  4547. > > > |>bill is due.
  4548. > > > |>
  4549. > > > |>would also like the filter to not allow any traffic other than HTTP.
  4550. > > > |>
  4551. > > > |>any ideas?
  4552. > > > |>
  4553. > > > |>
  4554. > > > |>-
  4555. > > > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4556. > > > |> with "unsubscribe usr-tc" in the body of the message.
  4557. > > > |> For information on digests or retrieving files and old messages send
  4558. > > > |> "help" to the same address.  Do not use quotes in your message.
  4559. > > > |>
  4560. > > > |>
  4561. > > > |
  4562. > > > |
  4563. > > > |-
  4564. > > > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4565. > > > | with "unsubscribe usr-tc" in the body of the message.
  4566. > > > | For information on digests or retrieving files and old messages send
  4567. > > > | "help" to the same address.  Do not use quotes in your message.
  4568. > > > |
  4569. > > >
  4570. > > >
  4571. > > > -
  4572. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4573. > > >  with "unsubscribe usr-tc" in the body of the message.
  4574. > > >  For information on digests or retrieving files and old messages send
  4575. > > >  "help" to the same address.  Do not use quotes in your message.
  4576. > > >
  4577. > >
  4578. > > -----------------------------------------------------
  4579. > > Brian Feeny (BF304)     signal@shreve.net
  4580. > > 318-222-2638 x 109      http://www.shreve.net/~signal
  4581. > > Network Administrator   ShreveNet Inc. (ASN 11881)
  4582. > >
  4583. > > -
  4584. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4585. > >  with "unsubscribe usr-tc" in the body of the message.
  4586. > >  For information on digests or retrieving files and old messages send
  4587. > >  "help" to the same address.  Do not use quotes in your message.
  4588. > 
  4589. > 
  4590. > -
  4591. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4592. >  with "unsubscribe usr-tc" in the body of the message.
  4593. >  For information on digests or retrieving files and old messages send
  4594. >  "help" to the same address.  Do not use quotes in your message.
  4595. > 
  4596.  
  4597. Brian Feeny (BF304)     signal@shreve.net   
  4598. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4599. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4600.  
  4601.  
  4602. -
  4603.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4604.  with "unsubscribe usr-tc" in the body of the message.
  4605.  For information on digests or retrieving files and old messages send
  4606.  "help" to the same address.  Do not use quotes in your message.
  4607.  
  4608.  
  4609. -------------------------------------------------------------------------------
  4610.  
  4611. From: Brian <signal@shreve.net>
  4612. Subject: Re: (usr-tc) Filter
  4613. Date: 07 Oct 1999 11:38:54 -0500 (CDT)
  4614.  
  4615. On Thu, 7 Oct 1999 eric@dol.net wrote:
  4616.  
  4617. > This assumes the customer uses a web browser. What happens in this case then the 
  4618. > customer only uses email?
  4619.  
  4620. well everything else would/could be blocked except web.  
  4621.  
  4622. > 
  4623. > 
  4624. > 
  4625. > At 01:48 AM 9/8/99 +1000, you wrote:
  4626. > >One thing you could do would be to write a script that changes that particular
  4627. > >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  4628. > >and using the route-map feature in your cisco(if you have a cisco) for forward
  4629. > >all traffic on that 192.168 network to A web site say
  4630. > >http://outoftime.yourdomain.com/ and with that same access list you could deny
  4631. > >all other traffic.
  4632. > >
  4633. > >NOTE: I have never implemented this, but I like the idea of informing the user
  4634. > >that they are out of time so I will do it within the coming weeks.
  4635. > >
  4636. > >Thanks,
  4637. > >Aaron
  4638. > >
  4639. > >Jamie Orzechowski wrote:
  4640. > >
  4641. > >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4642. > >> to one specific site.
  4643. > >>
  4644. > >> We would like have filter so that any late payment people will still be able
  4645. > >> to login but they will be redirected to a website informing them that their
  4646. > >> bill is due.
  4647. > >>
  4648. > >> would also like the filter to not allow any traffic other than HTTP.
  4649. > >>
  4650. > >> any ideas?
  4651. > >>
  4652. > >> -
  4653. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4654. > >>  with "unsubscribe usr-tc" in the body of the message.
  4655. > >>  For information on digests or retrieving files and old messages send
  4656. > >>  "help" to the same address.  Do not use quotes in your message.
  4657. > >
  4658. > >
  4659. > >-
  4660. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4661. > > with "unsubscribe usr-tc" in the body of the message.
  4662. > > For information on digests or retrieving files and old messages send
  4663. > > "help" to the same address.  Do not use quotes in your message.
  4664. > >Delaware Online!.........The SMART Choice!  
  4665. > With 56K V.90 & X2 & Flex Modems 
  4666. > Phone : 302-762-0375                
  4667. > Fax:     302-762-3462        
  4668. > Failure is NOT an option...
  4669. > 
  4670. > 
  4671. > 
  4672. > -
  4673. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4674. >  with "unsubscribe usr-tc" in the body of the message.
  4675. >  For information on digests or retrieving files and old messages send
  4676. >  "help" to the same address.  Do not use quotes in your message.
  4677. > 
  4678.  
  4679. Brian Feeny (BF304)     signal@shreve.net   
  4680. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4681. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4682.  
  4683.  
  4684. -
  4685.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4686.  with "unsubscribe usr-tc" in the body of the message.
  4687.  For information on digests or retrieving files and old messages send
  4688.  "help" to the same address.  Do not use quotes in your message.
  4689.  
  4690.  
  4691. -------------------------------------------------------------------------------
  4692.  
  4693. From: Dataheart <lists@dataheart.net>
  4694. Subject: Re: (usr-tc) Filter
  4695. Date: 08 Oct 1999 02:42:35 +1000
  4696.  
  4697. A valid point.
  4698.  
  4699. in the script I suggested to change the FRAMED-IP-ADDRESS radius attribute simply
  4700. add a sendmail routein to send them an E-mail.
  4701.  
  4702. or if you use NT this should be able to be done with the CDONTS vbscript feature.
  4703.  
  4704. Thanks,
  4705. Aaron
  4706.  
  4707. eric@dol.net wrote:
  4708.  
  4709. > This assumes the customer uses a web browser. What happens in this case then the
  4710. > customer only uses email?
  4711. >
  4712. > At 01:48 AM 9/8/99 +1000, you wrote:
  4713. > >One thing you could do would be to write a script that changes that particular
  4714. > >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  4715. > >and using the route-map feature in your cisco(if you have a cisco) for forward
  4716. > >all traffic on that 192.168 network to A web site say
  4717. > >http://outoftime.yourdomain.com/ and with that same access list you could deny
  4718. > >all other traffic.
  4719. > >
  4720. > >NOTE: I have never implemented this, but I like the idea of informing the user
  4721. > >that they are out of time so I will do it within the coming weeks.
  4722. > >
  4723. > >Thanks,
  4724. > >Aaron
  4725. > >
  4726. > >Jamie Orzechowski wrote:
  4727. > >
  4728. > >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4729. > >> to one specific site.
  4730. > >>
  4731. > >> We would like have filter so that any late payment people will still be able
  4732. > >> to login but they will be redirected to a website informing them that their
  4733. > >> bill is due.
  4734. > >>
  4735. > >> would also like the filter to not allow any traffic other than HTTP.
  4736. > >>
  4737. > >> any ideas?
  4738. > >>
  4739. > >> -
  4740. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4741. > >>  with "unsubscribe usr-tc" in the body of the message.
  4742. > >>  For information on digests or retrieving files and old messages send
  4743. > >>  "help" to the same address.  Do not use quotes in your message.
  4744. > >
  4745. > >
  4746. > >-
  4747. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4748. > > with "unsubscribe usr-tc" in the body of the message.
  4749. > > For information on digests or retrieving files and old messages send
  4750. > > "help" to the same address.  Do not use quotes in your message.
  4751. > >Delaware Online!.........The SMART Choice!
  4752. > With 56K V.90 & X2 & Flex Modems
  4753. > Phone : 302-762-0375
  4754. > Fax:    302-762-3462
  4755. > Failure is NOT an option...
  4756. >
  4757. > -
  4758. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4759. >  with "unsubscribe usr-tc" in the body of the message.
  4760. >  For information on digests or retrieving files and old messages send
  4761. >  "help" to the same address.  Do not use quotes in your message.
  4762.  
  4763.  
  4764. -
  4765.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4766.  with "unsubscribe usr-tc" in the body of the message.
  4767.  For information on digests or retrieving files and old messages send
  4768.  "help" to the same address.  Do not use quotes in your message.
  4769.  
  4770.  
  4771. -------------------------------------------------------------------------------
  4772.  
  4773. From: Kevin Benton <s1kevin@tims.net>
  4774. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  4775. Date: 07 Oct 1999 13:39:07 -0400 (EDT)
  4776.  
  4777. On Thu, 7 Oct 1999, Richard Lorbieski wrote:
  4778.  
  4779. > Where in the TCM do you set the dbm levels? I looked everwhere on the
  4780. > DSP config settings.
  4781.  
  4782. Same place as on the quads - at the modem level.  Click on the modem
  4783. status lights, configure, programmed settings, and poke around.  Most
  4784. people don't even know you can change settings for the modems on a DSP
  4785. card...
  4786.  
  4787. Kevin
  4788.  
  4789. > Aaron Nabil wrote:
  4790. > > 
  4791. > > One of my client ISP's has both USR hiperdsp's and Ascend
  4792. > > MAX's.  I've noticed that the Max's seem to perform better
  4793. > > (ratio of successful connects, number of dropped connections)
  4794. > > than the USR's, even when connecting to USR modems.
  4795. > > 
  4796. > > About 2am this morning I had a flash of insight and drove
  4797. > > into my office (I have a well-equipped home lab, but needed
  4798. > > access to a 4-wire interface.  Not much traffic at 2am, and
  4799. > > no trouble finding a parking space downtown.)  It was worth
  4800. > > the trip, I think I hit pay dirt.
  4801. > > 
  4802. > > What I tested was the level the server (ISP) modem was
  4803. > > transmitting at.  I was surprised to see that is was at -10dbm,
  4804. > > which is quite hot.  Beacuse of the way digital lines are
  4805. > > coded, higher power levels have worse s/n ratios, there
  4806. > > aren't at many quantitization bits available at higher powers.
  4807. > > 
  4808. > > I plugged in my laptop, fired up tcm, and looked at the hiperdsp
  4809. > > config.  It was set for -11dbm.  Hmmm.  I set it for -15, and yup,
  4810. > > I get -14 when I measure it.  An off by one error someplace, no
  4811. > > doubt.  But it gets better.
  4812. > > 
  4813. > > I call into our Max's and measured the level they were sending.  Only
  4814. > > -14dbm, much lower power, more what I was expecting.  Telnet in
  4815. > > and check to see what they are set to, -13dbm, another off by one, but
  4816. > > this time in the opposite direction!
  4817. > > 
  4818. > > Here's a summary:
  4819. > >                         Configured for          Actually sends
  4820. > > USR HiperDSP            -11dbm                  -10dbm
  4821. > > Ascend Max              -13dbm                  -14dbm
  4822. > > 
  4823. > > I don't have any scripts in place that monitor failure ratios, but
  4824. > > if someone does I'd be interested if they could set half their modems
  4825. > > to -15dbm (for an output of -14dbm) and see what effect that has.
  4826. > > 
  4827. > > --
  4828. > > Aaron Nabil
  4829. > > 
  4830. > > -
  4831. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4832. > >  with "unsubscribe usr-tc" in the body of the message.
  4833. > >  For information on digests or retrieving files and old messages send
  4834. > >  "help" to the same address.  Do not use quotes in your message.
  4835. > 
  4836. > -- 
  4837. > 
  4838. > Richard Lorbieski - richard@alpha1.net
  4839. > Chief Technical Officer - Senior System Administrator
  4840. > Alpha1 Internet  http://www.alpha1.net
  4841. > 409.731.8236  - 877.4.alpha1 (877.425.7421)
  4842. > 
  4843. > -
  4844. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4845. >  with "unsubscribe usr-tc" in the body of the message.
  4846. >  For information on digests or retrieving files and old messages send
  4847. >  "help" to the same address.  Do not use quotes in your message.
  4848. > 
  4849.  
  4850. E-Mail:  s1kevin@tims.net
  4851. Web:     http://users.sota-oh.com/~s1kevin/
  4852. Unsolicited advertisements processing fee: $50 subject to change without notice
  4853.  
  4854.  
  4855. -
  4856.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4857.  with "unsubscribe usr-tc" in the body of the message.
  4858.  For information on digests or retrieving files and old messages send
  4859.  "help" to the same address.  Do not use quotes in your message.
  4860.  
  4861.  
  4862. -------------------------------------------------------------------------------
  4863.  
  4864. From: Charles Sprickman <spork@inch.com>
  4865. Subject: Re: (usr-tc) Filter
  4866. Date: 07 Oct 1999 13:43:29 -0400 (EDT)
  4867.  
  4868. Do the same as with the web server, but run a dummy popper that always
  4869. responds with "-ERR Pay your bill, fool!".  See
  4870. http://www.tdx.co.uk/software/ for an example dummy popper.  A bit of
  4871. hacking and you're on your way...
  4872.  
  4873. Charles
  4874.  
  4875. On Thu, 7 Oct 1999 eric@dol.net wrote:
  4876.  
  4877. > This assumes the customer uses a web browser. What happens in this case then the 
  4878. > customer only uses email?
  4879. > 
  4880. > 
  4881. > 
  4882. > At 01:48 AM 9/8/99 +1000, you wrote:
  4883. > >One thing you could do would be to write a script that changes that particular
  4884. > >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  4885. > >and using the route-map feature in your cisco(if you have a cisco) for forward
  4886. > >all traffic on that 192.168 network to A web site say
  4887. > >http://outoftime.yourdomain.com/ and with that same access list you could deny
  4888. > >all other traffic.
  4889. > >
  4890. > >NOTE: I have never implemented this, but I like the idea of informing the user
  4891. > >that they are out of time so I will do it within the coming weeks.
  4892. > >
  4893. > >Thanks,
  4894. > >Aaron
  4895. > >
  4896. > >Jamie Orzechowski wrote:
  4897. > >
  4898. > >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  4899. > >> to one specific site.
  4900. > >>
  4901. > >> We would like have filter so that any late payment people will still be able
  4902. > >> to login but they will be redirected to a website informing them that their
  4903. > >> bill is due.
  4904. > >>
  4905. > >> would also like the filter to not allow any traffic other than HTTP.
  4906. > >>
  4907. > >> any ideas?
  4908. > >>
  4909. > >> -
  4910. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4911. > >>  with "unsubscribe usr-tc" in the body of the message.
  4912. > >>  For information on digests or retrieving files and old messages send
  4913. > >>  "help" to the same address.  Do not use quotes in your message.
  4914. > >
  4915. > >
  4916. > >-
  4917. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4918. > > with "unsubscribe usr-tc" in the body of the message.
  4919. > > For information on digests or retrieving files and old messages send
  4920. > > "help" to the same address.  Do not use quotes in your message.
  4921. > >Delaware Online!.........The SMART Choice!  
  4922. > With 56K V.90 & X2 & Flex Modems 
  4923. > Phone : 302-762-0375                
  4924. > Fax:     302-762-3462        
  4925. > Failure is NOT an option...
  4926. > 
  4927. > 
  4928. > 
  4929. > -
  4930. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4931. >  with "unsubscribe usr-tc" in the body of the message.
  4932. >  For information on digests or retrieving files and old messages send
  4933. >  "help" to the same address.  Do not use quotes in your message.
  4934. > 
  4935.  
  4936.  
  4937. -
  4938.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4939.  with "unsubscribe usr-tc" in the body of the message.
  4940.  For information on digests or retrieving files and old messages send
  4941.  "help" to the same address.  Do not use quotes in your message.
  4942.  
  4943.  
  4944. -------------------------------------------------------------------------------
  4945.  
  4946. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  4947. Subject: Re: (usr-tc) NMC Command Reference
  4948. Date: 07 Oct 1999 13:15:53 -0500
  4949.  
  4950.  
  4951.  
  4952. If you search on "hiper" and "management" you'll get hits on the HiperNMC
  4953. Parameter reference,  HiperNMC Getting Started Guide,  HiperNMC Product
  4954. Reference and a couple others.
  4955.  
  4956.  
  4957.  
  4958.  
  4959. Brian <signal@shreve.net> on 10/07/99 09:57:03 AM
  4960.  
  4961. Please respond to usr-tc@lists.xmission.com
  4962.  
  4963. Sent by:  Brian <signal@shreve.net>
  4964.  
  4965.  
  4966. cc:    (Steve Valiunas/MW/US/3Com)
  4967.  
  4968.  
  4969.  
  4970.  
  4971.  
  4972.  
  4973. I am trying to get a handle on the Command Reference to use with HiperNMC
  4974. 6.x.  I don't see a HiperNMC 6.x command reference on TotalService.  What
  4975. I do see is:
  4976.  
  4977. NMC version 5.0 parameter reference
  4978. HiPer NMC Parameter Reference Errata Sheet
  4979. HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
  4980.  
  4981.  
  4982. That being said, are those the 3 files I should look at, or does a
  4983. "HiperNMC version 6.0 parameter reference" exist somewhere?  I am assuming
  4984. you just go about using the 5.0 parameter reference with a few changes
  4985. documented in the erattas...........
  4986.  
  4987. Brian
  4988.  
  4989. Brian Feeny (BF304)     signal@shreve.net
  4990. 318-222-2638 x 109  http://www.shreve.net/~signal
  4991. Network Administrator   ShreveNet Inc. (ASN 11881)
  4992.  
  4993.  
  4994. -
  4995.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4996.  with "unsubscribe usr-tc" in the body of the message.
  4997.  For information on digests or retrieving files and old messages send
  4998.  "help" to the same address.  Do not use quotes in your message.
  4999.  
  5000.  
  5001.  
  5002.  
  5003.  
  5004.  
  5005. -
  5006.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5007.  with "unsubscribe usr-tc" in the body of the message.
  5008.  For information on digests or retrieving files and old messages send
  5009.  "help" to the same address.  Do not use quotes in your message.
  5010.  
  5011.  
  5012. -------------------------------------------------------------------------------
  5013.  
  5014. From: Brian <signal@shreve.net>
  5015. Subject: Re: (usr-tc) NMC Command Reference
  5016. Date: 07 Oct 1999 13:30:56 -0500 (CDT)
  5017.  
  5018. On Thu, 7 Oct 1999, Steve Valiunas wrote:
  5019.  
  5020. > 
  5021. > 
  5022. > If you search on "hiper" and "management" you'll get hits on the HiperNMC
  5023. > Parameter reference,  HiperNMC Getting Started Guide,  HiperNMC Product
  5024. > Reference and a couple others.
  5025.  
  5026. Hmm, any reason why going to "document library" and clicking on "Network
  5027. Managment Card" doesn't turn these up?
  5028.  
  5029. Thanks for the help,
  5030.  
  5031. Brian
  5032.  
  5033.  
  5034. > 
  5035. > 
  5036. > 
  5037. > 
  5038. > Brian <signal@shreve.net> on 10/07/99 09:57:03 AM
  5039. > 
  5040. > Please respond to usr-tc@lists.xmission.com
  5041. > 
  5042. > Sent by:  Brian <signal@shreve.net>
  5043. > 
  5044. > 
  5045. > To:   USRobotics TC Mailing List <usr-tc@xmission.com>
  5046. > cc:    (Steve Valiunas/MW/US/3Com)
  5047. > Subject:  (usr-tc) NMC Command Reference
  5048. > 
  5049. > 
  5050. > 
  5051. > 
  5052. > 
  5053. > 
  5054. > I am trying to get a handle on the Command Reference to use with HiperNMC
  5055. > 6.x.  I don't see a HiperNMC 6.x command reference on TotalService.  What
  5056. > I do see is:
  5057. > 
  5058. > NMC version 5.0 parameter reference
  5059. > HiPer NMC Parameter Reference Errata Sheet
  5060. > HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
  5061. > 
  5062. > 
  5063. > That being said, are those the 3 files I should look at, or does a
  5064. > "HiperNMC version 6.0 parameter reference" exist somewhere?  I am assuming
  5065. > you just go about using the 5.0 parameter reference with a few changes
  5066. > documented in the erattas...........
  5067. > 
  5068. > Brian
  5069. > 
  5070. > -----------------------------------------------------
  5071. > Brian Feeny (BF304)     signal@shreve.net
  5072. > 318-222-2638 x 109  http://www.shreve.net/~signal
  5073. > Network Administrator   ShreveNet Inc. (ASN 11881)
  5074. > 
  5075. > 
  5076. > -
  5077. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5078. >  with "unsubscribe usr-tc" in the body of the message.
  5079. >  For information on digests or retrieving files and old messages send
  5080. >  "help" to the same address.  Do not use quotes in your message.
  5081. > 
  5082. > 
  5083. > 
  5084. > 
  5085. > 
  5086. > 
  5087. > -
  5088. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5089. >  with "unsubscribe usr-tc" in the body of the message.
  5090. >  For information on digests or retrieving files and old messages send
  5091. >  "help" to the same address.  Do not use quotes in your message.
  5092. > 
  5093.  
  5094. Brian Feeny (BF304)     signal@shreve.net   
  5095. 318-222-2638 x 109    http://www.shreve.net/~signal      
  5096. Network Administrator   ShreveNet Inc. (ASN 11881)           
  5097.  
  5098.  
  5099.  
  5100. -
  5101.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5102.  with "unsubscribe usr-tc" in the body of the message.
  5103.  For information on digests or retrieving files and old messages send
  5104.  "help" to the same address.  Do not use quotes in your message.
  5105.  
  5106.  
  5107. -------------------------------------------------------------------------------
  5108.  
  5109. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  5110. Subject: Re: (usr-tc) NMC Command Reference
  5111. Date: 07 Oct 1999 14:05:19 -0500
  5112.  
  5113.  
  5114.  
  5115. Don't know if it's a Good reason,  but it looks like the plain-old-reason is
  5116. that the links are incomplete for some of the docs.  We'll try to get this
  5117. straightened out...    For what it's worth-  the "Total Control Hubs : TCS3.5"
  5118. product family  should be complete.
  5119.  
  5120.   Sorry about that.
  5121.  
  5122.      Steve
  5123.  
  5124.  
  5125.  
  5126.  
  5127.  
  5128. Brian <signal@shreve.net> on 10/07/99 01:30:56 PM
  5129.  
  5130. Please respond to usr-tc@lists.xmission.com
  5131.  
  5132. Sent by:  Brian <signal@shreve.net>
  5133.  
  5134.  
  5135. cc:    (Steve Valiunas/MW/US/3Com)
  5136.  
  5137.  
  5138.  
  5139.  
  5140. On Thu, 7 Oct 1999, Steve Valiunas wrote:
  5141.  
  5142. >
  5143. >
  5144. > If you search on "hiper" and "management" you'll get hits on the HiperNMC
  5145. > Parameter reference,  HiperNMC Getting Started Guide,  HiperNMC Product
  5146. > Reference and a couple others.
  5147.  
  5148. Hmm, any reason why going to "document library" and clicking on "Network
  5149. Managment Card" doesn't turn these up?
  5150.  
  5151. Thanks for the help,
  5152.  
  5153. Brian
  5154.  
  5155.  
  5156. >
  5157. >
  5158. >
  5159. >
  5160. > Brian <signal@shreve.net> on 10/07/99 09:57:03 AM
  5161. >
  5162. > Please respond to usr-tc@lists.xmission.com
  5163. >
  5164. > Sent by:  Brian <signal@shreve.net>
  5165. >
  5166. >
  5167. > To:   USRobotics TC Mailing List <usr-tc@xmission.com>
  5168. > cc:    (Steve Valiunas/MW/US/3Com)
  5169. > Subject:  (usr-tc) NMC Command Reference
  5170. >
  5171. >
  5172. >
  5173. >
  5174. >
  5175. >
  5176. > I am trying to get a handle on the Command Reference to use with HiperNMC
  5177. > 6.x.  I don't see a HiperNMC 6.x command reference on TotalService.  What
  5178. > I do see is:
  5179. >
  5180. > NMC version 5.0 parameter reference
  5181. > HiPer NMC Parameter Reference Errata Sheet
  5182. > HiPer NMC SNMP and MIB Reference Errata Sheet V6.0, 6.1, 6.2
  5183. >
  5184. >
  5185. > That being said, are those the 3 files I should look at, or does a
  5186. > "HiperNMC version 6.0 parameter reference" exist somewhere?  I am assuming
  5187. > you just go about using the 5.0 parameter reference with a few changes
  5188. > documented in the erattas...........
  5189. >
  5190. > Brian
  5191. >
  5192. > -----------------------------------------------------
  5193. > Brian Feeny (BF304)     signal@shreve.net
  5194. > 318-222-2638 x 109  http://www.shreve.net/~signal
  5195. > Network Administrator   ShreveNet Inc. (ASN 11881)
  5196. >
  5197. >
  5198. > -
  5199. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5200. >  with "unsubscribe usr-tc" in the body of the message.
  5201. >  For information on digests or retrieving files and old messages send
  5202. >  "help" to the same address.  Do not use quotes in your message.
  5203. >
  5204. >
  5205. >
  5206. >
  5207. >
  5208. >
  5209. > -
  5210. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5211. >  with "unsubscribe usr-tc" in the body of the message.
  5212. >  For information on digests or retrieving files and old messages send
  5213. >  "help" to the same address.  Do not use quotes in your message.
  5214. >
  5215.  
  5216. Brian Feeny (BF304)     signal@shreve.net
  5217. 318-222-2638 x 109  http://www.shreve.net/~signal
  5218. Network Administrator   ShreveNet Inc. (ASN 11881)
  5219.  
  5220.  
  5221.  
  5222. -
  5223.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5224.  with "unsubscribe usr-tc" in the body of the message.
  5225.  For information on digests or retrieving files and old messages send
  5226.  "help" to the same address.  Do not use quotes in your message.
  5227.  
  5228.  
  5229.  
  5230.  
  5231.  
  5232.  
  5233. -
  5234.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5235.  with "unsubscribe usr-tc" in the body of the message.
  5236.  For information on digests or retrieving files and old messages send
  5237.  "help" to the same address.  Do not use quotes in your message.
  5238.  
  5239.  
  5240. -------------------------------------------------------------------------------
  5241.  
  5242. From: Mike Andrews <mandrews@bit0.com>
  5243. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?) 
  5244. Date: 07 Oct 1999 15:14:50 -0400 (EDT)
  5245.  
  5246. There was some discussion on transmit levels a while back -- check the
  5247. archives.  If I remember right, David Bolen said that ANS made a habit of
  5248. setting all their modem pools (for AOL mostly) to -13dBm.
  5249.  
  5250. We had a few people have problems when we tried backing ours down, so for
  5251. now I've left it alone until I can get a better idea.
  5252.  
  5253. Complicating things more is that we have both Quads and DSP's, and the
  5254. Quads default to -11, but the DSP's default (or at least used to default)
  5255. to -12.  The Courier I-Modem I have at home defaults to -12.  What the
  5256. actual transmit power works out to in all these cases at each modulation
  5257. is anyone's guess...
  5258.  
  5259.  
  5260. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  5261. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  5262. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  5263. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  5264.  
  5265.  
  5266. -
  5267.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5268.  with "unsubscribe usr-tc" in the body of the message.
  5269.  For information on digests or retrieving files and old messages send
  5270.  "help" to the same address.  Do not use quotes in your message.
  5271.  
  5272.  
  5273. -------------------------------------------------------------------------------
  5274.  
  5275. From: eric@dol.net
  5276. Subject: Re: (usr-tc) Filter
  5277. Date: 07 Oct 1999 13:20:54 -0600
  5278.  
  5279. Would the customer be able to get their mail with a dns lookup of the mail.xx.net 
  5280. mail server from an inside ip address or would they get connected then get a 
  5281. "could not locate the server" errror message.  We currently send notes to the 
  5282. customer telling them their account will become inactive on a certain date but I 
  5283. like the idea of throwing up a web page saying your did not renew your account 
  5284. please call the office.
  5285. eric
  5286.  
  5287.  
  5288.  
  5289. At 02:42 AM 10/8/99 +1000, you wrote:
  5290. >A valid point.
  5291. >
  5292. >in the script I suggested to change the FRAMED-IP-ADDRESS radius attribute simply
  5293. >add a sendmail routein to send them an E-mail.
  5294. >
  5295. >or if you use NT this should be able to be done with the CDONTS vbscript feature.
  5296. >
  5297. >Thanks,
  5298. >Aaron
  5299. >
  5300. >eric@dol.net wrote:
  5301. >
  5302. >> This assumes the customer uses a web browser. What happens in this case then the
  5303. >> customer only uses email?
  5304. >>
  5305. >> At 01:48 AM 9/8/99 +1000, you wrote:
  5306. >> >One thing you could do would be to write a script that changes that particular
  5307. >> >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  5308. >> >and using the route-map feature in your cisco(if you have a cisco) for forward
  5309. >> >all traffic on that 192.168 network to A web site say
  5310. >> >http://outoftime.yourdomain.com/ and with that same access list you could deny
  5311. >> >all other traffic.
  5312. >> >
  5313. >> >NOTE: I have never implemented this, but I like the idea of informing the user
  5314. >> >that they are out of time so I will do it within the coming weeks.
  5315. >> >
  5316. >> >Thanks,
  5317. >> >Aaron
  5318. >> >
  5319. >> >Jamie Orzechowski wrote:
  5320. >> >
  5321. >> >> I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  5322. >> >> to one specific site.
  5323. >> >>
  5324. >> >> We would like have filter so that any late payment people will still be able
  5325. >> >> to login but they will be redirected to a website informing them that their
  5326. >> >> bill is due.
  5327. >> >>
  5328. >> >> would also like the filter to not allow any traffic other than HTTP.
  5329. >> >>
  5330. >> >> any ideas?
  5331. >> >>
  5332. >> >> -
  5333. >> >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5334. >> >>  with "unsubscribe usr-tc" in the body of the message.
  5335. >> >>  For information on digests or retrieving files and old messages send
  5336. >> >>  "help" to the same address.  Do not use quotes in your message.
  5337. >> >
  5338. >> >
  5339. >> >-
  5340. >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5341. >> > with "unsubscribe usr-tc" in the body of the message.
  5342. >> > For information on digests or retrieving files and old messages send
  5343. >> > "help" to the same address.  Do not use quotes in your message.
  5344. >> >Delaware Online!.........The SMART Choice!
  5345. >> With 56K V.90 & X2 & Flex Modems
  5346. >> Phone : 302-762-0375
  5347. >> Fax:    302-762-3462
  5348. >> Failure is NOT an option...
  5349. >>
  5350. >> -
  5351. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5352. >>  with "unsubscribe usr-tc" in the body of the message.
  5353. >>  For information on digests or retrieving files and old messages send
  5354. >>  "help" to the same address.  Do not use quotes in your message.
  5355. >
  5356. >
  5357. >-
  5358. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5359. > with "unsubscribe usr-tc" in the body of the message.
  5360. > For information on digests or retrieving files and old messages send
  5361. > "help" to the same address.  Do not use quotes in your message.
  5362. >Delaware Online!.........The SMART Choice!  
  5363. With 56K V.90 & X2 & Flex Modems 
  5364. Phone : 302-762-0375                
  5365. Fax:     302-762-3462        
  5366. Failure is NOT an option...
  5367.  
  5368.  
  5369.  
  5370. -
  5371.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5372.  with "unsubscribe usr-tc" in the body of the message.
  5373.  For information on digests or retrieving files and old messages send
  5374.  "help" to the same address.  Do not use quotes in your message.
  5375.  
  5376.  
  5377. -------------------------------------------------------------------------------
  5378.  
  5379. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  5380. Subject: Re: (usr-tc) Filter
  5381. Date: 07 Oct 1999 07:22:41 -0500 (CDT)
  5382.  
  5383.  
  5384. On Thu, 7 Oct 1999, Startup Suppliers Ltd. wrote:
  5385.  
  5386. > I am interested in this too, please forward response to me.
  5387. A filter will not do it, you need more than a filter, You first need some 
  5388. time of script or something that records that the user has not paid the 
  5389. fee etc, and then change the user record to be directed at a particular 
  5390. website.  
  5391.  
  5392. One way of doing it is having the user be modfied to be a L2tp user where 
  5393. in he would only go to one pariticular site irrespective of any we 
  5394. address he puts.  Long time back there was email chain on various ways to 
  5395. do this.  You may want to dig up the archive and take a look on how to do 
  5396. this with l2tp.  
  5397.  
  5398. krish
  5399.  
  5400.  
  5401. > 
  5402. > Okeyo
  5403. > 
  5404. > 
  5405. > At 10:00 AM 10/6/99 -0400, you wrote:
  5406. > >I am trying to create an ARC filter that will make ALL HTTP traffic redirect
  5407. > >to one specific site.
  5408. > >
  5409. > >We would like have filter so that any late payment people will still be able
  5410. > >to login but they will be redirected to a website informing them that their
  5411. > >bill is due.
  5412. > >
  5413. > >would also like the filter to not allow any traffic other than HTTP.
  5414. > >
  5415. > >any ideas?
  5416. > >
  5417. > >
  5418. > >-
  5419. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5420. > > with "unsubscribe usr-tc" in the body of the message.
  5421. > > For information on digests or retrieving files and old messages send
  5422. > > "help" to the same address.  Do not use quotes in your message.
  5423. > >
  5424. > >
  5425. > 
  5426. > 
  5427. > -
  5428. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5429. >  with "unsubscribe usr-tc" in the body of the message.
  5430. >  For information on digests or retrieving files and old messages send
  5431. >  "help" to the same address.  Do not use quotes in your message.
  5432. > 
  5433.  
  5434. -
  5435.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5436.  with "unsubscribe usr-tc" in the body of the message.
  5437.  For information on digests or retrieving files and old messages send
  5438.  "help" to the same address.  Do not use quotes in your message.
  5439.  
  5440.  
  5441. -------------------------------------------------------------------------------
  5442.  
  5443. From: Brian <signal@shreve.net>
  5444. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?) 
  5445. Date: 07 Oct 1999 20:41:38 -0500 (CDT)
  5446.  
  5447. On Thu, 7 Oct 1999, Mike Andrews wrote:
  5448.  
  5449. > There was some discussion on transmit levels a while back -- check the
  5450. > archives.  If I remember right, David Bolen said that ANS made a habit of
  5451. > setting all their modem pools (for AOL mostly) to -13dBm.
  5452.  
  5453. nod, I have those emails.  The thing is, that was on the Quads.  The quads
  5454. could do analog or digital.  The default modem templates were optimized
  5455. for analog calls not digital.  So you would have to make some changes to
  5456. the Quads to optimize for CT1/PRI.
  5457.  
  5458. David did clarify however that the HDM's didn't have this problem.  But
  5459. that was when they first came out, who knows whats what since then.
  5460.  
  5461. > 
  5462. > We had a few people have problems when we tried backing ours down, so for
  5463. > now I've left it alone until I can get a better idea.
  5464. > 
  5465. > Complicating things more is that we have both Quads and DSP's, and the
  5466. > Quads default to -11, but the DSP's default (or at least used to default)
  5467. > to -12.  The Courier I-Modem I have at home defaults to -12.  What the
  5468. > actual transmit power works out to in all these cases at each modulation
  5469. > is anyone's guess...
  5470. > 
  5471. > 
  5472. > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  5473. > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  5474. > Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  5475. > "With sufficient thrust, pigs fly just fine." -- RFC 1925
  5476. > 
  5477. > 
  5478. > -
  5479. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5480. >  with "unsubscribe usr-tc" in the body of the message.
  5481. >  For information on digests or retrieving files and old messages send
  5482. >  "help" to the same address.  Do not use quotes in your message.
  5483. > 
  5484.  
  5485. Brian Feeny (BF304)     signal@shreve.net   
  5486. 318-222-2638 x 109    http://www.shreve.net/~signal      
  5487. Network Administrator   ShreveNet Inc. (ASN 11881)           
  5488.  
  5489.  
  5490. -
  5491.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5492.  with "unsubscribe usr-tc" in the body of the message.
  5493.  For information on digests or retrieving files and old messages send
  5494.  "help" to the same address.  Do not use quotes in your message.
  5495.  
  5496.  
  5497. -------------------------------------------------------------------------------
  5498.  
  5499. From: "Brian A. Burgmeier" <brianb@ntwrld.com>
  5500. Subject: Re: (usr-tc) Filter
  5501. Date: 07 Oct 1999 19:31:23 -0700
  5502.  
  5503. Micah,
  5504.  
  5505. Maybe with the new radius that you set up, you could figure out a way to have
  5506. certain users assign a certain IP that take them to a "Your Bill is Due" web page
  5507. and prevents them from going anywhere else?
  5508.  
  5509.  
  5510. Dataheart wrote:
  5511.  
  5512. > One thing you could do would be to write a script that changes that particular
  5513. > users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168 network
  5514. > and using the route-map feature in your cisco(if you have a cisco) for forward
  5515. > all traffic on that 192.168 network to A web site say
  5516. > http://outoftime.yourdomain.com/ and with that same access list you could deny
  5517. > all other traffic.
  5518. > NOTE: I have never implemented this, but I like the idea of informing the user
  5519. > that they are out of time so I will do it within the coming weeks.
  5520. >
  5521. > Thanks,
  5522. > Aaron
  5523.  
  5524.  
  5525.  
  5526.  
  5527. -
  5528.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5529.  with "unsubscribe usr-tc" in the body of the message.
  5530.  For information on digests or retrieving files and old messages send
  5531.  "help" to the same address.  Do not use quotes in your message.
  5532.  
  5533.  
  5534. -------------------------------------------------------------------------------
  5535.  
  5536. From: Mike Andrews <mandrews@bit0.com>
  5537. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?) 
  5538. Date: 07 Oct 1999 23:38:58 -0400 (EDT)
  5539.  
  5540. On Thu, 7 Oct 1999, Brian wrote:
  5541.  
  5542. > On Thu, 7 Oct 1999, Mike Andrews wrote:
  5543. > 
  5544. > > There was some discussion on transmit levels a while back -- check the
  5545. > > archives.  If I remember right, David Bolen said that ANS made a habit of
  5546. > > setting all their modem pools (for AOL mostly) to -13dBm.
  5547. > 
  5548. > nod, I have those emails.  The thing is, that was on the Quads.  The quads
  5549. > could do analog or digital.  The default modem templates were optimized
  5550. > for analog calls not digital.  So you would have to make some changes to
  5551. > the Quads to optimize for CT1/PRI.
  5552. > 
  5553. > David did clarify however that the HDM's didn't have this problem.  But
  5554. > that was when they first came out, who knows whats what since then.
  5555.  
  5556. FWIW...  I just blew a 2.0.81 DSP back to factory defaults and it comes up
  5557. set to -11 now, instead of -12 like it used to.  So it looks like both
  5558. Quads and DSPs default to -11 now.
  5559.  
  5560. (Courier I-Modem still does -12 on my BRI at home...  that would be
  5561. interesting to experiment on...)
  5562.  
  5563. Anyway.  Given that the measured level and the programmed level tend to
  5564. vary on both 3Com and Ass^Hcend stuff...  anyone have a new consensus as
  5565. to what we should be using instead of 11?  13?  15?
  5566.  
  5567.  
  5568. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  5569. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  5570. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  5571. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  5572.  
  5573.  
  5574.  
  5575. -
  5576.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5577.  with "unsubscribe usr-tc" in the body of the message.
  5578.  For information on digests or retrieving files and old messages send
  5579.  "help" to the same address.  Do not use quotes in your message.
  5580.  
  5581.  
  5582. -------------------------------------------------------------------------------
  5583.  
  5584. From: "Campbell Simpson" <Campbell.Simpson@telecom.co.nz>
  5585. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?) -Reply
  5586. Date: 08 Oct 1999 16:50:53 +1300
  5587.  
  5588. We have our HiPer DSP cards set to -11dB. There has been plenty of =
  5589. discussion about what the levels should be set at and we are currently =
  5590. lowering the transmit levels on a number of our NAS by 1dB each week to =
  5591. see what effect it has on call stability and connect speeds.=20
  5592.  
  5593. I'll let you know what our findings are when we have finished the trials
  5594.  
  5595.  
  5596.  
  5597. -
  5598.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5599.  with "unsubscribe usr-tc" in the body of the message.
  5600.  For information on digests or retrieving files and old messages send
  5601.  "help" to the same address.  Do not use quotes in your message.
  5602.  
  5603.  
  5604. -------------------------------------------------------------------------------
  5605.  
  5606. From: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
  5607. Subject: Re: (usr-tc) DSL
  5608. Date: 08 Oct 1999 12:50:21 +0300
  5609.  
  5610. Hi,
  5611.  
  5612. Mike Wilker wrote:
  5613.  
  5614. > Does anyone still run the Affinity DSL on their TotalControls?  I am trying
  5615. > to set one up that we've had for a year now, but I can't get the command
  5616. > line to come up on the card.  Does it use the same console cable as the
  5617. > HiperArcs and NMCs, and is there another way to configure it, say through
  5618. > the Viper DSL?
  5619.  
  5620. The best way is to use cable from MP (RJ45<->DB25, no nullmodem).
  5621.  
  5622. > Thanks.
  5623. >
  5624. > Mike Wilker
  5625. > Operations Manager
  5626. > Local Link, Inc.
  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. Vadim.
  5635.  
  5636.  
  5637. -
  5638.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5639.  with "unsubscribe usr-tc" in the body of the message.
  5640.  For information on digests or retrieving files and old messages send
  5641.  "help" to the same address.  Do not use quotes in your message.
  5642.  
  5643.  
  5644. -------------------------------------------------------------------------------
  5645.  
  5646. From: Robert von Bismarck <rvb@petrel.ch>
  5647. Subject: RE: (usr-tc) Filter
  5648. Date: 08 Oct 1999 11:06:28 +0200 
  5649.  
  5650. Or use qpopper with the Bulletin mode activated. See
  5651. http://www.eudora.com/free/servers.html
  5652.  
  5653.  
  5654. --
  5655. Robert von Bismarck
  5656. Network Systems Engineer
  5657. Petrel Communications SA / SPAN
  5658. Tel : +41 22 304 47 47
  5659. Fax : +41 22 300 48 43
  5660. WWW : http://www.petrel.ch
  5661. e-mail : rvb@petrel.ch
  5662.  
  5663. > -----Original Message-----
  5664. > From:    Charles Sprickman [SMTP:spork@inch.com]
  5665. > Sent:    jeudi, 7. octobre 1999 19:43
  5666. > To:    usr-tc@lists.xmission.com
  5667. > Subject:    Re: (usr-tc) Filter
  5668. > 
  5669. > Do the same as with the web server, but run a dummy popper that always
  5670. > responds with "-ERR Pay your bill, fool!".  See
  5671. > http://www.tdx.co.uk/software/ for an example dummy popper.  A bit of
  5672. > hacking and you're on your way...
  5673. > 
  5674. > Charles
  5675. > 
  5676. > On Thu, 7 Oct 1999 eric@dol.net wrote:
  5677. > 
  5678. > > This assumes the customer uses a web browser. What happens in this case
  5679. > then the 
  5680. > > customer only uses email?
  5681. > > 
  5682. > > 
  5683. > > 
  5684. > > At 01:48 AM 9/8/99 +1000, you wrote:
  5685. > > >One thing you could do would be to write a script that changes that
  5686. > particular
  5687. > > >users FRAMED-IP-ADDRESS radius attribute to something on say a 192.168
  5688. > network
  5689. > > >and using the route-map feature in your cisco(if you have a cisco) for
  5690. > forward
  5691. > > >all traffic on that 192.168 network to A web site say
  5692. > > >http://outoftime.yourdomain.com/ and with that same access list you
  5693. > could deny
  5694. > > >all other traffic.
  5695. > > >
  5696. > > >NOTE: I have never implemented this, but I like the idea of informing
  5697. > the user
  5698. > > >that they are out of time so I will do it within the coming weeks.
  5699. > > >
  5700. > > >Thanks,
  5701. > > >Aaron
  5702. > > >
  5703. > > >Jamie Orzechowski wrote:
  5704. > > >
  5705. > > >> I am trying to create an ARC filter that will make ALL HTTP traffic
  5706. > redirect
  5707. > > >> to one specific site.
  5708. > > >>
  5709. > > >> We would like have filter so that any late payment people will still
  5710. > be able
  5711. > > >> to login but they will be redirected to a website informing them that
  5712. > their
  5713. > > >> bill is due.
  5714. > > >>
  5715. > > >> would also like the filter to not allow any traffic other than HTTP.
  5716. > > >>
  5717. > > >> any ideas?
  5718. > > >>
  5719. > > >> -
  5720. > > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5721. > > >>  with "unsubscribe usr-tc" in the body of the message.
  5722. > > >>  For information on digests or retrieving files and old messages send
  5723. > > >>  "help" to the same address.  Do not use quotes in your message.
  5724. > > >
  5725. > > >
  5726. > > >-
  5727. > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5728. > > > with "unsubscribe usr-tc" in the body of the message.
  5729. > > > For information on digests or retrieving files and old messages send
  5730. > > > "help" to the same address.  Do not use quotes in your message.
  5731. > > >Delaware Online!.........The SMART Choice!  
  5732. > > With 56K V.90 & X2 & Flex Modems 
  5733. > > Phone : 302-762-0375                
  5734. > > Fax:     302-762-3462        
  5735. > > Failure is NOT an option...
  5736. > > 
  5737. > > 
  5738. > > 
  5739. > > -
  5740. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5741. > >  with "unsubscribe usr-tc" in the body of the message.
  5742. > >  For information on digests or retrieving files and old messages send
  5743. > >  "help" to the same address.  Do not use quotes in your message.
  5744. > > 
  5745. > 
  5746. > 
  5747. > -
  5748. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5749. >  with "unsubscribe usr-tc" in the body of the message.
  5750. >  For information on digests or retrieving files and old messages send
  5751. >  "help" to the same address.  Do not use quotes in your message.
  5752.  
  5753. -
  5754.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5755.  with "unsubscribe usr-tc" in the body of the message.
  5756.  For information on digests or retrieving files and old messages send
  5757.  "help" to the same address.  Do not use quotes in your message.
  5758.  
  5759.  
  5760. -------------------------------------------------------------------------------
  5761.  
  5762. From: Daniel Mpolokoso <daniel@zamnet.zm>
  5763. Subject: (usr-tc) Latest E1/R2 code for HiPer DSP
  5764. Date: 08 Oct 1999 11:10:03 +0200
  5765.  
  5766. Hi,
  5767.  
  5768. I'd be grateful for information on how I can get access to the latest E1/R2
  5769. code for the HiPer DSP. Our nearest support is South Africa and they don't
  5770. have access to the code for some reason.
  5771.  
  5772. The latest information I have indicates that E1/R2 code is not yet in
  5773. general release and as such, will probably not appear on the Total Service
  5774. site for quite a while.
  5775.  
  5776. I'm really getting desperate to get our HiPer DSPs interfacing to our
  5777. telco's exchange (E1 R2 signaling, HDB3, Multiframing with no CRC) and look
  5778. forward to any form of assistance anyone can provide to help us get our
  5779. system online.
  5780.  
  5781. Thanks,
  5782.  
  5783.  
  5784. Daniel.
  5785. Daniel Mpolokoso - Technical Manager,           Email:  daniel@zamnet.zm
  5786. ZAMNET Communication Systems Limited,           Phone: +260 - 1 - 772516
  5787. P.O. Box 38299, Lusaka, Zambia.                 Fax:   +260 - 1 - 224775
  5788.  
  5789. -
  5790.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5791.  with "unsubscribe usr-tc" in the body of the message.
  5792.  For information on digests or retrieving files and old messages send
  5793.  "help" to the same address.  Do not use quotes in your message.
  5794.  
  5795.  
  5796. -------------------------------------------------------------------------------
  5797.  
  5798. From: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
  5799. Subject: Re: (usr-tc) HiPer DSP and E1/R2
  5800. Date: 08 Oct 1999 17:24:29 +0300
  5801.  
  5802.  
  5803. --------------BCBE7299EA7BDFF348384543
  5804. Content-Type: text/plain; charset=koi8-r
  5805. Content-Transfer-Encoding: 7bit
  5806.  
  5807. Hi David,
  5808.  
  5809. David Bachta wrote:
  5810.  
  5811. > Hi Daniel,
  5812. >
  5813. > You will need an E1/R2 version of Hiper DSP code.  The filename is in the format
  5814. > of HR******.DMF, where the *s are the version number.   The HE******.DMF files
  5815. > are for E1/PRI and the HD******.DMF files are for T1/PRI.  The R2 code is not
  5816. > generally available yet but there are beta and engineering releases that some
  5817. > customers have been using.
  5818.  
  5819. Ooooh! Where???
  5820.  
  5821. We have many customer who need this release (now we give them Dual CAS+ Quad
  5822. Digital). How can we get access to this code? I haven't seen it on beta tester page.
  5823.  
  5824.  
  5825.  
  5826.  
  5827. >
  5828. >
  5829. > Your best bet is to call your local support team for assistance at :
  5830. >
  5831. >      South Africa        0800-995014
  5832. >
  5833. > Hope this helps...
  5834. >
  5835. > Regards,
  5836. > David
  5837. >
  5838. > Daniel Mpolokoso <daniel@zamnet.zm> on 10/04/99 07:16:31 AM
  5839. >
  5840. > Please respond to usr-tc@lists.xmission.com
  5841. >
  5842. > Sent by:  Daniel Mpolokoso <daniel@zamnet.zm>
  5843. >
  5844. > To:   usr-tc <usr-tc@lists.xmission.com>
  5845. > cc:    (David Bachta/MW/US/3Com)
  5846. > Subject:  (usr-tc) HiPer DSP and E1/R2
  5847. >
  5848. > Hi,
  5849. >
  5850. > I've been battling for a week trying to get HiPer DSP version 2.0.19 to
  5851. > interface with our telco's switch. They are using basic E1 R2 signaling as
  5852. > per ITU-T standards. I'd be grateful for anyone out there using E1 R2
  5853. > signaling to give me pointers as to what version of software I should be
  5854. > running and examples of typical configurations.
  5855. >
  5856. > Thanks,
  5857. >
  5858. > Daniel.
  5859. > ------------------------------------------------------------------------
  5860. > Daniel Mpolokoso - Technical Manager,           Email:  daniel@zamnet.zm
  5861. > ZAMNET Communication Systems Limited,           Phone: +260 - 1 - 772516
  5862. > P.O. Box 38299, Lusaka, Zambia.                 Fax:   +260 - 1 - 224775
  5863. >
  5864. > -
  5865. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5866. >  with "unsubscribe usr-tc" in the body of the message.
  5867. >  For information on digests or retrieving files and old messages send
  5868. >  "help" to the same address.  Do not use quotes in your message.
  5869. >
  5870. > -
  5871. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5872. >  with "unsubscribe usr-tc" in the body of the message.
  5873. >  For information on digests or retrieving files and old messages send
  5874. >  "help" to the same address.  Do not use quotes in your message.
  5875.  
  5876.  
  5877.  
  5878. --
  5879. _______________________________________________
  5880.  
  5881. Best regards,
  5882. Vadim Tulinov.
  5883.  
  5884.  
  5885. --------------BCBE7299EA7BDFF348384543
  5886. Content-Type: text/html; charset=koi8-r
  5887. Content-Transfer-Encoding: 7bit
  5888.  
  5889. <HTML>
  5890. Hi David,
  5891.  
  5892. <P>David Bachta wrote:
  5893. <BLOCKQUOTE TYPE=CITE>Hi Daniel,
  5894.  
  5895. <P>You will need an E1/R2 version of Hiper DSP code.  The filename
  5896. is in the format
  5897. <BR>of HR******.DMF, where the *s are the version number.   The
  5898. HE******.DMF files
  5899. <BR>are for E1/PRI and the HD******.DMF files are for T1/PRI.  The
  5900. R2 code is not
  5901. <BR>generally available yet but there are <B><I>beta and engineering releases</I></B>
  5902. that some
  5903. <BR>customers have been using.</BLOCKQUOTE>
  5904. Ooooh! Where???
  5905.  
  5906. <P>We have many customer who need this release (now we give them Dual CAS+
  5907. Quad Digital). How can we get access to this code? I haven't seen it on
  5908. beta tester page.
  5909. <BR> 
  5910. <BR> 
  5911. <BLOCKQUOTE TYPE=CITE> 
  5912.  
  5913. <P>Your best bet is to call your local support team for assistance at :
  5914.  
  5915. <P>     South Africa       
  5916. 0800-995014
  5917.  
  5918. <P>Hope this helps...
  5919.  
  5920. <P>Regards,
  5921. <BR>David
  5922.  
  5923. <P>Daniel Mpolokoso <daniel@zamnet.zm> on 10/04/99 07:16:31 AM
  5924.  
  5925. <P>Please respond to usr-tc@lists.xmission.com
  5926.  
  5927. <P>Sent by:  Daniel Mpolokoso <daniel@zamnet.zm>
  5928.  
  5929. <P>To:   usr-tc <usr-tc@lists.xmission.com>
  5930. <BR>cc:    (David Bachta/MW/US/3Com)
  5931. <BR>Subject:  (usr-tc) HiPer DSP and E1/R2
  5932.  
  5933. <P>Hi,
  5934.  
  5935. <P>I've been battling for a week trying to get HiPer DSP version 2.0.19
  5936. to
  5937. <BR>interface with our telco's switch. They are using basic E1 R2 signaling
  5938. as
  5939. <BR>per ITU-T standards. I'd be grateful for anyone out there using E1
  5940. R2
  5941. <BR>signaling to give me pointers as to what version of software I should
  5942. be
  5943. <BR>running and examples of typical configurations.
  5944.  
  5945. <P>Thanks,
  5946.  
  5947. <P>Daniel.
  5948. <BR>------------------------------------------------------------------------
  5949. <BR>Daniel Mpolokoso - Technical Manager,          
  5950. Email:  daniel@zamnet.zm
  5951. <BR>ZAMNET Communication Systems Limited,          
  5952. Phone: +260 - 1 - 772516
  5953. <BR>P.O. Box 38299, Lusaka, Zambia.                
  5954. Fax:   +260 - 1 - 224775
  5955.  
  5956. <P>-
  5957. <BR> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5958. <BR> with "unsubscribe usr-tc" in the body of the message.
  5959. <BR> For information on digests or retrieving files and old messages
  5960. send
  5961. <BR> "help" to the same address.  Do not use quotes in your message.
  5962.  
  5963. <P>-
  5964. <BR> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5965. <BR> with "unsubscribe usr-tc" in the body of the message.
  5966. <BR> For information on digests or retrieving files and old messages
  5967. send
  5968. <BR> "help" to the same address.  Do not use quotes in your message.</BLOCKQUOTE>
  5969.  
  5970.  
  5971. <P>--
  5972. <BR>_______________________________________________
  5973.  
  5974. <P>Best regards,
  5975. <BR>Vadim Tulinov.
  5976. <BR> </HTML>
  5977.  
  5978. --------------BCBE7299EA7BDFF348384543--
  5979.  
  5980.  
  5981. -
  5982.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5983.  with "unsubscribe usr-tc" in the body of the message.
  5984.  For information on digests or retrieving files and old messages send
  5985.  "help" to the same address.  Do not use quotes in your message.
  5986.  
  5987.  
  5988. -------------------------------------------------------------------------------
  5989.  
  5990. From: Jerry Wright <jwright@hyperserv.com>
  5991. Subject: Re: (usr-tc) Netserver problem
  5992. Date: 08 Oct 1999 10:40:53 -0700
  5993.  
  5994. I had this problem, it was driving me crazy.  Turned out the the RAM on the NAC
  5995. card wasn't solidly in place.
  5996.    Just a thought.
  5997.           --Jerry
  5998.  
  5999. Dataheart wrote:
  6000.  
  6001. > ok,
  6002. > I have re-flashed the card and still the same thing flashes 13 times then
  6003. > flashes quickly then solid green and the loop is endless.
  6004. > Ths console is also blank.
  6005. >
  6006. > Any other ideas?
  6007. >
  6008. > Thanks,
  6009. > Aaron
  6010. >
  6011. > Scott Trautman wrote:
  6012. >
  6013. > > Anything on the console port? Bootup messages? (actually don't think you
  6014. > > would see those if I recall correctly, just a login prompt when it is up...)
  6015. > >
  6016. > > Get out the pcsdl, source and re-upload it via serial cable. Hint: set your
  6017. > > serial port to at least 57600 w/dip switches.
  6018. > >
  6019. > > Sounds like your flash got corrupted.
  6020. > >
  6021. > > Or send it back to 3Com and they'll do probably the same thing.
  6022. > >
  6023. > > SMT
  6024. > >
  6025. > > > -----Original Message-----
  6026. > > > From: Dataheart [mailto:lists@dataheart.net]
  6027. > > > Sent: Thursday, September 30, 1999 10:49 AM
  6028. > > > To: usr-tc@lists.xmission.com
  6029. > > > Subject: (usr-tc) Netserver problem
  6030. > > >
  6031. > > >
  6032. > > > Well I'm just full of problems arent I :-D
  6033. > > >
  6034. > > > I have a Netserver card  that once powered up the rn/fl led
  6035. > > > flashes green on
  6036. > > > and off 13 times, then flashes quickly for a few seconds,
  6037. > > > then goes solid green
  6038. > > > for a while, then repeast the process.
  6039. > > > Anyone know whats going on?
  6040. > > >
  6041. > > > Thanks,
  6042. > > > Aaron
  6043. > > >
  6044. > > >
  6045. > > > -
  6046. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6047. > > >  with "unsubscribe usr-tc" in the body of the message.
  6048. > > >  For information on digests or retrieving files and old messages send
  6049. > > >  "help" to the same address.  Do not use quotes in your message.
  6050. > > >
  6051. > >
  6052. > > -
  6053. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6054. > >  with "unsubscribe usr-tc" in the body of the message.
  6055. > >  For information on digests or retrieving files and old messages send
  6056. > >  "help" to the same address.  Do not use quotes in your message.
  6057. >
  6058. > -
  6059. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6060. >  with "unsubscribe usr-tc" in the body of the message.
  6061. >  For information on digests or retrieving files and old messages send
  6062. >  "help" to the same address.  Do not use quotes in your message.
  6063.  
  6064.  
  6065. -
  6066.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6067.  with "unsubscribe usr-tc" in the body of the message.
  6068.  For information on digests or retrieving files and old messages send
  6069.  "help" to the same address.  Do not use quotes in your message.
  6070.  
  6071.  
  6072. -------------------------------------------------------------------------------
  6073.  
  6074. From: Brian <signal@shreve.net>
  6075. Subject: (usr-tc) Does Windows98 listen on RIP?!?
  6076. Date: 08 Oct 1999 18:21:11 -0500 (CDT)
  6077.  
  6078.  
  6079. I noticed today that alot of the Windows98 machines show our total
  6080. controls hubs in their routing tables as a default route!  Its got a high
  6081. metric of 1000, and the "true" default route is set as 1, but I was
  6082. curious about how Windows98 even knew about our total control hubs.  They
  6083. are on the same network.  Anyone else notice this?  Anything negative
  6084. about it?  How do you stop 98 from listening to those routes?
  6085.  
  6086. Brian
  6087.  
  6088.  
  6089. Brian Feeny (BF304)     signal@shreve.net   
  6090. 318-222-2638 x 109    http://www.shreve.net/~signal      
  6091. Network Administrator   ShreveNet Inc. (ASN 11881)           
  6092.  
  6093.  
  6094. -
  6095.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6096.  with "unsubscribe usr-tc" in the body of the message.
  6097.  For information on digests or retrieving files and old messages send
  6098.  "help" to the same address.  Do not use quotes in your message.
  6099.  
  6100.  
  6101. -------------------------------------------------------------------------------
  6102.  
  6103. From: jeff.binkley@asacomp.com (Jeff Binkley)
  6104. Subject: (usr-tc) Does Windows98 listen on RIP?!?
  6105. Date: 08 Oct 1999 20:02:00 -0500
  6106.  
  6107. -> I noticed today that alot of the Windows98 machines show our total controls
  6108. -> hubs in their routing tables as a default route!  Its got a high metric of
  6109. -> 1000, and the "true" default route is set as 1, but I was curious about how
  6110. -> Windows98 even knew about our total control hubs.  They are on the same
  6111. -> network.  Anyone else notice this?  Anything negative about it?  How do you
  6112. -> stop 98 from listening to those routes?
  6113.  
  6114.  
  6115. If you find out let me know too.  We've got a customer which has two
  6116. RAS servers on their LAN (one is a 3com and the other Ascend) and
  6117. their routing tables show the same thing.  The odd part is after
  6118. awhile they won't be able toget through their default gateway
  6119. (the Ascend unit) unless either they delete the route with the 1000
  6120. metric or reboot their machine.  It's driving them crazy. Of course
  6121. they use the Ascend to dial into us and into the Internet.
  6122.  
  6123. Jeff Binkley
  6124. ASA Network Computing
  6125.  
  6126. -
  6127.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6128.  with "unsubscribe usr-tc" in the body of the message.
  6129.  For information on digests or retrieving files and old messages send
  6130.  "help" to the same address.  Do not use quotes in your message.
  6131.  
  6132.  
  6133. -------------------------------------------------------------------------------
  6134.  
  6135. From: Brian <signal@shreve.net>
  6136. Subject: Re: (usr-tc) Does Windows98 listen on RIP?!?
  6137. Date: 08 Oct 1999 21:19:04 -0500 (CDT)
  6138.  
  6139.  
  6140. actually, we have an ascend box also, a Max, and I didn't start noticing
  6141. this until recently, and the max was just turned up.  I am wondering if
  6142. the max is whats putting those routes into windows thru some sort of
  6143. routing communication.........
  6144.  
  6145.  
  6146. On Fri, 8 Oct 1999, Jeff Binkley wrote:
  6147.  
  6148. > -> I noticed today that alot of the Windows98 machines show our total controls
  6149. > -> hubs in their routing tables as a default route!  Its got a high metric of
  6150. > -> 1000, and the "true" default route is set as 1, but I was curious about how
  6151. > -> Windows98 even knew about our total control hubs.  They are on the same
  6152. > -> network.  Anyone else notice this?  Anything negative about it?  How do you
  6153. > -> stop 98 from listening to those routes?
  6154. > 
  6155. > 
  6156. > If you find out let me know too.  We've got a customer which has two
  6157. > RAS servers on their LAN (one is a 3com and the other Ascend) and
  6158. > their routing tables show the same thing.  The odd part is after
  6159. > awhile they won't be able toget through their default gateway
  6160. > (the Ascend unit) unless either they delete the route with the 1000
  6161. > metric or reboot their machine.  It's driving them crazy. Of course
  6162. > they use the Ascend to dial into us and into the Internet.
  6163. > 
  6164. > Jeff Binkley
  6165. > ASA Network Computing
  6166. > 
  6167. > -
  6168. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6169. >  with "unsubscribe usr-tc" in the body of the message.
  6170. >  For information on digests or retrieving files and old messages send
  6171. >  "help" to the same address.  Do not use quotes in your message.
  6172. > 
  6173.  
  6174. Brian Feeny (BF304)     signal@shreve.net   
  6175. 318-222-2638 x 109    http://www.shreve.net/~signal      
  6176. Network Administrator   ShreveNet Inc. (ASN 11881)           
  6177.  
  6178.  
  6179. -
  6180.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6181.  with "unsubscribe usr-tc" in the body of the message.
  6182.  For information on digests or retrieving files and old messages send
  6183.  "help" to the same address.  Do not use quotes in your message.
  6184.  
  6185.  
  6186. -------------------------------------------------------------------------------
  6187.  
  6188. From: Mike Andrews <mandrews@bit0.com>
  6189. Subject: Re: (usr-tc) Does Windows98 listen on RIP?!?
  6190. Date: 09 Oct 1999 18:22:32 -0400 (EDT)
  6191.  
  6192. Probably caching ICMP redirects, if I had to guess.
  6193.  
  6194. Win98 doesn't do RIP unless you specifically install the RIP stuff from
  6195. the CDROM -- and it's buried *deep* on that CD in one of the powertools or
  6196. unsupported directories... not standard stuff.
  6197.  
  6198.  
  6199. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  6200. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  6201. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  6202. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  6203.  
  6204. On Fri, 8 Oct 1999, Brian wrote:
  6205.  
  6206. > 
  6207. > I noticed today that alot of the Windows98 machines show our total
  6208. > controls hubs in their routing tables as a default route!  Its got a high
  6209. > metric of 1000, and the "true" default route is set as 1, but I was
  6210. > curious about how Windows98 even knew about our total control hubs.  They
  6211. > are on the same network.  Anyone else notice this?  Anything negative
  6212. > about it?  How do you stop 98 from listening to those routes?
  6213. > 
  6214. > Brian
  6215. > 
  6216. > 
  6217. > -----------------------------------------------------
  6218. > Brian Feeny (BF304)     signal@shreve.net   
  6219. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  6220. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  6221. > 
  6222. > 
  6223. > -
  6224. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6225. >  with "unsubscribe usr-tc" in the body of the message.
  6226. >  For information on digests or retrieving files and old messages send
  6227. >  "help" to the same address.  Do not use quotes in your message.
  6228. > 
  6229.  
  6230.  
  6231. -
  6232.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6233.  with "unsubscribe usr-tc" in the body of the message.
  6234.  For information on digests or retrieving files and old messages send
  6235.  "help" to the same address.  Do not use quotes in your message.
  6236.  
  6237.  
  6238. -------------------------------------------------------------------------------
  6239.  
  6240. From: Mike Wronski <mwronski@coredump.ae.usr.com>
  6241. Subject: Re: (usr-tc) Does Windows98 listen on RIP?!?
  6242. Date: 09 Oct 1999 22:19:29 -0500 (CDT)
  6243.  
  6244. On Fri, 8 Oct 1999, Jeff Binkley wrote:
  6245.  
  6246. > -> I noticed today that alot of the Windows98 machines show our total controls
  6247. > -> hubs in their routing tables as a default route!  Its got a high metric of
  6248. > -> 1000, and the "true" default route is set as 1, but I was curious about how
  6249. > -> Windows98 even knew about our total control hubs.  They are on the same
  6250. > -> network.  Anyone else notice this?  Anything negative about it?  How do you
  6251. > -> stop 98 from listening to those routes?
  6252. > 
  6253. > 
  6254. > If you find out let me know too.  We've got a customer which has two
  6255. > RAS servers on their LAN (one is a 3com and the other Ascend) and
  6256. > their routing tables show the same thing.  The odd part is after
  6257. > awhile they won't be able toget through their default gateway
  6258. > (the Ascend unit) unless either they delete the route with the 1000
  6259. > metric or reboot their machine.  It's driving them crazy. Of course
  6260. > they use the Ascend to dial into us and into the Internet.
  6261. > 
  6262.  
  6263. You cant fix 98.. It listens to ICMP router advertisments.. You can
  6264. however stop the HARC from adertising itself via the command
  6265. "DISABLE ICMP ROUTER_ADVERTISE"
  6266.  
  6267.  
  6268. +--------------------------------------+
  6269. Mike Wronski (mike@coredump.ae.usr.com)
  6270. 3Com Network Systems Engineer
  6271.  
  6272.  
  6273.  
  6274. -
  6275.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6276.  with "unsubscribe usr-tc" in the body of the message.
  6277.  For information on digests or retrieving files and old messages send
  6278.  "help" to the same address.  Do not use quotes in your message.
  6279.  
  6280.  
  6281. -------------------------------------------------------------------------------
  6282.  
  6283. From: Scott Trautman <scottt@corp.gdinet.com>
  6284. Subject: (usr-tc) Finding that no-answering modem
  6285. Date: 10 Oct 1999 09:29:42 -0500
  6286.  
  6287. Went for months without a no-answer modem, now seem to have had a real spate
  6288. of them.
  6289. Fortunately it does seem that simply resetting the modem in TCM 'fixes' it,
  6290. but we don't
  6291. fix it before we get a call or two of 'no answer modem'. 
  6292.  
  6293. Anyone running any kind of script/log analysis that finds no answer modems?
  6294.  
  6295. I also had a fellow from 3Com show me an "Autoresponse" trick to reset the
  6296. modem automatically
  6297. if it got a no answer. I've since forgotten how, and not really sure if
  6298. that'd really do the
  6299. trick anyway. And it would be mighty tedious to set all our ports for this.
  6300.  
  6301. SMT
  6302.  
  6303. Scott M. Trautman               800-482-4638
  6304. Global Dialog Internet          608-240-4638,4637fax
  6305. 2810 Crossroads, STE LL2         scott@gdinet.com
  6306. Madison WI 53718                    http://www.gdinet.com
  6307.  
  6308. -
  6309.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6310.  with "unsubscribe usr-tc" in the body of the message.
  6311.  For information on digests or retrieving files and old messages send
  6312.  "help" to the same address.  Do not use quotes in your message.
  6313.  
  6314.  
  6315. -------------------------------------------------------------------------------
  6316.  
  6317. From: "Greg Owens" <gowens@magnolia-net.com>
  6318. Subject: Re: (usr-tc) Finding that no-answering modem
  6319. Date: 10 Oct 1999 09:59:51 -0500
  6320.  
  6321. Where in the TCM are you going to reset it successfully. Seems like every
  6322. time we have a hung (no answer) modem we have to unplug the card and and
  6323. plug it back in. Also is there a way to busy out 1 or 2 modems in a card
  6324. (DSP)  from the TCM. Thanks
  6325. Greg Owens
  6326. Magnolia Internet Services
  6327. http://www.magnolia-net.com
  6328. ----- Original Message -----
  6329. Sent: Sunday, October 10, 1999 9:29 AM
  6330.  
  6331.  
  6332. > Went for months without a no-answer modem, now seem to have had a real
  6333. spate
  6334. > of them.
  6335. > Fortunately it does seem that simply resetting the modem in TCM 'fixes'
  6336. it,
  6337. > but we don't
  6338. > fix it before we get a call or two of 'no answer modem'.
  6339. >
  6340. > Anyone running any kind of script/log analysis that finds no answer
  6341. modems?
  6342. >
  6343. > I also had a fellow from 3Com show me an "Autoresponse" trick to reset the
  6344. > modem automatically
  6345. > if it got a no answer. I've since forgotten how, and not really sure if
  6346. > that'd really do the
  6347. > trick anyway. And it would be mighty tedious to set all our ports for
  6348. this.
  6349. >
  6350. > SMT
  6351. >
  6352. > Scott M. Trautman               800-482-4638
  6353. > Global Dialog Internet          608-240-4638,4637fax
  6354. > 2810 Crossroads, STE LL2         scott@gdinet.com
  6355. > Madison WI 53718                    http://www.gdinet.com
  6356. >
  6357. > -
  6358. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6359. >  with "unsubscribe usr-tc" in the body of the message.
  6360. >  For information on digests or retrieving files and old messages send
  6361. >  "help" to the same address.  Do not use quotes in your message.
  6362. >
  6363.  
  6364.  
  6365. -
  6366.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6367.  with "unsubscribe usr-tc" in the body of the message.
  6368.  For information on digests or retrieving files and old messages send
  6369.  "help" to the same address.  Do not use quotes in your message.
  6370.  
  6371.  
  6372. -------------------------------------------------------------------------------
  6373.  
  6374. From: Scott Trautman <scottt@corp.gdinet.com>
  6375. Subject: RE: (usr-tc) Finding that no-answering modem
  6376. Date: 10 Oct 1999 11:57:40 -0500
  6377.  
  6378. Simply highlighting the modem, actions/commands, software reset.
  6379.  
  6380. Busy out modems? Simple. At the T1; before it hits the modem.
  6381. Highlight your T1 card, actions/commands, select the TRUNK # corresponding
  6382. to the problem modem, and do a soft or hard busy out of the DS0.
  6383.  
  6384. THIS much I DO know! :^)
  6385.  
  6386. USED to have to pull the card on stuck modems, but hasn't seemed to be the
  6387. case since the last modem code update quite some time ago. Also doesn't
  6388. seem to happen nearly as often either.
  6389.  
  6390. SMT
  6391.  
  6392. > -----Original Message-----
  6393. > From: Greg Owens [mailto:gowens@magnolia-net.com]
  6394. > Sent: Sunday, October 10, 1999 10:00 AM
  6395. > To: usr-tc@lists.xmission.com
  6396. > Subject: Re: (usr-tc) Finding that no-answering modem
  6397. > 
  6398. > 
  6399. > Where in the TCM are you going to reset it successfully. 
  6400. > Seems like every
  6401. > time we have a hung (no answer) modem we have to unplug the 
  6402. > card and and
  6403. > plug it back in. Also is there a way to busy out 1 or 2 
  6404. > modems in a card
  6405. > (DSP)  from the TCM. Thanks
  6406. > Greg Owens
  6407. > Magnolia Internet Services
  6408. > http://www.magnolia-net.com
  6409. > ----- Original Message -----
  6410. > From: Scott Trautman <scottt@corp.gdinet.com>
  6411. > To: <usr-tc@lists.xmission.com>
  6412. > Sent: Sunday, October 10, 1999 9:29 AM
  6413. > Subject: (usr-tc) Finding that no-answering modem
  6414. > 
  6415. > 
  6416. > > Went for months without a no-answer modem, now seem to have 
  6417. > had a real
  6418. > spate
  6419. > > of them.
  6420. > > Fortunately it does seem that simply resetting the modem in 
  6421. > TCM 'fixes'
  6422. > it,
  6423. > > but we don't
  6424. > > fix it before we get a call or two of 'no answer modem'.
  6425. > >
  6426. > > Anyone running any kind of script/log analysis that finds no answer
  6427. > modems?
  6428. > >
  6429. > > I also had a fellow from 3Com show me an "Autoresponse" 
  6430. > trick to reset the
  6431. > > modem automatically
  6432. > > if it got a no answer. I've since forgotten how, and not 
  6433. > really sure if
  6434. > > that'd really do the
  6435. > > trick anyway. And it would be mighty tedious to set all our 
  6436. > ports for
  6437. > this.
  6438. > >
  6439. > > SMT
  6440. > >
  6441. > > Scott M. Trautman               800-482-4638
  6442. > > Global Dialog Internet          608-240-4638,4637fax
  6443. > > 2810 Crossroads, STE LL2         scott@gdinet.com
  6444. > > Madison WI 53718                    http://www.gdinet.com
  6445. > >
  6446. > > -
  6447. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6448. > >  with "unsubscribe usr-tc" in the body of the message.
  6449. > >  For information on digests or retrieving files and old 
  6450. > messages send
  6451. > >  "help" to the same address.  Do not use quotes in your message.
  6452. > >
  6453. > 
  6454. > 
  6455. > -
  6456. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6457. >  with "unsubscribe usr-tc" in the body of the message.
  6458. >  For information on digests or retrieving files and old messages send
  6459. >  "help" to the same address.  Do not use quotes in your message.
  6460. > 
  6461.  
  6462. -
  6463.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6464.  with "unsubscribe usr-tc" in the body of the message.
  6465.  For information on digests or retrieving files and old messages send
  6466.  "help" to the same address.  Do not use quotes in your message.
  6467.  
  6468.  
  6469. -------------------------------------------------------------------------------
  6470.  
  6471. From: "Greg Owens" <gowens@magnolia-net.com>
  6472. Subject: Re: (usr-tc) Finding that no-answering modem
  6473. Date: 10 Oct 1999 16:50:43 -0500
  6474.  
  6475. Hmmm...That is exactly how I have been trying to reset the modem yet it has
  6476. never worked. Not even once..And it happens to us at least once a month
  6477. lately when it used to never!!  We are running the latest code also...Oh
  6478. well...Thanks for the tip on how to busy out the modem. At least now if it
  6479. happens I won't have to drive to the office and reset it I will just busy it
  6480. out till morning.
  6481. Greg Owens
  6482. Magnolia Internet Services
  6483. http://www.magnolia-net.com
  6484. ----- Original Message -----
  6485. Sent: Sunday, October 10, 1999 11:57 AM
  6486.  
  6487.  
  6488. > Simply highlighting the modem, actions/commands, software reset.
  6489. >
  6490. > Busy out modems? Simple. At the T1; before it hits the modem.
  6491. > Highlight your T1 card, actions/commands, select the TRUNK # corresponding
  6492. > to the problem modem, and do a soft or hard busy out of the DS0.
  6493. >
  6494. > THIS much I DO know! :^)
  6495. >
  6496. > USED to have to pull the card on stuck modems, but hasn't seemed to be the
  6497. > case since the last modem code update quite some time ago. Also doesn't
  6498. > seem to happen nearly as often either.
  6499. >
  6500. > SMT
  6501. >
  6502. > > -----Original Message-----
  6503. > > From: Greg Owens [mailto:gowens@magnolia-net.com]
  6504. > > Sent: Sunday, October 10, 1999 10:00 AM
  6505. > > To: usr-tc@lists.xmission.com
  6506. > > Subject: Re: (usr-tc) Finding that no-answering modem
  6507. > >
  6508. > >
  6509. > > Where in the TCM are you going to reset it successfully.
  6510. > > Seems like every
  6511. > > time we have a hung (no answer) modem we have to unplug the
  6512. > > card and and
  6513. > > plug it back in. Also is there a way to busy out 1 or 2
  6514. > > modems in a card
  6515. > > (DSP)  from the TCM. Thanks
  6516. > > Greg Owens
  6517. > > Magnolia Internet Services
  6518. > > http://www.magnolia-net.com
  6519. > > ----- Original Message -----
  6520. > > From: Scott Trautman <scottt@corp.gdinet.com>
  6521. > > To: <usr-tc@lists.xmission.com>
  6522. > > Sent: Sunday, October 10, 1999 9:29 AM
  6523. > > Subject: (usr-tc) Finding that no-answering modem
  6524. > >
  6525. > >
  6526. > > > Went for months without a no-answer modem, now seem to have
  6527. > > had a real
  6528. > > spate
  6529. > > > of them.
  6530. > > > Fortunately it does seem that simply resetting the modem in
  6531. > > TCM 'fixes'
  6532. > > it,
  6533. > > > but we don't
  6534. > > > fix it before we get a call or two of 'no answer modem'.
  6535. > > >
  6536. > > > Anyone running any kind of script/log analysis that finds no answer
  6537. > > modems?
  6538. > > >
  6539. > > > I also had a fellow from 3Com show me an "Autoresponse"
  6540. > > trick to reset the
  6541. > > > modem automatically
  6542. > > > if it got a no answer. I've since forgotten how, and not
  6543. > > really sure if
  6544. > > > that'd really do the
  6545. > > > trick anyway. And it would be mighty tedious to set all our
  6546. > > ports for
  6547. > > this.
  6548. > > >
  6549. > > > SMT
  6550. > > >
  6551. > > > Scott M. Trautman               800-482-4638
  6552. > > > Global Dialog Internet          608-240-4638,4637fax
  6553. > > > 2810 Crossroads, STE LL2         scott@gdinet.com
  6554. > > > Madison WI 53718                    http://www.gdinet.com
  6555. > > >
  6556. > > > -
  6557. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6558. > > >  with "unsubscribe usr-tc" in the body of the message.
  6559. > > >  For information on digests or retrieving files and old
  6560. > > messages send
  6561. > > >  "help" to the same address.  Do not use quotes in your message.
  6562. > > >
  6563. > >
  6564. > >
  6565. > > -
  6566. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6567. > >  with "unsubscribe usr-tc" in the body of the message.
  6568. > >  For information on digests or retrieving files and old messages send
  6569. > >  "help" to the same address.  Do not use quotes in your message.
  6570. > >
  6571. >
  6572. > -
  6573. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6574. >  with "unsubscribe usr-tc" in the body of the message.
  6575. >  For information on digests or retrieving files and old messages send
  6576. >  "help" to the same address.  Do not use quotes in your message.
  6577. >
  6578.  
  6579.  
  6580. -
  6581.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6582.  with "unsubscribe usr-tc" in the body of the message.
  6583.  For information on digests or retrieving files and old messages send
  6584.  "help" to the same address.  Do not use quotes in your message.
  6585.  
  6586.  
  6587. -------------------------------------------------------------------------------
  6588.  
  6589. From: John Campbell <sparky@roava.net>
  6590. Subject: (usr-tc) 3COM ISP List
  6591. Date: 11 Oct 1999 08:33:35 -0400
  6592.  
  6593.     USR/3-COM use to have a list on the Internet that had a searchable list of
  6594. ISP's that used there equipment. Anyone know of that site address...
  6595. Looking for Atlanta, ISP that uses X2/V.90 Standards to reference a
  6596. customer to who is moving there.. Thanks
  6597.  
  6598. John Campbell
  6599. mailto:sparky@roava.net
  6600. http://www.roava.net
  6601.  
  6602. -
  6603.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6604.  with "unsubscribe usr-tc" in the body of the message.
  6605.  For information on digests or retrieving files and old messages send
  6606.  "help" to the same address.  Do not use quotes in your message.
  6607.  
  6608.  
  6609. -------------------------------------------------------------------------------
  6610.  
  6611. From: Kevin Benton <s1kevin@tims.net>
  6612. Subject: Re: (usr-tc) Finding that no-answering modem
  6613. Date: 11 Oct 1999 09:48:40 -0400 (EDT)
  6614.  
  6615. On Sun, 10 Oct 1999, Greg Owens wrote:
  6616.  
  6617. > Hmmm...That is exactly how I have been trying to reset the modem yet it has
  6618. > never worked. Not even once..And it happens to us at least once a month
  6619. > lately when it used to never!!  We are running the latest code also...Oh
  6620. > well...Thanks for the tip on how to busy out the modem. At least now if it
  6621. > happens I won't have to drive to the office and reset it I will just busy it
  6622. > out till morning.
  6623.  
  6624. Just be sure that you don't get fast busies as a result of your modem busy
  6625. out.  Some configurations of T1's don't properly communicate with the CO
  6626. (often a lack of capability at the switch because of telco config when
  6627. ordered).  We had a problem where an AT&T 5-ESS set to National mode was
  6628. not configured properly to accept channel busy outs at the T1 level
  6629. because the 5-ESS National Mode configuration was set not to accept it
  6630. properly at the switch.  Our end was quite happy to send the signaling on
  6631. the PRI, but the switch didn't accept it.  Hence, we had to get them to
  6632. reconfigure the lines in custom mode and things worked just fine.  At
  6633. other times, the telco changes other options without properly notifying
  6634. customers so that they can test everything which got changed (such as our
  6635. problem with lost callers after 29 seconds which was due to the fact that
  6636. the telco enabled a feature which we didn't have to test against at
  6637. initial installation, nor were we warned that it could be implemented
  6638. later).
  6639.  
  6640. Seeing that you didn't know how to busy out a modem (as many people don't
  6641. when they're getting started and even some more experienced users), you
  6642. may want to consider contacting your 3Com sales rep about getting the free
  6643. Total Control training classes which 3Com is offering.  A lot of good
  6644. information is disseminated there in the one day course.  It's actually
  6645. worth paying for but 3Com is offering it for free so that customers get to
  6646. know what the TC Chassis' are capable of.  It's not a show up and throw up
  6647. class.  It's a real nitty gritty training session for TCM users.  I went
  6648. to 3Com Rolling Meadows for two days to take their one day class and even
  6649. though I had the same class both days, I walked away with new information
  6650. on both days.
  6651.  
  6652. Kevin Benton
  6653. SOTA Technologies
  6654.  
  6655. E-Mail:  s1kevin@tims.net
  6656. Web:     http://users.sota-oh.com/~s1kevin/
  6657. Unsolicited advertisements processing fee: $50 subject to change without notice
  6658.  
  6659.  
  6660. -
  6661.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6662.  with "unsubscribe usr-tc" in the body of the message.
  6663.  For information on digests or retrieving files and old messages send
  6664.  "help" to the same address.  Do not use quotes in your message.
  6665.  
  6666.  
  6667. -------------------------------------------------------------------------------
  6668.  
  6669. From: Marlo Montanaro <marlo@monmouth.com>
  6670. Subject: RE: (usr-tc) Does Windows98 listen on RIP?!?
  6671. Date: 11 Oct 1999 10:30:03 -0400
  6672.  
  6673.  
  6674. ------ =_NextPart_000_01BF13D3.9516A660
  6675. Content-Type: text/plain; charset="us-ascii"
  6676. Content-Transfer-Encoding: 7bit
  6677.  
  6678. Something we want to do????
  6679.  
  6680. Marlo
  6681.  
  6682.  
  6683. -----Original Message-----
  6684. Sent:    Saturday, October 09, 1999 11:19 PM
  6685.  
  6686. On Fri, 8 Oct 1999, Jeff Binkley wrote:
  6687.  
  6688. > -> I noticed today that alot of the Windows98 machines show our total controls
  6689. > -> hubs in their routing tables as a default route!  Its got a high metric of
  6690. > -> 1000, and the "true" default route is set as 1, but I was curious about how
  6691. > -> Windows98 even knew about our total control hubs.  They are on the same
  6692. > -> network.  Anyone else notice this?  Anything negative about it?  How do you
  6693. > -> stop 98 from listening to those routes?
  6694. > 
  6695. > 
  6696. > If you find out let me know too.  We've got a customer which has two
  6697. > RAS servers on their LAN (one is a 3com and the other Ascend) and
  6698. > their routing tables show the same thing.  The odd part is after
  6699. > awhile they won't be able toget through their default gateway
  6700. > (the Ascend unit) unless either they delete the route with the 1000
  6701. > metric or reboot their machine.  It's driving them crazy. Of course
  6702. > they use the Ascend to dial into us and into the Internet.
  6703. > 
  6704.  
  6705. You cant fix 98.. It listens to ICMP router advertisments.. You can
  6706. however stop the HARC from adertising itself via the command
  6707. "DISABLE ICMP ROUTER_ADVERTISE"
  6708.  
  6709.  
  6710. +--------------------------------------+
  6711. Mike Wronski (mike@coredump.ae.usr.com)
  6712. 3Com Network Systems Engineer
  6713.  
  6714.  
  6715.  
  6716. -
  6717.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6718.  with "unsubscribe usr-tc" in the body of the message.
  6719.  For information on digests or retrieving files and old messages send
  6720.  "help" to the same address.  Do not use quotes in your message.
  6721.  
  6722. ------ =_NextPart_000_01BF13D3.9516A660
  6723. Content-Type: application/ms-tnef
  6724. Content-Transfer-Encoding: base64
  6725.  
  6726. eJ8+IgQOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
  6727. b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA2AEAAAEAAAARAAAAAwAAMAIAAAAL
  6728. AA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAEHVzci10Y0BsaXN0cy54
  6729. bWlzc2lvbi5jb20AU01UUAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAB4AAjABAAAABQAA
  6730. AFNNVFAAAAAAHgADMAEAAAAaAAAAdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQAAAAMAFQwBAAAA
  6731. AwD+DwYAAAAeAAEwAQAAABwAAAAndXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbScAAgELMAEAAAAf
  6732. AAAAU01UUDpVU1ItVENATElTVFMuWE1JU1NJT04uQ09NAAADAAA5AAAAAAsAQDoBAAAAAwBxOgAA
  6733. AAAeAPZfAQAAABoAAAB1c3ItdGNAbGlzdHMueG1pc3Npb24uY29tAAAAAgH3XwEAAABRAAAAAAAA
  6734. AIErH6S+oxAZnW4A3QEPVAIAAAAQdXNyLXRjQGxpc3RzLnhtaXNzaW9uLmNvbQBTTVRQAHVzci10
  6735. Y0BsaXN0cy54bWlzc2lvbi5jb20AAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAALI
  6736. aQEEgAEALQAAAFJFOiAodXNyLXRjKSBEb2VzIFdpbmRvd3M5OCBsaXN0ZW4gb24gUklQPyE/AB0O
  6737. AQWAAwAOAAAAzwcKAAsACgAeAAMAAQAXAQEggAMADgAAAM8HCgALAAoAHQA1AAEASAEBCYABACEA
  6738. AABBNjY5Q0U4RERDN0ZEMzExQkFFMjUyNTQwMEUxMjQwQQA+BwEDkAYABAkAACEAAAALAAIAAQAA
  6739. AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAsPxFG/UTvwEeAHAA
  6740. AQAAAC0AAABSRTogKHVzci10YykgRG9lcyBXaW5kb3dzOTggbGlzdGVuIG9uIFJJUD8hPwAAAAAC
  6741. AXEAAQAAABYAAAABvxP1GzyNzmmnf9wR07riUlQA4SQKAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A
  6742. HwwBAAAAEwAAAG1hcmxvQG1vbm1vdXRoLmNvbQAAAwAGENzSFRkDAAcQXwUAAB4ACBABAAAAZQAA
  6743. AFNPTUVUSElOR1dFV0FOVFRPRE8/Pz8/TUFSTE8tLS0tLU9SSUdJTkFMTUVTU0FHRS0tLS0tRlJP
  6744. TTpNSUtFV1JPTlNLSVNNVFA6TVdST05TS0lAQ09SRURVTVBBRVVTUkNPTVMAAAAAAgEJEAEAAADT
  6745. BQAAzwUAAPwIAABMWkZ1ZHL6qHcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcThwKDAFAO9nBycTIP
  6746. 9iZ9CoAIyCA7CW8yNWY1AoAKgXVjAFALA2MDAEELYG5nMTAzM+kMYGxuAiBlC6YGAANwhQ/AaAuA
  6747. ZyB3ZRdgAwBwBUB0byBkbz//GEEVQAuAFjAYkgXQCsAJAJ8KogqEGcoLMBiQMzYBQKcVEAFAEUBv
  6748. dAWQdBCEUDE2IC0cok8FEGcPC4AHQAXQB5BzYWdlPxyjGYYbtBuBCxMbtmktGDE0NAFAGJAxODBH
  6749. AUAM0CBDYiBGA2E6RQyDYg/gTWlrF4BXAwNgAIBraSBbU02gVFA6bXcixEAFoQEJgHVtcC5hZS6Q
  6750. dXNyLgWgbV0ZhV8hcAZgAjAh1wYQdAhwZCBheSwgTxvwb2KRBJAgMDknQDE5KDCJKBAxOiggIFBN
  6751. JWcMVG8h1yThLXRjQIEYkHN0cy54bQQBjmkCICUSJWh1Ymob4UEh11JlOiAoKjQpaCBEbweRVwuA
  6752. GCB3sHM5OCAqognwIAIg4QfwSVA/IRhwHl8fabcbBAu2GZNPA6AhkGknQC8u8CdhKBMnQEoBESBC
  6753. 4QuAa2xleRdgG7Ih0E0ZmT4ckDZASSAWAHT8aWMJgBfhJxEX4A+ABUD/B0AbwC9wNIAXECKRLocA
  6754. wfMXIQeRc2gusC9wCHAX4d8BkAMgBaACMANgbA9ANfjeaCxgBCALgDhSaQXAA2C+dTbQF0EBkTTg
  6755. BCBhPaE7GBABEGEV4AVAPNJlIeYgNoAq0CBnOAE98Bcg3GdoOTAPwAUQYzghNem/FZAg0CdAAHA3
  6756. EThxIjrwfQpQIj4MPDA5sQ/APbIxvSdAYjzwNoEXoAQgYwhxfwhgPaEG4ERROeE16S54Zfp2L1Fr
  6757. FiAH4EVkOi874/ouPvBUOHA1AArAF4AvgZ84Yh2wB4A16RYgdHcFsOJrSaFBbnkWEUcwOyDvF4A2
  6758. tDeBBAA/TEMXFBYgmmcm0GlHUEVVaXRN0fZIOfEYICBMgAxwNfgqwPhvcCAu4QNSLwU9ExgAfRcQ
  6759. b0zxPpNNwDXmU55J/zSAUEFRkC6BSDEFQDTgBUAvB4BHgTnxF/BvSaFXZX4nTvE/VETgUSEHgAXA
  6760. dz8XIA9wO+A9wUvhNeZSQXsF8A+wckdQD6BKVTyhTLxBTi2ATJJDcT3wMyUhb0GXG8A4cAXAQQTw
  6761. CfBk/y4AQaE15jx/PYI500qWTYL3FXBJpC9wZDcQCrFPYT2h9wGABJA15mFYgTTgOFI1Ab0CICcF
  6762. QCegRVFjIm8d0P0X0Wg80T/RXmQ+Fk6xB9B7JyA15ig4Yl00KiADAHT/LgBn8D2BBCBegFzjY1MB
  6763. AP9WEWMzQwUD8BcQOFNBQjXm+0AGXqFlBuA4AV5kOUVJodU/ECcEIGQFEHY9Ezhwo1HQBQBhenlJ
  6764. oE80gP8FoAhwD7Bd6TUAJOBp1GeF/xfyBzE8MRfxRTJBsXJTOGJuSQIwBJEPwC5TnBmEWa1VUWMX
  6765. siAQeFFhLkmgDz8QLwVZARgASUNNULM+hAXAYWRaQTbQcweA/wIwKuBJoHV1GYQ54UdBBcDDUSM4
  6766. YkhBUkNRlHgw73hjFzJPgA+wbDSAbnA98A84YiUhA4Fd1SJESVMQQUJMRXdkUk9VgFRFUl9BRFZ/
  6767. QJJUfkBFIhmPCisco9uBj4KeK4AUImsoKxAigOskHyUhKYAUMwhQUdAHwKtL4wYAeS8xbQQgRRVw
  6768. dxihYkaIvwoeNSlxZ+Fz/zwBBQFkAXJzKlInQA+wQbFfA5Fu4AtwAyAX8SIAwGp3BbAYIARgQCsK
  6769. gAVqhCL/iuoqNEJwPEREMARwNQA4NX8HgR2ydCUhgAWxC4ACEHL/AMA20C+BL4FyAB3QKsFsRL9A
  6770. IUdAFzIgED2DVaJsNxCfkiVDgl3GQhA4cGxwQnD/czVgQ3gwbkAdkUmhLiA2ovlw03F1G8E8I1BB
  6771. bTGSOwuJFBIBAJywAAMAEBAAAAAAAwAREAEAAAADAIAQ/////0AABzCA5JgV9RO/AUAACDCA5JgV
  6772. 9RO/AQsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA
  6773. AAAAEIUAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAABShQAAtw0AAAMABIAIIAYAAAAAAMAA
  6774. AAAAAABGAAAAAAGFAAAAAAAAHgAFgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4w
  6775. AAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAA
  6776. EYUAAAAAAAADAAiACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ACYAIIAYAAAAAAMAAAAAA
  6777. AABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEA
  6778. AAAAAAAAHgALgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAA
  6779. AFJFOiAAAAAAAwANNP03AAAiZQ==
  6780.  
  6781. ------ =_NextPart_000_01BF13D3.9516A660--
  6782.  
  6783.  
  6784. -
  6785.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6786.  with "unsubscribe usr-tc" in the body of the message.
  6787.  For information on digests or retrieving files and old messages send
  6788.  "help" to the same address.  Do not use quotes in your message.
  6789.  
  6790.  
  6791. -------------------------------------------------------------------------------
  6792.  
  6793. From: Scott Trautman <scottt@corp.gdinet.com>
  6794. Subject: RE: (usr-tc) Finding that no-answering modem
  6795. Date: 11 Oct 1999 09:46:55 -0500
  6796.  
  6797. I concur on the training; I know in our area there are plans to have
  6798. a session in the near future. Even those that think they "know it all", will
  6799. learn some new tricks. I've been fortunate to get to know George Ebert at
  6800. 3Com,
  6801. and he's been a fantastic resource for those types of things. It'll be nice,
  6802. though,
  6803. to retain more than say 30% from those valuable informal sessions; as well
  6804. as
  6805. send a couple of our Admins to the training.
  6806.  
  6807. I had suggested perhaps a TC users conference would be cool; something like
  6808. an ISPCON
  6809. but specifically for TC units. 1-2 days with conferences on many of the
  6810. subjects we talk
  6811. about here. There's a lot more "under the hood" than many of us ever get to,
  6812. and I know
  6813. we could, if we knew about them, use a lot more features than we currently
  6814. do.
  6815.  
  6816. A few examples....I'm sure y'all can think of many more.....
  6817.  
  6818. - T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
  6819. ratio's, etc.)
  6820. - Monitoring/auto responder
  6821. - Getting more mileage out of TCM
  6822. - Advanced SNMP
  6823. - Authentication/Accounting
  6824. - Dialup user issues (monitoring, filtering, setup, etc.)
  6825. - HiperARC setup
  6826. - TC "future" - VoIP, ?
  6827. - Hardware planning (so how many DSP's can I put in a dual 45a chassis? How
  6828. much juice do quads take?)
  6829. - Getting to the bottom of modem compatibility issues
  6830. - Making a mobile or other artwork out of old TC cards you can't seem to
  6831. sell for squat...:^)
  6832.  
  6833. I'd pay $1-2k for such a day-2day conference.....Just thoughts....
  6834.  
  6835. SMT
  6836.  
  6837. -
  6838.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6839.  with "unsubscribe usr-tc" in the body of the message.
  6840.  For information on digests or retrieving files and old messages send
  6841.  "help" to the same address.  Do not use quotes in your message.
  6842.  
  6843.  
  6844. -------------------------------------------------------------------------------
  6845.  
  6846. From: Jeff Mcadams <jeffm@iglou.com>
  6847. Subject: (usr-tc) TC user's conference?
  6848. Date: 11 Oct 1999 11:07:44 -0400
  6849.  
  6850. Thus spake Scott Trautman
  6851. >I concur on the training; I know in our area there are plans to have a
  6852. >session in the near future. Even those that think they "know it all",
  6853. >will learn some new tricks. I've been fortunate to get to know George
  6854. >Ebert at 3Com, and he's been a fantastic resource for those types of
  6855. >things. It'll be nice, though, to retain more than say 30% from those
  6856. >valuable informal sessions; as well as send a couple of our Admins to
  6857. >the training.
  6858.  
  6859. Indeed...those informal training sessions are good...and they're a good
  6860. way for 3Com folks to get feedback from customers (there were about 8 of
  6861. us at the one in Louisville...there was some good give and take there).
  6862. I just wish they could get 3Com folks to come that aren't in the sales
  6863. side of things...while the sales folks are good (Tom Goodman and George
  6864. Ebert are indeed wonderful resources), it seems that, within 3Com,
  6865. feedback doesn't really seem to be taken seriously from the sales folks.
  6866. :/  Unfortunately, this seems to be the case in many companies...not
  6867. just 3Com.
  6868.  
  6869. >I had suggested perhaps a TC users conference would be cool; something
  6870. >like an ISPCON but specifically for TC units. 1-2 days with conferences
  6871. >on many of the subjects we talk about here. There's a lot more "under
  6872. >the hood" than many of us ever get to, and I know we could, if we knew
  6873. >about them, use a lot more features than we currently do.
  6874.  
  6875. Neat idea...I'd certainly go for it (if I could get my company to pay
  6876. for the travel ;)
  6877.  
  6878. >A few examples....I'm sure y'all can think of many more.....
  6879.  
  6880. >- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
  6881. >ratio's, etc.)
  6882.  
  6883. Good...unfortunately, there's not much in the way of tools in the TC's
  6884. to do trouble resolution on these things.  More control over the
  6885. CSU/DSU's would be *very* useful here.
  6886.  
  6887. >- Getting more mileage out of TCM
  6888.  
  6889. Hrmm...unfortunately, I've pretty much given up on TCM...you can only
  6890. get so much mileage out of a VW bug.  :/  I'm beginning to write some
  6891. Perl5 (with SNMP module) scripts to interact with the TC's...  I'm not
  6892. quite to the point of putting TCM type functionality together...I'm
  6893. starting with scripts to fulfull specific functions...I may, eventually,
  6894. get to that point.
  6895.  
  6896. >- Advanced SNMP
  6897.  
  6898. Isn't that a contradiction in terms?  ;)
  6899.  
  6900. >- Dialup user issues (monitoring, filtering, setup, etc.)
  6901. >- Getting to the bottom of modem compatibility issues
  6902.  
  6903. I see these two kinda being two different sides of the same coin...most
  6904. specifically, I would benefit from a seriously in depth seminar about
  6905. modem technology...unfortunately, I'm not sure how generally useful this
  6906. would be as I'm thinking about actually getting down into the encoding
  6907. of the data into the analog waveform and stuff.  :)
  6908.  
  6909. >- HiperARC setup
  6910. >- TC "future" - VoIP, ?
  6911.  
  6912. Indeed...this would be nice...especially to give feedback to 3Com
  6913. through it.  Where do you/I/we want this platform to go?  I sent a nice
  6914. long letter to the list the other day and got very little feedback...one
  6915. person agreeing with me (in private, asked for his message not to be
  6916. publically posted), and one person sort of disagreeing with me in
  6917. public.  :)
  6918.  
  6919. >I'd pay $1-2k for such a day-2day conference.....Just thoughts....
  6920.  
  6921. Unfortunately, that'd probably be out of our price range...but I would
  6922. be interested in such a conference in idea at least.  :)
  6923. -- 
  6924. Jeff McAdams                            Email: jeffm@iglou.com
  6925. Head Network Administrator              Voice: (502) 966-3848
  6926. IgLou Internet Services                        (800) 436-4456
  6927.  
  6928. -
  6929.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6930.  with "unsubscribe usr-tc" in the body of the message.
  6931.  For information on digests or retrieving files and old messages send
  6932.  "help" to the same address.  Do not use quotes in your message.
  6933.  
  6934.  
  6935. -------------------------------------------------------------------------------
  6936.  
  6937. From: "Eric Billeter" <ebilleter@cableone.net>
  6938. Subject: RE: (usr-tc) Finding that no-answering modem
  6939. Date: 11 Oct 1999 10:12:02 -0700
  6940.  
  6941. This is a multi-part message in MIME format.
  6942.  
  6943. ------=_NextPart_000_F0A0_01BF13D1.1083F800
  6944. Content-Type: text/plain;
  6945.     charset="iso-8859-1"
  6946. Content-Transfer-Encoding: 7bit
  6947.  
  6948. Here is a perl script which I have been using for several weeks.
  6949.  
  6950. It will look at all the DSP modems in the chassis and will create a web page
  6951. which lists the modems, calls taken, calls failed, and the failure ratio.
  6952. It also uses NTsendmail to alert you if there are modems which match failure
  6953. criteria.  I use 15% failure rates with at least 20 failures.  It will send
  6954. you an email telling you the pop/chassis , slot and modems which are
  6955. failing.  It also generates a web page which you can refer to.  I have the
  6956. script running every 30 minutes.
  6957.  
  6958. Thanks
  6959. Eric Billeter
  6960. Internet Engineer
  6961. Cable One, Inc.
  6962.  
  6963. eric.billeter@cableone.net
  6964. 602-364-6462
  6965.  
  6966. -----Original Message-----
  6967. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman
  6968. Sent: Sunday, October 10, 1999 7:30 AM
  6969.  
  6970.  
  6971. Went for months without a no-answer modem, now seem to have had a real spate
  6972. of them.
  6973. Fortunately it does seem that simply resetting the modem in TCM 'fixes' it,
  6974. but we don't
  6975. fix it before we get a call or two of 'no answer modem'.
  6976.  
  6977. Anyone running any kind of script/log analysis that finds no answer modems?
  6978.  
  6979. I also had a fellow from 3Com show me an "Autoresponse" trick to reset the
  6980. modem automatically
  6981. if it got a no answer. I've since forgotten how, and not really sure if
  6982. that'd really do the
  6983. trick anyway. And it would be mighty tedious to set all our ports for this.
  6984.  
  6985. SMT
  6986.  
  6987. Scott M. Trautman               800-482-4638
  6988. Global Dialog Internet          608-240-4638,4637fax
  6989. 2810 Crossroads, STE LL2         scott@gdinet.com
  6990. Madison WI 53718                    http://www.gdinet.com
  6991.  
  6992. -
  6993.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6994.  with "unsubscribe usr-tc" in the body of the message.
  6995.  For information on digests or retrieving files and old messages send
  6996.  "help" to the same address.  Do not use quotes in your message.
  6997.  
  6998. ------=_NextPart_000_F0A0_01BF13D1.1083F800
  6999. Content-Type: application/octet-stream;
  7000.     name="badmodems.pl"
  7001. Content-Transfer-Encoding: quoted-printable
  7002. Content-Disposition: attachment;
  7003.     filename="badmodems.pl"
  7004.  
  7005. #!c:\perl\bin
  7006.  
  7007. # badmodems.pl
  7008. #
  7009.  
  7010.  
  7011. use SNMP_Session;
  7012. use BER;
  7013. use Socket;
  7014. use strict;
  7015. use NTsendmail;
  7016.  
  7017.  
  7018. $ENV{"NTsendmail"} =3D "mail.mydomain.com";    #Enter your Mail Server =
  7019. Here
  7020. my $mail =3D new NTsendmail;                   #Do not change this line
  7021.  
  7022. %snmpget::OIDS =3D (  'OID1' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.24',
  7023.                     'OID2' =3D>  '1.3.6.1.4.1.429.1.6.10.1.1.4',
  7024.                  );
  7025. my $community=3D"public";                      # Your community String
  7026. my $router =3D "127.0.0.1";                    # IP Address of NMC
  7027. my $outputfile =3D "modem-fail.htm";           # File to output to=20
  7028. my $location =3D "My Pop";                     # Location Descriptor
  7029. my $sender =3D "tech\@mydomain.com";           # Mail From=20
  7030. my $recipient =3D "tech\@mydomain.com";        # Mail To
  7031. my $subject =3D "$location modems";            # Mail Subject
  7032. my $message;
  7033.  
  7034. my @callok;
  7035. my @callfail;
  7036. my($sysName,$sysUptime,$interfaces,$value1,$value2) =3D
  7037.     =
  7038. snmpgettable($router,$community,'OID1'),snmpgettable2($router,$community,=
  7039. 'OID2');
  7040. my $i;
  7041. my $slot;
  7042. my $modem;
  7043. my $callratio;
  7044. my $modemcount =3D @callok + 0 ;
  7045. open FILE, ">$outputfile";
  7046. #print FILE "Content-Type: text/html\n\n";=09
  7047. print FILE  "<HEAD><TITLE>Modem Report for $location</TITLE></HEAD>\n";
  7048. print FILE  "<BODY><HTML>\n";
  7049. print FILE "<TABLE>";
  7050.  
  7051. print FILE "<TR><TD width=3D10%>Slot</TD><TD width=3D5%></TD><TD =
  7052. width=3D15%>Modem<TD width=3D20%></TD><TD width=3D15%>Incoming</TD><TD =
  7053. width=3D25%>Failed</TD><TD>Faiure</TD></TR>";
  7054. print FILE =
  7055. "<TR><TD></TD><TD></TD><TD><TD></TD><TD>Calls</TD><TD>Calls</TD><TD>Ratio=
  7056. </TD></TR>";=20
  7057. print FILE "<TR></TR>";
  7058.  
  7059. # In the following lines you can configure the failure ratios and the =
  7060. thresholds for alerts.
  7061.  
  7062.  
  7063. for $i ( 1 .. $modemcount) {
  7064.  
  7065.     $slot=3Dint (($i-1)/24)+1;
  7066.     $modem=3Dint ($i-(($slot-1)*24));
  7067.  
  7068.         if ((@callfail[$i-1] > 20) and (@callfail[$i-1] > =
  7069. (@callok[$i-1])*.15)) {
  7070.         print FILE  "<TR bgcolor=3D#ff6600><TD>";
  7071.         $message=3D"$message $location Slot $slot Modem $modem is failing\n";
  7072.  
  7073.         }
  7074.  
  7075.         else {
  7076.         print FILE "<TR><TD>";
  7077.         }
  7078.  
  7079.     print FILE  "SLOT</TD><TD> ",$slot,"</TD><TD>";
  7080.     print FILE  "     Modem</TD><TD> ",$modem,"</TD><TD>";
  7081.     print FILE  @callok[$i-1],"</TD><TD>",@callfail[$i-1],;
  7082.  
  7083. if (@callfail[$i-1]=3D=3D0 and @callok[$i-1]>=3D0) {
  7084. $callratio=3D0;
  7085. }
  7086.  
  7087. else {
  7088. $callratio=3D(@callfail[$i-1]/(@callfail[$i-1]+@callok[$i-1]))*100;
  7089. }
  7090.     print FILE  "\n</TD><TD>";
  7091. my $width=3D5;
  7092. my $prec=3D2;
  7093. printf FILE "%5.2f\n", $callratio;
  7094. print FILE "</TD></TR>";
  7095.     }
  7096.  
  7097. print FILE  "</TABLE></html></body>";
  7098. close FILE;
  7099. =09
  7100.     if (length $message > 0){
  7101.     print "mail sent";
  7102.     $mail->send($sender, $recipient, $subject, $message);=20
  7103.     }
  7104.     else {
  7105.     print "OK";
  7106.  
  7107.     }
  7108. exit(0);
  7109.  
  7110. sub snmpgettable{
  7111.   my($host,$community,$var) =3D @_;
  7112.   my($next_oid,$enoid,$orig_oid,=20
  7113.      $response, $bindings, $binding, $value, $inoid,$outoid,
  7114.      $upoid,$oid,@table,$tempo);
  7115.   die "Unknown SNMP var $var\n"=20
  7116.     unless $snmpget::OIDS{$var};
  7117.  =20
  7118.   $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  7119.   $enoid=3D$orig_oid;
  7120.   srand();
  7121.   my $session =3D SNMP_Session->open ($host ,
  7122.                                  $community,=20
  7123.                                  161);
  7124.   for(;;)  {
  7125.     if ($session->getnext_request_response(($enoid))) {
  7126.       $response =3D $session->pdu_buffer;
  7127.       ($bindings) =3D $session->decode_get_response ($response);
  7128.       ($binding,$bindings) =3D decode_sequence ($bindings);
  7129.       ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
  7130.       # quit once we are outside the table
  7131.       last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
  7132.       $tempo =3D pretty_print($value);
  7133.      #   print $tempo,"\n";
  7134.     push @callfail, $tempo;
  7135.         $value1=3D$value1 + $tempo ;
  7136.  
  7137.       $tempo=3D~s/\t/ /g;
  7138.       $tempo=3D~s/\n/ /g;
  7139.       $tempo=3D~s/^\s+//;
  7140.       $tempo=3D~s/\s+$//;
  7141.       push @table, $tempo;
  7142.     } else {
  7143.       die "No answer from $ARGV[0]\n";
  7144.     }
  7145.     $enoid=3D$next_oid;
  7146.   }
  7147.   $session->close ();=20
  7148. if( $value1 eq ''){$value1 =3D 0 };
  7149. #     print "$value1\n";
  7150.   return (@table);
  7151. }
  7152. sub snmpgettable2{
  7153.   my($host,$community,$var) =3D @_;
  7154.   my($next_oid,$enoid,$orig_oid,=20
  7155.      $response, $bindings, $binding, $value, $inoid,$outoid,
  7156.      $upoid,$oid,@table,$tempo);
  7157.   die "Unknown SNMP var $var\n"=20
  7158.     unless $snmpget::OIDS{$var};
  7159.  =20
  7160.   $orig_oid =3D encode_oid(split /\./, $snmpget::OIDS{$var});
  7161.   $enoid=3D$orig_oid;
  7162.   srand();
  7163.   my $session =3D SNMP_Session->open ($host ,
  7164.                                  $community,=20
  7165.                                  161);
  7166.   for(;;)  {
  7167.     if ($session->getnext_request_response(($enoid))) {
  7168.       $response =3D $session->pdu_buffer;
  7169.       ($bindings) =3D $session->decode_get_response ($response);
  7170.       ($binding,$bindings) =3D decode_sequence ($bindings);
  7171.       ($next_oid,$value) =3D decode_by_template ($binding, "%O%@");
  7172.       # quit once we are outside the table
  7173.       last unless BER::encoded_oid_prefix_p($orig_oid,$next_oid);
  7174.       $tempo =3D pretty_print($value);
  7175. #       print $tempo,"\n";
  7176.     push @callok, $tempo;
  7177.       $value2=3D$value2 + $tempo ;
  7178.       $tempo=3D~s/\t/ /g;
  7179.       $tempo=3D~s/\n/ /g;
  7180.       $tempo=3D~s/^\s+//;
  7181.       $tempo=3D~s/\s+$//;
  7182.       push @table, $tempo;
  7183.     } else {
  7184.       die "No answer from $ARGV[0]\n";
  7185.     }
  7186.     $enoid=3D$next_oid;
  7187.   }
  7188.   $session->close ();=20
  7189. if( $value2 eq ''){$value2 =3D 0 };
  7190. #     print "$value2\n";
  7191.   return (@table);
  7192. }
  7193.  
  7194.  
  7195. ------=_NextPart_000_F0A0_01BF13D1.1083F800--
  7196.  
  7197.  
  7198.  
  7199.  
  7200. -
  7201.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7202.  with "unsubscribe usr-tc" in the body of the message.
  7203.  For information on digests or retrieving files and old messages send
  7204.  "help" to the same address.  Do not use quotes in your message.
  7205.  
  7206.  
  7207. -------------------------------------------------------------------------------
  7208.  
  7209. From: Jeff Mcadams <jeffm@iglou.com>
  7210. Subject: (usr-tc) SNMP limitations on NMC's
  7211. Date: 11 Oct 1999 13:43:52 -0400
  7212.  
  7213. What's the plan on fixing the NMC's so they'll handle SNMP PDU's larger
  7214. than 1500 bytes (or whatever it is around that number that is the actual
  7215. limitation)?  Now that I'm starting to write some SNMP scripting...I'm
  7216. *quickly* running into this limitation, and its gonna really suck to
  7217. have to code around it.
  7218.  
  7219. Can the NMC's IP stack not reassemble or something?  Isn't that terribly
  7220. broken?
  7221. -- 
  7222. Jeff McAdams                            Email: jeffm@iglou.com
  7223. Head Network Administrator              Voice: (502) 966-3848
  7224. IgLou Internet Services                        (800) 436-4456
  7225.  
  7226. -
  7227.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7228.  with "unsubscribe usr-tc" in the body of the message.
  7229.  For information on digests or retrieving files and old messages send
  7230.  "help" to the same address.  Do not use quotes in your message.
  7231.  
  7232.  
  7233. -------------------------------------------------------------------------------
  7234.  
  7235. From: Mike Andrews <mandrews@bit0.com>
  7236. Subject: Re: (usr-tc) SNMP limitations on NMC's
  7237. Date: 11 Oct 1999 15:44:49 -0400 (EDT)
  7238.  
  7239. I thought they fixed this in NMC 6.x...?
  7240.  
  7241. In 5.x and earlier it would actually kill the whole IP stack on the card
  7242. and you had to reboot the NMC.  I thought I tested 6.1.7 and it didn't
  7243. kill the card anymore.
  7244.  
  7245. (They finally fixed all those off-by-one Radius accounting bugs too.)
  7246.  
  7247. Anyway, the reason I have that ma_snmp.pm wrapper around all my SNMP code
  7248. is because there's a workaround for that bug in there, among other
  7249. things...  It takes the array of OIDs you're going to query and breaks
  7250. them up into chunks small enough to make the card happy, then reassembles
  7251. the responses.
  7252.  
  7253.  
  7254. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  7255. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  7256. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  7257. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  7258.  
  7259. On Mon, 11 Oct 1999, Jeff Mcadams wrote:
  7260.  
  7261. > What's the plan on fixing the NMC's so they'll handle SNMP PDU's larger
  7262. > than 1500 bytes (or whatever it is around that number that is the actual
  7263. > limitation)?  Now that I'm starting to write some SNMP scripting...I'm
  7264. > *quickly* running into this limitation, and its gonna really suck to
  7265. > have to code around it.
  7266. > 
  7267. > Can the NMC's IP stack not reassemble or something?  Isn't that terribly
  7268. > broken?
  7269.  
  7270.  
  7271.  
  7272. -
  7273.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7274.  with "unsubscribe usr-tc" in the body of the message.
  7275.  For information on digests or retrieving files and old messages send
  7276.  "help" to the same address.  Do not use quotes in your message.
  7277.  
  7278.  
  7279. -------------------------------------------------------------------------------
  7280.  
  7281. From: Jeff Mcadams <jeffm@iglou.com>
  7282. Subject: Re: (usr-tc) SNMP limitations on NMC's
  7283. Date: 11 Oct 1999 15:54:48 -0400
  7284.  
  7285. Thus spake Mike Andrews
  7286. >I thought they fixed this in NMC 6.x...?
  7287.  
  7288. >In 5.x and earlier it would actually kill the whole IP stack on the card
  7289. >and you had to reboot the NMC.  I thought I tested 6.1.7 and it didn't
  7290. >kill the card anymore.
  7291.  
  7292. Well...it is fixed so that it doesn't kill the Agent anymore.  But they
  7293. didn't fix it enough so that you can get responses to your large get.
  7294. Your get still times out...but at least you don't have to go back and
  7295. reboot the card (which is particularly difficult to do when you don't
  7296. have an functional SNMP Agent on it) now.
  7297.  
  7298. Oh...and it didn't seem to kill the whole IP stack for me...the card was
  7299. still pingable...just no SNMP response from it...like it killed the
  7300. agent.
  7301.  
  7302. >Anyway, the reason I have that ma_snmp.pm wrapper around all my SNMP code
  7303. >is because there's a workaround for that bug in there, among other
  7304. >things...  It takes the array of OIDs you're going to query and breaks
  7305. >them up into chunks small enough to make the card happy, then reassembles
  7306. >the responses.
  7307.  
  7308. Yeah...I've been writing code today to do essentially that...at least
  7309. proof of concept code so I know how to do it...maybe now that I've
  7310. worked out the details of what I have to do to work around this
  7311. crazyness I can get back to actually writing useful code.  :)
  7312. -- 
  7313. Jeff McAdams                            Email: jeffm@iglou.com
  7314. Head Network Administrator              Voice: (502) 966-3848
  7315. IgLou Internet Services                        (800) 436-4456
  7316.  
  7317. -
  7318.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7319.  with "unsubscribe usr-tc" in the body of the message.
  7320.  For information on digests or retrieving files and old messages send
  7321.  "help" to the same address.  Do not use quotes in your message.
  7322.  
  7323.  
  7324. -------------------------------------------------------------------------------
  7325.  
  7326. From: "Wayne Barber" <barberw@tidewater.net>
  7327. Subject: (usr-tc) Sega Dreamcast
  7328. Date: 11 Oct 1999 16:01:31 -0400
  7329.  
  7330. Has anyone else tried to connect the new Dreamcast game machine to their TC
  7331. hub? It seems to be similar to a web TV box, but it should work from the
  7332. local mail server as well as dial-up. I have a new customer who is having
  7333. trouble getting connected and the error messages on my end show garbled
  7334. passwords or last letter dropped. It sounds similar to a previous problem,
  7335. but I don't recall the solution.
  7336.  
  7337. We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and 5.5.5
  7338. on NMC.
  7339.  
  7340. Thanks,
  7341. Wayne Barber
  7342. Coastal Telco Services
  7343.  
  7344.  
  7345. -
  7346.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7347.  with "unsubscribe usr-tc" in the body of the message.
  7348.  For information on digests or retrieving files and old messages send
  7349.  "help" to the same address.  Do not use quotes in your message.
  7350.  
  7351.  
  7352. -------------------------------------------------------------------------------
  7353.  
  7354. From: "Jamie Orzechowski" <mhz@ripnet.com>
  7355. Subject: Re: (usr-tc) Sega Dreamcast
  7356. Date: 11 Oct 1999 16:16:54 -0400
  7357.  
  7358. the Dreamcast uses and HCF modem ... whoopie!
  7359.  
  7360. Wonder if it's upgradable to later drivers??
  7361.  
  7362. ----- Original Message -----
  7363. Sent: Monday, October 11, 1999 4:01 PM
  7364.  
  7365.  
  7366. > Has anyone else tried to connect the new Dreamcast game machine to their
  7367. TC
  7368. > hub? It seems to be similar to a web TV box, but it should work from the
  7369. > local mail server as well as dial-up. I have a new customer who is having
  7370. > trouble getting connected and the error messages on my end show garbled
  7371. > passwords or last letter dropped. It sounds similar to a previous problem,
  7372. > but I don't recall the solution.
  7373. >
  7374. > We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and
  7375. 5.5.5
  7376. > on NMC.
  7377. >
  7378. > Thanks,
  7379. > Wayne Barber
  7380. > Coastal Telco Services
  7381. >
  7382. >
  7383. > -
  7384. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7385. >  with "unsubscribe usr-tc" in the body of the message.
  7386. >  For information on digests or retrieving files and old messages send
  7387. >  "help" to the same address.  Do not use quotes in your message.
  7388. >
  7389.  
  7390.  
  7391. -
  7392.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7393.  with "unsubscribe usr-tc" in the body of the message.
  7394.  For information on digests or retrieving files and old messages send
  7395.  "help" to the same address.  Do not use quotes in your message.
  7396.  
  7397.  
  7398. -------------------------------------------------------------------------------
  7399.  
  7400. From: Richard Lorbieski <richard@alpha1.net>
  7401. Subject: Re: (usr-tc) Sega Dreamcast
  7402. Date: 11 Oct 1999 15:19:15 -0500
  7403.  
  7404. I had to add 1 comma at the end of the number.
  7405.  
  7406. Wayne Barber wrote:
  7407. > 
  7408. > Has anyone else tried to connect the new Dreamcast game machine to their TC
  7409. > hub? It seems to be similar to a web TV box, but it should work from the
  7410. > local mail server as well as dial-up. I have a new customer who is having
  7411. > trouble getting connected and the error messages on my end show garbled
  7412. > passwords or last letter dropped. It sounds similar to a previous problem,
  7413. > but I don't recall the solution.
  7414. > 
  7415. > We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and 5.5.5
  7416. > on NMC.
  7417. > 
  7418. > Thanks,
  7419. > Wayne Barber
  7420. > Coastal Telco Services
  7421. > 
  7422. > -
  7423. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7424. >  with "unsubscribe usr-tc" in the body of the message.
  7425. >  For information on digests or retrieving files and old messages send
  7426. >  "help" to the same address.  Do not use quotes in your message.
  7427.  
  7428. -- 
  7429.  
  7430. Richard Lorbieski - richard@alpha1.net
  7431. Chief Technical Officer - Senior System Administrator
  7432. Alpha1 Internet  http://www.alpha1.net
  7433. 409.731.8236  - 877.4.alpha1 (877.425.7421)
  7434.  
  7435. -
  7436.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7437.  with "unsubscribe usr-tc" in the body of the message.
  7438.  For information on digests or retrieving files and old messages send
  7439.  "help" to the same address.  Do not use quotes in your message.
  7440.  
  7441.  
  7442. -------------------------------------------------------------------------------
  7443.  
  7444. From: "Andrew:PC Global, Inc." <andrew@pcglobal.net>
  7445. Subject: Re: (usr-tc) Sega Dreamcast
  7446. Date: 11 Oct 1999 13:22:22 -0700
  7447.  
  7448. just curious as to why someone would attach this Dreamcast to a TC unit...
  7449. Thanks
  7450. Andrew
  7451. ****************************
  7452. ----- Original Message -----
  7453. Sent: Monday, October 11, 1999 1:19 PM
  7454.  
  7455.  
  7456. I had to add 1 comma at the end of the number.
  7457.  
  7458. Wayne Barber wrote:
  7459. >
  7460. > Has anyone else tried to connect the new Dreamcast game machine to their
  7461. TC
  7462. > hub? It seems to be similar to a web TV box, but it should work from the
  7463. > local mail server as well as dial-up. I have a new customer who is having
  7464. > trouble getting connected and the error messages on my end show garbled
  7465. > passwords or last letter dropped. It sounds similar to a previous problem,
  7466. > but I don't recall the solution.
  7467. >
  7468. > We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and
  7469. 5.5.5
  7470. > on NMC.
  7471. >
  7472. > Thanks,
  7473. > Wayne Barber
  7474. > Coastal Telco Services
  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. Richard Lorbieski - richard@alpha1.net
  7485. Chief Technical Officer - Senior System Administrator
  7486. Alpha1 Internet  http://www.alpha1.net
  7487. 409.731.8236  - 877.4.alpha1 (877.425.7421)
  7488.  
  7489. -
  7490.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7491.  with "unsubscribe usr-tc" in the body of the message.
  7492.  For information on digests or retrieving files and old messages send
  7493.  "help" to the same address.  Do not use quotes in your message.
  7494.  
  7495.  
  7496.  
  7497. -
  7498.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7499.  with "unsubscribe usr-tc" in the body of the message.
  7500.  For information on digests or retrieving files and old messages send
  7501.  "help" to the same address.  Do not use quotes in your message.
  7502.  
  7503.  
  7504. -------------------------------------------------------------------------------
  7505.  
  7506. From: Marius Strom <marius@alpha1.net>
  7507. Subject: Re: (usr-tc) Sega Dreamcast
  7508. Date: 11 Oct 1999 15:36:19 -0500 (CDT)
  7509.  
  7510. It can dialup for Internet Access.. We, the ISP's, reap the benefits.
  7511. *chuckle*
  7512.  
  7513. -- 
  7514. Marius Strom <marius@alpha1.net>
  7515. Professional Geek/Unix System Administrator
  7516. Alpha1 Internet <http://www.alpha1.net>
  7517. http://www.marius.org/marius.pgp 0x5645C228
  7518.  
  7519. In theory, there is no difference between theory and practice...
  7520. ...In practice, there is a big difference.
  7521.  
  7522.  
  7523. On Mon, 11 Oct 1999, Andrew:PC Global, Inc. wrote:
  7524.  
  7525. > just curious as to why someone would attach this Dreamcast to a TC unit...
  7526. > Thanks
  7527. > Andrew
  7528. > ****************************
  7529. > ----- Original Message -----
  7530. > From: Richard Lorbieski <richard@alpha1.net>
  7531. > To: <usr-tc@lists.xmission.com>
  7532. > Sent: Monday, October 11, 1999 1:19 PM
  7533. > Subject: Re: (usr-tc) Sega Dreamcast
  7534. > 
  7535. > 
  7536. > I had to add 1 comma at the end of the number.
  7537. > 
  7538. > Wayne Barber wrote:
  7539. > >
  7540. > > Has anyone else tried to connect the new Dreamcast game machine to their
  7541. > TC
  7542. > > hub? It seems to be similar to a web TV box, but it should work from the
  7543. > > local mail server as well as dial-up. I have a new customer who is having
  7544. > > trouble getting connected and the error messages on my end show garbled
  7545. > > passwords or last letter dropped. It sounds similar to a previous problem,
  7546. > > but I don't recall the solution.
  7547. > >
  7548. > > We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and
  7549. > 5.5.5
  7550. > > on NMC.
  7551. > >
  7552. > > Thanks,
  7553. > > Wayne Barber
  7554. > > Coastal Telco Services
  7555. > >
  7556. > > -
  7557. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7558. > >  with "unsubscribe usr-tc" in the body of the message.
  7559. > >  For information on digests or retrieving files and old messages send
  7560. > >  "help" to the same address.  Do not use quotes in your message.
  7561. > 
  7562. > --
  7563. > 
  7564. > Richard Lorbieski - richard@alpha1.net
  7565. > Chief Technical Officer - Senior System Administrator
  7566. > Alpha1 Internet  http://www.alpha1.net
  7567. > 409.731.8236  - 877.4.alpha1 (877.425.7421)
  7568. > 
  7569. > -
  7570. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7571. >  with "unsubscribe usr-tc" in the body of the message.
  7572. >  For information on digests or retrieving files and old messages send
  7573. >  "help" to the same address.  Do not use quotes in your message.
  7574. > 
  7575. > 
  7576. > 
  7577. > -
  7578. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7579. >  with "unsubscribe usr-tc" in the body of the message.
  7580. >  For information on digests or retrieving files and old messages send
  7581. >  "help" to the same address.  Do not use quotes in your message.
  7582. > 
  7583.  
  7584.  
  7585. -
  7586.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7587.  with "unsubscribe usr-tc" in the body of the message.
  7588.  For information on digests or retrieving files and old messages send
  7589.  "help" to the same address.  Do not use quotes in your message.
  7590.  
  7591.  
  7592. -------------------------------------------------------------------------------
  7593.  
  7594. From: Steve Rivera <sales@wrca.net>
  7595. Subject: (usr-tc) ???? Analog Application Set up
  7596. Date: 11 Oct 1999 18:12:10 -0400
  7597.  
  7598. I have a chassis that I am preparing for analog application.
  7599. I have set the quad modems to use the nic card thru config TCM.
  7600. Are there any  answering parameters that must be config'd?
  7601.  
  7602. Here's the chassis Config:
  7603.  
  7604. Chassis w/ Dual 70A
  7605. NMC card w/ nic
  7606. Netserver PRI w/ nic
  7607. 15- Quad Digital Modems
  7608. ....................................................
  7609. Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA)
  7610. sales@wrca.net  v-732-833-2111 pgr-732-325-1092
  7611.  
  7612. WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card)
  7613. Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink
  7614. IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit
  7615. MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More
  7616.  
  7617.  
  7618.  
  7619.  
  7620.       
  7621.  
  7622.  
  7623.  
  7624.  
  7625.  
  7626. -
  7627.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7628.  with "unsubscribe usr-tc" in the body of the message.
  7629.  For information on digests or retrieving files and old messages send
  7630.  "help" to the same address.  Do not use quotes in your message.
  7631.  
  7632.  
  7633. -------------------------------------------------------------------------------
  7634.  
  7635. From: Steve Rivera <sales@wrca.net>
  7636. Subject: RE: (usr-tc) Quad cards not answering analog calls
  7637. Date: 11 Oct 1999 18:17:07 -0400
  7638.  
  7639. Once you set the Line Interface to NIC,:
  7640. Do you need to represent the DTE (Terminal) Connection via the cable (4in1) 
  7641. to raise the DTR Signal?
  7642.  
  7643. At 12:45 PM 10/06/1999 -0300, you wrote:
  7644.  
  7645. >I assume you are using POTS lines.  If you have the Line Interface Options
  7646. >for the modem set to nic rather than pritdm or t1tdm that should be all you
  7647. >have to do to in order to make the modem pick up the line.
  7648. >
  7649. >On Wednesday, October 06, 1999 1:42 PM, Network Administrator
  7650. >[SMTP:netadmin@seidata.com] wrote:
  7651. > > I am using the v.34 analog/digital Quad cards (v.5.6.7) with the Netserver
  7652. > > card. I had six existing cards using the same version of software. I
  7653. >recently
  7654. > > added 8 new lines to this box and two quad cards. The quads will not
  7655. >answer
  7656. > > incoming calls. I have checked each modem individually as well as tried
  7657. >other
  7658. > > cards and re-flashed the code to the cards. If anyone has any idea what
  7659. >may
  7660. > > be the problem, please reply.
  7661. > >
  7662. > >
  7663. > > -Cheryl
  7664. > > Seidata Network Services, Inc.
  7665. > > <http://www.seidata.com>
  7666. > >
  7667. >
  7668. >
  7669. >
  7670. >-
  7671. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7672. >  with "unsubscribe usr-tc" in the body of the message.
  7673. >  For information on digests or retrieving files and old messages send
  7674. >  "help" to the same address.  Do not use quotes in your message.
  7675.  
  7676.  
  7677. -
  7678.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7679.  with "unsubscribe usr-tc" in the body of the message.
  7680.  For information on digests or retrieving files and old messages send
  7681.  "help" to the same address.  Do not use quotes in your message.
  7682.  
  7683.  
  7684. -------------------------------------------------------------------------------
  7685.  
  7686. From: Brian Elfert <brian@citilink.com>
  7687. Subject: Re: (usr-tc) Sega Dreamcast
  7688. Date: 11 Oct 1999 18:48:50 -0500 (CDT)
  7689.  
  7690.  
  7691.  
  7692. On Mon, 11 Oct 1999, Jamie Orzechowski wrote:
  7693.  
  7694. > the Dreamcast uses and HCF modem ... whoopie!
  7695. > 
  7696. > Wonder if it's upgradable to later drivers??
  7697.  
  7698. I would assume the drivers are on the Internet CD.  I wonder if Sega will
  7699. be upgrading the CDs, and at what price?
  7700.  
  7701. Brian
  7702.  
  7703.  
  7704. -
  7705.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7706.  with "unsubscribe usr-tc" in the body of the message.
  7707.  For information on digests or retrieving files and old messages send
  7708.  "help" to the same address.  Do not use quotes in your message.
  7709.  
  7710.  
  7711. -------------------------------------------------------------------------------
  7712.  
  7713. From: K Mitchell <mitch@keyconn.net>
  7714. Subject: Re: (usr-tc) Sega Dreamcast
  7715. Date: 11 Oct 1999 19:40:33 -0400
  7716.  
  7717. At 04:01 PM 10/11/99 -0400, "Wayne Barber" <barberw@tidewater.net> wrote:
  7718. >Has anyone else tried to connect the new Dreamcast game machine to their TC
  7719. >hub? It seems to be similar to a web TV box, but it should work from the
  7720. >local mail server as well as dial-up. I have a new customer who is having
  7721. >trouble getting connected and the error messages on my end show garbled
  7722. >passwords or last letter dropped. It sounds similar to a previous problem,
  7723. >but I don't recall the solution.
  7724. >
  7725. >We are running 1.2.60 on the DSP, 5.9.9 on quads, 4.1.59-6 on ARC and 5.5.5
  7726. >on NMC.
  7727.  
  7728. This issue was visited awhile back and, as I recall, the solution works for
  7729. WebTV as well as Dreamcast units;
  7730. set ppp authentication_preference PAP
  7731. set ppp receive_authentication PAP
  7732. change Framed-Compression in Radius from None to  Van-Jacobsen-TCP-IP
  7733.  
  7734. HTH,
  7735. -- 
  7736. Kirk Mitchell-General Manager        mitch@keyconn.net
  7737. Keystone Connect                     Unlock Your World
  7738. Altoona, PA   814-941-5000      http://www.keyconn.net
  7739.  
  7740.  
  7741. -
  7742.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7743.  with "unsubscribe usr-tc" in the body of the message.
  7744.  For information on digests or retrieving files and old messages send
  7745.  "help" to the same address.  Do not use quotes in your message.
  7746.  
  7747.  
  7748. -------------------------------------------------------------------------------
  7749.  
  7750. From: Mike Andrews <mandrews@bit0.com>
  7751. Subject: (usr-tc) arcs and ospf
  7752. Date: 11 Oct 1999 21:21:16 -0400 (EDT)
  7753.  
  7754. I've been having a really bizarre problem off and on the last week or two.
  7755. Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  7756. routing table loses all OSPF routes, and the ARC stops announcing its
  7757. routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  7758. most of the time (not all the time) rebooting the ARC will.
  7759.  
  7760. One thing that seemed to trigger it was rebooting some of our Ciscos...
  7761. and since that happens so infrequently (not rebooted since going to ARC
  7762. 4.2 in fact) it's hard to track down.  I don't know which one exactly,
  7763. maybe our AS border router dying is what threw it off.
  7764.  
  7765. It also happened last night when I installed a Cisco Catalyst 2924XL
  7766. (replacing an old 10BaseT hub, finally!) which didn't involve rebooting
  7767. the Ciscos, but involved having them unreachable for a minute or two as
  7768. cables were switched and Spanning Tree did its thing...
  7769.  
  7770. I have another ARC with no modems on the same LAN (for testing) and it
  7771. initially did the same thing, but now I'm having trouble reproducing it.
  7772. When it was screwed up one night, it fixed itself overnight, but it
  7773. obviously took hours to do, which kinda defeats the purpose of OSPF.
  7774.  
  7775. I know this is really vague, but problem is, I don't really know where to
  7776. start looking for this, because I didn't document very well what my
  7777. current OSPF settings are.  (A bulk-config-to-ASCII utility would be
  7778. REALLY HELPFUL HERE :)  I could reverse-engineer HARM and try to get a
  7779. dump of that part of the config via SNMP somehow, I guess, but... yuck.
  7780. Anyway, I'm also not a real in-depth OSPF guru yet.
  7781.  
  7782. Has anyone seen anything like this before or know of any particular
  7783. settings that I might want to check?  This is driving me nuts (not to
  7784. mention my customers) and I'm not sure where to start.
  7785.  
  7786. A quick look at some of the 'show' screens -- this is with the card
  7787. actually routing correctly:
  7788.  
  7789. > show ospf global
  7790.  
  7791. GLOBAL OSPF SETTINGS
  7792. Router ID:                                 206.240.130.12
  7793. Administrative Status:                     ENABLED
  7794. OSPF Version Number:                       2
  7795. Area Border Router Status:                 DISABLED
  7796. Autonomous System Border Router Status:    ENABLED
  7797. Type-of-service (TOS) Support:             OFF
  7798. External LSDB Limit:                       -1
  7799. Multicast Extensions Support:              OFF
  7800. Exit Overflow Interval:                    0
  7801. Router's Support for OSPF Demand Routing:  OFF
  7802. OSPF Traps:                                DISABLED
  7803.  
  7804. > show ospf area 0.0.0.0
  7805.  
  7806. OSPF AREA SETTINGS
  7807. Area ID:                                   0.0.0.0
  7808. OSPF Area Type:                            TRANSIT
  7809. Area Status:                               ENABLED
  7810.  
  7811. > list ospf recei
  7812.  
  7813. OSPF Receive Policies:
  7814.  Address/Mask       Action            Routing Preference
  7815.  199.077.100.000/23 Accept            Pref1
  7816.  206.240.130.000/23 Accept            Pref1
  7817.  208.006.168.000/22 Accept            Pref1
  7818.  
  7819. > list ospf send
  7820.  
  7821. OSPF Send Policies:
  7822. Source  Address/Mask       Action
  7823. LOCAL   199.077.100.000/23 Advertise
  7824. LOCAL   206.240.130.000/23 Advertise
  7825. LOCAL   208.006.168.000/22 Advertise
  7826.  
  7827. > list ospf int
  7828. OSPF INTERFACE TABLE
  7829. IfIpAddr/IfInd  AreaId          IfType AdminStat IfState      Metric
  7830. 206.240.130.12  0.0.0.0         BC     ENABLED   OtherDsgRtr  10
  7831.  
  7832.  
  7833.  
  7834. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  7835. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  7836. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  7837. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  7838.  
  7839.  
  7840. -
  7841.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7842.  with "unsubscribe usr-tc" in the body of the message.
  7843.  For information on digests or retrieving files and old messages send
  7844.  "help" to the same address.  Do not use quotes in your message.
  7845.  
  7846.  
  7847. -------------------------------------------------------------------------------
  7848.  
  7849. From: K Mitchell <mitch@keyconn.net>
  7850. Subject: RE: (usr-tc) Finding that no-answering modem
  7851. Date: 11 Oct 1999 21:18:01 -0400
  7852.  
  7853. At 10:12 AM 10/11/99 -0700, Eric wrote:
  7854. >Here is a perl script which I have been using for several weeks.
  7855. >
  7856. >It will look at all the DSP modems in the chassis and will create a web page
  7857. >which lists the modems, calls taken, calls failed, and the failure ratio.
  7858. >It also uses NTsendmail to alert you if there are modems which match failure
  7859. >criteria.  I use 15% failure rates with at least 20 failures.  It will send
  7860. >you an email telling you the pop/chassis , slot and modems which are
  7861. >failing.  It also generates a web page which you can refer to.  I have the
  7862. >script running every 30 minutes.
  7863.  
  7864. I get a;
  7865. c:\winnt\system32>perl c:\queue\badmodems.pl
  7866. Can't locate SNMP_Session.pm in @INC (@INC contains: C:/Perl/lib C
  7867. \queue\badmodems.pl line 7.
  7868. BEGIN failed--compilation aborted at c:\queue\badmodems.pl line 7.
  7869.  
  7870. Where do I get a copy of SNMP_Session.pm? How do you have it scheduled?
  7871.  
  7872. Thanks,
  7873. -- 
  7874. Kirk Mitchell-General Manager        mitch@keyconn.net
  7875. Keystone Connect                     Unlock Your World
  7876. Altoona, PA   814-941-5000      http://www.keyconn.net
  7877.  
  7878.  
  7879. -
  7880.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7881.  with "unsubscribe usr-tc" in the body of the message.
  7882.  For information on digests or retrieving files and old messages send
  7883.  "help" to the same address.  Do not use quotes in your message.
  7884.  
  7885.  
  7886. -------------------------------------------------------------------------------
  7887.  
  7888. From: Mike Andrews <mandrews@bit0.com>
  7889. Subject: RE: (usr-tc) Finding that no-answering modem
  7890. Date: 11 Oct 1999 21:26:02 -0400 (EDT)
  7891.  
  7892. On Mon, 11 Oct 1999, K Mitchell wrote:
  7893.  
  7894. > Where do I get a copy of SNMP_Session.pm?
  7895.  
  7896. Quick answer: Install MRTG :)
  7897.  
  7898. (The library is available separately, but MRTG is indispensable enough on
  7899. its own...)
  7900.  
  7901.  
  7902. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  7903. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  7904. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  7905. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  7906.  
  7907.  
  7908. -
  7909.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7910.  with "unsubscribe usr-tc" in the body of the message.
  7911.  For information on digests or retrieving files and old messages send
  7912.  "help" to the same address.  Do not use quotes in your message.
  7913.  
  7914.  
  7915. -------------------------------------------------------------------------------
  7916.  
  7917. From: Jeff Mcadams <jeffm@iglou.com>
  7918. Subject: Re: (usr-tc) arcs and ospf
  7919. Date: 11 Oct 1999 21:35:09 -0400
  7920.  
  7921. Thus spake Mike Andrews
  7922. >I've been having a really bizarre problem off and on the last week or two.
  7923. >Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  7924. >routing table loses all OSPF routes, and the ARC stops announcing its
  7925. >routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  7926. >most of the time (not all the time) rebooting the ARC will.
  7927.  
  7928. >One thing that seemed to trigger it was rebooting some of our Ciscos...
  7929. >and since that happens so infrequently (not rebooted since going to ARC
  7930. >4.2 in fact) it's hard to track down.  I don't know which one exactly,
  7931. >maybe our AS border router dying is what threw it off.
  7932.  
  7933. Hrmm...something to check...not sure if this will have any
  7934. signficance...is the settings/values for the designated router on your
  7935. ethernet(s) when this happens.  I suspect your Cisco's were the
  7936. designated routers initially, and when they went away, one of your Arc's
  7937. got promoted to that...who knows what happened when your cisco's came
  7938. back.
  7939.  
  7940. When I was first playing with 4.2.29, I noticed a little bit of odd
  7941. behavior with the Arc's wrt designated routers...but then when I set up
  7942. a test lab environment for it, I couldn't reproduce it.  What I saw was
  7943. then I brought the Arc up on 4.2.29, it would take over the designated
  7944. router functionality somehow...which would be against the OSPF spec, but
  7945. possible for it to happen.  I haven't played with OSPF on the arc's
  7946. since then in any great depth...I've got one up and running on 4.2.32 at
  7947. this point, but haven't really done anything with it.
  7948.  
  7949. Maybe this will give you an idea of something to look at.  Switching
  7950. designated routers is definitely something you want to avoid if at all
  7951. possible because its going to cause a resyncronization of LSA databases
  7952. and a recalc of most (all?) of the shortest path first
  7953. calculations...so...this *can* cause up to a couple of minutes of your
  7954. routing being hosed as potentially every router on your network recalcs
  7955. its OSPF routes.
  7956. -- 
  7957. Jeff McAdams                            Email: jeffm@iglou.com
  7958. Head Network Administrator              Voice: (502) 966-3848
  7959. IgLou Internet Services                        (800) 436-4456
  7960.  
  7961. -
  7962.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7963.  with "unsubscribe usr-tc" in the body of the message.
  7964.  For information on digests or retrieving files and old messages send
  7965.  "help" to the same address.  Do not use quotes in your message.
  7966.  
  7967.  
  7968. -------------------------------------------------------------------------------
  7969.  
  7970. From: "Greg Owens" <gowens@magnolia-net.com>
  7971. Subject: Re: (usr-tc) Finding that no-answering modem
  7972. Date: 11 Oct 1999 20:37:47 -0500
  7973.  
  7974. Kevin...Thanks for the info....Not sure how it will affect us as we don't
  7975. have PRI's (not avaliable in our area...Yes we're very rural) We have to
  7976. C-T1's If there is an issue of fast busies with them let me know.
  7977.     3Com sales rep.  Haven't heard from him in nearly 2  years yet we have
  7978. bought around $50,000 worth of 3Com equipment ( I realize not much compared
  7979. to alot you guys but for a small upstart not chump change either) I will
  7980. check with Soulunet tomorrow and see if they know anything about the
  7981. training. Sounds like it we could really benifit from it. Good Info...Many
  7982. Thanks If any one knows the 3Com rep for the Southern Arkansas region I
  7983. would love to meet him/her
  7984.  
  7985. Greg Owens
  7986. Magnolia Internet Services
  7987. http://www.magnolia-net.com
  7988. ----- Original Message -----
  7989. Sent: Monday, October 11, 1999 8:48 AM
  7990.  
  7991.  
  7992. > On Sun, 10 Oct 1999, Greg Owens wrote:
  7993. >
  7994. > > Hmmm...That is exactly how I have been trying to reset the modem yet it
  7995. has
  7996. > > never worked. Not even once..And it happens to us at least once a month
  7997. > > lately when it used to never!!  We are running the latest code also...Oh
  7998. > > well...Thanks for the tip on how to busy out the modem. At least now if
  7999. it
  8000. > > happens I won't have to drive to the office and reset it I will just
  8001. busy it
  8002. > > out till morning.
  8003. >
  8004. > Just be sure that you don't get fast busies as a result of your modem busy
  8005. > out.  Some configurations of T1's don't properly communicate with the CO
  8006. > (often a lack of capability at the switch because of telco config when
  8007. > ordered).  We had a problem where an AT&T 5-ESS set to National mode was
  8008. > not configured properly to accept channel busy outs at the T1 level
  8009. > because the 5-ESS National Mode configuration was set not to accept it
  8010. > properly at the switch.  Our end was quite happy to send the signaling on
  8011. > the PRI, but the switch didn't accept it.  Hence, we had to get them to
  8012. > reconfigure the lines in custom mode and things worked just fine.  At
  8013. > other times, the telco changes other options without properly notifying
  8014. > customers so that they can test everything which got changed (such as our
  8015. > problem with lost callers after 29 seconds which was due to the fact that
  8016. > the telco enabled a feature which we didn't have to test against at
  8017. > initial installation, nor were we warned that it could be implemented
  8018. > later).
  8019. >
  8020. > Seeing that you didn't know how to busy out a modem (as many people don't
  8021. > when they're getting started and even some more experienced users), you
  8022. > may want to consider contacting your 3Com sales rep about getting the free
  8023. > Total Control training classes which 3Com is offering.  A lot of good
  8024. > information is disseminated there in the one day course.  It's actually
  8025. > worth paying for but 3Com is offering it for free so that customers get to
  8026. > know what the TC Chassis' are capable of.  It's not a show up and throw up
  8027. > class.  It's a real nitty gritty training session for TCM users.  I went
  8028. > to 3Com Rolling Meadows for two days to take their one day class and even
  8029. > though I had the same class both days, I walked away with new information
  8030. > on both days.
  8031. >
  8032. > Kevin Benton
  8033. > SOTA Technologies
  8034. >
  8035. > E-Mail:  s1kevin@tims.net
  8036. > Web:     http://users.sota-oh.com/~s1kevin/
  8037. > Unsolicited advertisements processing fee: $50 subject to change without
  8038. notice
  8039. >
  8040. >
  8041. > -
  8042. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8043. >  with "unsubscribe usr-tc" in the body of the message.
  8044. >  For information on digests or retrieving files and old messages send
  8045. >  "help" to the same address.  Do not use quotes in your message.
  8046. >
  8047.  
  8048.  
  8049. -
  8050.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8051.  with "unsubscribe usr-tc" in the body of the message.
  8052.  For information on digests or retrieving files and old messages send
  8053.  "help" to the same address.  Do not use quotes in your message.
  8054.  
  8055.  
  8056. -------------------------------------------------------------------------------
  8057.  
  8058. From: K Mitchell <mitch@keyconn.net>
  8059. Subject: RE: (usr-tc) Finding that no-answering modem
  8060. Date: 11 Oct 1999 21:58:44 -0400
  8061.  
  8062. At 09:26 PM 10/11/99 -0400, you wrote:
  8063. >On Mon, 11 Oct 1999, K Mitchell wrote:
  8064. >
  8065. >> Where do I get a copy of SNMP_Session.pm?
  8066. >
  8067. >Quick answer: Install MRTG :)
  8068. >
  8069. >(The library is available separately, but MRTG is indispensable enough on
  8070. >its own...)
  8071.  
  8072. I've had mrtg running for over a year  :)
  8073. Copied SNMP_Session.pm and BER.pm into perl\lib, now it has a problem
  8074. because I don't have NTsendmail.pm, as I use JMail, which doesn't appear to
  8075. have a jmail.pm. What do I need to change to have it use JMail?
  8076.  
  8077. Thanks,
  8078. -- 
  8079. Kirk Mitchell-General Manager        mitch@keyconn.net
  8080. Keystone Connect                     Unlock Your World
  8081. Altoona, PA   814-941-5000      http://www.keyconn.net
  8082.  
  8083.  
  8084. -
  8085.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8086.  with "unsubscribe usr-tc" in the body of the message.
  8087.  For information on digests or retrieving files and old messages send
  8088.  "help" to the same address.  Do not use quotes in your message.
  8089.  
  8090.  
  8091. -------------------------------------------------------------------------------
  8092.  
  8093. From: Aaron Nabil <nabil@spiritone.com>
  8094. Subject: Re: (usr-tc) arcs and ospf
  8095. Date: 12 Oct 1999 05:21:41 -0700 (PDT)
  8096.  
  8097. Mike Andrews writes...
  8098. >I've been having a really bizarre problem off and on the last week or two.
  8099. >Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  8100. >routing table loses all OSPF routes, and the ARC stops announcing its
  8101. >routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  8102. >most of the time (not all the time) rebooting the ARC will.
  8103. >
  8104. >One thing that seemed to trigger it was rebooting some of our Ciscos...
  8105. >and since that happens so infrequently (not rebooted since going to ARC
  8106. >4.2 in fact) it's hard to track down.  I don't know which one exactly,
  8107. >maybe our AS border router dying is what threw it off.
  8108. > 
  8109. > . . .
  8110. >
  8111. >Has anyone seen anything like this before or know of any particular
  8112. >settings that I might want to check?  This is driving me nuts (not to
  8113. >mention my customers) and I'm not sure where to start.
  8114.  
  8115. Make sure your tc's aren't becoming the DR.  To check, do a "list ospf nei",
  8116. see if any of them are in any state other than "two way".  To fix, do a
  8117. "set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
  8118. them and reboot.
  8119.  
  8120.  
  8121. -- 
  8122. Aaron Nabil
  8123.  
  8124. -
  8125.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8126.  with "unsubscribe usr-tc" in the body of the message.
  8127.  For information on digests or retrieving files and old messages send
  8128.  "help" to the same address.  Do not use quotes in your message.
  8129.  
  8130.  
  8131. -------------------------------------------------------------------------------
  8132.  
  8133. From: Scott Trautman <scottt@corp.gdinet.com>
  8134. Subject: RE: (usr-tc) TC user's conference?
  8135. Date: 12 Oct 1999 08:06:48 -0500
  8136.  
  8137.  
  8138.  
  8139. -----Original Message-----
  8140. Sent: Monday, October 11, 1999 10:08 AM
  8141.  
  8142.  
  8143. Thus spake Scott Trautman
  8144. >I concur on the training; I know in our area there are plans to have a
  8145. >session in the near future. Even those that think they "know it all",
  8146. >will learn some new tricks. I've been fortunate to get to know George
  8147. >Ebert at 3Com, and he's been a fantastic resource for those types of
  8148. >things. It'll be nice, though, to retain more than say 30% from those
  8149. >valuable informal sessions; as well as send a couple of our Admins to
  8150. >the training.
  8151.  
  8152. Indeed...those informal training sessions are good...and they're a good
  8153. way for 3Com folks to get feedback from customers (there were about 8 of
  8154. us at the one in Louisville...there was some good give and take there).
  8155. I just wish they could get 3Com folks to come that aren't in the sales
  8156. side of things...while the sales folks are good (Tom Goodman and George
  8157. Ebert are indeed wonderful resources), it seems that, within 3Com,
  8158. feedback doesn't really seem to be taken seriously from the sales folks.
  8159. :/  Unfortunately, this seems to be the case in many companies...not
  8160. just 3Com.
  8161.  
  8162. Yep, similiar experiences. Unfortunate. Understand that they can't be all
  8163. things to all people, but seems like there'd be a few strategic things
  8164. they could do without a whole huge effort. Also understood is the things
  8165. you'd like to see maybe only a handful think is as important. My thing
  8166. (currently) is I'd like to see the ptrace style output. Then I go look at
  8167. my Cisco routers, they have even less than that where it's even more
  8168. important. Shrug.
  8169.  
  8170. >I had suggested perhaps a TC users conference would be cool; something
  8171. >like an ISPCON but specifically for TC units. 1-2 days with conferences
  8172. >on many of the subjects we talk about here. There's a lot more "under
  8173. >the hood" than many of us ever get to, and I know we could, if we knew
  8174. >about them, use a lot more features than we currently do.
  8175.  
  8176. Neat idea...I'd certainly go for it (if I could get my company to pay
  8177. for the travel ;)
  8178.  
  8179. >A few examples....I'm sure y'all can think of many more.....
  8180.  
  8181. >- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
  8182. >ratio's, etc.)
  8183.  
  8184. Good...unfortunately, there's not much in the way of tools in the TC's
  8185. to do trouble resolution on these things.  More control over the
  8186. CSU/DSU's would be *very* useful here.
  8187.  
  8188. Well, useful to the extent that problems they're seeing <through> the TC
  8189. equipment
  8190. is really telco issues, and being able to better tell the difference would
  8191. be
  8192. really helpful.
  8193.  
  8194. >- Getting more mileage out of TCM
  8195.  
  8196. Hrmm...unfortunately, I've pretty much given up on TCM...you can only
  8197. get so much mileage out of a VW bug.  :/  I'm beginning to write some
  8198. Perl5 (with SNMP module) scripts to interact with the TC's...  I'm not
  8199. quite to the point of putting TCM type functionality together...I'm
  8200. starting with scripts to fulfull specific functions...I may, eventually,
  8201. get to that point.
  8202.  
  8203. George helped me along off of the same thought. I get quite a bit of use
  8204. from TCM, and it beats
  8205. the snot out of any other dialup control interface I've seen. Cisco, for
  8206. example, I'm not sure
  8207. they have ANY such graphical interface. 
  8208.  
  8209. >- Advanced SNMP
  8210.  
  8211. Isn't that a contradiction in terms?  ;)
  8212.  
  8213. Well, no, kind of like TCM, I think one could do a lot more if one
  8214. understood better "how it all
  8215. fits together". Some of recent trails on SNMP manipulation that I've not
  8216. delved into could be quite
  8217. useful. For example, have a feeling I could probably find my "no answer"
  8218. modems via SNMP a lot easier
  8219. than any sort of RADIUS accounting grooming or the usual expect-like
  8220. scripting. I just don't know
  8221. how at this point. Session on, say, okay, (and we use this tool...great) RRD
  8222. for modems in use monitoring,
  8223. but other types of trap monitoring perhaps.
  8224.  
  8225. >- Dialup user issues (monitoring, filtering, setup, etc.)
  8226. >- Getting to the bottom of modem compatibility issues
  8227.  
  8228. I see these two kinda being two different sides of the same coin...most
  8229. specifically, I would benefit from a seriously in depth seminar about
  8230. modem technology...unfortunately, I'm not sure how generally useful this
  8231. would be as I'm thinking about actually getting down into the encoding
  8232. of the data into the analog waveform and stuff.  :)
  8233.  
  8234. Sure. I'm personally not all that interested in the encoding level of
  8235. things,
  8236. but would be in understanding more fully WHY Rockwell chipset modems are
  8237. such a 
  8238. problem. (I mean other than "they suck")
  8239.  
  8240. >- HiperARC setup
  8241. >- TC "future" - VoIP, ?
  8242.  
  8243. Indeed...this would be nice...especially to give feedback to 3Com
  8244. through it.  Where do you/I/we want this platform to go?  I sent a nice
  8245. long letter to the list the other day and got very little feedback...one
  8246. person agreeing with me (in private, asked for his message not to be
  8247. publically posted), and one person sort of disagreeing with me in
  8248. public.  :)
  8249.  
  8250. >I'd pay $1-2k for such a day-2day conference.....Just thoughts....
  8251.  
  8252. Unfortunately, that'd probably be out of our price range...but I would
  8253. be interested in such a conference in idea at least.  :)
  8254.  
  8255. Shrug.
  8256.  
  8257. SMT
  8258.  
  8259. -- 
  8260. Jeff McAdams                            Email: jeffm@iglou.com
  8261. Head Network Administrator              Voice: (502) 966-3848
  8262. IgLou Internet Services                        (800) 436-4456
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8272.  with "unsubscribe usr-tc" in the body of the message.
  8273.  For information on digests or retrieving files and old messages send
  8274.  "help" to the same address.  Do not use quotes in your message.
  8275.  
  8276.  
  8277. -------------------------------------------------------------------------------
  8278.  
  8279. From: Jeff Mcadams <jeffm@iglou.com>
  8280. Subject: Re: (usr-tc) TC user's conference?
  8281. Date: 12 Oct 1999 09:42:18 -0400
  8282.  
  8283. Thus spake Scott Trautman
  8284. >Yep, similiar experiences. Unfortunate. Understand that they can't be all
  8285. >things to all people, but seems like there'd be a few strategic things
  8286. >they could do without a whole huge effort. Also understood is the things
  8287. >you'd like to see maybe only a handful think is as important. My thing
  8288. >(currently) is I'd like to see the ptrace style output. Then I go look at
  8289. >my Cisco routers, they have even less than that where it's even more
  8290. >important. Shrug.
  8291.  
  8292. I don't know...there's some *really* good trouble-shooting tools in
  8293. Ciscos...you just have to go about it in a different way.  Now, there is
  8294. certainly an issue of which works better, and that's very valid...but
  8295. you do have tools in Ciscos...they just don't work the same way.  :/
  8296.  
  8297. >>A few examples....I'm sure y'all can think of many more.....
  8298.  
  8299. >>- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
  8300. >>ratio's, etc.)
  8301.  
  8302. >Good...unfortunately, there's not much in the way of tools in the TC's
  8303. >to do trouble resolution on these things.  More control over the
  8304. >CSU/DSU's would be *very* useful here.
  8305.  
  8306. >Well, useful to the extent that problems they're seeing <through> the
  8307. >TC equipment is really telco issues, and being able to better tell the
  8308. >difference would be really helpful.
  8309.  
  8310. Exactly...I would *really* like to have a decent suite of BER tests
  8311. available on the CSU/DSU's...I'd like to be able to do payload
  8312. loopbacks (in order to be able to test the actual CSU/DSU better)...
  8313.  
  8314. Maybe this is a bit bizarre...but it would be nifty to have a way to
  8315. "simulate" a telco switch on the DSPs or something like that.  Something
  8316. where we could plug a DSP into another DSP (cross-over t1 cable) and
  8317. actually bring up the D channel, and maybe even "place calls" over it.
  8318. With a good set of BER tests, and this ability, you could almost
  8319. eliminate the need for T1 test sets.  ;)  Anyway...these things are
  8320. definitely farther off type of things...but would be cool.  :)  I
  8321. certainly want to see engineering resources pulled away from maturing
  8322. the modem code on the DSPs to do things like this.  :)
  8323.  
  8324. >>- Getting more mileage out of TCM
  8325.  
  8326. >Hrmm...unfortunately, I've pretty much given up on TCM...you can only
  8327. >get so much mileage out of a VW bug.  :/  I'm beginning to write some
  8328. >Perl5 (with SNMP module) scripts to interact with the TC's...  I'm not
  8329. >quite to the point of putting TCM type functionality together...I'm
  8330. >starting with scripts to fulfull specific functions...I may, eventually,
  8331. >get to that point.
  8332.  
  8333. >George helped me along off of the same thought. I get quite a bit of
  8334. >use from TCM, and it beats the snot out of any other dialup control
  8335. >interface I've seen. Cisco, for example, I'm not sure they have ANY
  8336. >such graphical interface. 
  8337.  
  8338. Yeah...I've talked with George about this extensively...and while the
  8339. interface is pretty good.  TCM as a whole has some significant
  8340. limitations...things I can think of off the top of my head...
  8341.  
  8342. - You can only really manipulate one chassis at once...with some good
  8343. scripting ability you could manipulate multiple chassis at once (which
  8344. is what I've been doing with my perl scripts recently...iterate through
  8345. all our chassis and perform action xyz)...there's just really no good
  8346. way to do this with TCM, so when you get beyond...oh...10 or so chassis,
  8347. it starts getting really tedious to administer things in TCM...that
  8348. number varies with the patience of the one doing the administration.  :)
  8349.  
  8350. >>- Advanced SNMP
  8351.  
  8352. >Isn't that a contradiction in terms?  ;)
  8353.  
  8354. >Well, no, kind of like TCM, I think one could do a lot more if one
  8355. >understood better "how it all fits together". Some of recent trails on
  8356. >SNMP manipulation that I've not delved into could be quite useful. For
  8357. >example, have a feeling I could probably find my "no answer" modems via
  8358. >SNMP a lot easier than any sort of RADIUS accounting grooming or the
  8359. >usual expect-like scripting. I just don't know how at this point.
  8360. >Session on, say, okay, (and we use this tool...great) RRD for modems in
  8361. >use monitoring, but other types of trap monitoring perhaps.
  8362.  
  8363. Yeah...I understand your point...and it is a good one.  Wrapping your
  8364. brain around the functioning of SNMP does take some work...but once it
  8365. clicks...it then becomes more a matter of how good your are at scripting
  8366. (which I'm just getting into) to be able to make use of it.  One good
  8367. thing that I think could come out of this would be methods of working
  8368. around the limitations of the SNMP implementations (ie, fairly small max
  8369. PDU size that is such a limit on the NMC :/ ).
  8370.  
  8371. >>- Dialup user issues (monitoring, filtering, setup, etc.)
  8372. >>- Getting to the bottom of modem compatibility issues
  8373.  
  8374. >I see these two kinda being two different sides of the same coin...most
  8375. >specifically, I would benefit from a seriously in depth seminar about
  8376. >modem technology...unfortunately, I'm not sure how generally useful this
  8377. >would be as I'm thinking about actually getting down into the encoding
  8378. >of the data into the analog waveform and stuff.  :)
  8379.  
  8380. >Sure. I'm personally not all that interested in the encoding level of
  8381. >things, but would be in understanding more fully WHY Rockwell chipset
  8382. >modems are such a problem. (I mean other than "they suck")
  8383.  
  8384. Well...true...and I'm probably interested in getting way deeper than
  8385. necessary...but that's kinda the way I am...I was one of those kids that
  8386. always asked "Why?"...not because I wanted to annoy someone, but because
  8387. I really and truly was interested into how things worked, why things are
  8388. the way they are, etc.  :)  I'd be interested in learning about noise
  8389. levels, transmit and receive levels, how the actual modulation and
  8390. encoding works so I can understand why those values are important, and
  8391. how they're dealt with...all that.  I'm doing some studying on my own,
  8392. but its *really* hard to find information on this type of stuff (esp.
  8393. since some of the specs aren't freely available...blech)
  8394. -- 
  8395. Jeff McAdams                            Email: jeffm@iglou.com
  8396. Head Network Administrator              Voice: (502) 966-3848
  8397. IgLou Internet Services                        (800) 436-4456
  8398.  
  8399. -
  8400.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8401.  with "unsubscribe usr-tc" in the body of the message.
  8402.  For information on digests or retrieving files and old messages send
  8403.  "help" to the same address.  Do not use quotes in your message.
  8404.  
  8405.  
  8406. -------------------------------------------------------------------------------
  8407.  
  8408. From: "Cheryl Johnson" <netadmin@seidata.com>
  8409. Subject: Re: (usr-tc) Finding that no-answering modem
  8410. Date: 12 Oct 1999 09:52:06 -0500
  8411.  
  8412. Its great to run a script to find them, but personally I would like to know
  8413. what is causing this to happen and find a permanent fix for the problem. I
  8414. have had this happen on various codes using the DSP cards. Tried reseting
  8415. the modem, the DSP card,  and reverting back to older code, and nothing
  8416. works permanently. I am beginning to think this may not be on the DSP or the
  8417. chassis itself, but possibly a telco issue. Just a thought.
  8418.  
  8419. Cheryl Johnson
  8420. Seidata Network Services, Inc.
  8421. http://www.seidata.com
  8422.  
  8423. ----- Original Message -----
  8424. Sent: Sunday, October 10, 1999 4:50 PM
  8425.  
  8426.  
  8427. > Hmmm...That is exactly how I have been trying to reset the modem yet it
  8428. has
  8429. > never worked. Not even once..And it happens to us at least once a month
  8430. > lately when it used to never!!  We are running the latest code also...Oh
  8431. > well...Thanks for the tip on how to busy out the modem. At least now if it
  8432. > happens I won't have to drive to the office and reset it I will just busy
  8433. it
  8434. > out till morning.
  8435. > Greg Owens
  8436. > Magnolia Internet Services
  8437. > http://www.magnolia-net.com
  8438. > ----- Original Message -----
  8439. > From: Scott Trautman <scottt@corp.gdinet.com>
  8440. > To: <usr-tc@lists.xmission.com>
  8441. > Sent: Sunday, October 10, 1999 11:57 AM
  8442. > Subject: RE: (usr-tc) Finding that no-answering modem
  8443. >
  8444. >
  8445. > > Simply highlighting the modem, actions/commands, software reset.
  8446. > >
  8447. > > Busy out modems? Simple. At the T1; before it hits the modem.
  8448. > > Highlight your T1 card, actions/commands, select the TRUNK #
  8449. corresponding
  8450. > > to the problem modem, and do a soft or hard busy out of the DS0.
  8451. > >
  8452. > > THIS much I DO know! :^)
  8453. > >
  8454. > > USED to have to pull the card on stuck modems, but hasn't seemed to be
  8455. the
  8456. > > case since the last modem code update quite some time ago. Also doesn't
  8457. > > seem to happen nearly as often either.
  8458. > >
  8459. > > SMT
  8460. > >
  8461. > > > -----Original Message-----
  8462. > > > From: Greg Owens [mailto:gowens@magnolia-net.com]
  8463. > > > Sent: Sunday, October 10, 1999 10:00 AM
  8464. > > > To: usr-tc@lists.xmission.com
  8465. > > > Subject: Re: (usr-tc) Finding that no-answering modem
  8466. > > >
  8467. > > >
  8468. > > > Where in the TCM are you going to reset it successfully.
  8469. > > > Seems like every
  8470. > > > time we have a hung (no answer) modem we have to unplug the
  8471. > > > card and and
  8472. > > > plug it back in. Also is there a way to busy out 1 or 2
  8473. > > > modems in a card
  8474. > > > (DSP)  from the TCM. Thanks
  8475. > > > Greg Owens
  8476. > > > Magnolia Internet Services
  8477. > > > http://www.magnolia-net.com
  8478. > > > ----- Original Message -----
  8479. > > > From: Scott Trautman <scottt@corp.gdinet.com>
  8480. > > > To: <usr-tc@lists.xmission.com>
  8481. > > > Sent: Sunday, October 10, 1999 9:29 AM
  8482. > > > Subject: (usr-tc) Finding that no-answering modem
  8483. > > >
  8484. > > >
  8485. > > > > Went for months without a no-answer modem, now seem to have
  8486. > > > had a real
  8487. > > > spate
  8488. > > > > of them.
  8489. > > > > Fortunately it does seem that simply resetting the modem in
  8490. > > > TCM 'fixes'
  8491. > > > it,
  8492. > > > > but we don't
  8493. > > > > fix it before we get a call or two of 'no answer modem'.
  8494. > > > >
  8495. > > > > Anyone running any kind of script/log analysis that finds no answer
  8496. > > > modems?
  8497. > > > >
  8498. > > > > I also had a fellow from 3Com show me an "Autoresponse"
  8499. > > > trick to reset the
  8500. > > > > modem automatically
  8501. > > > > if it got a no answer. I've since forgotten how, and not
  8502. > > > really sure if
  8503. > > > > that'd really do the
  8504. > > > > trick anyway. And it would be mighty tedious to set all our
  8505. > > > ports for
  8506. > > > this.
  8507. > > > >
  8508. > > > > SMT
  8509. > > > >
  8510. > > > > Scott M. Trautman               800-482-4638
  8511. > > > > Global Dialog Internet          608-240-4638,4637fax
  8512. > > > > 2810 Crossroads, STE LL2         scott@gdinet.com
  8513. > > > > Madison WI 53718                    http://www.gdinet.com
  8514. > > > >
  8515. > > > > -
  8516. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8517. > > > >  with "unsubscribe usr-tc" in the body of the message.
  8518. > > > >  For information on digests or retrieving files and old
  8519. > > > messages send
  8520. > > > >  "help" to the same address.  Do not use quotes in your message.
  8521. > > > >
  8522. > > >
  8523. > > >
  8524. > > > -
  8525. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8526. > > >  with "unsubscribe usr-tc" in the body of the message.
  8527. > > >  For information on digests or retrieving files and old messages send
  8528. > > >  "help" to the same address.  Do not use quotes in your message.
  8529. > > >
  8530. > >
  8531. > > -
  8532. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8533. > >  with "unsubscribe usr-tc" in the body of the message.
  8534. > >  For information on digests or retrieving files and old messages send
  8535. > >  "help" to the same address.  Do not use quotes in your message.
  8536. > >
  8537. >
  8538. >
  8539. > -
  8540. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8541. >  with "unsubscribe usr-tc" in the body of the message.
  8542. >  For information on digests or retrieving files and old messages send
  8543. >  "help" to the same address.  Do not use quotes in your message.
  8544. >
  8545.  
  8546.  
  8547. -
  8548.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8549.  with "unsubscribe usr-tc" in the body of the message.
  8550.  For information on digests or retrieving files and old messages send
  8551.  "help" to the same address.  Do not use quotes in your message.
  8552.  
  8553.  
  8554. -------------------------------------------------------------------------------
  8555.  
  8556. From: Jeff Mcadams <jeffm@iglou.com>
  8557. Subject: Re: (usr-tc) TC user's conference?
  8558. Date: 12 Oct 1999 09:52:24 -0400
  8559.  
  8560. Thus spake Jeff Mcadams
  8561. >Yeah...I've talked with George about this extensively...and while the
  8562. >interface is pretty good.  TCM as a whole has some significant
  8563. >limitations...things I can think of off the top of my head...
  8564.  
  8565. >- You can only really manipulate one chassis at once...with some good
  8566. >scripting ability you could manipulate multiple chassis at once (which
  8567. >is what I've been doing with my perl scripts recently...iterate through
  8568. >all our chassis and perform action xyz)...there's just really no good
  8569. >way to do this with TCM, so when you get beyond...oh...10 or so chassis,
  8570. >it starts getting really tedious to administer things in TCM...that
  8571. >number varies with the patience of the one doing the administration.  :)
  8572.  
  8573. Duh...forgot to type in the other one...  :/
  8574.  
  8575. - Copying configs from one card to one or more others is terribly
  8576. inefficient...setting *all* of the config settings, when you're dealing
  8577. with a large number of settings can take a *long* time.  Would be good
  8578. to have the ability to only set the settings that are different...same
  8579. eventual effect (the cards end up with identical configs) but
  8580. considerably more effecient...this is one of the main reasons that I
  8581. moved away from using TCM as my primary tool for configuring chassis
  8582. (that and I happened to have access to one that did these things
  8583. better...unfortunately, its not mine to give away, or I would do so).
  8584. -- 
  8585. Jeff McAdams                            Email: jeffm@iglou.com
  8586. Head Network Administrator              Voice: (502) 966-3848
  8587. IgLou Internet Services                        (800) 436-4456
  8588.  
  8589. -
  8590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8591.  with "unsubscribe usr-tc" in the body of the message.
  8592.  For information on digests or retrieving files and old messages send
  8593.  "help" to the same address.  Do not use quotes in your message.
  8594.  
  8595.  
  8596. -------------------------------------------------------------------------------
  8597.  
  8598. From: Jim Johnson <jim@perigee.net>
  8599. Subject: (usr-tc) 2.0.60 HDM Code
  8600. Date: 12 Oct 1999 10:17:45 -0400
  8601.  
  8602.  
  8603.  
  8604. Is anyone using HDM 2.0.60.0 code.  It is an Engineering Release which
  8605. implements a DSP reset whenever the DSP goes idle on both ports.  It is
  8606. a temporary fix to the hanging pair of modems problem, but I just wanted
  8607. some feedback, if any was available, before we put it on any of our
  8608. production modems.
  8609.  
  8610. Thanks,
  8611.  
  8612. Jim
  8613.  
  8614. -
  8615.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8616.  with "unsubscribe usr-tc" in the body of the message.
  8617.  For information on digests or retrieving files and old messages send
  8618.  "help" to the same address.  Do not use quotes in your message.
  8619.  
  8620.  
  8621. -------------------------------------------------------------------------------
  8622.  
  8623. From: "Jason A. Nunnelley" <interests@linkfast.net>
  8624. Subject: RE: (usr-tc) 2.0.60 HDM Code
  8625. Date: 12 Oct 1999 09:25:46 -0700
  8626.  
  8627. I am curious. I am not seeing this problem in my network. Is this a common
  8628. problem, or isolated to certain cards?
  8629.  
  8630. Jason
  8631.  
  8632. -----Original Message-----
  8633. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  8634. Sent: Tuesday, October 12, 1999 7:18 AM
  8635.  
  8636.  
  8637.  
  8638.  
  8639. Is anyone using HDM 2.0.60.0 code.  It is an Engineering Release which
  8640. implements a DSP reset whenever the DSP goes idle on both ports.  It is
  8641. a temporary fix to the hanging pair of modems problem, but I just wanted
  8642. some feedback, if any was available, before we put it on any of our
  8643. production modems.
  8644.  
  8645. Thanks,
  8646.  
  8647. Jim
  8648.  
  8649. -
  8650.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8651.  with "unsubscribe usr-tc" in the body of the message.
  8652.  For information on digests or retrieving files and old messages send
  8653.  "help" to the same address.  Do not use quotes in your message.
  8654.  
  8655.  
  8656. -
  8657.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8658.  with "unsubscribe usr-tc" in the body of the message.
  8659.  For information on digests or retrieving files and old messages send
  8660.  "help" to the same address.  Do not use quotes in your message.
  8661.  
  8662.  
  8663. -------------------------------------------------------------------------------
  8664.  
  8665. From: Brian <signal@shreve.net>
  8666. Subject: RE: (usr-tc) 2.0.60 HDM Code
  8667. Date: 12 Oct 1999 09:37:35 -0500 (CDT)
  8668.  
  8669. On Tue, 12 Oct 1999, Jason A. Nunnelley wrote:
  8670.  
  8671. > I am curious. I am not seeing this problem in my network. Is this a common
  8672. > problem, or isolated to certain cards?
  8673.  
  8674. depends really on the size of your network.  We are at over 1000 ports and
  8675. I only see it happen maybe once every 10 days.
  8676.  
  8677. Brian
  8678.  
  8679.  
  8680. > 
  8681. > Jason
  8682. > 
  8683. > -----Original Message-----
  8684. > From: owner-usr-tc@lists.xmission.com
  8685. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  8686. > Sent: Tuesday, October 12, 1999 7:18 AM
  8687. > To: usr-tc Mailing List
  8688. > Subject: (usr-tc) 2.0.60 HDM Code
  8689. > 
  8690. > 
  8691. > 
  8692. > 
  8693. > Is anyone using HDM 2.0.60.0 code.  It is an Engineering Release which
  8694. > implements a DSP reset whenever the DSP goes idle on both ports.  It is
  8695. > a temporary fix to the hanging pair of modems problem, but I just wanted
  8696. > some feedback, if any was available, before we put it on any of our
  8697. > production modems.
  8698. > 
  8699. > Thanks,
  8700. > 
  8701. > Jim
  8702. > 
  8703. > -
  8704. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8705. >  with "unsubscribe usr-tc" in the body of the message.
  8706. >  For information on digests or retrieving files and old messages send
  8707. >  "help" to the same address.  Do not use quotes in your message.
  8708. > 
  8709. > 
  8710. > -
  8711. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8712. >  with "unsubscribe usr-tc" in the body of the message.
  8713. >  For information on digests or retrieving files and old messages send
  8714. >  "help" to the same address.  Do not use quotes in your message.
  8715. > 
  8716.  
  8717. Brian Feeny (BF304)     signal@shreve.net   
  8718. 318-222-2638 x 109    http://www.shreve.net/~signal      
  8719. Network Administrator   ShreveNet Inc. (ASN 11881)           
  8720.  
  8721.  
  8722. -
  8723.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8724.  with "unsubscribe usr-tc" in the body of the message.
  8725.  For information on digests or retrieving files and old messages send
  8726.  "help" to the same address.  Do not use quotes in your message.
  8727.  
  8728.  
  8729. -------------------------------------------------------------------------------
  8730.  
  8731. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  8732. Subject: RE: (usr-tc) arcs and ospf
  8733. Date: 12 Oct 1999 09:41:01 -0500
  8734.  
  8735.  
  8736.  
  8737. |-----Original Message-----
  8738. |From: owner-usr-tc@lists.xmission.com
  8739. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  8740. |Sent: Tuesday, October 12, 1999 7:22 AM
  8741. |To: usr-tc@lists.xmission.com
  8742. |Subject: Re: (usr-tc) arcs and ospf
  8743. |
  8744. |
  8745. |Mike Andrews writes...
  8746. |>I've been having a really bizarre problem off and on the last week or two.
  8747. |>Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  8748. |>routing table loses all OSPF routes, and the ARC stops announcing its
  8749. |>routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  8750. |>most of the time (not all the time) rebooting the ARC will.
  8751. |>
  8752. |>One thing that seemed to trigger it was rebooting some of our Ciscos...
  8753. |>and since that happens so infrequently (not rebooted since going to ARC
  8754. |>4.2 in fact) it's hard to track down.  I don't know which one exactly,
  8755. |>maybe our AS border router dying is what threw it off.
  8756. |> 
  8757. |> . . .
  8758. |>
  8759. |>Has anyone seen anything like this before or know of any particular
  8760. |>settings that I might want to check?  This is driving me nuts (not to
  8761. |>mention my customers) and I'm not sure where to start.
  8762. |
  8763. |Make sure your tc's aren't becoming the DR.  To check, do a "list ospf nei",
  8764. |see if any of them are in any state other than "two way".  To fix, do a
  8765. |"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
  8766. |them and reboot.
  8767. |
  8768.  
  8769. That recomendation is actually in the release notes for 4.2.32...
  8770.  
  8771. -M
  8772.  
  8773.  
  8774. -
  8775.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8776.  with "unsubscribe usr-tc" in the body of the message.
  8777.  For information on digests or retrieving files and old messages send
  8778.  "help" to the same address.  Do not use quotes in your message.
  8779.  
  8780.  
  8781. -------------------------------------------------------------------------------
  8782.  
  8783. From: Jeff Mcadams <jeffm@iglou.com>
  8784. Subject: Re: (usr-tc) arcs and ospf
  8785. Date: 12 Oct 1999 11:10:19 -0400
  8786.  
  8787. Thus spake Mike Wronski
  8788. >|Mike Andrews writes...
  8789. >|>I've been having a really bizarre problem off and on the last week or two.
  8790. >|>Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  8791. >|>routing table loses all OSPF routes, and the ARC stops announcing its
  8792. >|>routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  8793. >|>most of the time (not all the time) rebooting the ARC will.
  8794.  
  8795. >|>One thing that seemed to trigger it was rebooting some of our Ciscos...
  8796. >|>and since that happens so infrequently (not rebooted since going to ARC
  8797. >|>4.2 in fact) it's hard to track down.  I don't know which one exactly,
  8798. >|>maybe our AS border router dying is what threw it off.
  8799.  
  8800. >|>Has anyone seen anything like this before or know of any particular
  8801. >|>settings that I might want to check?  This is driving me nuts (not to
  8802. >|>mention my customers) and I'm not sure where to start.
  8803.  
  8804. >|Make sure your tc's aren't becoming the DR.  To check, do a "list ospf nei",
  8805. >|see if any of them are in any state other than "two way".  To fix, do a
  8806. >|"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
  8807. >|them and reboot.
  8808.  
  8809. >That recomendation is actually in the release notes for 4.2.32...
  8810.  
  8811. There are problems with the DR/BDR code in 4.2.x then?  Hrmm...could
  8812. suck if you don't have 2 other OSPF speakers on a subnet...if they
  8813. reboot, then the Arc would become DR, and when they come back up, they
  8814. won't take over from it.  :/  Would require a reboot of possibly two
  8815. Arcs for get the DR to be something other than an Arc in that situation.
  8816. :/
  8817. -- 
  8818. Jeff McAdams                            Email: jeffm@iglou.com
  8819. Head Network Administrator              Voice: (502) 966-3848
  8820. IgLou Internet Services                        (800) 436-4456
  8821.  
  8822. -
  8823.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8824.  with "unsubscribe usr-tc" in the body of the message.
  8825.  For information on digests or retrieving files and old messages send
  8826.  "help" to the same address.  Do not use quotes in your message.
  8827.  
  8828.  
  8829. -------------------------------------------------------------------------------
  8830.  
  8831. From: Jim Johnson <jim@perigee.net>
  8832. Subject: Re: (usr-tc) 2.0.60 HDM Code
  8833. Date: 12 Oct 1999 11:19:50 -0400
  8834.  
  8835.  
  8836. We see a pair of ports go down about once every week or two in a 16 PRI
  8837. Group.  I am not sure what code revisions are affected by this problem,
  8838. but all of the newer ones are susceptible.
  8839.  
  8840. When it strikes early in a hunt group and you are in a first available
  8841. hunt sequence, it can be quite devastating. :(
  8842.  
  8843. -Jim
  8844.  
  8845. "Jason A. Nunnelley" wrote:
  8846. > 
  8847. > I am curious. I am not seeing this problem in my network. Is this a common
  8848. > problem, or isolated to certain cards?
  8849. > 
  8850. > Jason
  8851. > 
  8852. > -----Original Message-----
  8853. > From: owner-usr-tc@lists.xmission.com
  8854. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson
  8855. > Sent: Tuesday, October 12, 1999 7:18 AM
  8856. > To: usr-tc Mailing List
  8857. > Subject: (usr-tc) 2.0.60 HDM Code
  8858. > 
  8859. > Is anyone using HDM 2.0.60.0 code.  It is an Engineering Release which
  8860. > implements a DSP reset whenever the DSP goes idle on both ports.  It is
  8861. > a temporary fix to the hanging pair of modems problem, but I just wanted
  8862. > some feedback, if any was available, before we put it on any of our
  8863. > production modems.
  8864. > 
  8865. > Thanks,
  8866. > 
  8867. > Jim
  8868. > 
  8869. > -
  8870. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8871. >  with "unsubscribe usr-tc" in the body of the message.
  8872. >  For information on digests or retrieving files and old messages send
  8873. >  "help" to the same address.  Do not use quotes in your message.
  8874. > 
  8875. > -
  8876. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8877. >  with "unsubscribe usr-tc" in the body of the message.
  8878. >  For information on digests or retrieving files and old messages send
  8879. >  "help" to the same address.  Do not use quotes in your message.
  8880.  
  8881. -
  8882.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8883.  with "unsubscribe usr-tc" in the body of the message.
  8884.  For information on digests or retrieving files and old messages send
  8885.  "help" to the same address.  Do not use quotes in your message.
  8886.  
  8887.  
  8888. -------------------------------------------------------------------------------
  8889.  
  8890. From: Mike Andrews <mandrews@bit0.com>
  8891. Subject: RE: (usr-tc) arcs and ospf
  8892. Date: 12 Oct 1999 11:23:27 -0400 (EDT)
  8893.  
  8894. On Tue, 12 Oct 1999, Mike Wronski wrote:
  8895.  
  8896. > |Mike Andrews writes...
  8897. > |>I've been having a really bizarre problem off and on the last week or two.
  8898. > |>Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  8899. > |>routing table loses all OSPF routes, and the ARC stops announcing its
  8900. > |>routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  8901. > |>most of the time (not all the time) rebooting the ARC will.
  8902. > |>
  8903. > |>One thing that seemed to trigger it was rebooting some of our Ciscos...
  8904. > |>and since that happens so infrequently (not rebooted since going to ARC
  8905. > |>4.2 in fact) it's hard to track down.  I don't know which one exactly,
  8906. > |>maybe our AS border router dying is what threw it off.
  8907. > |> 
  8908. > |> . . .
  8909. > |>
  8910. > |>Has anyone seen anything like this before or know of any particular
  8911. > |>settings that I might want to check?  This is driving me nuts (not to
  8912. > |>mention my customers) and I'm not sure where to start.
  8913. > |
  8914. > |Make sure your tc's aren't becoming the DR.  To check, do a "list ospf nei",
  8915. > |see if any of them are in any state other than "two way".  To fix, do a
  8916. > |"set ospf interface THE_OSPF_INTERFACE router_priority 0" on each of
  8917. > |them and reboot.
  8918. > |
  8919. > 
  8920. > That recomendation is actually in the release notes for 4.2.32...
  8921.  
  8922.  
  8923. OK, that's three votes for DR/BDR designation being the problem. :)  And
  8924. dumb me for not paying closer attention to the release notes.
  8925.  
  8926. Basically I had left every single router in my network set to the default
  8927. of priority 0.  I've just set my border Cisco to 50, the next fastest
  8928. Cisco to 40, all the 2500's to 20, and left the TC's and two FreeBSD
  8929. machines running gated set to 0.  I rebooted what was the DR at the time
  8930. (I know, coulda just disabled/reenabled OSPF, but the customers on it
  8931. didn't notice) and didn't have any problems with the TC's.  We'll see...
  8932.  
  8933.  
  8934. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  8935. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  8936. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  8937. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  8938.  
  8939.  
  8940. -
  8941.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8942.  with "unsubscribe usr-tc" in the body of the message.
  8943.  For information on digests or retrieving files and old messages send
  8944.  "help" to the same address.  Do not use quotes in your message.
  8945.  
  8946.  
  8947. -------------------------------------------------------------------------------
  8948.  
  8949. From: Curt Shambeau <curt@execpc.com>
  8950. Subject: Re: (usr-tc) 2.0.60 HDM Code
  8951. Date: 12 Oct 1999 11:35:09 -0500 (CDT)
  8952.  
  8953. > Is anyone using HDM 2.0.60.0 code.  It is an Engineering Release which
  8954. > implements a DSP reset whenever the DSP goes idle on both ports.  It is
  8955. > a temporary fix to the hanging pair of modems problem, but I just wanted
  8956. > some feedback, if any was available, before we put it on any of our
  8957. > production modems.
  8958.  
  8959. Is this code posted someplace, or is it available only by calling their
  8960. tech support department?
  8961.  
  8962.  
  8963. | Curtis V. Shambeau  |  curt@execpc.com  |  Senior Vice President  |
  8964. |   ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol:  VOYN     |
  8965.  
  8966.  
  8967. -
  8968.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8969.  with "unsubscribe usr-tc" in the body of the message.
  8970.  For information on digests or retrieving files and old messages send
  8971.  "help" to the same address.  Do not use quotes in your message.
  8972.  
  8973.  
  8974. -------------------------------------------------------------------------------
  8975.  
  8976. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  8977. Subject: Re: (usr-tc) 2.0.60 HDM Code
  8978. Date: 12 Oct 1999 12:09:14 -0500
  8979.  
  8980.  
  8981.  
  8982.      ER or Engineering Release Code is only available by calling to Tech
  8983. Support, and then WE (Tech Support) must get permission to release the code.
  8984. This is done so that we can document the use of these special codes to see if
  8985. the fix the specific issue they are supposed address, and also to see if the new
  8986. fix for one issue causes issues with any other processes in the code or product.
  8987.  
  8988.      If you wish to contact us, we're here 24x7.
  8989.  
  8990.  
  8991.      3Com Tech Support   (800) 231-8770       (please note that after hours
  8992. support does require an after hours contract).
  8993.  
  8994.  
  8995.      I hope this helps.
  8996.  
  8997.  
  8998.      Todd      ;-}
  8999.  
  9000.  
  9001.  
  9002.  
  9003.  
  9004.  
  9005. Curt Shambeau <curt@execpc.com> on 10/12/99 11:35:09 AM
  9006.  
  9007. Please respond to usr-tc@lists.xmission.com
  9008.  
  9009. Sent by:  Curt Shambeau <curt@execpc.com>
  9010.  
  9011.  
  9012. cc:    (Todd Keister/MW/US/3Com)
  9013.  
  9014.  
  9015.  
  9016.  
  9017. > Is anyone using HDM 2.0.60.0 code.  It is an Engineering Release which
  9018. > implements a DSP reset whenever the DSP goes idle on both ports.  It is
  9019. > a temporary fix to the hanging pair of modems problem, but I just wanted
  9020. > some feedback, if any was available, before we put it on any of our
  9021. > production modems.
  9022.  
  9023. Is this code posted someplace, or is it available only by calling their
  9024. tech support department?
  9025.  
  9026.  
  9027. | Curtis V. Shambeau  |  curt@execpc.com  |  Senior Vice President  |
  9028. |   ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol:  VOYN     |
  9029.  
  9030.  
  9031. -
  9032.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9033.  with "unsubscribe usr-tc" in the body of the message.
  9034.  For information on digests or retrieving files and old messages send
  9035.  "help" to the same address.  Do not use quotes in your message.
  9036.  
  9037.  
  9038.  
  9039.  
  9040.  
  9041.  
  9042. -
  9043.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9044.  with "unsubscribe usr-tc" in the body of the message.
  9045.  For information on digests or retrieving files and old messages send
  9046.  "help" to the same address.  Do not use quotes in your message.
  9047.  
  9048.  
  9049. -------------------------------------------------------------------------------
  9050.  
  9051. From: Jeff Mcadams <jeffm@iglou.com>
  9052. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9053. Date: 12 Oct 1999 13:12:31 -0400
  9054.  
  9055. Thus spake Todd Keister
  9056. >     ER or Engineering Release Code is only available by calling to
  9057. >Tech Support, and then WE (Tech Support) must get permission to release
  9058. >the code.  
  9059.  
  9060. Good grief, its getting worse.  What's next?  Are we going to have to
  9061. get a note from our mother's to use ER code?  Blech.
  9062.  
  9063. >This is done so that we can document the use of these special codes to
  9064. >see if the fix the specific issue they are supposed address, and also
  9065. >to see if the new fix for one issue causes issues with any other
  9066. >processes in the code or product.
  9067.  
  9068. Is it at all possible that 3Com could ever *eliminate* beaurocracy in
  9069. their processes rather than constantly adding layer upon layer of it?
  9070.  
  9071. >     I hope this helps.
  9072.  
  9073. Unfortunately, no, I doubt it really does.  :/
  9074.  
  9075. Does anyone in upper management at 3Com listen to what we're saying?  I
  9076. sometimes get the distinct impression that they really don't give a crap
  9077. what we feel.  I guess that is progress though...we do have *some*
  9078. people at 3Com listening to us now...even if they aren't the people
  9079. making decisions on most of these things.
  9080.  
  9081. Jeff "getting frustrated with 3Com idiocy again" McAdams
  9082.  
  9083. -
  9084.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9085.  with "unsubscribe usr-tc" in the body of the message.
  9086.  For information on digests or retrieving files and old messages send
  9087.  "help" to the same address.  Do not use quotes in your message.
  9088.  
  9089.  
  9090. -------------------------------------------------------------------------------
  9091.  
  9092. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  9093. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9094. Date: 12 Oct 1999 12:36:54 -0500
  9095.  
  9096.  
  9097.  
  9098.      Jeff:
  9099.  
  9100.      I think you have missed the point.   We don't just want to "Throw Code" at
  9101. given issues.  It may seem like extra steps, and sometimes it is laborious to
  9102. follow these procedures, but in business, law, and especially in science, if you
  9103. don't have clearly documented data trails, and reproducible results - then you
  9104. have not accomplished a darn thing.
  9105.  
  9106.      Once again:
  9107.                >This is done so that we can document the use of these special
  9108. codes to
  9109.                >see if the code fixes the specific issue it was designed to
  9110. address, AND also
  9111.                >to see if the new fix for one issue causes issues with any other
  9112.                >processes in the code or product.
  9113.  
  9114.      If we were to just release code "willy nilly" and not track what we've
  9115. done, it would be of no use to anyone, and we would be breaking many more things
  9116. than we fix.
  9117.  
  9118.      ER code is "special issue" code that addresses one speicific problem, and
  9119. it is not feasible to stress check this code for all possible issues in all
  9120. possible configurations.  A specific ER code may have a known issue with another
  9121. process - and that will be fixed before an ER is promoted to a Service Release.
  9122. In the meanwhile customers who desperately need one item fixed, and who can
  9123. "make due" while any other errors are resolved - can do just that - they can get
  9124. the fix that they need - and they can get it NOW (which is the whole point of
  9125. this process).
  9126.  
  9127.      I hope this clarifies my prior statements, and I hope this helps to clarify
  9128. what could on the surface seem to be another "Stupid Policy" that is actually
  9129. just a part of the Scientific Method.
  9130.  
  9131.  
  9132.      Todd ;-}
  9133.  
  9134.  
  9135.  
  9136.  
  9137.  
  9138.  
  9139. Jeff Mcadams <jeffm@iglou.com> on 10/12/99 12:12:31 PM
  9140.  
  9141. Please respond to usr-tc@lists.xmission.com
  9142.  
  9143. Sent by:  Jeff Mcadams <jeffm@iglou.com>
  9144.  
  9145.  
  9146. cc:    (Todd Keister/MW/US/3Com)
  9147.  
  9148.  
  9149.  
  9150.  
  9151. Thus spake Todd Keister
  9152. >     ER or Engineering Release Code is only available by calling to
  9153. >Tech Support, and then WE (Tech Support) must get permission to release
  9154. >the code.
  9155.  
  9156. Good grief, its getting worse.  What's next?  Are we going to have to
  9157. get a note from our mother's to use ER code?  Blech.
  9158.  
  9159. >This is done so that we can document the use of these special codes to
  9160. >see if the fix the specific issue they are supposed address, and also
  9161. >to see if the new fix for one issue causes issues with any other
  9162. >processes in the code or product.
  9163.  
  9164. Is it at all possible that 3Com could ever *eliminate* beaurocracy in
  9165. their processes rather than constantly adding layer upon layer of it?
  9166.  
  9167. >     I hope this helps.
  9168.  
  9169. Unfortunately, no, I doubt it really does.  :/
  9170.  
  9171. Does anyone in upper management at 3Com listen to what we're saying?  I
  9172. sometimes get the distinct impression that they really don't give a crap
  9173. what we feel.  I guess that is progress though...we do have *some*
  9174. people at 3Com listening to us now...even if they aren't the people
  9175. making decisions on most of these things.
  9176.  
  9177. Jeff "getting frustrated with 3Com idiocy again" McAdams
  9178.  
  9179. -
  9180.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9181.  with "unsubscribe usr-tc" in the body of the message.
  9182.  For information on digests or retrieving files and old messages send
  9183.  "help" to the same address.  Do not use quotes in your message.
  9184.  
  9185.  
  9186.  
  9187.  
  9188.  
  9189.  
  9190. -
  9191.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9192.  with "unsubscribe usr-tc" in the body of the message.
  9193.  For information on digests or retrieving files and old messages send
  9194.  "help" to the same address.  Do not use quotes in your message.
  9195.  
  9196.  
  9197. -------------------------------------------------------------------------------
  9198.  
  9199. From: Jeff Mcadams <jeffm@iglou.com>
  9200. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9201. Date: 12 Oct 1999 14:01:36 -0400
  9202.  
  9203. Thus spake Todd Keister
  9204. >     I think you have missed the point.   We don't just want to "Throw
  9205. >Code" at given issues.  It may seem like extra steps, and sometimes it
  9206. >is laborious to follow these procedures, but in business, law, and
  9207. >especially in science, if you don't have clearly documented data
  9208. >trails, and reproducible results - then you have not accomplished a
  9209. >darn thing.
  9210.  
  9211. No...I didn't miss the point...I understand where you're coming
  9212. from...*however*.  This seems (from my perspective at least) to be a
  9213. reaction to as you put it "release[ing] code 'willy nilly'".  IMO, the
  9214. fix isn't to put yet another layer of beaurocracy down to track it, the
  9215. real fix is to have tech support be good enough at what they do, and
  9216. enough information available to them (I think this second part is the
  9217. killer) that they can more intelligently use ER code releases as
  9218. trouble-shooting tools.  This is, as you say, intended to provide a fix
  9219. for those that need it, and feedback on those fixes before they're put
  9220. into an SR, but putting yet another layer of beaurocracy on this just
  9221. puts that much more difficulty on us, the customers actually *using*
  9222. this equipment and code, from being able to make the most from it.
  9223.  
  9224. Basically, 3Com just added yet one more layer between us, the customers,
  9225. and the development process of the code, yet one more layer that
  9226. insulates our feedback from the actual people making decisions about
  9227. the development of the product(s).
  9228.  
  9229. Please don't get me wrong, Todd...I'm certainly not trying to take a
  9230. shot at you, or any other tech support folks.  I'm taking a shot at 3Com
  9231. overall, who's (corporate) reaction to things seems to be to add more
  9232. beaurocracy to things where there are problems in an effort to fix
  9233. them...when...at the core, at least a major component of the problems are
  9234. that there's entirely too much beaurocracy already, and customers are
  9235. already entirely too isolated from the development effort.
  9236.  
  9237. >     I hope this clarifies my prior statements, and I hope this helps
  9238. >to clarify what could on the surface seem to be another "Stupid Policy"
  9239. >that is actually just a part of the Scientific Method.
  9240.  
  9241. Oh, I'm very clear on 3Com's thinking here...some of it even makes
  9242. sense...that doesn't mean its not "another 'Stupid Policy'" though.  ;)
  9243.  
  9244. My other question still stands though...and this may be one that you,
  9245. Todd, may not be able to answer, and I can understand that...but does
  9246. upper management at 3Com really take us seriously?  We (the users of tc
  9247. equipment on this list) have constently, over the years, alerted 3Com to
  9248. problem after problem, most of which were ignored until they reached
  9249. epic proportions, resulted in various people threatening lawsuits,
  9250. resulted in cascades of complaints from the users both on this list and
  9251. in the totalservice fora.  These problems are, almost invariably, not
  9252. acted upon until it reached a crisis situation at 3Com and consequently
  9253. took much greater effort to fix than it would have if addressed when it
  9254. was first mentioned on the list.
  9255.  
  9256. I will say that 3Com has seemed to become more responsive to actual
  9257. implementation problems...ie, actually fixing bugs in code...while at
  9258. the same time making it, in many cases, actually harder for the customer
  9259. to get ahold of the code that makes the fixes.  Security issues are
  9260. still dealt with in much too slow of a manner.  I reported "Yet
  9261. Another(tm)" SNMP bug in the Total Control platform almost 3 weeks ago
  9262. now (not yet made public...will be soon), and still haven't gotten any
  9263. feedback about it.  3 weeks is *way* too long for a bug like this to
  9264. exist in a known state.  There should be an SR release for security
  9265. issues made immediately...take the last released code...start from that
  9266. base, and develop a fix for the security hole independently of your
  9267. other fixes...3Com seems to have a *very* lax attitude concerning
  9268. security fixes.
  9269.  
  9270. We've been complaining about support contracts for years now...any
  9271. progress there?  None that I've heard of...indeed, this too has gone in
  9272. the wrong direction.  Used to be that you had to have equal support
  9273. coverage on each card in a chassis, then you had to have it on each
  9274. chassis in a location, now you have to have it on all your chassis in
  9275. all your locations.  This should be going the other direction!  There
  9276. are easily accessible serial numbers on each card (shoot, you can even
  9277. pull them up in a nice clean spreadsheet format via TCM!), why not have
  9278. support contracts be done on a per-card basis?  Again...we here at IgLou
  9279. specifically have been asking for exactly this for over a year, and the
  9280. only response we have gotten from *anyone* (other than our sales rep,
  9281. who agrees with us) has been a call to give us the pricing as it
  9282. currently exists, they were *totally* unwilling to even *consider* that
  9283. their support contract structure was sub-optimal.
  9284.  
  9285. 3Com has *YET* to deal with the NETServer to HiPer Arc upgrade issue.
  9286. They still are foisting essentially a Bait and Switch tactic on their
  9287. long-time customers that have NETServer cards.  3Com has known about
  9288. issues in the NETServer code base and refuses to take necessary and
  9289. available steps to fix them (either replace the cards with Arcs, or
  9290. back-port Pilgrim to the older cards, either would be an acceptable
  9291. solution, 3Com refuses to do either), and now I've heard reports that
  9292. 3Com tech support folks either don't know about this situation (broken
  9293. MPIP in NETServers specifically) or don't acknowledge it as a known
  9294. problem.  Yeesh.  I answered a post in the totalservice *.totalcontrol
  9295. newsgroup just the other day telling someone that they were SOL
  9296. regarding this issue because 3Com refused to stand by their product.
  9297.  
  9298. These are the types of things that illustrate what I'm talking
  9299. about...3Com would rather add more beaurocracy and hierarchy to things
  9300. to try to fix it rather than step back, realize that the beaurocracy and
  9301. hierarchy is largely what's standing in their way from figuring out what
  9302. the real fixes are.
  9303. -- 
  9304. Jeff McAdams                            Email: jeffm@iglou.com
  9305. Head Network Administrator              Voice: (502) 966-3848
  9306. IgLou Internet Services                        (800) 436-4456
  9307.  
  9308. -
  9309.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9310.  with "unsubscribe usr-tc" in the body of the message.
  9311.  For information on digests or retrieving files and old messages send
  9312.  "help" to the same address.  Do not use quotes in your message.
  9313.  
  9314.  
  9315. -------------------------------------------------------------------------------
  9316.  
  9317. From: "Marshall Morgan" <marshall@netdoor.com>
  9318. Subject: RE: (usr-tc) 2.0.60 HDM Code
  9319. Date: 12 Oct 1999 13:06:45 -0500
  9320.  
  9321. We just purchased additional DSP Upgrade kits.  How to we get more recent code
  9322. on them if they ship with older code without a service contract?
  9323.  
  9324. BTW: Making code fixes available without service contracts is a good way to
  9325. ensure the 3com name stays good in the eyes of the end-user customer ... or
  9326. would 3com rather have us run old code (with old code problems) on our modems
  9327. that does not work with our newer customer modems.
  9328.  
  9329. Marshall Morgan
  9330.  
  9331. > -----Original Message-----
  9332. > From: owner-usr-tc@lists.xmission.com
  9333. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister
  9334. > Sent: Tuesday, October 12, 1999 12:37 PM
  9335. > To: usr-tc@lists.xmission.com
  9336. > Subject: Re: (usr-tc) 2.0.60 HDM Code
  9337. >
  9338. >
  9339. >
  9340. >
  9341. >      Jeff:
  9342. >
  9343. >      I think you have missed the point.   We don't just want to
  9344. > "Throw Code" at
  9345. > given issues.  It may seem like extra steps, and sometimes it is
  9346. > laborious to
  9347. > follow these procedures, but in business, law, and especially in
  9348. > science, if you
  9349. > don't have clearly documented data trails, and reproducible results
  9350. > - then you
  9351. > have not accomplished a darn thing.
  9352. >
  9353. >      Once again:
  9354. >                >This is done so that we can document the use of
  9355. > these special
  9356. > codes to
  9357. >                >see if the code fixes the specific issue it was designed to
  9358. > address, AND also
  9359. >                >to see if the new fix for one issue causes issues
  9360. > with any other
  9361. >                >processes in the code or product.
  9362. >
  9363. >      If we were to just release code "willy nilly" and not track what we've
  9364. > done, it would be of no use to anyone, and we would be breaking
  9365. > many more things
  9366. > than we fix.
  9367. >
  9368. >      ER code is "special issue" code that addresses one speicific
  9369. > problem, and
  9370. > it is not feasible to stress check this code for all possible issues in all
  9371. > possible configurations.  A specific ER code may have a known issue
  9372. > with another
  9373. > process - and that will be fixed before an ER is promoted to a
  9374. > Service Release.
  9375. > In the meanwhile customers who desperately need one item fixed, and who can
  9376. > "make due" while any other errors are resolved - can do just that -
  9377. > they can get
  9378. > the fix that they need - and they can get it NOW (which is the
  9379. > whole point of
  9380. > this process).
  9381. >
  9382. >      I hope this clarifies my prior statements, and I hope this
  9383. > helps to clarify
  9384. > what could on the surface seem to be another "Stupid Policy" that
  9385. > is actually
  9386. > just a part of the Scientific Method.
  9387. >
  9388. >
  9389. >      Todd ;-}
  9390.  
  9391.  
  9392. -
  9393.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9394.  with "unsubscribe usr-tc" in the body of the message.
  9395.  For information on digests or retrieving files and old messages send
  9396.  "help" to the same address.  Do not use quotes in your message.
  9397.  
  9398.  
  9399. -------------------------------------------------------------------------------
  9400.  
  9401. From: Jeff Mcadams <jeffm@iglou.com>
  9402. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9403. Date: 12 Oct 1999 14:13:46 -0400
  9404.  
  9405. Thus spake Marshall Morgan
  9406. >We just purchased additional DSP Upgrade kits.  How to we get more recent code
  9407. >on them if they ship with older code without a service contract?
  9408.  
  9409. In this specific situation, you can go to the totalservice website and
  9410. register your new cards for warranty support.  This last for 90 days and
  9411. gets you full access to all the code I believe.  The suggestion I heard,
  9412. because of a bug in the registration code on their web site, is that its
  9413. a good idea to set up a new login and password for the totalservice web
  9414. site each time you do this...something about overlapping warranty
  9415. periods not being recognized correctly and when the first warranty
  9416. period runs out your access to the code is revoked...even though you
  9417. have other warranties still in effect.
  9418. -- 
  9419. Jeff McAdams                            Email: jeffm@iglou.com
  9420. Head Network Administrator              Voice: (502) 966-3848
  9421. IgLou Internet Services                        (800) 436-4456
  9422.  
  9423. -
  9424.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9425.  with "unsubscribe usr-tc" in the body of the message.
  9426.  For information on digests or retrieving files and old messages send
  9427.  "help" to the same address.  Do not use quotes in your message.
  9428.  
  9429.  
  9430. -------------------------------------------------------------------------------
  9431.  
  9432. From: "Todd Keister" <Todd_Keister@mw.3com.com>
  9433. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9434. Date: 12 Oct 1999 14:15:42 -0500
  9435.  
  9436.  
  9437.  
  9438.  
  9439.  
  9440.      Jeff was right "On the Money" with this one....
  9441.  
  9442.  
  9443.      The purchase of a new kit, or product gives you access to the website for
  9444. software upgrades, as well as technical support for 90 days.  If you have
  9445. problems accessing the site, please call us at Tech Support.  We may be able to
  9446. help.  The hours for this kind of support are 8AM to 5PM, but since this covers
  9447. the entire country this works out to 8AM EST to 5 PM PST, or 7AM to 7PM Central
  9448. (we're in Chicago).
  9449.  
  9450.      If you, the members of this list, ever have issues, then please call us at
  9451. (800) 231-8770.
  9452.  
  9453.      You will also find that our Knowledgebase tool has been making great
  9454. strides.  We have populated the database with many more solutions, and many of
  9455. these have now been published on the web based interface for use by anyone.
  9456. This is located at http://knowledgebase.3com.com/
  9457.  
  9458.  
  9459.      I hope this helps.
  9460.  
  9461.      Todd ;-}
  9462.  
  9463.      PS:  If you are wondering why you may get cards with "old code" it may be
  9464. related to the card being warehoused first by 3Com, and then by the
  9465. Wholesaler/Distributor, and possibly a Reseller as well.  Supply chains and
  9466. beaurocracy - I won't go there.... ;-}
  9467.  
  9468.  
  9469.  
  9470.  
  9471.  
  9472.  
  9473. Jeff Mcadams <jeffm@iglou.com> on 10/12/99 01:13:46 PM
  9474.  
  9475. Please respond to usr-tc@lists.xmission.com
  9476.  
  9477. Sent by:  Jeff Mcadams <jeffm@iglou.com>
  9478.  
  9479.  
  9480. cc:    (Todd Keister/MW/US/3Com)
  9481.  
  9482.  
  9483.  
  9484.  
  9485. Thus spake Marshall Morgan
  9486. >We just purchased additional DSP Upgrade kits.  How to we get more recent code
  9487. >on them if they ship with older code without a service contract?
  9488.  
  9489. In this specific situation, you can go to the totalservice website and
  9490. register your new cards for warranty support.  This last for 90 days and
  9491. gets you full access to all the code I believe.  The suggestion I heard,
  9492. because of a bug in the registration code on their web site, is that its
  9493. a good idea to set up a new login and password for the totalservice web
  9494. site each time you do this...something about overlapping warranty
  9495. periods not being recognized correctly and when the first warranty
  9496. period runs out your access to the code is revoked...even though you
  9497. have other warranties still in effect.
  9498. --
  9499. Jeff McAdams                            Email: jeffm@iglou.com
  9500. Head Network Administrator              Voice: (502) 966-3848
  9501. IgLou Internet Services                        (800) 436-4456
  9502.  
  9503. -
  9504.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9505.  with "unsubscribe usr-tc" in the body of the message.
  9506.  For information on digests or retrieving files and old messages send
  9507.  "help" to the same address.  Do not use quotes in your message.
  9508.  
  9509.  
  9510.  
  9511.  
  9512.  
  9513.  
  9514. -
  9515.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9516.  with "unsubscribe usr-tc" in the body of the message.
  9517.  For information on digests or retrieving files and old messages send
  9518.  "help" to the same address.  Do not use quotes in your message.
  9519.  
  9520.  
  9521. -------------------------------------------------------------------------------
  9522.  
  9523. From:  <farber@admin.f-tech.net>
  9524. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9525. Date: 12 Oct 1999 19:57:02 -0400 (EDT)
  9526.  
  9527. One of the few pleasures in life is telling the salesbot on the phone
  9528. that I will NOT be renewing my support contract.
  9529.  
  9530. For the amount it would cost to cover 2 chassis and a dozen DSP's, ARC's
  9531. and NMC's they need to do alot better than they are now.
  9532.  
  9533. They released NFAS code and OSPF beta code... whipee.  Make the damned
  9534. thing connect more reliabily and then worry about networking code (ala
  9535. OSPF).  
  9536.  
  9537. Paul Farber
  9538. Farber Technology
  9539. farber@admin.f-tech.net
  9540. Ph  570-628-5303
  9541. Fax 570-628-5545
  9542.  
  9543. On Tue, 12 Oct 1999, Jeff Mcadams wrote:
  9544.  
  9545. > Thus spake Todd Keister
  9546. > >     ER or Engineering Release Code is only available by calling to
  9547. > >Tech Support, and then WE (Tech Support) must get permission to release
  9548. > >the code.  
  9549. > 
  9550. > Good grief, its getting worse.  What's next?  Are we going to have to
  9551. > get a note from our mother's to use ER code?  Blech.
  9552. > 
  9553. > >This is done so that we can document the use of these special codes to
  9554. > >see if the fix the specific issue they are supposed address, and also
  9555. > >to see if the new fix for one issue causes issues with any other
  9556. > >processes in the code or product.
  9557. > 
  9558. > Is it at all possible that 3Com could ever *eliminate* beaurocracy in
  9559. > their processes rather than constantly adding layer upon layer of it?
  9560. > 
  9561. > >     I hope this helps.
  9562. > 
  9563. > Unfortunately, no, I doubt it really does.  :/
  9564. > 
  9565. > Does anyone in upper management at 3Com listen to what we're saying?  I
  9566. > sometimes get the distinct impression that they really don't give a crap
  9567. > what we feel.  I guess that is progress though...we do have *some*
  9568. > people at 3Com listening to us now...even if they aren't the people
  9569. > making decisions on most of these things.
  9570. > 
  9571. > Jeff "getting frustrated with 3Com idiocy again" McAdams
  9572. > 
  9573. > -
  9574. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9575. >  with "unsubscribe usr-tc" in the body of the message.
  9576. >  For information on digests or retrieving files and old messages send
  9577. >  "help" to the same address.  Do not use quotes in your message.
  9578. > 
  9579.  
  9580.  
  9581. -
  9582.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9583.  with "unsubscribe usr-tc" in the body of the message.
  9584.  For information on digests or retrieving files and old messages send
  9585.  "help" to the same address.  Do not use quotes in your message.
  9586.  
  9587.  
  9588. -------------------------------------------------------------------------------
  9589.  
  9590. From: Corneliu Rudeanu <rudy@dntis.ro>
  9591. Subject: (usr-tc) Radius question
  9592. Date: 13 Oct 1999 03:42:43 +0300 (EEST)
  9593.  
  9594.  
  9595. I was really surprised to see how HARC deals with the radius packet
  9596. identifier.
  9597.  
  9598. RFC states as clear as posibile: "For retransmissions where the contents
  9599. are identical, the Identifier MUST remain unchanged.".
  9600.  
  9601. Yet watching (monitor radius) the id-s of the packets being retransmited I
  9602. found that hiperArc (4.2.29) assigns diferrent id for the packets being
  9603. re-sent to radius server for the same accounting request.
  9604.  
  9605. My question: how is suposed a Radius server to identify the duplicates?
  9606.  
  9607. TIA,
  9608. Corneliu
  9609.  
  9610.  
  9611.  
  9612.  
  9613. -
  9614.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9615.  with "unsubscribe usr-tc" in the body of the message.
  9616.  For information on digests or retrieving files and old messages send
  9617.  "help" to the same address.  Do not use quotes in your message.
  9618.  
  9619.  
  9620. -------------------------------------------------------------------------------
  9621.  
  9622. From: jeff.binkley@asacomp.com (Jeff Binkley)
  9623. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9624. Date: 12 Oct 1999 20:49:00 -0500
  9625.  
  9626. -> One of the few pleasures in life is telling the salesbot on the phone that I
  9627. -> will NOT be renewing my support contract.
  9628. ->
  9629. -> For the amount it would cost to cover 2 chassis and a dozen DSP's, ARC's and
  9630. -> NMC's they need to do alot better than they are now.
  9631. ->
  9632. -> They released NFAS code and OSPF beta code... whipee.  Make the damned thing
  9633. -> connect more reliabily and then worry about networking code (ala OSPF).
  9634.  
  9635. I too boycotted renewing my maintenance contract for almost a year
  9636. for many of the same reasons you and others have expressed.  I just
  9637. downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
  9638. Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
  9639. killed my webramps.  I was actually on Ramp Networks website tonight and
  9640. they have an engineering note specifically for TC w/HiPerArcs.  They
  9641. pretty much pointed the gun straight at 3Com.   Back to the original
  9642. point of your message I wonder how many of us have witheld revenue from
  9643. 3Com over the maintenance contract issues  ?  I will say the
  9644. process for purchasing the maintenance contract and getting it
  9645. active was much much better this time (albeit I couldn't active
  9646. it via the website due to some cgi problem) but the ole reliable
  9647. fax machine came through with flying colors.
  9648.  
  9649.  
  9650. Jeff Binkley
  9651. ASA Network Computing
  9652.  
  9653. -
  9654.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9655.  with "unsubscribe usr-tc" in the body of the message.
  9656.  For information on digests or retrieving files and old messages send
  9657.  "help" to the same address.  Do not use quotes in your message.
  9658.  
  9659.  
  9660. -------------------------------------------------------------------------------
  9661.  
  9662. From: Aaron Nabil <nabil@spiritone.com>
  9663. Subject: Re: (usr-tc) Radius question
  9664. Date: 12 Oct 1999 18:14:07 -0700 (PDT)
  9665.  
  9666. Corneliu Rudeanu writes...
  9667. >I was really surprised to see how HARC deals with the radius packet
  9668. >identifier.
  9669. >
  9670. >RFC states as clear as posibile: "For retransmissions where the contents
  9671. >are identical, the Identifier MUST remain unchanged.".
  9672. >
  9673. >Yet watching (monitor radius) the id-s of the packets being retransmited I
  9674. >found that hiperArc (4.2.29) assigns diferrent id for the packets being
  9675. >re-sent to radius server for the same accounting request.
  9676.  
  9677. Hah!  It's much better than that!  (Note the date, too!)
  9678.  
  9679. >From: Aaron Nabil <nabil@spiritone.com>
  9680. >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
  9681. >Date: 14 Jun 1998 16:58:15 -0700 (PDT)
  9682. >
  9683. >
  9684. >The HiperArc has a nasty Radius bug.
  9685. >
  9686. >If a packet get lost in transit or for some other reason is never 
  9687. >acknoweldged, the HiperArc increments the identifier and tries 
  9688. >sending it again after the timeout period.
  9689. >
  9690. >But later, when it comes time to send another request, it has 
  9691. >"forgotten" that it previously incremented the identifier and merrily 
  9692. >uses the last one again!
  9693.  
  9694. Not only does it incorrectly increment the identifier, it then
  9695. goes on to re-use the same identifier again later!  Yes, this is
  9696. so incredibly broken it's not even imaginable that it hasn't
  9697. been fixed.  But it hasn't.  
  9698.  
  9699. >My question: how is suposed a Radius server to identify the duplicates?
  9700.  
  9701. The Radius server is supposed to contact the System Administrator
  9702. and get him to purchase products from a vendor that knows how to 
  9703. read a RFC, or, failing that, at least fixes problems when they
  9704. are pointed out to them.
  9705.  
  9706. -- 
  9707. Aaron Nabil
  9708.  
  9709. -
  9710.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9711.  with "unsubscribe usr-tc" in the body of the message.
  9712.  For information on digests or retrieving files and old messages send
  9713.  "help" to the same address.  Do not use quotes in your message.
  9714.  
  9715.  
  9716. -------------------------------------------------------------------------------
  9717.  
  9718. From: Brian <signal@shreve.net>
  9719. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9720. Date: 12 Oct 1999 20:28:46 -0500 (CDT)
  9721.  
  9722.  
  9723.  
  9724. Ok, here is an idea.  At least post on Totalservice what ER codes are
  9725. available, what they are supposed to fix.  This way we know the option
  9726. exists.
  9727.  
  9728. Another plus would be "fill out this form before downloading the code".
  9729. Then you all could spam our mailboxes and ask us to evaluate the
  9730. code........a little automation, good for us, good for you, you don't have
  9731. to pay those expensive tech support people just to hand us the ER code,
  9732. you get your data, and we get our code.
  9733.  
  9734. Brian
  9735.  
  9736.  
  9737. On Tue, 12 Oct 1999, Todd Keister wrote:
  9738.  
  9739. > 
  9740. > 
  9741. >      Jeff:
  9742. > 
  9743. >      I think you have missed the point.   We don't just want to "Throw Code" at
  9744. > given issues.  It may seem like extra steps, and sometimes it is laborious to
  9745. > follow these procedures, but in business, law, and especially in science, if you
  9746. > don't have clearly documented data trails, and reproducible results - then you
  9747. > have not accomplished a darn thing.
  9748. > 
  9749. >      Once again:
  9750. >                >This is done so that we can document the use of these special
  9751. > codes to
  9752. >                >see if the code fixes the specific issue it was designed to
  9753. > address, AND also
  9754. >                >to see if the new fix for one issue causes issues with any other
  9755. >                >processes in the code or product.
  9756. > 
  9757. >      If we were to just release code "willy nilly" and not track what we've
  9758. > done, it would be of no use to anyone, and we would be breaking many more things
  9759. > than we fix.
  9760. > 
  9761. >      ER code is "special issue" code that addresses one speicific problem, and
  9762. > it is not feasible to stress check this code for all possible issues in all
  9763. > possible configurations.  A specific ER code may have a known issue with another
  9764. > process - and that will be fixed before an ER is promoted to a Service Release.
  9765. > In the meanwhile customers who desperately need one item fixed, and who can
  9766. > "make due" while any other errors are resolved - can do just that - they can get
  9767. > the fix that they need - and they can get it NOW (which is the whole point of
  9768. > this process).
  9769. > 
  9770. >      I hope this clarifies my prior statements, and I hope this helps to clarify
  9771. > what could on the surface seem to be another "Stupid Policy" that is actually
  9772. > just a part of the Scientific Method.
  9773. > 
  9774. > 
  9775. >      Todd ;-}
  9776. > 
  9777. > 
  9778. > 
  9779. > 
  9780. > 
  9781. > 
  9782. > Jeff Mcadams <jeffm@iglou.com> on 10/12/99 12:12:31 PM
  9783. > 
  9784. > Please respond to usr-tc@lists.xmission.com
  9785. > 
  9786. > Sent by:  Jeff Mcadams <jeffm@iglou.com>
  9787. > 
  9788. > 
  9789. > To:   usr-tc@lists.xmission.com
  9790. > cc:    (Todd Keister/MW/US/3Com)
  9791. > Subject:  Re: (usr-tc) 2.0.60 HDM Code
  9792. > 
  9793. > 
  9794. > 
  9795. > 
  9796. > Thus spake Todd Keister
  9797. > >     ER or Engineering Release Code is only available by calling to
  9798. > >Tech Support, and then WE (Tech Support) must get permission to release
  9799. > >the code.
  9800. > 
  9801. > Good grief, its getting worse.  What's next?  Are we going to have to
  9802. > get a note from our mother's to use ER code?  Blech.
  9803. > 
  9804. > >This is done so that we can document the use of these special codes to
  9805. > >see if the fix the specific issue they are supposed address, and also
  9806. > >to see if the new fix for one issue causes issues with any other
  9807. > >processes in the code or product.
  9808. > 
  9809. > Is it at all possible that 3Com could ever *eliminate* beaurocracy in
  9810. > their processes rather than constantly adding layer upon layer of it?
  9811. > 
  9812. > >     I hope this helps.
  9813. > 
  9814. > Unfortunately, no, I doubt it really does.  :/
  9815. > 
  9816. > Does anyone in upper management at 3Com listen to what we're saying?  I
  9817. > sometimes get the distinct impression that they really don't give a crap
  9818. > what we feel.  I guess that is progress though...we do have *some*
  9819. > people at 3Com listening to us now...even if they aren't the people
  9820. > making decisions on most of these things.
  9821. > 
  9822. > Jeff "getting frustrated with 3Com idiocy again" McAdams
  9823. > 
  9824. > -
  9825. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9826. >  with "unsubscribe usr-tc" in the body of the message.
  9827. >  For information on digests or retrieving files and old messages send
  9828. >  "help" to the same address.  Do not use quotes in your message.
  9829. > 
  9830. > 
  9831. > 
  9832. > 
  9833. > 
  9834. > 
  9835. > -
  9836. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9837. >  with "unsubscribe usr-tc" in the body of the message.
  9838. >  For information on digests or retrieving files and old messages send
  9839. >  "help" to the same address.  Do not use quotes in your message.
  9840. > 
  9841.  
  9842. Brian Feeny (BF304)     signal@shreve.net   
  9843. 318-222-2638 x 109    http://www.shreve.net/~signal      
  9844. Network Administrator   ShreveNet Inc. (ASN 11881)           
  9845.  
  9846.  
  9847. -
  9848.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9849.  with "unsubscribe usr-tc" in the body of the message.
  9850.  For information on digests or retrieving files and old messages send
  9851.  "help" to the same address.  Do not use quotes in your message.
  9852.  
  9853.  
  9854. -------------------------------------------------------------------------------
  9855.  
  9856. From: Brian <signal@shreve.net>
  9857. Subject: Re: (usr-tc) 2.0.60 HDM Code
  9858. Date: 12 Oct 1999 20:34:24 -0500 (CDT)
  9859.  
  9860. On Tue, 12 Oct 1999, Todd Keister wrote:
  9861.  
  9862. > 
  9863. > 
  9864. > 
  9865. > 
  9866. >      Jeff was right "On the Money" with this one....
  9867. > 
  9868. > 
  9869. >      The purchase of a new kit, or product gives you access to the website for
  9870. > software upgrades, as well as technical support for 90 days.  If you have
  9871. > problems accessing the site, please call us at Tech Support.  We may be able to
  9872. > help.  The hours for this kind of support are 8AM to 5PM, but since this covers
  9873. > the entire country this works out to 8AM EST to 5 PM PST, or 7AM to 7PM Central
  9874. > (we're in Chicago).
  9875. > 
  9876.  
  9877. he was also right on the money when he spoke of the bug thats been in that
  9878. system for a LONG time.  The one where overlapping warranty periods
  9879. totally screw you out of your code, since you don't get access for the
  9880. first 90 days.
  9881.  
  9882. It would be great if 3Com could use all those millions of dollars it makes
  9883. of selling of their stuff, and pay a single person, maybe $25 per hour, to
  9884. fix that bug in your system............
  9885.  
  9886.  
  9887. >      If you, the members of this list, ever have issues, then please call us at
  9888. > (800) 231-8770.
  9889. > 
  9890. >      You will also find that our Knowledgebase tool has been making great
  9891. > strides.  We have populated the database with many more solutions, and many of
  9892. > these have now been published on the web based interface for use by anyone.
  9893. > This is located at http://knowledgebase.3com.com/
  9894. > 
  9895. > 
  9896. >      I hope this helps.
  9897. > 
  9898. >      Todd ;-}
  9899. > 
  9900. >      PS:  If you are wondering why you may get cards with "old code" it may be
  9901. > related to the card being warehoused first by 3Com, and then by the
  9902. > Wholesaler/Distributor, and possibly a Reseller as well.  Supply chains and
  9903. > beaurocracy - I won't go there.... ;-}
  9904. > 
  9905. > 
  9906. > 
  9907. > 
  9908. > 
  9909. > 
  9910. > Jeff Mcadams <jeffm@iglou.com> on 10/12/99 01:13:46 PM
  9911. > 
  9912. > Please respond to usr-tc@lists.xmission.com
  9913. > 
  9914. > Sent by:  Jeff Mcadams <jeffm@iglou.com>
  9915. > 
  9916. > 
  9917. > To:   usr-tc@lists.xmission.com
  9918. > cc:    (Todd Keister/MW/US/3Com)
  9919. > Subject:  Re: (usr-tc) 2.0.60 HDM Code
  9920. > 
  9921. > 
  9922. > 
  9923. > 
  9924. > Thus spake Marshall Morgan
  9925. > >We just purchased additional DSP Upgrade kits.  How to we get more recent code
  9926. > >on them if they ship with older code without a service contract?
  9927. > 
  9928. > In this specific situation, you can go to the totalservice website and
  9929. > register your new cards for warranty support.  This last for 90 days and
  9930. > gets you full access to all the code I believe.  The suggestion I heard,
  9931. > because of a bug in the registration code on their web site, is that its
  9932. > a good idea to set up a new login and password for the totalservice web
  9933. > site each time you do this...something about overlapping warranty
  9934. > periods not being recognized correctly and when the first warranty
  9935. > period runs out your access to the code is revoked...even though you
  9936. > have other warranties still in effect.
  9937. > --
  9938. > Jeff McAdams                            Email: jeffm@iglou.com
  9939. > Head Network Administrator              Voice: (502) 966-3848
  9940. > IgLou Internet Services                        (800) 436-4456
  9941. > 
  9942. > -
  9943. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9944. >  with "unsubscribe usr-tc" in the body of the message.
  9945. >  For information on digests or retrieving files and old messages send
  9946. >  "help" to the same address.  Do not use quotes in your message.
  9947. > 
  9948. > 
  9949. > 
  9950. > 
  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. Brian Feeny (BF304)     signal@shreve.net   
  9961. 318-222-2638 x 109    http://www.shreve.net/~signal      
  9962. Network Administrator   ShreveNet Inc. (ASN 11881)           
  9963.  
  9964.  
  9965. -
  9966.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9967.  with "unsubscribe usr-tc" in the body of the message.
  9968.  For information on digests or retrieving files and old messages send
  9969.  "help" to the same address.  Do not use quotes in your message.
  9970.  
  9971.  
  9972. -------------------------------------------------------------------------------
  9973.  
  9974. From: Brian <signal@shreve.net>
  9975. Subject: RE: (usr-tc) 2.0.60 HDM Code
  9976. Date: 12 Oct 1999 20:32:02 -0500 (CDT)
  9977.  
  9978. On Tue, 12 Oct 1999, Marshall Morgan wrote:
  9979.  
  9980. > We just purchased additional DSP Upgrade kits.  How to we get more recent code
  9981. > on them if they ship with older code without a service contract?
  9982.  
  9983. Login to totalservice.  Once in their, you can register equipment for
  9984. warranty.  It will want the serial numbers of the DSP cards.  Enter them,
  9985. it validates them in real time,and grants you access on the account you
  9986. are logged in with.
  9987.  
  9988. It works for me 50% of the time, but hopefully they have fixed any bugs in
  9989. that system.
  9990.  
  9991.  
  9992. > 
  9993. > BTW: Making code fixes available without service contracts is a good way to
  9994. > ensure the 3com name stays good in the eyes of the end-user customer ... or
  9995. > would 3com rather have us run old code (with old code problems) on our modems
  9996. > that does not work with our newer customer modems.
  9997.  
  9998. brian
  9999.  
  10000.  
  10001. > 
  10002. > Marshall Morgan
  10003. > 
  10004. > > -----Original Message-----
  10005. > > From: owner-usr-tc@lists.xmission.com
  10006. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister
  10007. > > Sent: Tuesday, October 12, 1999 12:37 PM
  10008. > > To: usr-tc@lists.xmission.com
  10009. > > Subject: Re: (usr-tc) 2.0.60 HDM Code
  10010. > >
  10011. > >
  10012. > >
  10013. > >
  10014. > >      Jeff:
  10015. > >
  10016. > >      I think you have missed the point.   We don't just want to
  10017. > > "Throw Code" at
  10018. > > given issues.  It may seem like extra steps, and sometimes it is
  10019. > > laborious to
  10020. > > follow these procedures, but in business, law, and especially in
  10021. > > science, if you
  10022. > > don't have clearly documented data trails, and reproducible results
  10023. > > - then you
  10024. > > have not accomplished a darn thing.
  10025. > >
  10026. > >      Once again:
  10027. > >                >This is done so that we can document the use of
  10028. > > these special
  10029. > > codes to
  10030. > >                >see if the code fixes the specific issue it was designed to
  10031. > > address, AND also
  10032. > >                >to see if the new fix for one issue causes issues
  10033. > > with any other
  10034. > >                >processes in the code or product.
  10035. > >
  10036. > >      If we were to just release code "willy nilly" and not track what we've
  10037. > > done, it would be of no use to anyone, and we would be breaking
  10038. > > many more things
  10039. > > than we fix.
  10040. > >
  10041. > >      ER code is "special issue" code that addresses one speicific
  10042. > > problem, and
  10043. > > it is not feasible to stress check this code for all possible issues in all
  10044. > > possible configurations.  A specific ER code may have a known issue
  10045. > > with another
  10046. > > process - and that will be fixed before an ER is promoted to a
  10047. > > Service Release.
  10048. > > In the meanwhile customers who desperately need one item fixed, and who can
  10049. > > "make due" while any other errors are resolved - can do just that -
  10050. > > they can get
  10051. > > the fix that they need - and they can get it NOW (which is the
  10052. > > whole point of
  10053. > > this process).
  10054. > >
  10055. > >      I hope this clarifies my prior statements, and I hope this
  10056. > > helps to clarify
  10057. > > what could on the surface seem to be another "Stupid Policy" that
  10058. > > is actually
  10059. > > just a part of the Scientific Method.
  10060. > >
  10061. > >
  10062. > >      Todd ;-}
  10063. > 
  10064. > 
  10065. > -
  10066. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10067. >  with "unsubscribe usr-tc" in the body of the message.
  10068. >  For information on digests or retrieving files and old messages send
  10069. >  "help" to the same address.  Do not use quotes in your message.
  10070. > 
  10071.  
  10072. Brian Feeny (BF304)     signal@shreve.net   
  10073. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10074. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10075.  
  10076.  
  10077. -
  10078.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10079.  with "unsubscribe usr-tc" in the body of the message.
  10080.  For information on digests or retrieving files and old messages send
  10081.  "help" to the same address.  Do not use quotes in your message.
  10082.  
  10083.  
  10084. -------------------------------------------------------------------------------
  10085.  
  10086. From: Brian <signal@shreve.net>
  10087. Subject: Re: (usr-tc) 2.0.60 HDM Code
  10088. Date: 12 Oct 1999 20:45:03 -0500 (CDT)
  10089.  
  10090. On Tue, 12 Oct 1999, Jeff Binkley wrote:
  10091.  
  10092. > -> One of the few pleasures in life is telling the salesbot on the phone that I
  10093. > -> will NOT be renewing my support contract.
  10094. > ->
  10095. > -> For the amount it would cost to cover 2 chassis and a dozen DSP's, ARC's and
  10096. > -> NMC's they need to do alot better than they are now.
  10097. > ->
  10098. > -> They released NFAS code and OSPF beta code... whipee.  Make the damned thing
  10099. > -> connect more reliabily and then worry about networking code (ala OSPF).
  10100. > 
  10101. > I too boycotted renewing my maintenance contract for almost a year
  10102. > for many of the same reasons you and others have expressed.  I just
  10103. > downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
  10104. > Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
  10105. > killed my webramps.  I was actually on Ramp Networks website tonight and
  10106. > they have an engineering note specifically for TC w/HiPerArcs.  They
  10107. > pretty much pointed the gun straight at 3Com.   Back to the original
  10108. > point of your message I wonder how many of us have witheld revenue from
  10109. > 3Com over the maintenance contract issues  ?  I will say the
  10110. > process for purchasing the maintenance contract and getting it
  10111. > active was much much better this time (albeit I couldn't active
  10112. > it via the website due to some cgi problem) but the ole reliable
  10113. > fax machine came through with flying colors.
  10114.  
  10115. We have.  I would be very happy to pay 3Com a fair price for maintenence
  10116. contracts.  We almost had a deal cinched and at the last minute they
  10117. changed the price, and we never went with it.
  10118.  
  10119. Once you are a certain size, and you have certain momentum, you are
  10120. *always* buying dsp's every few weeks.  So technically, if you just keep
  10121. registering those numbers on totalservice, you will always be covered
  10122. under 90 days support.
  10123.  
  10124. This is bad for 3com though, so they really should fix the contract
  10125. situation, so we can get real contracts.  I just want software, I am not
  10126. interested in there tech support.  I have been working on TC hubs for
  10127. years, setup dozens and dozens of them, and done just about everything
  10128. worth doing on them.  But I get subjected to calling into an 800 number,
  10129. at 11pm, so that some guy who sounds half asleep can call me back with a
  10130. piss poor (tired?) attitude, who probably has been working there like a
  10131. few weeks, or months, and doesn't have anywhere near the experience I do
  10132. on these hubs.  "Did you try rebooting the chassis?"...........
  10133.  
  10134. I feel I am in a constant battle with 3com, just to get code I have
  10135. legitimate access too etc.
  10136.  
  10137. I mean, if you buy a chassis that has TCS 3.5 on it, and you bought a
  10138. support contract with TCS 3.5..........shouldn't your account still let
  10139. you download the TCS 3.5 code forever?  I mean, its not like they are
  10140. giving you something you didn't already have........you paid for it, its
  10141. not a newer version, its the version that was on the damn thing when you
  10142. bought it!
  10143.  
  10144. I can log into Cisco, and download any code on that site, no questions
  10145. asked..........I can do that with a $250 2501 service contract.  Do I
  10146. screw Cisco? Hell no, because the contracts for *all* the stuff I have is
  10147. just as good of a deal as the pricing on the 2501 contracts.
  10148.  
  10149. You can bet that when people like myself need support contracts, its not
  10150. because we don't know how to use the equipment, its because the stuff
  10151. isn't working, we need fixes, we need to let 3com know it doesn't work.
  10152.  
  10153. > 
  10154. > 
  10155. > Jeff Binkley
  10156. > ASA Network Computing
  10157. > 
  10158. > -
  10159. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10160. >  with "unsubscribe usr-tc" in the body of the message.
  10161. >  For information on digests or retrieving files and old messages send
  10162. >  "help" to the same address.  Do not use quotes in your message.
  10163. > 
  10164.  
  10165. Brian Feeny (BF304)     signal@shreve.net   
  10166. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10167. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10168.  
  10169.  
  10170. -
  10171.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10172.  with "unsubscribe usr-tc" in the body of the message.
  10173.  For information on digests or retrieving files and old messages send
  10174.  "help" to the same address.  Do not use quotes in your message.
  10175.  
  10176.  
  10177. -------------------------------------------------------------------------------
  10178.  
  10179. From:  <farber@admin.f-tech.net>
  10180. Subject: Re: (usr-tc) 2.0.60 HDM Code
  10181. Date: 12 Oct 1999 22:17:24 -0400 (EDT)
  10182.  
  10183. I did just buy 4 DPS's and they did come with newer code than I had been
  10184. running... I haven't upgraded from 1.x to the 2.x simply because it really
  10185. didn't fix anything.. just added some features that I don't need.
  10186.  
  10187. I recall the DSP contract at $250 per DSP.. that's a dozen cards that need
  10188. covered (gotta have support for them all now).  Seeing that I have called
  10189. 3Com ZERO times this year (other than warranty repair) and the code I am
  10190. running now seems to be OK it's a hard sell to pull almost $3K from me for
  10191. support.
  10192.  
  10193. I was 2 seconds from ordering my first Ascend box.... I will now go back
  10194. and kick myself in the rear for buying DPS's.
  10195.  
  10196.  
  10197.  
  10198. Paul Farber
  10199. Farber Technology
  10200. farber@admin.f-tech.net
  10201. Ph  570-628-5303
  10202. Fax 570-628-5545
  10203.  
  10204. On Tue, 12 Oct 1999, Brian wrote:
  10205.  
  10206. > I can log into Cisco, and download any code on that site, no questions
  10207. > asked..........I can do that with a $250 2501 service contract.  Do I
  10208. > screw Cisco? Hell no, because the contracts for *all* the stuff I have is
  10209. > just as good of a deal as the pricing on the 2501 contracts.
  10210. > 
  10211. > You can bet that when people like myself need support contracts, its not
  10212. > because we don't know how to use the equipment, its because the stuff
  10213. > isn't working, we need fixes, we need to let 3com know it doesn't work.
  10214.  
  10215.  
  10216. -
  10217.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10218.  with "unsubscribe usr-tc" in the body of the message.
  10219.  For information on digests or retrieving files and old messages send
  10220.  "help" to the same address.  Do not use quotes in your message.
  10221.  
  10222.  
  10223. -------------------------------------------------------------------------------
  10224.  
  10225. From: "Mike McHenry" <mmchen@minn.net>
  10226. Subject: (usr-tc) OSPF default route problem
  10227. Date: 12 Oct 1999 21:16:34 -0500
  10228.  
  10229.  
  10230. Hello all,
  10231.  
  10232. I have been running OSPF on the 4.2.32-1 ARC code for several weeks and have
  10233. just started to see a disturbing problem. In certain cases it appears as
  10234. though the ARC is replacing it's own default route with the one advertised
  10235. in my OSPF broadcasts. My core router is set to advertise the default route
  10236. via OSPF with the following IOS config
  10237.  
  10238. router ospf 10
  10239.  default-information originate always
  10240.  
  10241. and in certain non-reproducable cases my chassis decide to favor this OSPF
  10242. default route over their own.
  10243.  
  10244. Obviously this is NOT correct behavior, OSPF-learned routes should NOT be
  10245. favored above static routes and that is what is happening here. After some
  10246. time the OSPF hiccups and I am left with several chassis that no longer have
  10247. a default route, not good.
  10248.  
  10249. Has anyone else run into this issue? I almost wonder if I am getting a
  10250. little too many routes in my OSPF area, things have been acting very odd
  10251. lately with OSPF in general on my USR TC chassis.
  10252.  
  10253. Mike McHenry
  10254.  Systems Administrator
  10255.  MinnNet Communications, Inc.
  10256.  
  10257.  
  10258. -
  10259.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10260.  with "unsubscribe usr-tc" in the body of the message.
  10261.  For information on digests or retrieving files and old messages send
  10262.  "help" to the same address.  Do not use quotes in your message.
  10263.  
  10264.  
  10265. -------------------------------------------------------------------------------
  10266.  
  10267. From: "Mike McHenry" <mmchen@minn.net>
  10268. Subject: RE: (usr-tc) arcs and ospf
  10269. Date: 12 Oct 1999 21:22:37 -0500
  10270.  
  10271. This exact problem has happened to me several times and it was NOT caused by
  10272. the ARC deciding to become the DR. I have a small network of about 13 Lucent
  10273. portmasters, 3 USR TC chassis, one Cisco 4500 and one Cisco 4700 router. ALL
  10274. of the termservers are set with OSPF priority 0, meaning they will never
  10275. become a DR or BDR. The Cisco 4500 and 4700 OSPF priorities were left as-is
  10276. leaving one to become the DR and the other to become the BDR.
  10277.  
  10278. If I rebooted or otherwise disturbed the DR the USR TC chassis would lose
  10279. all their OSPF routing. The Lucent equipment did not have a problem at all.
  10280. Getting the OSPF back on the USRs required a reboot of every chassis. For
  10281. now I have set one of the Ciscos to priority 0 so that it will never become
  10282. a BDR or DR. It seems as though the HARC cards have a problem recognizing a
  10283. change of a BDR to a DR while the rest of my equipment does not.
  10284.  
  10285. If this problem is indeed being caused by an ARC deciding to become a DR
  10286. then it would seem to be a bug. In my case this should not be happening as
  10287. all the HARCs are set to NOT participate in DR/BDR elections.
  10288.  
  10289. Mike McHenry
  10290.  Systems Administrator
  10291.  MinnNet Communications, Inc.
  10292.  
  10293. -----Original Message-----
  10294. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  10295. Sent: Monday, October 11, 1999 8:35 PM
  10296.  
  10297.  
  10298. Thus spake Mike Andrews
  10299. >I've been having a really bizarre problem off and on the last week or two.
  10300. >Occasionally some of my ARCs will suddenly stop doing OSPF right.  The
  10301. >routing table loses all OSPF routes, and the ARC stops announcing its
  10302. >routes via OSPF to our Ciscos.  Disabling/enabling OSPF doesn't help, but
  10303. >most of the time (not all the time) rebooting the ARC will.
  10304.  
  10305. >One thing that seemed to trigger it was rebooting some of our Ciscos...
  10306. >and since that happens so infrequently (not rebooted since going to ARC
  10307. >4.2 in fact) it's hard to track down.  I don't know which one exactly,
  10308. >maybe our AS border router dying is what threw it off.
  10309.  
  10310. Hrmm...something to check...not sure if this will have any
  10311. signficance...is the settings/values for the designated router on your
  10312. ethernet(s) when this happens.  I suspect your Cisco's were the
  10313. designated routers initially, and when they went away, one of your Arc's
  10314. got promoted to that...who knows what happened when your cisco's came
  10315. back.
  10316.  
  10317. When I was first playing with 4.2.29, I noticed a little bit of odd
  10318. behavior with the Arc's wrt designated routers...but then when I set up
  10319. a test lab environment for it, I couldn't reproduce it.  What I saw was
  10320. then I brought the Arc up on 4.2.29, it would take over the designated
  10321. router functionality somehow...which would be against the OSPF spec, but
  10322. possible for it to happen.  I haven't played with OSPF on the arc's
  10323. since then in any great depth...I've got one up and running on 4.2.32 at
  10324. this point, but haven't really done anything with it.
  10325.  
  10326. Maybe this will give you an idea of something to look at.  Switching
  10327. designated routers is definitely something you want to avoid if at all
  10328. possible because its going to cause a resyncronization of LSA databases
  10329. and a recalc of most (all?) of the shortest path first
  10330. calculations...so...this *can* cause up to a couple of minutes of your
  10331. routing being hosed as potentially every router on your network recalcs
  10332. its OSPF routes.
  10333. --
  10334. Jeff McAdams                            Email: jeffm@iglou.com
  10335. Head Network Administrator              Voice: (502) 966-3848
  10336. IgLou Internet Services                        (800) 436-4456
  10337.  
  10338. -
  10339.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10340.  with "unsubscribe usr-tc" in the body of the message.
  10341.  For information on digests or retrieving files and old messages send
  10342.  "help" to the same address.  Do not use quotes in your message.
  10343.  
  10344.  
  10345. -
  10346.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10347.  with "unsubscribe usr-tc" in the body of the message.
  10348.  For information on digests or retrieving files and old messages send
  10349.  "help" to the same address.  Do not use quotes in your message.
  10350.  
  10351.  
  10352. -------------------------------------------------------------------------------
  10353.  
  10354. From: Brian <signal@shreve.net>
  10355. Subject: Re: (usr-tc) 2.0.60 HDM Code
  10356. Date: 12 Oct 1999 21:40:31 -0500 (CDT)
  10357.  
  10358. On Tue, 12 Oct 1999 farber@admin.f-tech.net wrote:
  10359.  
  10360. > I did just buy 4 DPS's and they did come with newer code than I had been
  10361. > running... I haven't upgraded from 1.x to the 2.x simply because it really
  10362. > didn't fix anything.. just added some features that I don't need.
  10363. > 
  10364. > I recall the DSP contract at $250 per DSP.. that's a dozen cards that need
  10365.  
  10366. if someone has the "software only support" numbers for all the cards (nmc,
  10367. arcs, dsp's) it would be cool to post that.
  10368.  
  10369. Brian
  10370.  
  10371.  
  10372. > 
  10373. > 
  10374. > Paul Farber
  10375. > Farber Technology
  10376. > farber@admin.f-tech.net
  10377. > Ph  570-628-5303
  10378. > Fax 570-628-5545
  10379. > 
  10380. > On Tue, 12 Oct 1999, Brian wrote:
  10381. > 
  10382. > > I can log into Cisco, and download any code on that site, no questions
  10383. > > asked..........I can do that with a $250 2501 service contract.  Do I
  10384. > > screw Cisco? Hell no, because the contracts for *all* the stuff I have is
  10385. > > just as good of a deal as the pricing on the 2501 contracts.
  10386. > > 
  10387. > > You can bet that when people like myself need support contracts, its not
  10388. > > because we don't know how to use the equipment, its because the stuff
  10389. > > isn't working, we need fixes, we need to let 3com know it doesn't work.
  10390. > 
  10391. > 
  10392. > -
  10393. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10394. >  with "unsubscribe usr-tc" in the body of the message.
  10395. >  For information on digests or retrieving files and old messages send
  10396. >  "help" to the same address.  Do not use quotes in your message.
  10397. > 
  10398.  
  10399. Brian Feeny (BF304)     signal@shreve.net   
  10400. 318-222-2638 x 109    http://www.shreve.net/~signal      
  10401. Network Administrator   ShreveNet Inc. (ASN 11881)           
  10402.  
  10403.  
  10404. -
  10405.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10406.  with "unsubscribe usr-tc" in the body of the message.
  10407.  For information on digests or retrieving files and old messages send
  10408.  "help" to the same address.  Do not use quotes in your message.
  10409.  
  10410.  
  10411. -------------------------------------------------------------------------------
  10412.  
  10413. From: Corneliu Rudeanu <rudy@dntis.ro>
  10414. Subject: Re: (usr-tc) Radius question
  10415. Date: 13 Oct 1999 05:49:12 +0300 (EEST)
  10416.  
  10417. On Tue, 12 Oct 1999, Aaron Nabil wrote:
  10418.  
  10419. > Corneliu Rudeanu writes...
  10420. > >Yet watching (monitor radius) the id-s of the packets being retransmited I
  10421. > >found that hiperArc (4.2.29) assigns diferrent id for the packets being
  10422. > >re-sent to radius server for the same accounting request.
  10423. > 
  10424. > Hah!  It's much better than that!  (Note the date, too!)
  10425. > 
  10426. > >From: Aaron Nabil <nabil@spiritone.com>
  10427. > >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
  10428. > >Date: 14 Jun 1998 16:58:15 -0700 (PDT)
  10429. > >
  10430. > >
  10431. > >The HiperArc has a nasty Radius bug.
  10432. > >
  10433. > >If a packet get lost in transit or for some other reason is never 
  10434. > >acknoweldged, the HiperArc increments the identifier and tries 
  10435. > >sending it again after the timeout period.
  10436. > >
  10437. > >But later, when it comes time to send another request, it has 
  10438. > >"forgotten" that it previously incremented the identifier and merrily 
  10439. > >uses the last one again!
  10440. > 
  10441. > Not only does it incorrectly increment the identifier, it then
  10442. > goes on to re-use the same identifier again later!  Yes, this is
  10443. > so incredibly broken it's not even imaginable that it hasn't
  10444. > been fixed.  But it hasn't.  
  10445. > 
  10446. > >My question: how is suposed a Radius server to identify the duplicates?
  10447. > 
  10448. > The Radius server is supposed to contact the System Administrator
  10449. > and get him to purchase products from a vendor that knows how to 
  10450. > read a RFC, or, failing that, at least fixes problems when they
  10451. > are pointed out to them.
  10452.  
  10453. Thanks for the prompt response. And my apollogies for re-opening the
  10454. subject.
  10455.  
  10456. I do agree with you: things should be good. Yet things are bad. I guess I
  10457. am not the only one looking for a solution. Does some kind of checksum
  10458. over acct-session-id, username, status-type worth any thrust? 
  10459.  
  10460. Even this kind of 'hand made' solution would help me.
  10461. Any advice?
  10462.  
  10463. TIA,
  10464. Corneliu Rudeanu
  10465.  
  10466.  
  10467.  
  10468. -
  10469.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10470.  with "unsubscribe usr-tc" in the body of the message.
  10471.  For information on digests or retrieving files and old messages send
  10472.  "help" to the same address.  Do not use quotes in your message.
  10473.  
  10474.  
  10475. -------------------------------------------------------------------------------
  10476.  
  10477. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  10478. Subject: Re: (usr-tc) Radius question
  10479. Date: 12 Oct 1999 22:29:00 -0500
  10480.  
  10481.  
  10482.  
  10483. Aaron & Corneliu,
  10484.  
  10485. >RFC states as clear as posibile: "For retransmissions where the contents
  10486. >are identical, the Identifier MUST remain unchanged.".
  10487.  
  10488. And the RFC warns just as clearly in the next sentence: " Note that if
  10489. Acct-Delay-Time is included
  10490. in the attributes of an Accounting-Request then the Acct-Delay-Time value will
  10491. be updated when
  10492. the packet is retransmitted, changing the content of the Attributes field and
  10493. requiring a new
  10494. Identifier and Request Authenticator."
  10495.  
  10496.  If you look closer at the retransmitted accounting packet you will notice that
  10497. it is NOT identical, due to
  10498. this fact. Therefore the packet MUST have a new identifier.
  10499.  
  10500.  
  10501. >My question: how is suposed a Radius server to identify the duplicates?
  10502.  
  10503.   This is a tough one-
  10504.   The radius server needs to be able to overcome the shortcomings of the
  10505. radius protocol.  It Can't rely simply on a single field that allows
  10506. only values of 1 to 254 to decide if it's seen a packet before. Imagine
  10507. a busy server- taking 1000 or more requests a second...
  10508.   One solution might be for the server to build it's own key- based on
  10509. NAS_IP,  SESSION_ID, and USER_NAME for example.  That would make the
  10510. packets pretty unique in most situations. This is the method used by the
  10511. latest version of 3Com's security server.
  10512.  
  10513.  
  10514. >>But later, when it comes time to send another request, it has
  10515. >>"forgotten" that it previously incremented the identifier and merrily
  10516. >>uses the last one again!
  10517.  
  10518.  Can you send along an example of this happening (using the same packet-ID
  10519. twice in a row for the same destination port and with current HiperArc code)?
  10520. If it is an issue it will be fixed.  Keep in mind though that it only
  10521. takes a couple hundred packets to wrap back around and reuse the same ID
  10522. again.
  10523.  
  10524. >The Radius server is supposed to contact the System Administrator
  10525. >and get him to purchase products from a vendor that knows how to
  10526. >read a RFC, or, failing that, at least fixes problems when they
  10527. >are pointed out to them.
  10528.  
  10529. What exactly was it that 3com missed in the RFC?
  10530.  
  10531.  
  10532. You can send the trace directly to me if you don't want to post to the list.
  10533.  
  10534.     Thanks,
  10535.      Steve_valiunas@3com.com
  10536.  
  10537.  
  10538.  
  10539.  
  10540.  
  10541. Aaron Nabil <nabil@spiritone.com> on 10/12/99 08:14:07 PM
  10542.  
  10543. Please respond to usr-tc@lists.xmission.com
  10544.  
  10545. Sent by:  Aaron Nabil <nabil@spiritone.com>
  10546.  
  10547.  
  10548. cc:    (Steve Valiunas/MW/US/3Com)
  10549.  
  10550.  
  10551.  
  10552.  
  10553. Corneliu Rudeanu writes...
  10554. >I was really surprised to see how HARC deals with the radius packet
  10555. >identifier.
  10556. >
  10557. >RFC states as clear as posibile: "For retransmissions where the contents
  10558. >are identical, the Identifier MUST remain unchanged.".
  10559. >
  10560. >Yet watching (monitor radius) the id-s of the packets being retransmited I
  10561. >found that hiperArc (4.2.29) assigns diferrent id for the packets being
  10562. >re-sent to radius server for the same accounting request.
  10563.  
  10564. Hah!  It's much better than that!  (Note the date, too!)
  10565.  
  10566. >From: Aaron Nabil <nabil@spiritone.com>
  10567. >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit
  10568. >Date: 14 Jun 1998 16:58:15 -0700 (PDT)
  10569. >
  10570. >
  10571. >The HiperArc has a nasty Radius bug.
  10572. >
  10573. >If a packet get lost in transit or for some other reason is never
  10574. >acknoweldged, the HiperArc increments the identifier and tries
  10575. >sending it again after the timeout period.
  10576. >
  10577. >But later, when it comes time to send another request, it has
  10578. >"forgotten" that it previously incremented the identifier and merrily
  10579. >uses the last one again!
  10580.  
  10581. Not only does it incorrectly increment the identifier, it then
  10582. goes on to re-use the same identifier again later!  Yes, this is
  10583. so incredibly broken it's not even imaginable that it hasn't
  10584. been fixed.  But it hasn't.
  10585.  
  10586. >My question: how is suposed a Radius server to identify the duplicates?
  10587.  
  10588. The Radius server is supposed to contact the System Administrator
  10589. and get him to purchase products from a vendor that knows how to
  10590. read a RFC, or, failing that, at least fixes problems when they
  10591. are pointed out to them.
  10592.  
  10593. --
  10594. Aaron Nabil
  10595.  
  10596. -
  10597.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10598.  with "unsubscribe usr-tc" in the body of the message.
  10599.  For information on digests or retrieving files and old messages send
  10600.  "help" to the same address.  Do not use quotes in your message.
  10601.  
  10602.  
  10603.  
  10604.  
  10605.  
  10606.  
  10607. -
  10608.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10609.  with "unsubscribe usr-tc" in the body of the message.
  10610.  For information on digests or retrieving files and old messages send
  10611.  "help" to the same address.  Do not use quotes in your message.
  10612.  
  10613.  
  10614. -------------------------------------------------------------------------------
  10615.  
  10616. From: "Scot Desort" <scot@njaccess.net>
  10617. Subject: RE: (usr-tc) 2.0.60 HDM Code
  10618. Date: 12 Oct 1999 23:23:30 -0400
  10619.  
  10620. I think Brian is on the right track here. Perhaps 3COM can split their
  10621. service contracts into 2 categories - firmware download only, and full
  10622. support with download and telephone support.
  10623.  
  10624. Those of us new to the platform (myself included) might benefit from the
  10625. convenience of knowing that phone support is available 24x7 when you're
  10626. staring at a box not taking calls at 2AM. But once you get the hang of TC
  10627. and know how to troubleshoot these things on your own (or at least with the
  10628. added help of those on this list), you can drop the tel support, and just
  10629. pay for code updates.
  10630.  
  10631. Does any of this matter to those on this list that are complaining about
  10632. 3COM's lack of timely response to code issues? Probably not. Should 3COM
  10633. redirect it's efforts to resolving these issues? Yep. Should they perhaps
  10634. head-up a small team (1 person) to field code enhancement and bug fix
  10635. requests, both from an email/web input area on the 3COM ISP pages, but also
  10636. through monitoring of this list and the totalcontol newsgroups? Absolutely.
  10637. 3COM may already be doing this "behind the scenes", quietly tracking and
  10638. logging this stuff, but it's apparent that the people who need to know the
  10639. most that it's being done and being worked on, the ISP customers, don't know
  10640. that someone has acknowledged the problem and it has been placed into an
  10641. engineering queue.
  10642.  
  10643. I think that things like this would greatly improve 3COM's image among it's
  10644. ISP customers, and even more so if they acted expediently on these issues
  10645. that trouble so many on this list. Give the telephone support staff access
  10646. to the database created as a result of these pages (hell, give us access to
  10647. these pages as well, even WITHOUT a contract). Tie the ER/SR releases to the
  10648. database, so it's easier to identify which bug is fixed with which release.
  10649. And most importantly, allowing us to view this database to obtain the status
  10650. of a confirmed bug and it's up-to-date progress in getting resolved would be
  10651. of tremendous benefit. To know that someone is actually WORKING on Jeff's
  10652. SNMP issue by simply searching the database is comforting (knowing that it
  10653. will be fixed QUICKLY is even better). Some of this status information may
  10654. already be in the 3KB, but a dedicated database for TC code issues and
  10655. status reports would be really great.
  10656.  
  10657. Scot
  10658. NJAccess
  10659.  
  10660.  
  10661. -----Original Message-----
  10662. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  10663. Sent: Tuesday, October 12, 1999 9:45 PM
  10664.  
  10665.  
  10666. On Tue, 12 Oct 1999, Jeff Binkley wrote:
  10667.  
  10668. > -> One of the few pleasures in life is telling the salesbot on the phone
  10669. that I
  10670. > -> will NOT be renewing my support contract.
  10671. > ->
  10672. > -> For the amount it would cost to cover 2 chassis and a dozen DSP's,
  10673. ARC's and
  10674. > -> NMC's they need to do alot better than they are now.
  10675. > ->
  10676. > -> They released NFAS code and OSPF beta code... whipee.  Make the damned
  10677. thing
  10678. > -> connect more reliabily and then worry about networking code (ala OSPF).
  10679. >
  10680. > I too boycotted renewing my maintenance contract for almost a year
  10681. > for many of the same reasons you and others have expressed.  I just
  10682. > downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
  10683. > Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
  10684. > killed my webramps.  I was actually on Ramp Networks website tonight and
  10685. > they have an engineering note specifically for TC w/HiPerArcs.  They
  10686. > pretty much pointed the gun straight at 3Com.   Back to the original
  10687. > point of your message I wonder how many of us have witheld revenue from
  10688. > 3Com over the maintenance contract issues  ?  I will say the
  10689. > process for purchasing the maintenance contract and getting it
  10690. > active was much much better this time (albeit I couldn't active
  10691. > it via the website due to some cgi problem) but the ole reliable
  10692. > fax machine came through with flying colors.
  10693.  
  10694. We have.  I would be very happy to pay 3Com a fair price for maintenence
  10695. contracts.  We almost had a deal cinched and at the last minute they
  10696. changed the price, and we never went with it.
  10697.  
  10698. Once you are a certain size, and you have certain momentum, you are
  10699. *always* buying dsp's every few weeks.  So technically, if you just keep
  10700. registering those numbers on totalservice, you will always be covered
  10701. under 90 days support.
  10702.  
  10703. This is bad for 3com though, so they really should fix the contract
  10704. situation, so we can get real contracts.  I just want software, I am not
  10705. interested in there tech support.  I have been working on TC hubs for
  10706. years, setup dozens and dozens of them, and done just about everything
  10707. worth doing on them.  But I get subjected to calling into an 800 number,
  10708. at 11pm, so that some guy who sounds half asleep can call me back with a
  10709. piss poor (tired?) attitude, who probably has been working there like a
  10710. few weeks, or months, and doesn't have anywhere near the experience I do
  10711. on these hubs.  "Did you try rebooting the chassis?"...........
  10712.  
  10713. I feel I am in a constant battle with 3com, just to get code I have
  10714. legitimate access too etc.
  10715.  
  10716. I mean, if you buy a chassis that has TCS 3.5 on it, and you bought a
  10717. support contract with TCS 3.5..........shouldn't your account still let
  10718. you download the TCS 3.5 code forever?  I mean, its not like they are
  10719. giving you something you didn't already have........you paid for it, its
  10720. not a newer version, its the version that was on the damn thing when you
  10721. bought it!
  10722.  
  10723. I can log into Cisco, and download any code on that site, no questions
  10724. asked..........I can do that with a $250 2501 service contract.  Do I
  10725. screw Cisco? Hell no, because the contracts for *all* the stuff I have is
  10726. just as good of a deal as the pricing on the 2501 contracts.
  10727.  
  10728. You can bet that when people like myself need support contracts, its not
  10729. because we don't know how to use the equipment, its because the stuff
  10730. isn't working, we need fixes, we need to let 3com know it doesn't work.
  10731.  
  10732. >
  10733. >
  10734. > Jeff Binkley
  10735. > ASA Network Computing
  10736. >
  10737. > -
  10738. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10739. >  with "unsubscribe usr-tc" in the body of the message.
  10740. >  For information on digests or retrieving files and old messages send
  10741. >  "help" to the same address.  Do not use quotes in your message.
  10742. >
  10743.  
  10744. Brian Feeny (BF304)     signal@shreve.net
  10745. 318-222-2638 x 109    http://www.shreve.net/~signal
  10746. Network Administrator   ShreveNet Inc. (ASN 11881)
  10747.  
  10748.  
  10749.  
  10750.  
  10751. -
  10752.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10753.  with "unsubscribe usr-tc" in the body of the message.
  10754.  For information on digests or retrieving files and old messages send
  10755.  "help" to the same address.  Do not use quotes in your message.
  10756.  
  10757.  
  10758. -------------------------------------------------------------------------------
  10759.  
  10760. From: "Ed" <ed@taylors.com>
  10761. Subject: (usr-tc) Funk Radius
  10762. Date: 13 Oct 1999 01:47:49 -0400
  10763.  
  10764. We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  10765. technician). Does anyone have any experience in this and is it better than
  10766. the current 6.0.9 3com Radius? Hard to believe it could be worse...
  10767.  
  10768. Any problems known?
  10769.  
  10770. Ed
  10771.  
  10772. ----- Original Message -----
  10773. Sent: Tuesday, October 12, 1999 10:49 PM
  10774.  
  10775.  
  10776. On Tue, 12 Oct 1999, Aaron Nabil wrote:
  10777.  
  10778. > Corneliu Rudeanu writes...
  10779. > >Yet watching (monitor radius) the id-s of the packets being retransmited
  10780. I
  10781. > >found that hiperArc (4.2.29) assigns diferrent id for the packets being
  10782. > >re-sent to radius server for the same accounting request.
  10783. >
  10784. > Hah!  It's much better than that!  (Note the date, too!)
  10785. >
  10786. > >From: Aaron Nabil <nabil@spiritone.com>
  10787. > >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after
  10788. re-transmit
  10789. > >Date: 14 Jun 1998 16:58:15 -0700 (PDT)
  10790. > >
  10791. > >
  10792. > >The HiperArc has a nasty Radius bug.
  10793. > >
  10794. > >If a packet get lost in transit or for some other reason is never
  10795. > >acknoweldged, the HiperArc increments the identifier and tries
  10796. > >sending it again after the timeout period.
  10797. > >
  10798. > >But later, when it comes time to send another request, it has
  10799. > >"forgotten" that it previously incremented the identifier and merrily
  10800. > >uses the last one again!
  10801. >
  10802. > Not only does it incorrectly increment the identifier, it then
  10803. > goes on to re-use the same identifier again later!  Yes, this is
  10804. > so incredibly broken it's not even imaginable that it hasn't
  10805. > been fixed.  But it hasn't.
  10806. >
  10807. > >My question: how is suposed a Radius server to identify the duplicates?
  10808. >
  10809. > The Radius server is supposed to contact the System Administrator
  10810. > and get him to purchase products from a vendor that knows how to
  10811. > read a RFC, or, failing that, at least fixes problems when they
  10812. > are pointed out to them.
  10813.  
  10814. Thanks for the prompt response. And my apollogies for re-opening the
  10815. subject.
  10816.  
  10817. I do agree with you: things should be good. Yet things are bad. I guess I
  10818. am not the only one looking for a solution. Does some kind of checksum
  10819. over acct-session-id, username, status-type worth any thrust?
  10820.  
  10821. Even this kind of 'hand made' solution would help me.
  10822. Any advice?
  10823.  
  10824. TIA,
  10825. Corneliu Rudeanu
  10826.  
  10827.  
  10828.  
  10829. -
  10830.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10831.  with "unsubscribe usr-tc" in the body of the message.
  10832.  For information on digests or retrieving files and old messages send
  10833.  "help" to the same address.  Do not use quotes in your message.
  10834.  
  10835.  
  10836.  
  10837. -
  10838.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10839.  with "unsubscribe usr-tc" in the body of the message.
  10840.  For information on digests or retrieving files and old messages send
  10841.  "help" to the same address.  Do not use quotes in your message.
  10842.  
  10843.  
  10844. -------------------------------------------------------------------------------
  10845.  
  10846. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  10847. Subject: Re: (usr-tc) Funk Radius
  10848. Date: 13 Oct 1999 02:09:48 -0400 (EDT)
  10849.  
  10850.  
  10851. Don't know anything about that one, but if you're going to buy something,
  10852. I'd suggest taking a look at Radiator. It's written in perl, so it's not
  10853. the fastest you can get, but you get the source and can make it do
  10854. *anything* you want. Not that you have to; I've seen a feature request
  10855. hit the support mailing list and the guys who wrote the package mentioning
  10856. that they've written it and tossed it on the ftp site...within *hours*.
  10857.  
  10858. Supports USR style VSAs and interfaces to your favorite sql or odbc
  10859. database out of the box.
  10860.  
  10861.  
  10862. On Wed, 13 Oct 1999, Ed wrote:
  10863.  
  10864. > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  10865. > technician). Does anyone have any experience in this and is it better than
  10866. > the current 6.0.9 3com Radius? Hard to believe it could be worse...
  10867.  
  10868.  
  10869. -
  10870.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10871.  with "unsubscribe usr-tc" in the body of the message.
  10872.  For information on digests or retrieving files and old messages send
  10873.  "help" to the same address.  Do not use quotes in your message.
  10874.  
  10875.  
  10876. -------------------------------------------------------------------------------
  10877.  
  10878. From: "Ed" <ed@taylors.com>
  10879. Subject: Re: (usr-tc) Funk Radius
  10880. Date: 13 Oct 1999 02:15:42 -0400
  10881.  
  10882. Perl? not sure I want to touch that one ;-)
  10883.  
  10884. Ed
  10885.  
  10886. ----- Original Message -----
  10887. Sent: Wednesday, October 13, 1999 2:09 AM
  10888.  
  10889.  
  10890.  
  10891. Don't know anything about that one, but if you're going to buy something,
  10892. I'd suggest taking a look at Radiator. It's written in perl, so it's not
  10893. the fastest you can get, but you get the source and can make it do
  10894. *anything* you want. Not that you have to; I've seen a feature request
  10895. hit the support mailing list and the guys who wrote the package mentioning
  10896. that they've written it and tossed it on the ftp site...within *hours*.
  10897.  
  10898. Supports USR style VSAs and interfaces to your favorite sql or odbc
  10899. database out of the box.
  10900.  
  10901.  
  10902. On Wed, 13 Oct 1999, Ed wrote:
  10903.  
  10904. > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  10905. > technician). Does anyone have any experience in this and is it better than
  10906. > the current 6.0.9 3com Radius? Hard to believe it could be worse...
  10907.  
  10908.  
  10909. -
  10910.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10911.  with "unsubscribe usr-tc" in the body of the message.
  10912.  For information on digests or retrieving files and old messages send
  10913.  "help" to the same address.  Do not use quotes in your message.
  10914.  
  10915.  
  10916.  
  10917. -
  10918.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10919.  with "unsubscribe usr-tc" in the body of the message.
  10920.  For information on digests or retrieving files and old messages send
  10921.  "help" to the same address.  Do not use quotes in your message.
  10922.  
  10923.  
  10924. -------------------------------------------------------------------------------
  10925.  
  10926. From: Jeff Mcadams <jeffm@iglou.com>
  10927. Subject: Re: (usr-tc) arcs and ospf
  10928. Date: 13 Oct 1999 07:54:56 -0400
  10929.  
  10930. Thus spake Mike McHenry
  10931. >This exact problem has happened to me several times and it was NOT
  10932. >caused by the ARC deciding to become the DR. I have a small network of
  10933. >about 13 Lucent portmasters, 3 USR TC chassis, one Cisco 4500 and one
  10934. >Cisco 4700 router. ALL of the termservers are set with OSPF priority 0,
  10935. >meaning they will never become a DR or BDR. The Cisco 4500 and 4700
  10936. >OSPF priorities were left as-is leaving one to become the DR and the
  10937. >other to become the BDR.
  10938.  
  10939. >If I rebooted or otherwise disturbed the DR the USR TC chassis would
  10940. >lose all their OSPF routing. The Lucent equipment did not have a
  10941. >problem at all.  Getting the OSPF back on the USRs required a reboot of
  10942. >every chassis. For now I have set one of the Ciscos to priority 0 so
  10943. >that it will never become a BDR or DR. It seems as though the HARC
  10944. >cards have a problem recognizing a change of a BDR to a DR while the
  10945. >rest of my equipment does not.
  10946.  
  10947. >If this problem is indeed being caused by an ARC deciding to become a
  10948. >DR then it would seem to be a bug. In my case this should not be
  10949. >happening as all the HARCs are set to NOT participate in DR/BDR
  10950. >elections.
  10951.  
  10952. Sounds like you've played with it considerably more than myself at
  10953. least, I'll defer to your experience with this code.  I had just played
  10954. with it enough to know that it puked mightily when something happened to
  10955. the DR...I hadn't played enough to know specifically what caused it.
  10956. Sounds like you've dug into it far enough that you know more specifics.
  10957. -- 
  10958. Jeff McAdams                            Email: jeffm@iglou.com
  10959. Head Network Administrator              Voice: (502) 966-3848
  10960. IgLou Internet Services                        (800) 436-4456
  10961.  
  10962. -
  10963.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10964.  with "unsubscribe usr-tc" in the body of the message.
  10965.  For information on digests or retrieving files and old messages send
  10966.  "help" to the same address.  Do not use quotes in your message.
  10967.  
  10968.  
  10969. -------------------------------------------------------------------------------
  10970.  
  10971. From: Jeff Mcadams <jeffm@iglou.com>
  10972. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  10973. Date: 13 Oct 1999 08:11:55 -0400
  10974.  
  10975. Thus spake Scot Desort
  10976. >I think Brian is on the right track here. Perhaps 3COM can split their
  10977. >service contracts into 2 categories - firmware download only, and full
  10978. >support with download and telephone support.
  10979.  
  10980. They already have a software only support contract...its just as
  10981. ridiculous as the rest of them.
  10982.  
  10983. >Does any of this matter to those on this list that are complaining
  10984. >about 3COM's lack of timely response to code issues? Probably not.
  10985. >Should 3COM redirect it's efforts to resolving these issues? Yep.
  10986. >Should they perhaps head-up a small team (1 person) to field code
  10987. >enhancement and bug fix requests, both from an email/web input area on
  10988. >the 3COM ISP pages, but also through monitoring of this list and the
  10989. >totalcontol newsgroups? Absolutely.  3COM may already be doing this
  10990. >"behind the scenes", quietly tracking and logging this stuff, but it's
  10991. >apparent that the people who need to know the most that it's being done
  10992. >and being worked on, the ISP customers, don't know that someone has
  10993. >acknowledged the problem and it has been placed into an engineering
  10994. >queue.
  10995.  
  10996. >I think that things like this would greatly improve 3COM's image among
  10997. >it's ISP customers, and even more so if they acted expediently on these
  10998. >issues that trouble so many on this list. Give the telephone support
  10999. >staff access to the database created as a result of these pages (hell,
  11000. >give us access to these pages as well, even WITHOUT a contract). Tie
  11001. >the ER/SR releases to the database, so it's easier to identify which
  11002. >bug is fixed with which release.  And most importantly, allowing us to
  11003. >view this database to obtain the status of a confirmed bug and it's
  11004. >up-to-date progress in getting resolved would be of tremendous benefit.
  11005. >To know that someone is actually WORKING on Jeff's SNMP issue by simply
  11006. >searching the database is comforting (knowing that it will be fixed
  11007. >QUICKLY is even better). Some of this status information may already be
  11008. >in the 3KB, but a dedicated database for TC code issues and status
  11009. >reports would be really great.
  11010.  
  11011. I think Scot (it is just 1 "t" right?) has some very good points here
  11012. that go hand in hand with my thoughts about beaurocracy (note the
  11013. scenes, closed development environment.  Don't worry 3Com, I'm not going
  11014. to suggest you Open Source the Pilgrim code, however, perhaps 3Com could
  11015. take some cues from the Open Source movement.  By putting more layers of
  11016. beaurocracy between the actual users and developers, there's just that
  11017. much more insulation that filters out valid feedback.  I reported that
  11018. SNMP bug nearly 3 weeks ago and I have received *no* communication
  11019. regarding it whatsoever.  I've been holding off reporting it publicly
  11020. waiting for 3Com to get a fix out for it, but I haven't a clue if that's
  11021. forthcoming anytime soon or not.  The last time I reported a 3Com bug it
  11022. slipped through the cracks and made it through a whole new major release
  11023. without getting fixed.  Better communication between the developers and
  11024. customers would fix this...if I knew that 3Com kept up good
  11025. communication with someone who reported a problem regarding that problem
  11026. and I weren't getting feedback about a problem I reported, then I'd know
  11027. to call again and try again, or know to go forward with a public posting
  11028. since it would seem that 3Com hasn't deemed it worthy to fix.  However,
  11029. given 3Com's unbelievably closed development environment, I haven't a
  11030. clue if this thing is sitting in some engineer's queue somewhere to be
  11031. fixed or not.  (Even if it is in a queue somewhere, for a security bug
  11032. like this, even that's unacceptable).
  11033.  
  11034. 3Com needs to seriously open up to their customers here...remove many
  11035. layers of beaurocracy (these two statements amount to the same thing),
  11036. and get them more involved...maybe even make the engineering mailing
  11037. lists and stuff publically available...get the customers in on the
  11038. actual development process.  Maybe making them publically available
  11039. would be a bad idea (would end up with too much noise), but perhaps
  11040. invite specific customers to join in?  There are certainly a few people
  11041. on this list that could give you some good feedback.  I know...this is a
  11042. pretty radical idea...maybe it doesn't need to go this far, but just
  11043. something that one of my co-workers and I were discussing the other day.
  11044. Regardless of how its done, 3Com *definitely* needs to open up to their
  11045. customers more.  When, in the course of 2-3 days on a mailing list, 4 or
  11046. 5 *MAJOR* issues can be mentioned that are still unaddressed after about
  11047. a year for each...something needs to be done.
  11048. -- 
  11049. Jeff McAdams                            Email: jeffm@iglou.com
  11050. Head Network Administrator              Voice: (502) 966-3848
  11051. IgLou Internet Services                        (800) 436-4456
  11052.  
  11053. -
  11054.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11055.  with "unsubscribe usr-tc" in the body of the message.
  11056.  For information on digests or retrieving files and old messages send
  11057.  "help" to the same address.  Do not use quotes in your message.
  11058.  
  11059.  
  11060. -------------------------------------------------------------------------------
  11061.  
  11062. From: jeff.binkley@asacomp.com (Jeff Binkley)
  11063. Subject: (usr-tc) RE: (USR-TC) RADIUS QUEST
  11064. Date: 13 Oct 1999 08:13:00 -0500
  11065.  
  11066.  
  11067.  
  11068.  
  11069.  
  11070.  
  11071.  
  11072. U>Aaron & Corneliu,
  11073.  
  11074. U>>RFC states as clear as posibile: "For retransmissions where the
  11075. U>contents >are identical, the Identifier MUST remain unchanged.".
  11076.  
  11077. U>And the RFC warns just as clearly in the next sentence: " Note that if
  11078. U>Acct-Delay-Time is included
  11079. U>in the attributes of an Accounting-Request then the Acct-Delay-Time
  11080. U>value will be updated when
  11081. U>the packet is retransmitted, changing the content of the Attributes
  11082. U>field and requiring a new
  11083. U>Identifier and Request Authenticator."
  11084.  
  11085. U> If you look closer at the retransmitted accounting packet you will
  11086. U>notice that
  11087. U>it is NOT identical, due to
  11088. U>this fact. Therefore the packet MUST have a new identifier.
  11089.  
  11090.  
  11091. U>>My question: how is suposed a Radius server to identify the
  11092. U>duplicates?
  11093.  
  11094. U>  This is a tough one-
  11095. U>  The radius server needs to be able to overcome the shortcomings of
  11096. U>the radius protocol.  It Can't rely simply on a single field that
  11097. U>allows only values of 1 to 254 to decide if it's seen a packet before.
  11098. U>Imagine a busy server- taking 1000 or more requests a second...
  11099. U>  One solution might be for the server to build it's own key- based on
  11100. U>NAS_IP,  SESSION_ID, and USER_NAME for example.  That would make the
  11101. U>packets pretty unique in most situations. This is the method used by
  11102. U>the latest version of 3Com's security server.
  11103.  
  11104.  
  11105. Do you mean 6.09 ?  If so, what about 6.08 ?
  11106.  
  11107. Jeff Binkley
  11108. ASA Network Computing
  11109.  
  11110.  
  11111. U>    Thanks,
  11112. U>     Steve_valiunas@3com.com
  11113.  
  11114. CMPQwk 1.42 9999
  11115.  
  11116. -
  11117.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11118.  with "unsubscribe usr-tc" in the body of the message.
  11119.  For information on digests or retrieving files and old messages send
  11120.  "help" to the same address.  Do not use quotes in your message.
  11121.  
  11122.  
  11123. -------------------------------------------------------------------------------
  11124.  
  11125. From: jeff.binkley@asacomp.com (Jeff Binkley)
  11126. Subject: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  11127. Date: 13 Oct 1999 08:13:00 -0500
  11128.  
  11129.  
  11130.  
  11131.  
  11132. Unless I am mistaken they do offer software only contracts.  I've seen 
  11133. them on Tech Data's price listing.  They are generally less than half of 
  11134. the full service contracts.
  11135.  
  11136. Jeff Binkley
  11137. ASA Network Computing
  11138.  
  11139.  
  11140. U>I think Brian is on the right track here. Perhaps 3COM can split their
  11141. U>service contracts into 2 categories - firmware download only, and full
  11142. U>support with download and telephone support.
  11143.  
  11144. U>Those of us new to the platform (myself included) might benefit from
  11145. U>the convenience of knowing that phone support is available 24x7 when
  11146. U>you're staring at a box not taking calls at 2AM. But once you get the
  11147. U>hang of TC and know how to troubleshoot these things on your own (or
  11148. U>at least with the added help of those on this list), you can drop the
  11149. U>tel support, and just pay for code updates.
  11150.  
  11151. U>Does any of this matter to those on this list that are complaining
  11152. U>about 3COM's lack of timely response to code issues? Probably not.
  11153. U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  11154. U>Should they perhaps head-up a small team (1 person) to field code
  11155. U>enhancement and bug fix requests, both from an email/web input area on
  11156. U>the 3COM ISP pages, but also through monitoring of this list and the
  11157. U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  11158. U>"behind the scenes", quietly tracking and logging this stuff, but it's
  11159. U>apparent that the people who need to know the most that it's being
  11160. U>done and being worked on, the ISP customers, don't know that someone
  11161. U>has acknowledged the problem and it has been placed into an
  11162. U>engineering queue.
  11163.  
  11164. U>I think that things like this would greatly improve 3COM's image among
  11165. U>it's ISP customers, and even more so if they acted expediently on
  11166. U>these issues that trouble so many on this list. Give the telephone
  11167. U>support staff access to the database created as a result of these
  11168. U>pages (hell, give us access to these pages as well, even WITHOUT a
  11169. U>contract). Tie the ER/SR releases to the database, so it's easier to
  11170. U>identify which bug is fixed with which release. And most importantly,
  11171. U>of allowing us to view this database to obtain the status a confirmed
  11172. U>of bug and it's up-to-date progress in getting resolved would be
  11173. U>tremendous benefit. To know that someone is actually WORKING on Jeff's
  11174. U>SNMP issue by simply searching the database is comforting (knowing 
  11175. that 
  11176. U>it will be fixed QUICKLY is even better). Some of this status
  11177. U>information may already be in the 3KB, but a dedicated database for TC
  11178. U>code issues and status reports would be really great.
  11179.  
  11180. U>Scot
  11181. U>NJAccess
  11182.  
  11183. CMPQwk 1.42 9999
  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.  
  11194. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  11195. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  11196. Date: 13 Oct 1999 08:06:16 -0500
  11197.  
  11198.  
  11199.  
  11200. >Do you mean 6.09 ?  If so, what about 6.08 ?
  11201.  
  11202.     It's available in an Engineering Release, so you'll have to call tech
  11203. support.  (I know-
  11204. another example of excess bureaucracy <g>).  It is in the process of being
  11205. posted as a
  11206. service release.  When this is completed you'll be able to grab it directly off
  11207. of
  11208. totalservice.3com.com.
  11209.    The Version is 6.0.83 and is available for WIndows.
  11210.    The more robust duplicate/out-of-order checking only affects accounting.
  11211. Authentication still relies on packet identifier
  11212.  
  11213. Steve
  11214.  
  11215.  
  11216.  
  11217.  
  11218. jeff.binkley@asacomp.com (Jeff Binkley) on 10/13/99 08:13:00 AM
  11219.  
  11220. Please respond to usr-tc@lists.xmission.com
  11221.  
  11222. Sent by:  jeff.binkley@asacomp.com (Jeff Binkley)
  11223.  
  11224.  
  11225. cc:    (Steve Valiunas/MW/US/3Com)
  11226.  
  11227.  
  11228.  
  11229.  
  11230.  
  11231.  
  11232.  
  11233.  
  11234.  
  11235.  
  11236. U>Aaron & Corneliu,
  11237.  
  11238. U>>RFC states as clear as posibile: "For retransmissions where the
  11239. U>contents >are identical, the Identifier MUST remain unchanged.".
  11240.  
  11241. U>And the RFC warns just as clearly in the next sentence: " Note that if
  11242. U>Acct-Delay-Time is included
  11243. U>in the attributes of an Accounting-Request then the Acct-Delay-Time
  11244. U>value will be updated when
  11245. U>the packet is retransmitted, changing the content of the Attributes
  11246. U>field and requiring a new
  11247. U>Identifier and Request Authenticator."
  11248.  
  11249. U> If you look closer at the retransmitted accounting packet you will
  11250. U>notice that
  11251. U>it is NOT identical, due to
  11252. U>this fact. Therefore the packet MUST have a new identifier.
  11253.  
  11254.  
  11255. U>>My question: how is suposed a Radius server to identify the
  11256. U>duplicates?
  11257.  
  11258. U>  This is a tough one-
  11259. U>  The radius server needs to be able to overcome the shortcomings of
  11260. U>the radius protocol.  It Can't rely simply on a single field that
  11261. U>allows only values of 1 to 254 to decide if it's seen a packet before.
  11262. U>Imagine a busy server- taking 1000 or more requests a second...
  11263. U>  One solution might be for the server to build it's own key- based on
  11264. U>NAS_IP,  SESSION_ID, and USER_NAME for example.  That would make the
  11265. U>packets pretty unique in most situations. This is the method used by
  11266. U>the latest version of 3Com's security server.
  11267.  
  11268.  
  11269. Do you mean 6.09 ?  If so, what about 6.08 ?
  11270.  
  11271. Jeff Binkley
  11272. ASA Network Computing
  11273.  
  11274.  
  11275. U>    Thanks,
  11276. U>     Steve_valiunas@3com.com
  11277.  
  11278. CMPQwk 1.42 9999
  11279.  
  11280. -
  11281.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11282.  with "unsubscribe usr-tc" in the body of the message.
  11283.  For information on digests or retrieving files and old messages send
  11284.  "help" to the same address.  Do not use quotes in your message.
  11285.  
  11286.  
  11287.  
  11288.  
  11289.  
  11290.  
  11291. -
  11292.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11293.  with "unsubscribe usr-tc" in the body of the message.
  11294.  For information on digests or retrieving files and old messages send
  11295.  "help" to the same address.  Do not use quotes in your message.
  11296.  
  11297.  
  11298. -------------------------------------------------------------------------------
  11299.  
  11300. From:  <farber@admin.f-tech.net>
  11301. Subject: RE: (usr-tc) 2.0.60 HDM Code
  11302. Date: 13 Oct 1999 09:30:02 -0400 (EDT)
  11303.  
  11304. If you call tech support at 2AM you are wasting your time.  Heck even if
  11305. you call at 11am you are wasting your time.  The support is just not
  11306. there.  I would find youself a good VAR (like source technology) that has
  11307. in house tech support for 3Com and use them first.
  11308.  
  11309. I guess that's the jist of most of the complaints.  I think 3Com is
  11310. realizing this but in an effort to keep revenue up they don't improve
  11311. support to meet the bottom line.... they just redo the contracts for
  11312. support and charge you more to make up for the people who have dropped
  11313. thier program.
  11314.  
  11315. How can other MAJOR access manufacturers get away with relaesing free code
  11316. for updates and 3Com cannot?  If 2.0.6 has a bug in it.. I shouldn't have
  11317. to pay for 2.0.7 that fixes the bug they sold me in the first place.
  11318. Thier almost as bad as Microsoft when it comes to licensing.
  11319.  
  11320. I remember about 2 years ago someone wrote an open letter to 3Com/USR
  11321. about the Total Control chassis and put it on the web... 3Com did respond
  11322. but it was a standard "we are continuing to make improvements" letter.
  11323.  
  11324. It sad that the customer base has to get just short of a revolt in order
  11325. to get even that kind of form letter response.
  11326.  
  11327. I am getting tired of 3Com, it's lack of interest in supporting it's users
  11328. and a support program that just plain is not worth it.
  11329.  
  11330. Paul Farber
  11331. Farber Technology
  11332. farber@admin.f-tech.net
  11333. Ph  570-628-5303
  11334. Fax 570-628-5545
  11335.  
  11336. > Those of us new to the platform (myself included) might benefit from the
  11337. > convenience of knowing that phone support is available 24x7 when you're
  11338. > staring at a box not taking calls at 2AM. But once you get the hang of TC
  11339. > and know how to troubleshoot these things on your own (or at least with the
  11340. > added help of those on this list), you can drop the tel support, and just
  11341. > pay for code updates.
  11342.  
  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. From: Jeff Mcadams <jeffm@iglou.com>
  11354. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  11355. Date: 13 Oct 1999 09:23:40 -0400
  11356.  
  11357. Thus spake Steve Valiunas
  11358. >>Do you mean 6.09 ?  If so, what about 6.08 ?
  11359.  
  11360. >    It's available in an Engineering Release, so you'll have to call
  11361. >tech support.  (I know- another example of excess bureaucracy <g>).  
  11362.  
  11363. Heh...I really don't mind calling tech support for ER's, it just kinda
  11364. annoyed me that tech support now has to go get permission from someone
  11365. else to give them out.   :)  And even that doesn't *terribly* bother
  11366. me...at least not on its own...its just a single fairly small example of
  11367. the larger problem.  :)
  11368. -- 
  11369. Jeff McAdams                            Email: jeffm@iglou.com
  11370. Head Network Administrator              Voice: (502) 966-3848
  11371. IgLou Internet Services                        (800) 436-4456
  11372.  
  11373. -
  11374.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11375.  with "unsubscribe usr-tc" in the body of the message.
  11376.  For information on digests or retrieving files and old messages send
  11377.  "help" to the same address.  Do not use quotes in your message.
  11378.  
  11379.  
  11380. -------------------------------------------------------------------------------
  11381.  
  11382. From: Aaron Nabil <nabil@spiritone.com>
  11383. Subject: Re: (usr-tc) Radius question
  11384. Date: 13 Oct 1999 07:35:32 -0700 (PDT)
  11385.  
  11386. Steve Valiunas writes...
  11387. > . . . 
  11388. >>>But later, when it comes time to send another request, it has
  11389. >>>"forgotten" that it previously incremented the identifier and merrily
  11390. >>>uses the last one again!
  11391. >
  11392. > Can you send along an example of this happening (using the same packet-ID
  11393. >twice in a row for the same destination port and with current HiperArc code)?
  11394. >If it is an issue it will be fixed.  Keep in mind though that it only
  11395. >takes a couple hundred packets to wrap back around and reuse the same ID
  11396. >again.
  11397.  
  11398. Sure.  As it happens, I still had the patch in my Radius to test
  11399. this, just a matter of changing the values.
  11400.  
  11401. First thing I tested was the auth, it now works fine, it doesn't
  11402. change the id on retransmit, and after a retransmit it correctly
  11403. increments the id.  If this was fixed intentionally, thanks.
  11404.  
  11405. Here's the acct test.  I patched our radius server to ignore request
  11406. ID 205.  I logged in, logged out (but ignored the stop), logged back
  11407. in, and the NAS has re-used ID 206 from the "retransmit" of the stop
  11408. for the start.
  11409.  
  11410.  
  11411. Code:       Accounting-Request
  11412. Identifier: 204
  11413. Attributes:
  11414.         Class = "902"
  11415.         User-Name = "nabil"
  11416.         Acct-Status-Type = Start
  11417.         Acct-Session-Id = "16777229"
  11418.         Acct-Delay-Time = 0
  11419.         Acct-Authentic = RADIUS
  11420.         Service-Type = Framed-User
  11421.         NAS-Port-Type = Async
  11422.         NAS-Port = 25
  11423.         USR-Modem-Training-Time = 18
  11424.         USR-Interface-Index = 1513
  11425.         USR-Chassis-Call-Slot = 2
  11426.         USR-Chassis-Call-Span = 1
  11427.         USR-Chassis-Call-Channel = 1
  11428.         USR-Unauthenticated-Time = 4
  11429.         Calling-Station-Id = ""
  11430.         USR-Modulation-Type = v90Digital
  11431.         USR-Simplified-MNP-Levels = ccittV42
  11432.         USR-Simplified-V42bis-Usage = ccittV42bis
  11433.         USR-Connect-Speed = 46666_BPS
  11434.         Framed-Protocol = PPP
  11435.  
  11436. Code:       Accounting-Response
  11437. Identifier: 204
  11438. Attributes:
  11439.  
  11440. Code:       Accounting-Request
  11441. Identifier: 205
  11442. Attributes:
  11443.         Class = "902"
  11444.         User-Name = "nabil"
  11445.         Acct-Status-Type = Stop
  11446.         Acct-Session-Id = "16777229"
  11447.         Acct-Delay-Time = 0
  11448.         Acct-Authentic = RADIUS
  11449.         Service-Type = Framed-User
  11450.         NAS-Port-Type = Async
  11451.         NAS-Port = 25
  11452.         USR-Modem-Training-Time = 18
  11453.         USR-Interface-Index = 1513
  11454.         USR-Chassis-Call-Slot = 2
  11455.         USR-Chassis-Call-Span = 1
  11456.         USR-Chassis-Call-Channel = 1
  11457.         USR-Unauthenticated-Time = 4
  11458.         Calling-Station-Id = ""
  11459.         USR-Modulation-Type = v90Digital
  11460.         USR-Simplified-MNP-Levels = ccittV42
  11461.         USR-Simplified-V42bis-Usage = ccittV42bis
  11462.         USR-Connect-Speed = 46666_BPS
  11463.         Framed-Protocol = PPP
  11464.         Acct-Session-Time = 9
  11465.         Acct-Terminate-Cause = User-Request
  11466.         Acct-Input-Octets = 440
  11467.         Acct-Output-Octets = 289
  11468.         Acct-Input-Packets = 15
  11469.         Acct-Output-Packets = 13
  11470.  
  11471. Code:       Accounting-Request
  11472. Identifier: 206
  11473. Attributes:
  11474.         Class = "902"
  11475.         User-Name = "nabil"
  11476.         Acct-Status-Type = Stop
  11477.         Acct-Session-Id = "16777229"
  11478.         Acct-Delay-Time = 60
  11479.         Acct-Authentic = RADIUS
  11480.         Service-Type = Framed-User
  11481.         NAS-Port-Type = Async
  11482.         NAS-Port = 25
  11483.         USR-Modem-Training-Time = 18
  11484.         USR-Interface-Index = 1513
  11485.         USR-Chassis-Call-Slot = 2
  11486.         USR-Chassis-Call-Span = 1
  11487.         USR-Chassis-Call-Channel = 1
  11488.         USR-Unauthenticated-Time = 4
  11489.         Calling-Station-Id = ""
  11490.         USR-Modulation-Type = v90Digital
  11491.         USR-Simplified-MNP-Levels = ccittV42
  11492.         USR-Simplified-V42bis-Usage = ccittV42bis
  11493.         USR-Connect-Speed = 46666_BPS
  11494.         Framed-Protocol = PPP
  11495.         Acct-Session-Time = 9
  11496.         Acct-Terminate-Cause = User-Request
  11497.         Acct-Input-Octets = 440
  11498.         Acct-Output-Octets = 289
  11499.         Acct-Input-Packets = 15
  11500.         Acct-Output-Packets = 13
  11501.  
  11502. Code:       Accounting-Response
  11503. Identifier: 206
  11504. Attributes:
  11505.  
  11506. Code:       Accounting-Request
  11507. Identifier: 206
  11508. Attributes:
  11509.         Class = "902"
  11510.         User-Name = "nabil"
  11511.         Acct-Status-Type = Start
  11512.         Acct-Session-Id = "16777230"
  11513.         Acct-Delay-Time = 0
  11514.         Acct-Authentic = RADIUS
  11515.         Service-Type = Framed-User
  11516.         NAS-Port-Type = Async
  11517.         NAS-Port = 25
  11518.         USR-Modem-Training-Time = 18
  11519.         USR-Interface-Index = 1513
  11520.         USR-Chassis-Call-Slot = 2
  11521.         USR-Chassis-Call-Span = 1
  11522.         USR-Chassis-Call-Channel = 1
  11523.         USR-Unauthenticated-Time = 5
  11524.         Calling-Station-Id = ""
  11525.         USR-Modulation-Type = v90Digital
  11526.         USR-Simplified-MNP-Levels = ccittV42
  11527.         USR-Simplified-V42bis-Usage = ccittV42bis
  11528.         USR-Connect-Speed = 46666_BPS
  11529.         Framed-Protocol = PPP
  11530.  
  11531. ** Sending to 208.130.244.232 port 1646 ....
  11532. Code:       Accounting-Response
  11533. Identifier: 206
  11534. Attributes:
  11535.  
  11536. Code:       Accounting-Request
  11537. Identifier: 207
  11538. Attributes:
  11539.         Class = "902"
  11540.         User-Name = "nabil"
  11541.         NAS-IP-Address = 208.130.244.232
  11542.         Acct-Status-Type = Stop
  11543.         Acct-Session-Id = "16777230"
  11544.         Acct-Delay-Time = 0
  11545.         . . .
  11546.  
  11547. >
  11548. > . . .
  11549. >What exactly was it that 3com missed in the RFC?
  11550.  
  11551. The part about unique identifiers.  Ie, using the same identifier for
  11552. two packets in a row isn't good.  Above, you re-used 206.
  11553.  
  11554. In addition to fixing this obviously broken behavior, how about providing
  11555. a configurable on the hiperarc to suppress the "acct-delay" so that 
  11556. retransmitted packets would be identical (and have the same ID), and thus 
  11557. easily filtered out by less sophisticated radius servers?
  11558.  
  11559.  
  11560. -- 
  11561. Aaron Nabil
  11562.  
  11563. -
  11564.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11565.  with "unsubscribe usr-tc" in the body of the message.
  11566.  For information on digests or retrieving files and old messages send
  11567.  "help" to the same address.  Do not use quotes in your message.
  11568.  
  11569.  
  11570. -------------------------------------------------------------------------------
  11571.  
  11572. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  11573. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  11574. Date: 13 Oct 1999 10:01:50 -0500
  11575.  
  11576.  
  11577.  
  11578.   The poor horse isn't even flinching anymore,  but...   We only perform limited
  11579. in-house testing on ERs so they can go out quickly-( we don't run them through
  11580. our internal testing group)  so we try to be careful about their distribution.
  11581. When I make an ER available I want to have accurate contact info for the
  11582. customer so I can get ahold of them if something nasty shows up with it at a
  11583. customer site.   If after a number of days several users have indicated that it
  11584. has fixed their issue and it warrants posting,  it will become a candidate for
  11585. being made available on totalservice for download as a ServiceRelease.
  11586.     It's a trade off-  There's an extra step involved for you (and for the call
  11587. center),  but there's less liklyhood of an ER causing problems for someone
  11588. because a problem was found and they didn't know.
  11589.    This was probably just a rehash of what Todd said the other day...
  11590.  
  11591. Steve
  11592.  
  11593.  
  11594.  
  11595.  
  11596.  
  11597. Jeff Mcadams <jeffm@iglou.com> on 10/13/99 08:23:40 AM
  11598.  
  11599. Please respond to usr-tc@lists.xmission.com
  11600.  
  11601. Sent by:  Jeff Mcadams <jeffm@iglou.com>
  11602.  
  11603.  
  11604. cc:    (Steve Valiunas/MW/US/3Com)
  11605.  
  11606.  
  11607.  
  11608.  
  11609. Thus spake Steve Valiunas
  11610. >>Do you mean 6.09 ?  If so, what about 6.08 ?
  11611.  
  11612. >    It's available in an Engineering Release, so you'll have to call
  11613. >tech support.  (I know- another example of excess bureaucracy <g>).
  11614.  
  11615. Heh...I really don't mind calling tech support for ER's, it just kinda
  11616. annoyed me that tech support now has to go get permission from someone
  11617. else to give them out.   :)  And even that doesn't *terribly* bother
  11618. me...at least not on its own...its just a single fairly small example of
  11619. the larger problem.  :)
  11620. --
  11621. Jeff McAdams                            Email: jeffm@iglou.com
  11622. Head Network Administrator              Voice: (502) 966-3848
  11623. IgLou Internet Services                        (800) 436-4456
  11624.  
  11625. -
  11626.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11627.  with "unsubscribe usr-tc" in the body of the message.
  11628.  For information on digests or retrieving files and old messages send
  11629.  "help" to the same address.  Do not use quotes in your message.
  11630.  
  11631.  
  11632.  
  11633.  
  11634.  
  11635.  
  11636. -
  11637.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11638.  with "unsubscribe usr-tc" in the body of the message.
  11639.  For information on digests or retrieving files and old messages send
  11640.  "help" to the same address.  Do not use quotes in your message.
  11641.  
  11642.  
  11643. -------------------------------------------------------------------------------
  11644.  
  11645. From: Jeff Mcadams <jeffm@iglou.com>
  11646. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  11647. Date: 13 Oct 1999 11:35:17 -0400
  11648.  
  11649. Thus spake Steve Valiunas
  11650. >  The poor horse isn't even flinching anymore,  but...   We only
  11651. >perform limited in-house testing on ERs so they can go out quickly-( we
  11652. >don't run them through our internal testing group)  so we try to be
  11653. >careful about their distribution.  When I make an ER available I want
  11654. >to have accurate contact info for the customer so I can get ahold of
  11655. >them if something nasty shows up with it at a customer site.   If after
  11656. >a number of days several users have indicated that it has fixed their
  11657. >issue and it warrants posting,  it will become a candidate for being
  11658. >made available on totalservice for download as a ServiceRelease.
  11659.  
  11660. Here's the crux of the issue.  3Com is basically adding more layers of
  11661. beaurocracy to try to *help* communication with their customers.  I'm
  11662. sorry, but that's just going about it the wrong way.
  11663.  
  11664. Linux kernel 2.3.21 *certainly* isn't extensively tested, and its
  11665. publicly available.  Cisco version 12.0 IOS certainly had plenty of bugs
  11666. in it when it was released...if you make stuff available to your
  11667. customers, and strip out all these layers of crap that we have to go
  11668. through, you *will* get more feedback from customers and foster better
  11669. communication between 3Com and us.  As it is, all you're doing is
  11670. forcing people to switch to informal support methods (and eschewing
  11671. support contracts...that its gotten to that point is a *SERIOUS*
  11672. indictment of 3Com) because we *can't* get the support we need and the
  11673. communication between 3Com and us concerning these releases...so then
  11674. 3Com, in an effort to fix this, just goes and adds yet another layer,
  11675. and makes it that much harder to get significant communication going.
  11676.  
  11677. You know...I've been avoiding "warezing" the 3Com releases in an effort
  11678. to give 3Com the benefit of the doubt...I'm just about -><- far away
  11679. from changing that attitude because 3Com keeps screwing their customers
  11680. over with respect to this and other things.  I've tried my best to work
  11681. within the system for 3Com, and I'm really running out of patience.
  11682. I've talked to sales reps, SE's, even product managers, and my (dare I
  11683. speak for other list members?) concerns have been, basically, blown off.
  11684.  
  11685. I'm saying, controlling the ER releases that closely is a "Bad
  11686. Thing[tm]"...and my thought isn't even (apparently) being considered in
  11687. the slightest.  Instead, the mantra is repeated that they're not fully
  11688. tested.  Bully...they're not fully tested...I don't care!  Put the
  11689. releases out there...tell us what you've changed in each, let *us*
  11690. figure out whether its a good idea to use that code in our situation or
  11691. not.  To be brutally honest, 3Com hasn't even shown that they can
  11692. consistently provide even basic tech support on this equipment (with the
  11693. exception of a few individuals...most of which, from what I can see, are
  11694. on this list), let *alone* know what the best thing to do in a real live
  11695. production environment is.
  11696.  
  11697. >    It's a trade off-  There's an extra step involved for you (and for
  11698. >the call center),  but there's less liklyhood of an ER causing problems
  11699. >for someone because a problem was found and they didn't know.
  11700.  
  11701. Again...this just points to the need for *more* communication and less
  11702. insulation of the customer, not the need to add "yet another" layer in
  11703. process.  Make bug tracking databases publically available.  (rework
  11704. your release numbering system so that it actually uses some semblance of
  11705. logic).  Make development work more transparent.
  11706.  
  11707. Shoot...if you need a bug tracking product to do this...just go to
  11708. www.mozilla.org and grab bugzilla...its open source, doesn't cost a
  11709. penny...works great, and is easily set up to allow public access to it.
  11710.  
  11711. As I said in a previous post...if such major issues as have been
  11712. mentioned here in the past couple of days are still outstanding after
  11713. such a lengthy period of time as many of them have still been
  11714. outstanding...there's something intrensically wrong with the system and
  11715. putting more layers on the system isn't the way to fix it.
  11716.  
  11717. Maybe I should take a dose of my own medicine...I've been working from
  11718. the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to
  11719. come at it from the other direction.  Maybe I/we need to start from the
  11720. top down...since my current actions seems to be ineffective, perhaps my
  11721. system is intrensically broken and I should be emailing Eric Benhamou
  11722. and Bruce Claflin and the like...maybe if I can get them to understand,
  11723. then some substantive changes will take place.
  11724.  
  11725. As I said the other day, 3Com's corporate reaction seems to be to put
  11726. *more* layers in the functioning when they see that there's a problem in
  11727. the process...they seem to do this without thinking that the solution
  11728. might really be to *remove* some.  Has anyone in 3Com even really
  11729. *considered* the idea that it might be better to have wide distribution
  11730. of these releases rather than trying to limit it?
  11731.  
  11732. Look at the thread that was going on regarding problems with OSPF.  I
  11733. didn't know the full extent of the problem, but someone else did.  If I
  11734. had been the only one with that code, 3Com wouldn't have really known
  11735. what was wrong there.
  11736.  
  11737. Cut out the layers of beaurocracy and I'd be willing to be that you'll
  11738. get better response from customers, better communication, fewer
  11739. complaints, and better feedback (without having to track and initiate
  11740. that feedback yourself) from customers because they'll *want* to help
  11741. you, and it won't be an arduous task for us.  I'm a generally helpful
  11742. guy, but I tend to not provide feedback to 3Com because I know its going
  11743. to end up being a several day ordeal and may not achieve any results.
  11744. This is all a result of the beaurocracy involved.  Strip it out and, at
  11745. least speaking for myself, you'll get considerably *more* feedback.
  11746.  
  11747. As with all of my posts...I feel I own my words, so feel free, (indeed,
  11748. please do!) forward my posts on up the chain of command, or on to anyone
  11749. that might be able to benefit.  My phone number is in my .sig, my
  11750. extension is 1153, I'm definitely not trying to do a hit and run
  11751. complaint here.  :)
  11752.  
  11753. I also know that the people on this list (for the most part from what
  11754. I've seen) are not in a position to do anything about these things
  11755. directly.  Believe me, I'm not trying to cause your life to be
  11756. miserable...I just don't know any other way to get feedback to 3Com
  11757. about these things.  Point me in a better direction and I'll go there (I
  11758. know...talk to my sales rep...I already have...he's very aware of our
  11759. issues here).
  11760.  
  11761. >   This was probably just a rehash of what Todd said the other day...
  11762.  
  11763. Basically, yeah...but better a rehash of things than no communication at
  11764. all.  :)
  11765. -- 
  11766. Jeff McAdams                            Email: jeffm@iglou.com
  11767. Head Network Administrator              Voice: (502) 966-3848
  11768. IgLou Internet Services                        (800) 436-4456
  11769.  
  11770. -
  11771.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11772.  with "unsubscribe usr-tc" in the body of the message.
  11773.  For information on digests or retrieving files and old messages send
  11774.  "help" to the same address.  Do not use quotes in your message.
  11775.  
  11776.  
  11777. -------------------------------------------------------------------------------
  11778.  
  11779. From: "Scot Desort" <scot@njaccess.net>
  11780. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  11781. Date: 13 Oct 1999 12:06:17 -0400
  11782.  
  11783. Jeff Mcadams wrote:
  11784.  
  11785. > They already have a software only support contract...its just as
  11786. > ridiculous as the rest of them.
  11787.  
  11788. Geez, didn't realize that. So I guess the pricing is not attractive? We all
  11789. want free, but if it were only a nominal charge, that might have helped ;-(
  11790.  
  11791. > I think Scot (it is just 1 "t" right?) has some very good points here
  11792.  
  11793. Yep, 1 't'. Thanks for noticing :-)
  11794.  
  11795. > Better communication between the developers and
  11796. > customers would fix this...if I knew that 3Com kept up good
  11797. > communication with someone who reported a problem regarding that problem
  11798. > and I weren't getting feedback about a problem I reported, then I'd know
  11799. > to call again and try again, or know to go forward with a public posting
  11800. > since it would seem that 3Com hasn't deemed it worthy to fix.  However,
  11801. > given 3Com's unbelievably closed development environment, I haven't a
  11802. > clue if this thing is sitting in some engineer's queue somewhere to be
  11803. > fixed or not.  (Even if it is in a queue somewhere, for a security bug
  11804. > like this, even that's unacceptable).
  11805.  
  11806. Exactly. Not knowing what's being done only adds to the frustration and
  11807. resentment.
  11808.  
  11809.  
  11810. > 3Com needs to seriously open up to their customers here...remove many
  11811. > layers of beaurocracy (these two statements amount to the same thing),
  11812. > and get them more involved...maybe even make the engineering mailing
  11813. > lists and stuff publically available...get the customers in on the
  11814. > actual development process.  Maybe making them publically available
  11815. > would be a bad idea (would end up with too much noise), but perhaps
  11816. > invite specific customers to join in?  There are certainly a few people
  11817. > on this list that could give you some good feedback.  I know...this is a
  11818. > pretty radical idea...maybe it doesn't need to go this far, but just
  11819. > something that one of my co-workers and I were discussing the other day.
  11820. > Regardless of how its done, 3Com *definitely* needs to open up to their
  11821. > customers more.  When, in the course of 2-3 days on a mailing list, 4 or
  11822. > 5 *MAJOR* issues can be mentioned that are still unaddressed after about
  11823. > a year for each...something needs to be done.
  11824.  
  11825. Hopefully something will change soon. It's a shame that something as basic
  11826. as the lack of close interaction with the user base is keeping the TC
  11827. product line from truly standing out in the NAS arena. 3COM, as you've
  11828. stated in the past many times, really has something special on their hands,
  11829. and the TC platform can do so much more. But until these basic code issues
  11830. and responsiveness to the needs of the users is addressed, the platform may
  11831. become doomed before it matures.
  11832.  
  11833. -Scot
  11834. NJAccess
  11835.  
  11836.  
  11837.  
  11838. -
  11839.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11840.  with "unsubscribe usr-tc" in the body of the message.
  11841.  For information on digests or retrieving files and old messages send
  11842.  "help" to the same address.  Do not use quotes in your message.
  11843.  
  11844.  
  11845. -------------------------------------------------------------------------------
  11846.  
  11847. From: "Ed" <ed@taylors.com>
  11848. Subject: (usr-tc) Awesome Jeff!
  11849. Date: 13 Oct 1999 12:03:28 -0400
  11850.  
  11851. <Claps>
  11852.  
  11853. Jeff you have pretty much completely summed up 3com support and technical
  11854. problems. Everyone should read your post.
  11855.  
  11856. I have said for months how much better it was as USR. Yes it had it's faults
  11857. but it was much better none the less. They LISTENED and tried to work to a
  11858. solution. We never had so many outstanding issues and that was 2 years ago.
  11859. You would think by now it would be close to perfected... it's not however
  11860. and this is because it is one way communication the other side isn't
  11861. listening. They dictate the rules and regs to us the customers and give the
  11862. attitude like it or leave it... we are close to leaving it.
  11863.  
  11864. Way too much beaurocracy to wade through at 3com. We have spent upwards of
  11865. $1,000,000 on 3com equipment and it doesn't seem to matter. Our word has
  11866. little value... Although I must give credit George Ebert has tried to help
  11867. and some high level guys like Krishnan and Mike Wronski do an awesome job
  11868. but they too are caught up in the muck of beaurocracy. You can't get to
  11869. these guys without going through red tape... and they cannot personally deal
  11870. with all customers.
  11871.  
  11872.  
  11873. Ed
  11874.  
  11875. ----- Original Message -----
  11876. Sent: Wednesday, October 13, 1999 11:35 AM
  11877.  
  11878.  
  11879. Thus spake Steve Valiunas
  11880. >  The poor horse isn't even flinching anymore,  but...   We only
  11881. >perform limited in-house testing on ERs so they can go out quickly-( we
  11882. >don't run them through our internal testing group)  so we try to be
  11883. >careful about their distribution.  When I make an ER available I want
  11884. >to have accurate contact info for the customer so I can get ahold of
  11885. >them if something nasty shows up with it at a customer site.   If after
  11886. >a number of days several users have indicated that it has fixed their
  11887. >issue and it warrants posting,  it will become a candidate for being
  11888. >made available on totalservice for download as a ServiceRelease.
  11889.  
  11890. Here's the crux of the issue.  3Com is basically adding more layers of
  11891. beaurocracy to try to *help* communication with their customers.  I'm
  11892. sorry, but that's just going about it the wrong way.
  11893.  
  11894. Linux kernel 2.3.21 *certainly* isn't extensively tested, and its
  11895. publicly available.  Cisco version 12.0 IOS certainly had plenty of bugs
  11896. in it when it was released...if you make stuff available to your
  11897. customers, and strip out all these layers of crap that we have to go
  11898. through, you *will* get more feedback from customers and foster better
  11899. communication between 3Com and us.  As it is, all you're doing is
  11900. forcing people to switch to informal support methods (and eschewing
  11901. support contracts...that its gotten to that point is a *SERIOUS*
  11902. indictment of 3Com) because we *can't* get the support we need and the
  11903. communication between 3Com and us concerning these releases...so then
  11904. 3Com, in an effort to fix this, just goes and adds yet another layer,
  11905. and makes it that much harder to get significant communication going.
  11906.  
  11907. You know...I've been avoiding "warezing" the 3Com releases in an effort
  11908. to give 3Com the benefit of the doubt...I'm just about -><- far away
  11909. from changing that attitude because 3Com keeps screwing their customers
  11910. over with respect to this and other things.  I've tried my best to work
  11911. within the system for 3Com, and I'm really running out of patience.
  11912. I've talked to sales reps, SE's, even product managers, and my (dare I
  11913. speak for other list members?) concerns have been, basically, blown off.
  11914.  
  11915. I'm saying, controlling the ER releases that closely is a "Bad
  11916. Thing[tm]"...and my thought isn't even (apparently) being considered in
  11917. the slightest.  Instead, the mantra is repeated that they're not fully
  11918. tested.  Bully...they're not fully tested...I don't care!  Put the
  11919. releases out there...tell us what you've changed in each, let *us*
  11920. figure out whether its a good idea to use that code in our situation or
  11921. not.  To be brutally honest, 3Com hasn't even shown that they can
  11922. consistently provide even basic tech support on this equipment (with the
  11923. exception of a few individuals...most of which, from what I can see, are
  11924. on this list), let *alone* know what the best thing to do in a real live
  11925. production environment is.
  11926.  
  11927. >    It's a trade off-  There's an extra step involved for you (and for
  11928. >the call center),  but there's less liklyhood of an ER causing problems
  11929. >for someone because a problem was found and they didn't know.
  11930.  
  11931. Again...this just points to the need for *more* communication and less
  11932. insulation of the customer, not the need to add "yet another" layer in
  11933. process.  Make bug tracking databases publically available.  (rework
  11934. your release numbering system so that it actually uses some semblance of
  11935. logic).  Make development work more transparent.
  11936.  
  11937. Shoot...if you need a bug tracking product to do this...just go to
  11938. www.mozilla.org and grab bugzilla...its open source, doesn't cost a
  11939. penny...works great, and is easily set up to allow public access to it.
  11940.  
  11941. As I said in a previous post...if such major issues as have been
  11942. mentioned here in the past couple of days are still outstanding after
  11943. such a lengthy period of time as many of them have still been
  11944. outstanding...there's something intrensically wrong with the system and
  11945. putting more layers on the system isn't the way to fix it.
  11946.  
  11947. Maybe I should take a dose of my own medicine...I've been working from
  11948. the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to
  11949. come at it from the other direction.  Maybe I/we need to start from the
  11950. top down...since my current actions seems to be ineffective, perhaps my
  11951. system is intrensically broken and I should be emailing Eric Benhamou
  11952. and Bruce Claflin and the like...maybe if I can get them to understand,
  11953. then some substantive changes will take place.
  11954.  
  11955. As I said the other day, 3Com's corporate reaction seems to be to put
  11956. *more* layers in the functioning when they see that there's a problem in
  11957. the process...they seem to do this without thinking that the solution
  11958. might really be to *remove* some.  Has anyone in 3Com even really
  11959. *considered* the idea that it might be better to have wide distribution
  11960. of these releases rather than trying to limit it?
  11961.  
  11962. Look at the thread that was going on regarding problems with OSPF.  I
  11963. didn't know the full extent of the problem, but someone else did.  If I
  11964. had been the only one with that code, 3Com wouldn't have really known
  11965. what was wrong there.
  11966.  
  11967. Cut out the layers of beaurocracy and I'd be willing to be that you'll
  11968. get better response from customers, better communication, fewer
  11969. complaints, and better feedback (without having to track and initiate
  11970. that feedback yourself) from customers because they'll *want* to help
  11971. you, and it won't be an arduous task for us.  I'm a generally helpful
  11972. guy, but I tend to not provide feedback to 3Com because I know its going
  11973. to end up being a several day ordeal and may not achieve any results.
  11974. This is all a result of the beaurocracy involved.  Strip it out and, at
  11975. least speaking for myself, you'll get considerably *more* feedback.
  11976.  
  11977. As with all of my posts...I feel I own my words, so feel free, (indeed,
  11978. please do!) forward my posts on up the chain of command, or on to anyone
  11979. that might be able to benefit.  My phone number is in my .sig, my
  11980. extension is 1153, I'm definitely not trying to do a hit and run
  11981. complaint here.  :)
  11982.  
  11983. I also know that the people on this list (for the most part from what
  11984. I've seen) are not in a position to do anything about these things
  11985. directly.  Believe me, I'm not trying to cause your life to be
  11986. miserable...I just don't know any other way to get feedback to 3Com
  11987. about these things.  Point me in a better direction and I'll go there (I
  11988. know...talk to my sales rep...I already have...he's very aware of our
  11989. issues here).
  11990.  
  11991. >   This was probably just a rehash of what Todd said the other day...
  11992.  
  11993. Basically, yeah...but better a rehash of things than no communication at
  11994. all.  :)
  11995. --
  11996. Jeff McAdams                            Email: jeffm@iglou.com
  11997. Head Network Administrator              Voice: (502) 966-3848
  11998. IgLou Internet Services                        (800) 436-4456
  11999.  
  12000. -
  12001.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12002.  with "unsubscribe usr-tc" in the body of the message.
  12003.  For information on digests or retrieving files and old messages send
  12004.  "help" to the same address.  Do not use quotes in your message.
  12005.  
  12006.  
  12007.  
  12008. -
  12009.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12010.  with "unsubscribe usr-tc" in the body of the message.
  12011.  For information on digests or retrieving files and old messages send
  12012.  "help" to the same address.  Do not use quotes in your message.
  12013.  
  12014.  
  12015. -------------------------------------------------------------------------------
  12016.  
  12017. From: "Ed" <ed@taylors.com>
  12018. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  12019. Date: 13 Oct 1999 12:15:46 -0400
  12020.  
  12021. "the platform may become doomed before it matures."
  12022.  
  12023. It has had years to mature... I believe it was actually further along and
  12024. more mature when USR had it. I mean OSPF is just now being released. Other
  12025. platforms have had OSPF for over 2 years. From what I understand before 3com
  12026. took over many things were slated to be done but dropped.
  12027.  
  12028. Ed
  12029.  
  12030. ----- Original Message -----
  12031. Sent: Wednesday, October 13, 1999 12:06 PM
  12032.  
  12033.  
  12034. Jeff Mcadams wrote:
  12035.  
  12036. > They already have a software only support contract...its just as
  12037. > ridiculous as the rest of them.
  12038.  
  12039. Geez, didn't realize that. So I guess the pricing is not attractive? We all
  12040. want free, but if it were only a nominal charge, that might have helped ;-(
  12041.  
  12042. > I think Scot (it is just 1 "t" right?) has some very good points here
  12043.  
  12044. Yep, 1 't'. Thanks for noticing :-)
  12045.  
  12046. > Better communication between the developers and
  12047. > customers would fix this...if I knew that 3Com kept up good
  12048. > communication with someone who reported a problem regarding that problem
  12049. > and I weren't getting feedback about a problem I reported, then I'd know
  12050. > to call again and try again, or know to go forward with a public posting
  12051. > since it would seem that 3Com hasn't deemed it worthy to fix.  However,
  12052. > given 3Com's unbelievably closed development environment, I haven't a
  12053. > clue if this thing is sitting in some engineer's queue somewhere to be
  12054. > fixed or not.  (Even if it is in a queue somewhere, for a security bug
  12055. > like this, even that's unacceptable).
  12056.  
  12057. Exactly. Not knowing what's being done only adds to the frustration and
  12058. resentment.
  12059.  
  12060.  
  12061. > 3Com needs to seriously open up to their customers here...remove many
  12062. > layers of beaurocracy (these two statements amount to the same thing),
  12063. > and get them more involved...maybe even make the engineering mailing
  12064. > lists and stuff publically available...get the customers in on the
  12065. > actual development process.  Maybe making them publically available
  12066. > would be a bad idea (would end up with too much noise), but perhaps
  12067. > invite specific customers to join in?  There are certainly a few people
  12068. > on this list that could give you some good feedback.  I know...this is a
  12069. > pretty radical idea...maybe it doesn't need to go this far, but just
  12070. > something that one of my co-workers and I were discussing the other day.
  12071. > Regardless of how its done, 3Com *definitely* needs to open up to their
  12072. > customers more.  When, in the course of 2-3 days on a mailing list, 4 or
  12073. > 5 *MAJOR* issues can be mentioned that are still unaddressed after about
  12074. > a year for each...something needs to be done.
  12075.  
  12076. Hopefully something will change soon. It's a shame that something as basic
  12077. as the lack of close interaction with the user base is keeping the TC
  12078. product line from truly standing out in the NAS arena. 3COM, as you've
  12079. stated in the past many times, really has something special on their hands,
  12080. and the TC platform can do so much more. But until these basic code issues
  12081. and responsiveness to the needs of the users is addressed, the platform may
  12082. become doomed before it matures.
  12083.  
  12084. -Scot
  12085. NJAccess
  12086.  
  12087.  
  12088.  
  12089. -
  12090.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12091.  with "unsubscribe usr-tc" in the body of the message.
  12092.  For information on digests or retrieving files and old messages send
  12093.  "help" to the same address.  Do not use quotes in your message.
  12094.  
  12095.  
  12096.  
  12097. -
  12098.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12099.  with "unsubscribe usr-tc" in the body of the message.
  12100.  For information on digests or retrieving files and old messages send
  12101.  "help" to the same address.  Do not use quotes in your message.
  12102.  
  12103.  
  12104. -------------------------------------------------------------------------------
  12105.  
  12106. From:  <farber@admin.f-tech.net>
  12107. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  12108. Date: 13 Oct 1999 12:24:15 -0400 (EDT)
  12109.  
  12110. > Thus spake Steve Valiunas
  12111. > >  The poor horse isn't even flinching anymore,  but...   We only
  12112. > >perform limited in-house testing on ERs so they can go out quickly-( we
  12113. > >don't run them through our internal testing group)  so we try to be
  12114. > >careful about their distribution.  When I make an ER available I want
  12115. > >to have accurate contact info for the customer so I can get ahold of
  12116. > >them if something nasty shows up with it at a customer site.   If after
  12117. > >a number of days several users have indicated that it has fixed their
  12118. > >issue and it warrants posting,  it will become a candidate for being
  12119. > >made available on totalservice for download as a ServiceRelease.
  12120.  
  12121. This would seem to be a contradiction of what most of us call BETA
  12122. testing.  If you only release ER code to a few select site.. then how can
  12123. you verify your code base will work when put out for general consumption?
  12124. Having two/three beta sites is not a through test.. it's more like an
  12125. attempt to beta test.
  12126.  
  12127. I would say release ER to all, then when customers call support (or an
  12128. engineer) about problems with the ER they can talk to the person involved
  12129. with the code... not a tech-bot in front of some database without a clue.
  12130.  
  12131. Most people will not just install an ER unless they know they need it.  If
  12132. they do and it blows up.. then hey, it's a beta and you get what you get.
  12133. 3Com's attempt to protect us from ourselves is not going over well.
  12134.  
  12135. BTW.. what about a LINUX port of TCM!!!!!!!!  Who can I mailbomb
  12136. concerning this? 
  12137.  
  12138.  
  12139. Paul Farber
  12140. Farber Technology
  12141. farber@admin.f-tech.net
  12142. Ph  570-628-5303
  12143. Fax 570-628-5545
  12144.  
  12145.  
  12146.  
  12147. -
  12148.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12149.  with "unsubscribe usr-tc" in the body of the message.
  12150.  For information on digests or retrieving files and old messages send
  12151.  "help" to the same address.  Do not use quotes in your message.
  12152.  
  12153.  
  12154. -------------------------------------------------------------------------------
  12155.  
  12156. From: Jeff Mcadams <jeffm@iglou.com>
  12157. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  12158. Date: 13 Oct 1999 12:21:00 -0400
  12159.  
  12160. Thus spake Scot Desort
  12161. >Jeff Mcadams wrote:
  12162. >> They already have a software only support contract...its just as
  12163. >> ridiculous as the rest of them.
  12164.  
  12165. >Geez, didn't realize that. So I guess the pricing is not attractive? We all
  12166. >want free, but if it were only a nominal charge, that might have helped ;-(
  12167.  
  12168. Yah...its still done on a $x/48-port chassis basis, which, for software
  12169. only, makes even less sense.  :/  And because 3Com is so concerned about
  12170. someone buying support on one chassis and having 10 that they don't have
  12171. support on, they still require you, with the software-only, to buy
  12172. support on *all* of your equipment equally.  *blam*, it was dead before
  12173. it even got out of the starting blocks for us.  And, of course, when we
  12174. called to complain about it, we got a call from the head of support
  12175. contracts who's point in calling was to explain to us what options were
  12176. available...again, he was totally unwilling to give any thought to the
  12177. idea that maybe, just maybe, there was a better way to do
  12178. things...totally blew off our concerns.
  12179. -- 
  12180. Jeff McAdams                            Email: jeffm@iglou.com
  12181. Head Network Administrator              Voice: (502) 966-3848
  12182. IgLou Internet Services                        (800) 436-4456
  12183.  
  12184. -
  12185.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12186.  with "unsubscribe usr-tc" in the body of the message.
  12187.  For information on digests or retrieving files and old messages send
  12188.  "help" to the same address.  Do not use quotes in your message.
  12189.  
  12190.  
  12191. -------------------------------------------------------------------------------
  12192.  
  12193. From: Charles Sprickman <spork@inch.com>
  12194. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  12195. Date: 13 Oct 1999 12:25:12 -0400 (EDT)
  12196.  
  12197.  
  12198. On Wed, 13 Oct 1999, Jeff Binkley wrote:
  12199.  
  12200. > Unless I am mistaken they do offer software only contracts.  I've seen 
  12201. > them on Tech Data's price listing.  They are generally less than half of 
  12202. > the full service contracts.
  12203.  
  12204. They are still pricey.  And on top of the price, we started getting
  12205. harrassing phone calls from some lackey in the 'service contract'
  12206. department saying:
  12207.  
  12208. -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  12209.  
  12210. -me: "Yes.  That's why I bought X contracts."
  12211.  
  12212. -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  12213.  
  12214. -me: "Yes."
  12215.  
  12216. -rude 3Com lady: "You're SUUURE you only have X chassis?"
  12217.  
  12218. -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  12219. crap off."
  12220.  
  12221. I didn't even buy direct from 3Com, but via a reseller.  They apparently
  12222. have the time and money to put losers like this on the phone to harass
  12223. customers about the number of contracts they have versus the number of
  12224. chassis they've purchased in the last 3 years.  What a waste.  What
  12225. arrogance.
  12226.  
  12227. I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  12228. routers that cost LESS than putting full support with no
  12229. "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  12230. numerous Cisco employees; support, sales, engineering that they let people
  12231. slide on most support/software issues.  They frown on 'version jumping'
  12232. where you go and thieve say IOS w/Firewall support when you bought basic
  12233. IP, but I've had so many instances where I've received support/software on
  12234. equipment with no contract.  I've even told the guy on the phone "I have
  12235. no contract" and the basic response is "We want you to be happy.  Your
  12236. hardware fried?  We'll send you new...  You need IOS 12.x to fix this bug?
  12237. Here it is."
  12238.  
  12239. Why can't 3Com adopt at least some of this attitude?  It's not like
  12240. Pilgrim is feature-packed like IOS, we're all just looking for solid
  12241. connects and standard routing features...
  12242.  
  12243. Charles
  12244.  
  12245. > Jeff Binkley
  12246. > ASA Network Computing
  12247. > 
  12248. > 
  12249. > U>I think Brian is on the right track here. Perhaps 3COM can split their
  12250. > U>service contracts into 2 categories - firmware download only, and full
  12251. > U>support with download and telephone support.
  12252. > 
  12253. > U>Those of us new to the platform (myself included) might benefit from
  12254. > U>the convenience of knowing that phone support is available 24x7 when
  12255. > U>you're staring at a box not taking calls at 2AM. But once you get the
  12256. > U>hang of TC and know how to troubleshoot these things on your own (or
  12257. > U>at least with the added help of those on this list), you can drop the
  12258. > U>tel support, and just pay for code updates.
  12259. > 
  12260. > U>Does any of this matter to those on this list that are complaining
  12261. > U>about 3COM's lack of timely response to code issues? Probably not.
  12262. > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  12263. > U>Should they perhaps head-up a small team (1 person) to field code
  12264. > U>enhancement and bug fix requests, both from an email/web input area on
  12265. > U>the 3COM ISP pages, but also through monitoring of this list and the
  12266. > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  12267. > U>"behind the scenes", quietly tracking and logging this stuff, but it's
  12268. > U>apparent that the people who need to know the most that it's being
  12269. > U>done and being worked on, the ISP customers, don't know that someone
  12270. > U>has acknowledged the problem and it has been placed into an
  12271. > U>engineering queue.
  12272. > 
  12273. > U>I think that things like this would greatly improve 3COM's image among
  12274. > U>it's ISP customers, and even more so if they acted expediently on
  12275. > U>these issues that trouble so many on this list. Give the telephone
  12276. > U>support staff access to the database created as a result of these
  12277. > U>pages (hell, give us access to these pages as well, even WITHOUT a
  12278. > U>contract). Tie the ER/SR releases to the database, so it's easier to
  12279. > U>identify which bug is fixed with which release. And most importantly,
  12280. > U>of allowing us to view this database to obtain the status a confirmed
  12281. > U>of bug and it's up-to-date progress in getting resolved would be
  12282. > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
  12283. > U>SNMP issue by simply searching the database is comforting (knowing 
  12284. > that 
  12285. > U>it will be fixed QUICKLY is even better). Some of this status
  12286. > U>information may already be in the 3KB, but a dedicated database for TC
  12287. > U>code issues and status reports would be really great.
  12288. > 
  12289. > U>Scot
  12290. > U>NJAccess
  12291. > 
  12292. > CMPQwk 1.42 9999
  12293. > 
  12294. > -
  12295. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12296. >  with "unsubscribe usr-tc" in the body of the message.
  12297. >  For information on digests or retrieving files and old messages send
  12298. >  "help" to the same address.  Do not use quotes in your message.
  12299. > 
  12300.  
  12301.  
  12302. -
  12303.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12304.  with "unsubscribe usr-tc" in the body of the message.
  12305.  For information on digests or retrieving files and old messages send
  12306.  "help" to the same address.  Do not use quotes in your message.
  12307.  
  12308.  
  12309. -------------------------------------------------------------------------------
  12310.  
  12311. From: Jeff Mcadams <jeffm@iglou.com>
  12312. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  12313. Date: 13 Oct 1999 12:25:31 -0400
  12314.  
  12315. Thus spake Ed
  12316. >"the platform may become doomed before it matures."
  12317.  
  12318. >It has had years to mature... I believe it was actually further along and
  12319. >more mature when USR had it. I mean OSPF is just now being released. Other
  12320. >platforms have had OSPF for over 2 years. From what I understand before 3com
  12321. >took over many things were slated to be done but dropped.
  12322.  
  12323. In all fairness...OSPF was on the engineering todo list for quite some
  12324. time at USR before they got bought by 3Com...the word I received was
  12325. that the engineers kept pulling it off because "it was too hard".  I
  12326. suspect 3Com had enough resources to put OSPF in the thing when USR just
  12327. didn't have enough resources (read, number of engineers) to do that and
  12328. still keep the rest of the development up on the platform.
  12329.  
  12330. Having said that though...I agree...I do think the maturity of the TC
  12331. platform is behind what it could be...it is maturing...but I think it
  12332. could do so at a much faster pace.
  12333. -- 
  12334. Jeff McAdams                            Email: jeffm@iglou.com
  12335. Head Network Administrator              Voice: (502) 966-3848
  12336. IgLou Internet Services                        (800) 436-4456
  12337.  
  12338. -
  12339.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12340.  with "unsubscribe usr-tc" in the body of the message.
  12341.  For information on digests or retrieving files and old messages send
  12342.  "help" to the same address.  Do not use quotes in your message.
  12343.  
  12344.  
  12345. -------------------------------------------------------------------------------
  12346.  
  12347. From: "Ed" <ed@taylors.com>
  12348. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  12349. Date: 13 Oct 1999 12:40:10 -0400
  12350.  
  12351. Jeff McAdams wrote:
  12352. "we got a call from the head of support contracts who's point in calling was
  12353. to explain to us what options were available...again, he was totally
  12354. unwilling to give any thought to the idea that maybe, just maybe, there was
  12355. a better way to do things...totally blew off our concerns."
  12356.  
  12357. Oh you got one of those calls too? ;-)
  12358.  
  12359. I told him 3com was only trying to make a Profit on Support... I told him I
  12360. always considered Support an Expense and then prodeceed to explain to him
  12361. how much I cared for his call.
  12362.  
  12363.  
  12364. Ed
  12365.  
  12366. ----- Original Message -----
  12367. Sent: Wednesday, October 13, 1999 12:21 PM
  12368.  
  12369.  
  12370. Thus spake Scot Desort
  12371. >Jeff Mcadams wrote:
  12372. >> They already have a software only support contract...its just as
  12373. >> ridiculous as the rest of them.
  12374.  
  12375. >Geez, didn't realize that. So I guess the pricing is not attractive? We all
  12376. >want free, but if it were only a nominal charge, that might have helped ;-(
  12377.  
  12378. Yah...its still done on a $x/48-port chassis basis, which, for software
  12379. only, makes even less sense.  :/  And because 3Com is so concerned about
  12380. someone buying support on one chassis and having 10 that they don't have
  12381. support on, they still require you, with the software-only, to buy
  12382. support on *all* of your equipment equally.  *blam*, it was dead before
  12383. it even got out of the starting blocks for us.  And, of course, when we
  12384. called to complain about it, we got a call from the head of support
  12385. contracts who's point in calling was to explain to us what options were
  12386. available...again, he was totally unwilling to give any thought to the
  12387. idea that maybe, just maybe, there was a better way to do
  12388. things...totally blew off our concerns.
  12389. --
  12390. Jeff McAdams                            Email: jeffm@iglou.com
  12391. Head Network Administrator              Voice: (502) 966-3848
  12392. IgLou Internet Services                        (800) 436-4456
  12393.  
  12394. -
  12395.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12396.  with "unsubscribe usr-tc" in the body of the message.
  12397.  For information on digests or retrieving files and old messages send
  12398.  "help" to the same address.  Do not use quotes in your message.
  12399.  
  12400.  
  12401.  
  12402. -
  12403.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12404.  with "unsubscribe usr-tc" in the body of the message.
  12405.  For information on digests or retrieving files and old messages send
  12406.  "help" to the same address.  Do not use quotes in your message.
  12407.  
  12408.  
  12409. -------------------------------------------------------------------------------
  12410.  
  12411. From: Charles Sprickman <spork@inch.com>
  12412. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  12413. Date: 13 Oct 1999 12:40:30 -0400 (EDT)
  12414.  
  12415. On Wed, 13 Oct 1999, Steve Valiunas wrote:
  12416.  
  12417. >   The poor horse isn't even flinching anymore, but...  We only perform
  12418. > limited in-house testing on ERs so they can go out quickly-( we don't
  12419. > run them through our internal testing group)  so we try to be careful
  12420. > about their distribution. 
  12421.  
  12422. Great, so as a 'software only' contract customer, I can't get ER releases.
  12423. Seems like the concern might be more about selling full-blown support
  12424. contracts in a panic/"I need this fix now" situation than organization.
  12425.  
  12426. Just call it "Beta", have some lawyers put some fancy language that
  12427. re-states what beta software is and make it available to anyone with
  12428. software access.  Hell, make me fill out a contract form, harass me by
  12429. email about how it's working...
  12430.  
  12431. It seems like you'd be better off getting beta code tested by a wider user
  12432. base, no?
  12433.  
  12434. Charles
  12435.  
  12436. > When I make an ER available I want to have
  12437. > accurate contact info for the customer so I can get ahold of them if
  12438. > something nasty shows up with it at a customer site.  If after a
  12439. > number of days several users have indicated that it has fixed their
  12440. > issue and it warrants posting, it will become a candidate for being
  12441. > made available on totalservice for download as a ServiceRelease.
  12442. >     It's a trade off-  There's an extra step involved for you (and for the call
  12443. > center),  but there's less liklyhood of an ER causing problems for someone
  12444. > because a problem was found and they didn't know.
  12445. >    This was probably just a rehash of what Todd said the other day...
  12446. > 
  12447. > Steve
  12448. > 
  12449. > 
  12450. > 
  12451. > 
  12452. > 
  12453. > Jeff Mcadams <jeffm@iglou.com> on 10/13/99 08:23:40 AM
  12454. > 
  12455. > Please respond to usr-tc@lists.xmission.com
  12456. > 
  12457. > Sent by:  Jeff Mcadams <jeffm@iglou.com>
  12458. > 
  12459. > 
  12460. > To:   usr-tc@lists.xmission.com
  12461. > cc:    (Steve Valiunas/MW/US/3Com)
  12462. > Subject:  Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  12463. > 
  12464. > 
  12465. > 
  12466. > 
  12467. > Thus spake Steve Valiunas
  12468. > >>Do you mean 6.09 ?  If so, what about 6.08 ?
  12469. > 
  12470. > >    It's available in an Engineering Release, so you'll have to call
  12471. > >tech support.  (I know- another example of excess bureaucracy <g>).
  12472. > 
  12473. > Heh...I really don't mind calling tech support for ER's, it just kinda
  12474. > annoyed me that tech support now has to go get permission from someone
  12475. > else to give them out.   :)  And even that doesn't *terribly* bother
  12476. > me...at least not on its own...its just a single fairly small example of
  12477. > the larger problem.  :)
  12478. > --
  12479. > Jeff McAdams                            Email: jeffm@iglou.com
  12480. > Head Network Administrator              Voice: (502) 966-3848
  12481. > IgLou Internet Services                        (800) 436-4456
  12482. > 
  12483. > -
  12484. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12485. >  with "unsubscribe usr-tc" in the body of the message.
  12486. >  For information on digests or retrieving files and old messages send
  12487. >  "help" to the same address.  Do not use quotes in your message.
  12488. > 
  12489. > 
  12490. > 
  12491. > 
  12492. > 
  12493. > 
  12494. > -
  12495. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12496. >  with "unsubscribe usr-tc" in the body of the message.
  12497. >  For information on digests or retrieving files and old messages send
  12498. >  "help" to the same address.  Do not use quotes in your message.
  12499. > 
  12500.  
  12501.  
  12502. -
  12503.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12504.  with "unsubscribe usr-tc" in the body of the message.
  12505.  For information on digests or retrieving files and old messages send
  12506.  "help" to the same address.  Do not use quotes in your message.
  12507.  
  12508.  
  12509. -------------------------------------------------------------------------------
  12510.  
  12511. From:  <farber@admin.f-tech.net>
  12512. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  12513. Date: 13 Oct 1999 12:57:39 -0400 (EDT)
  12514.  
  12515. I got one of them last week!  I tried to just cover a chassis that I
  12516. wanted to test out the "newer" features with.  Like OSPF, tunneling, etc.
  12517. They said you need all your chassis covered and you cannot get just the
  12518. support you *WANT*.
  12519.  
  12520. Even though I just purchased 4 DPS's and have 90 days free support.. they
  12521. (the nice 3com lady said that they don't do just certain cards.. and that
  12522. she would need to see an inventory of all the cards I owned).
  12523.  
  12524. I think not.
  12525.  
  12526. Paul Farber
  12527. Farber Technology
  12528. farber@admin.f-tech.net
  12529. Ph  570-628-5303
  12530. Fax 570-628-5545
  12531.  
  12532. On Wed, 13 Oct 1999, Charles Sprickman wrote:
  12533.  
  12534. > 
  12535. > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  12536. > 
  12537. > > Unless I am mistaken they do offer software only contracts.  I've seen 
  12538. > > them on Tech Data's price listing.  They are generally less than half of 
  12539. > > the full service contracts.
  12540. > 
  12541. > They are still pricey.  And on top of the price, we started getting
  12542. > harrassing phone calls from some lackey in the 'service contract'
  12543. > department saying:
  12544. > 
  12545. > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  12546. > 
  12547. > -me: "Yes.  That's why I bought X contracts."
  12548. > 
  12549. > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  12550. > 
  12551. > -me: "Yes."
  12552. > 
  12553. > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  12554. > 
  12555. > -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  12556. > crap off."
  12557. > 
  12558. > I didn't even buy direct from 3Com, but via a reseller.  They apparently
  12559. > have the time and money to put losers like this on the phone to harass
  12560. > customers about the number of contracts they have versus the number of
  12561. > chassis they've purchased in the last 3 years.  What a waste.  What
  12562. > arrogance.
  12563. > 
  12564. > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  12565. > routers that cost LESS than putting full support with no
  12566. > "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  12567. > numerous Cisco employees; support, sales, engineering that they let people
  12568. > slide on most support/software issues.  They frown on 'version jumping'
  12569. > where you go and thieve say IOS w/Firewall support when you bought basic
  12570. > IP, but I've had so many instances where I've received support/software on
  12571. > equipment with no contract.  I've even told the guy on the phone "I have
  12572. > no contract" and the basic response is "We want you to be happy.  Your
  12573. > hardware fried?  We'll send you new...  You need IOS 12.x to fix this bug?
  12574. > Here it is."
  12575. > 
  12576. > Why can't 3Com adopt at least some of this attitude?  It's not like
  12577. > Pilgrim is feature-packed like IOS, we're all just looking for solid
  12578. > connects and standard routing features...
  12579. > 
  12580. > Charles
  12581. >  
  12582. > > Jeff Binkley
  12583. > > ASA Network Computing
  12584. > > 
  12585. > > 
  12586. > > U>I think Brian is on the right track here. Perhaps 3COM can split their
  12587. > > U>service contracts into 2 categories - firmware download only, and full
  12588. > > U>support with download and telephone support.
  12589. > > 
  12590. > > U>Those of us new to the platform (myself included) might benefit from
  12591. > > U>the convenience of knowing that phone support is available 24x7 when
  12592. > > U>you're staring at a box not taking calls at 2AM. But once you get the
  12593. > > U>hang of TC and know how to troubleshoot these things on your own (or
  12594. > > U>at least with the added help of those on this list), you can drop the
  12595. > > U>tel support, and just pay for code updates.
  12596. > > 
  12597. > > U>Does any of this matter to those on this list that are complaining
  12598. > > U>about 3COM's lack of timely response to code issues? Probably not.
  12599. > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  12600. > > U>Should they perhaps head-up a small team (1 person) to field code
  12601. > > U>enhancement and bug fix requests, both from an email/web input area on
  12602. > > U>the 3COM ISP pages, but also through monitoring of this list and the
  12603. > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  12604. > > U>"behind the scenes", quietly tracking and logging this stuff, but it's
  12605. > > U>apparent that the people who need to know the most that it's being
  12606. > > U>done and being worked on, the ISP customers, don't know that someone
  12607. > > U>has acknowledged the problem and it has been placed into an
  12608. > > U>engineering queue.
  12609. > > 
  12610. > > U>I think that things like this would greatly improve 3COM's image among
  12611. > > U>it's ISP customers, and even more so if they acted expediently on
  12612. > > U>these issues that trouble so many on this list. Give the telephone
  12613. > > U>support staff access to the database created as a result of these
  12614. > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  12615. > > U>contract). Tie the ER/SR releases to the database, so it's easier to
  12616. > > U>identify which bug is fixed with which release. And most importantly,
  12617. > > U>of allowing us to view this database to obtain the status a confirmed
  12618. > > U>of bug and it's up-to-date progress in getting resolved would be
  12619. > > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
  12620. > > U>SNMP issue by simply searching the database is comforting (knowing 
  12621. > > that 
  12622. > > U>it will be fixed QUICKLY is even better). Some of this status
  12623. > > U>information may already be in the 3KB, but a dedicated database for TC
  12624. > > U>code issues and status reports would be really great.
  12625. > > 
  12626. > > U>Scot
  12627. > > U>NJAccess
  12628. > > 
  12629. > > CMPQwk 1.42 9999
  12630. > > 
  12631. > > -
  12632. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12633. > >  with "unsubscribe usr-tc" in the body of the message.
  12634. > >  For information on digests or retrieving files and old messages send
  12635. > >  "help" to the same address.  Do not use quotes in your message.
  12636. > > 
  12637. > 
  12638. > 
  12639. > -
  12640. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12641. >  with "unsubscribe usr-tc" in the body of the message.
  12642. >  For information on digests or retrieving files and old messages send
  12643. >  "help" to the same address.  Do not use quotes in your message.
  12644. > 
  12645.  
  12646.  
  12647. -
  12648.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12649.  with "unsubscribe usr-tc" in the body of the message.
  12650.  For information on digests or retrieving files and old messages send
  12651.  "help" to the same address.  Do not use quotes in your message.
  12652.  
  12653.  
  12654. -------------------------------------------------------------------------------
  12655.  
  12656. From: "Ed" <ed@taylors.com>
  12657. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  12658. Date: 13 Oct 1999 12:56:20 -0400
  12659.  
  12660. Charles you are correct and have hit it on the nose.
  12661.  
  12662. We also have Cisco and they have helped us greatly when we had no contract.
  12663. After they assisted us several times without a hassle I asked them what
  12664. would contracts cost and they told me... get this... we purchased them
  12665. because of their attitude toward us. They are more than helpful and I
  12666. believe this is the basic concept behind their enormous success... "Proud to
  12667. own a CISCO". It is almost like gold.
  12668.  
  12669.  
  12670. Ed
  12671.  
  12672. ----- Original Message -----
  12673. Sent: Wednesday, October 13, 1999 12:25 PM
  12674.  
  12675.  
  12676.  
  12677. On Wed, 13 Oct 1999, Jeff Binkley wrote:
  12678.  
  12679. > Unless I am mistaken they do offer software only contracts.  I've seen
  12680. > them on Tech Data's price listing.  They are generally less than half of
  12681. > the full service contracts.
  12682.  
  12683. They are still pricey.  And on top of the price, we started getting
  12684. harrassing phone calls from some lackey in the 'service contract'
  12685. department saying:
  12686.  
  12687. -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  12688.  
  12689. -me: "Yes.  That's why I bought X contracts."
  12690.  
  12691. -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  12692.  
  12693. -me: "Yes."
  12694.  
  12695. -rude 3Com lady: "You're SUUURE you only have X chassis?"
  12696.  
  12697. -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  12698. crap off."
  12699.  
  12700. I didn't even buy direct from 3Com, but via a reseller.  They apparently
  12701. have the time and money to put losers like this on the phone to harass
  12702. customers about the number of contracts they have versus the number of
  12703. chassis they've purchased in the last 3 years.  What a waste.  What
  12704. arrogance.
  12705.  
  12706. I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  12707. routers that cost LESS than putting full support with no
  12708. "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  12709. numerous Cisco employees; support, sales, engineering that they let people
  12710. slide on most support/software issues.  They frown on 'version jumping'
  12711. where you go and thieve say IOS w/Firewall support when you bought basic
  12712. IP, but I've had so many instances where I've received support/software on
  12713. equipment with no contract.  I've even told the guy on the phone "I have
  12714. no contract" and the basic response is "We want you to be happy.  Your
  12715. hardware fried?  We'll send you new...  You need IOS 12.x to fix this bug?
  12716. Here it is."
  12717.  
  12718. Why can't 3Com adopt at least some of this attitude?  It's not like
  12719. Pilgrim is feature-packed like IOS, we're all just looking for solid
  12720. connects and standard routing features...
  12721.  
  12722. Charles
  12723.  
  12724. > Jeff Binkley
  12725. > ASA Network Computing
  12726. >
  12727. >
  12728. > U>I think Brian is on the right track here. Perhaps 3COM can split their
  12729. > U>service contracts into 2 categories - firmware download only, and full
  12730. > U>support with download and telephone support.
  12731. >
  12732. > U>Those of us new to the platform (myself included) might benefit from
  12733. > U>the convenience of knowing that phone support is available 24x7 when
  12734. > U>you're staring at a box not taking calls at 2AM. But once you get the
  12735. > U>hang of TC and know how to troubleshoot these things on your own (or
  12736. > U>at least with the added help of those on this list), you can drop the
  12737. > U>tel support, and just pay for code updates.
  12738. >
  12739. > U>Does any of this matter to those on this list that are complaining
  12740. > U>about 3COM's lack of timely response to code issues? Probably not.
  12741. > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  12742. > U>Should they perhaps head-up a small team (1 person) to field code
  12743. > U>enhancement and bug fix requests, both from an email/web input area on
  12744. > U>the 3COM ISP pages, but also through monitoring of this list and the
  12745. > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  12746. > U>"behind the scenes", quietly tracking and logging this stuff, but it's
  12747. > U>apparent that the people who need to know the most that it's being
  12748. > U>done and being worked on, the ISP customers, don't know that someone
  12749. > U>has acknowledged the problem and it has been placed into an
  12750. > U>engineering queue.
  12751. >
  12752. > U>I think that things like this would greatly improve 3COM's image among
  12753. > U>it's ISP customers, and even more so if they acted expediently on
  12754. > U>these issues that trouble so many on this list. Give the telephone
  12755. > U>support staff access to the database created as a result of these
  12756. > U>pages (hell, give us access to these pages as well, even WITHOUT a
  12757. > U>contract). Tie the ER/SR releases to the database, so it's easier to
  12758. > U>identify which bug is fixed with which release. And most importantly,
  12759. > U>of allowing us to view this database to obtain the status a confirmed
  12760. > U>of bug and it's up-to-date progress in getting resolved would be
  12761. > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
  12762. > U>SNMP issue by simply searching the database is comforting (knowing
  12763. > that
  12764. > U>it will be fixed QUICKLY is even better). Some of this status
  12765. > U>information may already be in the 3KB, but a dedicated database for TC
  12766. > U>code issues and status reports would be really great.
  12767. >
  12768. > U>Scot
  12769. > U>NJAccess
  12770. >
  12771. > CMPQwk 1.42 9999
  12772. >
  12773. > -
  12774. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12775. >  with "unsubscribe usr-tc" in the body of the message.
  12776. >  For information on digests or retrieving files and old messages send
  12777. >  "help" to the same address.  Do not use quotes in your message.
  12778. >
  12779.  
  12780.  
  12781. -
  12782.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12783.  with "unsubscribe usr-tc" in the body of the message.
  12784.  For information on digests or retrieving files and old messages send
  12785.  "help" to the same address.  Do not use quotes in your message.
  12786.  
  12787.  
  12788.  
  12789. -
  12790.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12791.  with "unsubscribe usr-tc" in the body of the message.
  12792.  For information on digests or retrieving files and old messages send
  12793.  "help" to the same address.  Do not use quotes in your message.
  12794.  
  12795.  
  12796. -------------------------------------------------------------------------------
  12797.  
  12798. From: Jeff Mcadams <jeffm@iglou.com>
  12799. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  12800. Date: 13 Oct 1999 13:02:25 -0400
  12801.  
  12802. Thus spake Ed
  12803. >Jeff McAdams wrote:
  12804. >"we got a call from the head of support contracts who's point in calling was
  12805. >to explain to us what options were available...again, he was totally
  12806. >unwilling to give any thought to the idea that maybe, just maybe, there was
  12807. >a better way to do things...totally blew off our concerns."
  12808.  
  12809. >Oh you got one of those calls too? ;-)
  12810.  
  12811. Well...this was after complaining to high heaven to our sales rep who
  12812. forwarded our complaints on to this guy...then he didn't even call to
  12813. try to address our complaints...just to tell us what was available in
  12814. support contracts.  We already bloody knew what was available as far as
  12815. support contracts were concerned...that's why we were complaining!  :)
  12816.  
  12817. >I told him 3com was only trying to make a Profit on Support... 
  12818.  
  12819. I was basically told, at one point, that 3Com didn't want to do anything
  12820. that wasn't "revenue positive."  You can imagine the response that
  12821. brought.
  12822.  
  12823. >I told him I always considered Support an Expense and then prodeceed to
  12824. >explain to him how much I cared for his call.
  12825.  
  12826. Heh...yeah...my co-admin took the call here...he let the guy know, in no
  12827. uncertain terms, what we thought of the call and the support contract
  12828. situation in general...like I said...he totally blew us off...we were
  12829. never contacted again about that subject.
  12830. -- 
  12831. Jeff McAdams                            Email: jeffm@iglou.com
  12832. Head Network Administrator              Voice: (502) 966-3848
  12833. IgLou Internet Services                        (800) 436-4456
  12834.  
  12835. -
  12836.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12837.  with "unsubscribe usr-tc" in the body of the message.
  12838.  For information on digests or retrieving files and old messages send
  12839.  "help" to the same address.  Do not use quotes in your message.
  12840.  
  12841.  
  12842. -------------------------------------------------------------------------------
  12843.  
  12844. From: "Frank Angel" <franka@ecomnet.net>
  12845. Subject: RE: (usr-tc) Beaurocracy issues  ;)
  12846. Date: 13 Oct 1999 13:07:40 -0400
  12847.  
  12848. They may not be listening to you guys, but they are sure interested in
  12849. feedback for presales!
  12850.  
  12851. https://rap.prognostics.com/svy/3comPresales/2855-1.asp?doc_num=3comsales
  12852.  
  12853.  
  12854. |-----Original Message-----
  12855. |From: owner-usr-tc@lists.xmission.com
  12856. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
  12857. |Sent: Wednesday, October 13, 1999 12:40 PM
  12858. |To: usr-tc@lists.xmission.com
  12859. |Subject: Re: (usr-tc) Beaurocracy issues ;)
  12860. |
  12861. |
  12862. |Jeff McAdams wrote:
  12863. |"we got a call from the head of support contracts who's point
  12864. |in calling was
  12865. |to explain to us what options were available...again, he was totally
  12866. |unwilling to give any thought to the idea that maybe, just
  12867. |maybe, there was
  12868. |a better way to do things...totally blew off our concerns."
  12869. |
  12870. |Oh you got one of those calls too? ;-)
  12871. |
  12872. |I told him 3com was only trying to make a Profit on Support...
  12873. |I told him I
  12874. |always considered Support an Expense and then prodeceed to
  12875. |explain to him
  12876. |how much I cared for his call.
  12877. |
  12878. |
  12879. |Ed
  12880. |
  12881. |----- Original Message -----
  12882. |From: Jeff Mcadams <jeffm@iglou.com>
  12883. |To: <usr-tc@lists.xmission.com>
  12884. |Sent: Wednesday, October 13, 1999 12:21 PM
  12885. |Subject: Re: (usr-tc) Beaurocracy issues ;)
  12886. |
  12887. |
  12888. |Thus spake Scot Desort
  12889. |>Jeff Mcadams wrote:
  12890. |>> They already have a software only support contract...its just as
  12891. |>> ridiculous as the rest of them.
  12892. |
  12893. |>Geez, didn't realize that. So I guess the pricing is not
  12894. |attractive? We all
  12895. |>want free, but if it were only a nominal charge, that might
  12896. |have helped ;-(
  12897. |
  12898. |Yah...its still done on a $x/48-port chassis basis, which, for software
  12899. |only, makes even less sense.  :/  And because 3Com is so
  12900. |concerned about
  12901. |someone buying support on one chassis and having 10 that they
  12902. |don't have
  12903. |support on, they still require you, with the software-only, to buy
  12904. |support on *all* of your equipment equally.  *blam*, it was dead before
  12905. |it even got out of the starting blocks for us.  And, of course, when we
  12906. |called to complain about it, we got a call from the head of support
  12907. |contracts who's point in calling was to explain to us what options were
  12908. |available...again, he was totally unwilling to give any thought to the
  12909. |idea that maybe, just maybe, there was a better way to do
  12910. |things...totally blew off our concerns.
  12911. |--
  12912. |Jeff McAdams                            Email: jeffm@iglou.com
  12913. |Head Network Administrator              Voice: (502) 966-3848
  12914. |IgLou Internet Services                        (800) 436-4456
  12915. |
  12916. |-
  12917. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12918. | with "unsubscribe usr-tc" in the body of the message.
  12919. | For information on digests or retrieving files and old messages send
  12920. | "help" to the same address.  Do not use quotes in your message.
  12921. |
  12922. |
  12923. |
  12924. |-
  12925. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12926. | with "unsubscribe usr-tc" in the body of the message.
  12927. | For information on digests or retrieving files and old messages send
  12928. | "help" to the same address.  Do not use quotes in your message.
  12929. |
  12930.  
  12931.  
  12932. -
  12933.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12934.  with "unsubscribe usr-tc" in the body of the message.
  12935.  For information on digests or retrieving files and old messages send
  12936.  "help" to the same address.  Do not use quotes in your message.
  12937.  
  12938.  
  12939. -------------------------------------------------------------------------------
  12940.  
  12941. From: "Ed" <ed@taylors.com>
  12942. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  12943. Date: 13 Oct 1999 13:15:11 -0400
  12944.  
  12945. Jeff McAdams wrote:
  12946. "Well...this was after complaining to high heaven to our sales rep who
  12947. forwarded our complaints on to this guy..."
  12948.  
  12949. Yes thats what happened to us... we complained and this guy called to let us
  12950. know our options.
  12951.  
  12952. Funny how everyone feels the same way and 3com continues to push this. If we
  12953. all switched platforms I am sure they would begin to listen to the few
  12954. customers that remain. Many companies out there would gladly take our stuff
  12955. on trade on a port for port program.
  12956.  
  12957. I just keep hoping 3com will wake up and listen... my patience is running
  12958. thin though as I am sure are others.
  12959.  
  12960.  
  12961. Ed
  12962.  
  12963. ----- Original Message -----
  12964. Sent: Wednesday, October 13, 1999 1:02 PM
  12965.  
  12966.  
  12967. Thus spake Ed
  12968. >Jeff McAdams wrote:
  12969. >"we got a call from the head of support contracts who's point in calling
  12970. was
  12971. >to explain to us what options were available...again, he was totally
  12972. >unwilling to give any thought to the idea that maybe, just maybe, there was
  12973. >a better way to do things...totally blew off our concerns."
  12974.  
  12975. >Oh you got one of those calls too? ;-)
  12976.  
  12977. Well...this was after complaining to high heaven to our sales rep who
  12978. forwarded our complaints on to this guy...then he didn't even call to
  12979. try to address our complaints...just to tell us what was available in
  12980. support contracts.  We already bloody knew what was available as far as
  12981. support contracts were concerned...that's why we were complaining!  :)
  12982.  
  12983. >I told him 3com was only trying to make a Profit on Support...
  12984.  
  12985. I was basically told, at one point, that 3Com didn't want to do anything
  12986. that wasn't "revenue positive."  You can imagine the response that
  12987. brought.
  12988.  
  12989. >I told him I always considered Support an Expense and then prodeceed to
  12990. >explain to him how much I cared for his call.
  12991.  
  12992. Heh...yeah...my co-admin took the call here...he let the guy know, in no
  12993. uncertain terms, what we thought of the call and the support contract
  12994. situation in general...like I said...he totally blew us off...we were
  12995. never contacted again about that subject.
  12996. --
  12997. Jeff McAdams                            Email: jeffm@iglou.com
  12998. Head Network Administrator              Voice: (502) 966-3848
  12999. IgLou Internet Services                        (800) 436-4456
  13000.  
  13001. -
  13002.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13003.  with "unsubscribe usr-tc" in the body of the message.
  13004.  For information on digests or retrieving files and old messages send
  13005.  "help" to the same address.  Do not use quotes in your message.
  13006.  
  13007.  
  13008.  
  13009. -
  13010.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13011.  with "unsubscribe usr-tc" in the body of the message.
  13012.  For information on digests or retrieving files and old messages send
  13013.  "help" to the same address.  Do not use quotes in your message.
  13014.  
  13015.  
  13016. -------------------------------------------------------------------------------
  13017.  
  13018. From: "Randy Cosby" <dcosby@infowest.com>
  13019. Subject: RE: (usr-tc) Beaurocracy issues  ;)
  13020. Date: 13 Oct 1999 15:09:28 -0600
  13021.  
  13022. Stockholders can get results.
  13023.  
  13024. Has anyone mentioned any of these concerns on any of the 3COM stock
  13025. discussion forums, on RagingBull.com for example?
  13026.  
  13027. Randy
  13028.  
  13029. > -----Original Message-----
  13030. > From: owner-usr-tc@lists.xmission.com
  13031. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  13032. > Sent: Wednesday, October 13, 1999 11:02 AM
  13033. > To: usr-tc@lists.xmission.com
  13034. > Subject: Re: (usr-tc) Beaurocracy issues ;)
  13035. >
  13036. >
  13037. > Thus spake Ed
  13038. > >Jeff McAdams wrote:
  13039. > >"we got a call from the head of support contracts who's point in
  13040. > calling was
  13041. > >to explain to us what options were available...again, he was totally
  13042. > >unwilling to give any thought to the idea that maybe, just
  13043. > maybe, there was
  13044. > >a better way to do things...totally blew off our concerns."
  13045. >
  13046. > >Oh you got one of those calls too? ;-)
  13047. >
  13048. > Well...this was after complaining to high heaven to our sales rep who
  13049. > forwarded our complaints on to this guy...then he didn't even call to
  13050. > try to address our complaints...just to tell us what was available in
  13051. > support contracts.  We already bloody knew what was available as far as
  13052. > support contracts were concerned...that's why we were complaining!  :)
  13053. >
  13054. > >I told him 3com was only trying to make a Profit on Support...
  13055. >
  13056. > I was basically told, at one point, that 3Com didn't want to do anything
  13057. > that wasn't "revenue positive."  You can imagine the response that
  13058. > brought.
  13059. >
  13060. > >I told him I always considered Support an Expense and then prodeceed to
  13061. > >explain to him how much I cared for his call.
  13062. >
  13063. > Heh...yeah...my co-admin took the call here...he let the guy know, in no
  13064. > uncertain terms, what we thought of the call and the support contract
  13065. > situation in general...like I said...he totally blew us off...we were
  13066. > never contacted again about that subject.
  13067. > --
  13068. > Jeff McAdams                            Email: jeffm@iglou.com
  13069. > Head Network Administrator              Voice: (502) 966-3848
  13070. > IgLou Internet Services                        (800) 436-4456
  13071. >
  13072. > -
  13073. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13074. >  with "unsubscribe usr-tc" in the body of the message.
  13075. >  For information on digests or retrieving files and old messages send
  13076. >  "help" to the same address.  Do not use quotes in your message.
  13077. >
  13078.  
  13079.  
  13080. -
  13081.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13082.  with "unsubscribe usr-tc" in the body of the message.
  13083.  For information on digests or retrieving files and old messages send
  13084.  "help" to the same address.  Do not use quotes in your message.
  13085.  
  13086.  
  13087. -------------------------------------------------------------------------------
  13088.  
  13089. From: "Scot Desort" <scot@njaccess.net>
  13090. Subject: (usr-tc) Radius Effects...
  13091. Date: 13 Oct 1999 18:33:54 -0400
  13092.  
  13093. While we're all talking about Radius, we currently send the following
  13094. attributes to our TC for our default user:
  13095.  
  13096. Framed-IPAddress = 255.255.255.254
  13097. Framed-Routing = None
  13098.  
  13099. We recently signed up with Ziplink for wholesale nationwide dialup. A lot of
  13100. their equipment is Bay. They claim that when the Bay receives these
  13101. attributes, it chokes. It allows the connection, and the modem connect speed
  13102. is fine, but throughput is horrible. Over 50% of the packets drop, and after
  13103. a few minutes, the call will drop. They say we need to remove these
  13104. attributes from the Radius profile we send. Huh? Bay doesn't like these 2
  13105. *basic* attributes? They also said they don't like 'Port-limit=1', but I am
  13106. NOT removing that one. For this one, they state that they have trouble with
  13107. the Bay doing 128K ISDN anyway, so removing the attribute will have no
  13108. effect. Double "huh?"
  13109.  
  13110. My question is, what effect will this have on our local dialup customers
  13111. connecting to our TC? Will the TC happily work without receiving those 2
  13112. attributes? We are currently not running RIP on the TC (we are small, so
  13113. everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
  13114. start sending RIP updates to the dialup clients without the
  13115. Framed-Routing=none attribute set?
  13116.  
  13117. They also have some Max's out there, but a good portion of it's Bay. I don't
  13118. know of any way to have my Radius server send a different profile to their
  13119. proxy, so it has to be the same one I send to my TC.
  13120.  
  13121. Sorry for what might seem a stupid question - not real up to speed on RIP
  13122. and exactly what the framed-routing attribute does.
  13123.  
  13124. -Scot
  13125. NJAccess
  13126.  
  13127.  
  13128.  
  13129. -
  13130.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13131.  with "unsubscribe usr-tc" in the body of the message.
  13132.  For information on digests or retrieving files and old messages send
  13133.  "help" to the same address.  Do not use quotes in your message.
  13134.  
  13135.  
  13136. -------------------------------------------------------------------------------
  13137.  
  13138. From: James Nessen <nessenj@directcon.net>
  13139. Subject: (usr-tc) snmp pri
  13140. Date: 13 Oct 1999 16:05:28 -0700 (PDT)
  13141.  
  13142. Does anyone happen to know the oid for checking status on the pri cards on
  13143. a arc?
  13144.  
  13145. Thanks!
  13146.  
  13147. Jim
  13148.  
  13149. --
  13150. _.,+=~`^"-.,_.,+=~`^"-*.,_.,+=~'`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,
  13151.   James Nessen                       .,.   Server Engineer/Administrator
  13152.   Direct Connect Internet Services   .,.   Main Number:    (800) 711-9560
  13153.   <nessenj@directcon.net>            .,.   Operations:     (530) 677-1712
  13154.          "Linux: Because rebooting is for adding new hardware."
  13155.    PGP fingerprint =  B9 99 1F 5D 68 27 BB 4D  7B DB 0A A2 97 35 98 AF
  13156. _.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+*=~`^"-.,_.,+=%~`^"-.,_.,+=~`^"-.,
  13157.  
  13158.  
  13159. -
  13160.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13161.  with "unsubscribe usr-tc" in the body of the message.
  13162.  For information on digests or retrieving files and old messages send
  13163.  "help" to the same address.  Do not use quotes in your message.
  13164.  
  13165.  
  13166. -------------------------------------------------------------------------------
  13167.  
  13168. From: Brian <signal@shreve.net>
  13169. Subject: Re: (usr-tc) Funk Radius
  13170. Date: 13 Oct 1999 22:20:11 -0500 (CDT)
  13171.  
  13172. On Wed, 13 Oct 1999, Lon R. Stockton, Jr. wrote:
  13173.  
  13174. > 
  13175. > Don't know anything about that one, but if you're going to buy something,
  13176. > I'd suggest taking a look at Radiator. It's written in perl, so it's not
  13177. > the fastest you can get, but you get the source and can make it do
  13178. > *anything* you want. Not that you have to; I've seen a feature request
  13179.  
  13180. I will second Radiator.  As for speed.........well, use the radpwtst
  13181. program that comes with it, you will be impressed.  I know of ISP's with
  13182. 80,000+ users using Radiator, and they don't seem to have any
  13183. problems.....
  13184.  
  13185. > hit the support mailing list and the guys who wrote the package mentioning
  13186. > that they've written it and tossed it on the ftp site...within *hours*.
  13187. > 
  13188. > Supports USR style VSAs and interfaces to your favorite sql or odbc
  13189. > database out of the box.
  13190. > 
  13191. > 
  13192. > On Wed, 13 Oct 1999, Ed wrote:
  13193. > 
  13194. > > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  13195. > > technician). Does anyone have any experience in this and is it better than
  13196. > > the current 6.0.9 3com Radius? Hard to believe it could be worse...
  13197. > 
  13198. > 
  13199. > -
  13200. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13201. >  with "unsubscribe usr-tc" in the body of the message.
  13202. >  For information on digests or retrieving files and old messages send
  13203. >  "help" to the same address.  Do not use quotes in your message.
  13204. > 
  13205.  
  13206. Brian Feeny (BF304)     signal@shreve.net   
  13207. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13208. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13209.  
  13210.  
  13211. -
  13212.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13213.  with "unsubscribe usr-tc" in the body of the message.
  13214.  For information on digests or retrieving files and old messages send
  13215.  "help" to the same address.  Do not use quotes in your message.
  13216.  
  13217.  
  13218. -------------------------------------------------------------------------------
  13219.  
  13220. From: Brian <signal@shreve.net>
  13221. Subject: RE: (usr-tc) 2.0.60 HDM Code
  13222. Date: 13 Oct 1999 22:19:00 -0500 (CDT)
  13223.  
  13224. On Tue, 12 Oct 1999, Scot Desort wrote:
  13225.  
  13226. > I think Brian is on the right track here. Perhaps 3COM can split their
  13227. > service contracts into 2 categories - firmware download only, and full
  13228. > support with download and telephone support.
  13229.  
  13230. O, they *do* offer software download only support.........its just that I
  13231. am not entirely happy with that pricing either.
  13232.  
  13233. > 
  13234. > Scot
  13235. > NJAccess
  13236. > 
  13237. > 
  13238. > -----Original Message-----
  13239. > From: owner-usr-tc@lists.xmission.com
  13240. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  13241. > Sent: Tuesday, October 12, 1999 9:45 PM
  13242. > To: usr-tc@lists.xmission.com
  13243. > Subject: Re: (usr-tc) 2.0.60 HDM Code
  13244. > 
  13245. > 
  13246. > On Tue, 12 Oct 1999, Jeff Binkley wrote:
  13247. > 
  13248. > > -> One of the few pleasures in life is telling the salesbot on the phone
  13249. > that I
  13250. > > -> will NOT be renewing my support contract.
  13251. > > ->
  13252. > > -> For the amount it would cost to cover 2 chassis and a dozen DSP's,
  13253. > ARC's and
  13254. > > -> NMC's they need to do alot better than they are now.
  13255. > > ->
  13256. > > -> They released NFAS code and OSPF beta code... whipee.  Make the damned
  13257. > thing
  13258. > > -> connect more reliabily and then worry about networking code (ala OSPF).
  13259. > >
  13260. > > I too boycotted renewing my maintenance contract for almost a year
  13261. > > for many of the same reasons you and others have expressed.  I just
  13262. > > downloaded all of the TC 3.6 stuff but am gunshy about upgrading the
  13263. > > Hiperarc and DSP code. I got burned already on the 4.1.56-6 code that
  13264. > > killed my webramps.  I was actually on Ramp Networks website tonight and
  13265. > > they have an engineering note specifically for TC w/HiPerArcs.  They
  13266. > > pretty much pointed the gun straight at 3Com.   Back to the original
  13267. > > point of your message I wonder how many of us have witheld revenue from
  13268. > > 3Com over the maintenance contract issues  ?  I will say the
  13269. > > process for purchasing the maintenance contract and getting it
  13270. > > active was much much better this time (albeit I couldn't active
  13271. > > it via the website due to some cgi problem) but the ole reliable
  13272. > > fax machine came through with flying colors.
  13273. > 
  13274. > We have.  I would be very happy to pay 3Com a fair price for maintenence
  13275. > contracts.  We almost had a deal cinched and at the last minute they
  13276. > changed the price, and we never went with it.
  13277. > 
  13278. > Once you are a certain size, and you have certain momentum, you are
  13279. > *always* buying dsp's every few weeks.  So technically, if you just keep
  13280. > registering those numbers on totalservice, you will always be covered
  13281. > under 90 days support.
  13282. > 
  13283. > This is bad for 3com though, so they really should fix the contract
  13284. > situation, so we can get real contracts.  I just want software, I am not
  13285. > interested in there tech support.  I have been working on TC hubs for
  13286. > years, setup dozens and dozens of them, and done just about everything
  13287. > worth doing on them.  But I get subjected to calling into an 800 number,
  13288. > at 11pm, so that some guy who sounds half asleep can call me back with a
  13289. > piss poor (tired?) attitude, who probably has been working there like a
  13290. > few weeks, or months, and doesn't have anywhere near the experience I do
  13291. > on these hubs.  "Did you try rebooting the chassis?"...........
  13292. > 
  13293. > I feel I am in a constant battle with 3com, just to get code I have
  13294. > legitimate access too etc.
  13295. > 
  13296. > I mean, if you buy a chassis that has TCS 3.5 on it, and you bought a
  13297. > support contract with TCS 3.5..........shouldn't your account still let
  13298. > you download the TCS 3.5 code forever?  I mean, its not like they are
  13299. > giving you something you didn't already have........you paid for it, its
  13300. > not a newer version, its the version that was on the damn thing when you
  13301. > bought it!
  13302. > 
  13303. > I can log into Cisco, and download any code on that site, no questions
  13304. > asked..........I can do that with a $250 2501 service contract.  Do I
  13305. > screw Cisco? Hell no, because the contracts for *all* the stuff I have is
  13306. > just as good of a deal as the pricing on the 2501 contracts.
  13307. > 
  13308. > You can bet that when people like myself need support contracts, its not
  13309. > because we don't know how to use the equipment, its because the stuff
  13310. > isn't working, we need fixes, we need to let 3com know it doesn't work.
  13311. > 
  13312. > >
  13313. > >
  13314. > > Jeff Binkley
  13315. > > ASA Network Computing
  13316. > >
  13317. > > -
  13318. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13319. > >  with "unsubscribe usr-tc" in the body of the message.
  13320. > >  For information on digests or retrieving files and old messages send
  13321. > >  "help" to the same address.  Do not use quotes in your message.
  13322. > >
  13323. > 
  13324. > -----------------------------------------------------
  13325. > Brian Feeny (BF304)     signal@shreve.net
  13326. > 318-222-2638 x 109    http://www.shreve.net/~signal
  13327. > Network Administrator   ShreveNet Inc. (ASN 11881)
  13328. > 
  13329. > 
  13330. > 
  13331. > 
  13332. > -
  13333. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13334. >  with "unsubscribe usr-tc" in the body of the message.
  13335. >  For information on digests or retrieving files and old messages send
  13336. >  "help" to the same address.  Do not use quotes in your message.
  13337. > 
  13338.  
  13339. Brian Feeny (BF304)     signal@shreve.net   
  13340. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13341. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13342.  
  13343.  
  13344. -
  13345.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13346.  with "unsubscribe usr-tc" in the body of the message.
  13347.  For information on digests or retrieving files and old messages send
  13348.  "help" to the same address.  Do not use quotes in your message.
  13349.  
  13350.  
  13351. -------------------------------------------------------------------------------
  13352.  
  13353. From: Brian <signal@shreve.net>
  13354. Subject: Re: (usr-tc) Funk Radius
  13355. Date: 13 Oct 1999 22:21:04 -0500 (CDT)
  13356.  
  13357. On Wed, 13 Oct 1999, Ed wrote:
  13358.  
  13359. > Perl? not sure I want to touch that one ;-)
  13360. > 
  13361.  
  13362. perl is a big plus though.  It can run on many platforms and is fully
  13363. extensable.  The code is very efficient and clean, you would be impressed
  13364. trust me.
  13365.  
  13366. > Ed
  13367. > 
  13368. > ----- Original Message -----
  13369. > From: Lon R. Stockton, Jr. <lon@moonstar.com>
  13370. > To: <usr-tc@lists.xmission.com>
  13371. > Sent: Wednesday, October 13, 1999 2:09 AM
  13372. > Subject: Re: (usr-tc) Funk Radius
  13373. > 
  13374. > 
  13375. > 
  13376. > Don't know anything about that one, but if you're going to buy something,
  13377. > I'd suggest taking a look at Radiator. It's written in perl, so it's not
  13378. > the fastest you can get, but you get the source and can make it do
  13379. > *anything* you want. Not that you have to; I've seen a feature request
  13380. > hit the support mailing list and the guys who wrote the package mentioning
  13381. > that they've written it and tossed it on the ftp site...within *hours*.
  13382. > 
  13383. > Supports USR style VSAs and interfaces to your favorite sql or odbc
  13384. > database out of the box.
  13385. > 
  13386. > 
  13387. > On Wed, 13 Oct 1999, Ed wrote:
  13388. > 
  13389. > > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  13390. > > technician). Does anyone have any experience in this and is it better than
  13391. > > the current 6.0.9 3com Radius? Hard to believe it could be worse...
  13392. > 
  13393. > 
  13394. > -
  13395. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13396. >  with "unsubscribe usr-tc" in the body of the message.
  13397. >  For information on digests or retrieving files and old messages send
  13398. >  "help" to the same address.  Do not use quotes in your message.
  13399. > 
  13400. > 
  13401. > 
  13402. > -
  13403. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13404. >  with "unsubscribe usr-tc" in the body of the message.
  13405. >  For information on digests or retrieving files and old messages send
  13406. >  "help" to the same address.  Do not use quotes in your message.
  13407. > 
  13408.  
  13409. Brian Feeny (BF304)     signal@shreve.net   
  13410. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13411. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13412.  
  13413.  
  13414. -
  13415.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13416.  with "unsubscribe usr-tc" in the body of the message.
  13417.  For information on digests or retrieving files and old messages send
  13418.  "help" to the same address.  Do not use quotes in your message.
  13419.  
  13420.  
  13421. -------------------------------------------------------------------------------
  13422.  
  13423. From: Brian <signal@shreve.net>
  13424. Subject: RE: (usr-tc) 2.0.60 HDM Code
  13425. Date: 13 Oct 1999 22:27:12 -0500 (CDT)
  13426.  
  13427. > 
  13428. > How can other MAJOR access manufacturers get away with relaesing free code
  13429. > for updates and 3Com cannot?  If 2.0.6 has a bug in it.. I shouldn't have
  13430. > to pay for 2.0.7 that fixes the bug they sold me in the first place.
  13431. > Thier almost as bad as Microsoft when it comes to licensing.
  13432.  
  13433. yep, they should release bug fix code which adds no new features, so that
  13434. people can have it for free if they have paid for the code that has bugs
  13435. in it.  Instead they fix some bugs, add new features, and then call it a
  13436. major release and want more money.
  13437.  
  13438. > 
  13439. > I remember about 2 years ago someone wrote an open letter to 3Com/USR
  13440. > about the Total Control chassis and put it on the web... 3Com did respond
  13441. > but it was a standard "we are continuing to make improvements" letter.
  13442.  
  13443. That was the Total Control Unresolved Issues letter.  It was signed off on
  13444. by dozens of technical leads/sysadmins and CEO's of places using Total
  13445. Control.  I believe 3com did listen to alot of that letter and make
  13446. improvments, they did listen.  I don't think we should have to goto that
  13447. sort of extent, but if it works, perhaps its time for a second
  13448. revision.......not to blast them, just to put our thoughts together, and
  13449. that way they can get an idea of what we feel is important.
  13450.  
  13451. > 
  13452. > It sad that the customer base has to get just short of a revolt in order
  13453. > to get even that kind of form letter response.
  13454. > 
  13455. > I am getting tired of 3Com, it's lack of interest in supporting it's users
  13456. > and a support program that just plain is not worth it.
  13457. > 
  13458. > Paul Farber
  13459. > Farber Technology
  13460. > farber@admin.f-tech.net
  13461. > Ph  570-628-5303
  13462. > Fax 570-628-5545
  13463. > 
  13464. > > Those of us new to the platform (myself included) might benefit from the
  13465. > > convenience of knowing that phone support is available 24x7 when you're
  13466. > > staring at a box not taking calls at 2AM. But once you get the hang of TC
  13467. > > and know how to troubleshoot these things on your own (or at least with the
  13468. > > added help of those on this list), you can drop the tel support, and just
  13469. > > pay for code updates.
  13470. > 
  13471. > 
  13472. > -
  13473. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13474. >  with "unsubscribe usr-tc" in the body of the message.
  13475. >  For information on digests or retrieving files and old messages send
  13476. >  "help" to the same address.  Do not use quotes in your message.
  13477. > 
  13478.  
  13479. Brian Feeny (BF304)     signal@shreve.net   
  13480. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13481. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13482.  
  13483.  
  13484. -
  13485.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13486.  with "unsubscribe usr-tc" in the body of the message.
  13487.  For information on digests or retrieving files and old messages send
  13488.  "help" to the same address.  Do not use quotes in your message.
  13489.  
  13490.  
  13491. -------------------------------------------------------------------------------
  13492.  
  13493. From: Brian <signal@shreve.net>
  13494. Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
  13495. Date: 13 Oct 1999 22:43:09 -0500 (CDT)
  13496.  
  13497. > Shoot...if you need a bug tracking product to do this...just go to
  13498. > www.mozilla.org and grab bugzilla...its open source, doesn't cost a
  13499. > penny...works great, and is easily set up to allow public access to it.
  13500.  
  13501. *definitly*.  Redhat.com uses this.  Bugzilla rocks the casba, and its
  13502. free too.  I would love to go thru Bugzilla on Total Control, so i can see
  13503. what others are reporting.......unbiased, unedited.
  13504.  
  13505. I think alot of people find bugs but because its so HARD to report a bug
  13506. to 3com, it doesn't happen as often as it should.  But if a public
  13507. bugzilla existed, i think people like myself and others would just love to
  13508. populate the hell out of it and then 3com would get 10 fold the input they
  13509. are probably getting now.
  13510.  
  13511. But its like a two edged sword.  I imagine 3com woudln't want something
  13512. like this, because they would be too concerned about potential customers
  13513. seeing all the problems reported, or competition taking notes on 3com's
  13514. weaknesses.........the result is a coverup, and the slowing of gears.
  13515.  
  13516. Honesty would enable more free communication, and would allow you all to
  13517. produce a much better product, I know it.
  13518.  
  13519. Instead of hording the ER code, and forcing people to call your support
  13520. people, I would say put it on the site, force the people downloading it to
  13521. fill out a form (you really don't need to do that either, since you all
  13522. know which account downloaded the code).  then email that person once per
  13523. week a survey asking about how the code is coming, and ask for feedback.
  13524. You would get 10x the people using the code then, and even if only half
  13525. the people responded, you would get more feedback.
  13526.  
  13527. > Maybe I should take a dose of my own medicine...I've been working from
  13528. > the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to
  13529. > come at it from the other direction.  Maybe I/we need to start from the
  13530. > top down...since my current actions seems to be ineffective, perhaps my
  13531. > system is intrensically broken and I should be emailing Eric Benhamou
  13532. > and Bruce Claflin and the like...maybe if I can get them to understand,
  13533. > then some substantive changes will take place.
  13534.  
  13535. very much the idea behind the unresolved issues list, which was btw,
  13536. actually presented to the CEO of 3com.
  13537. > 
  13538. > Cut out the layers of beaurocracy and I'd be willing to be that you'll
  13539. > get better response from customers, better communication, fewer
  13540. > complaints, and better feedback (without having to track and initiate
  13541. > that feedback yourself) from customers because they'll *want* to help
  13542. > you, and it won't be an arduous task for us.  I'm a generally helpful
  13543.  
  13544. right.  You cant get ER code unless you call tech support............But I
  13545. don't want to call tech support.  Tech support doesn't know routing
  13546. protocols, has never configured complex radius setups, I have no intrest
  13547. in level 1 support.
  13548.  
  13549.  
  13550. > I also know that the people on this list (for the most part from what
  13551. > I've seen) are not in a position to do anything about these things
  13552. > directly.  Believe me, I'm not trying to cause your life to be
  13553. > miserable...I just don't know any other way to get feedback to 3Com
  13554. > about these things.  Point me in a better direction and I'll go there (I
  13555. > know...talk to my sales rep...I already have...he's very aware of our
  13556. > issues here).
  13557.  
  13558. I agree.  I think 3com engineers are really great and bright people.  It
  13559. must be hard to work for a company as large as 3com, its not like the
  13560. engineers call all the shots.  Its not like the engineers are going to
  13561. come out and say, whether they believe it or not, "the company i work for
  13562. has crappy procedures, blah blah".......we can't expect that, we can't
  13563. expect them to tell us what to do to help them.  We can only call them
  13564. like we seem them, and go from there.  It looks like "corporate" gridlock
  13565. type stuff and so maybe some streamlining of processes is in order.
  13566.  
  13567. > 
  13568. > >   This was probably just a rehash of what Todd said the other day...
  13569. > 
  13570. > Basically, yeah...but better a rehash of things than no communication at
  13571. > all.  :)
  13572. > -- 
  13573. > Jeff McAdams                            Email: jeffm@iglou.com
  13574. > Head Network Administrator              Voice: (502) 966-3848
  13575. > IgLou Internet Services                        (800) 436-4456
  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. Brian Feeny (BF304)     signal@shreve.net   
  13585. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13586. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13587.  
  13588.  
  13589. -
  13590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13591.  with "unsubscribe usr-tc" in the body of the message.
  13592.  For information on digests or retrieving files and old messages send
  13593.  "help" to the same address.  Do not use quotes in your message.
  13594.  
  13595.  
  13596. -------------------------------------------------------------------------------
  13597.  
  13598. From: "Brian Hitchcock" <brianh@kcweb.net>
  13599. Subject: RE: (usr-tc) Funk Radius
  13600. Date: 13 Oct 1999 22:51:16 -0500
  13601.  
  13602. anyone have a URL for these radius servers?
  13603.  
  13604. Brian Hitchcock
  13605.  
  13606.  
  13607. -----Original Message-----
  13608. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  13609. Sent: Wednesday, October 13, 1999 10:20 PM
  13610.  
  13611.  
  13612. On Wed, 13 Oct 1999, Lon R. Stockton, Jr. wrote:
  13613.  
  13614. >
  13615. > Don't know anything about that one, but if you're going to buy something,
  13616. > I'd suggest taking a look at Radiator. It's written in perl, so it's not
  13617. > the fastest you can get, but you get the source and can make it do
  13618. > *anything* you want. Not that you have to; I've seen a feature request
  13619.  
  13620. I will second Radiator.  As for speed.........well, use the radpwtst
  13621. program that comes with it, you will be impressed.  I know of ISP's with
  13622. 80,000+ users using Radiator, and they don't seem to have any
  13623. problems.....
  13624.  
  13625. > hit the support mailing list and the guys who wrote the package mentioning
  13626. > that they've written it and tossed it on the ftp site...within *hours*.
  13627. >
  13628. > Supports USR style VSAs and interfaces to your favorite sql or odbc
  13629. > database out of the box.
  13630. >
  13631. >
  13632. > On Wed, 13 Oct 1999, Ed wrote:
  13633. >
  13634. > > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  13635. > > technician). Does anyone have any experience in this and is it better
  13636. than
  13637. > > the current 6.0.9 3com Radius? Hard to believe it could be worse...
  13638. >
  13639. >
  13640. > -
  13641. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13642. >  with "unsubscribe usr-tc" in the body of the message.
  13643. >  For information on digests or retrieving files and old messages send
  13644. >  "help" to the same address.  Do not use quotes in your message.
  13645. >
  13646.  
  13647. Brian Feeny (BF304)     signal@shreve.net
  13648. 318-222-2638 x 109    http://www.shreve.net/~signal
  13649. Network Administrator   ShreveNet Inc. (ASN 11881)
  13650.  
  13651.  
  13652. -
  13653.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13654.  with "unsubscribe usr-tc" in the body of the message.
  13655.  For information on digests or retrieving files and old messages send
  13656.  "help" to the same address.  Do not use quotes in your message.
  13657.  
  13658.  
  13659. -
  13660.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13661.  with "unsubscribe usr-tc" in the body of the message.
  13662.  For information on digests or retrieving files and old messages send
  13663.  "help" to the same address.  Do not use quotes in your message.
  13664.  
  13665.  
  13666. -------------------------------------------------------------------------------
  13667.  
  13668. From: Brian <signal@shreve.net>
  13669. Subject: Re: (usr-tc) Beaurocracy issues  ;)
  13670. Date: 13 Oct 1999 22:47:15 -0500 (CDT)
  13671.  
  13672. On Wed, 13 Oct 1999, Jeff Mcadams wrote:
  13673.  
  13674. > Thus spake Scot Desort
  13675. > >Jeff Mcadams wrote:
  13676. > >> They already have a software only support contract...its just as
  13677. > >> ridiculous as the rest of them.
  13678. > 
  13679. > >Geez, didn't realize that. So I guess the pricing is not attractive? We all
  13680. > >want free, but if it were only a nominal charge, that might have helped ;-(
  13681. > 
  13682. > Yah...its still done on a $x/48-port chassis basis, which, for software
  13683. > only, makes even less sense.  :/  And because 3Com is so concerned about
  13684. > someone buying support on one chassis and having 10 that they don't have
  13685. > support on, they still require you, with the software-only, to buy
  13686. > support on *all* of your equipment equally.  *blam*, it was dead before
  13687. > it even got out of the starting blocks for us.  And, of course, when we
  13688. > called to complain about it, we got a call from the head of support
  13689. > contracts who's point in calling was to explain to us what options were
  13690. > available...again, he was totally unwilling to give any thought to the
  13691. > idea that maybe, just maybe, there was a better way to do
  13692. > things...totally blew off our concerns.
  13693.  
  13694. They don't want to budge.  They lose money over this.
  13695.  
  13696. If you make a good product, one that doesn't have problems, that is how
  13697. you keep support down.  Good documentation, good code, good compatibility.
  13698.  
  13699.  
  13700. > -- 
  13701. > Jeff McAdams                            Email: jeffm@iglou.com
  13702. > Head Network Administrator              Voice: (502) 966-3848
  13703. > IgLou Internet Services                        (800) 436-4456
  13704. > 
  13705. > -
  13706. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13707. >  with "unsubscribe usr-tc" in the body of the message.
  13708. >  For information on digests or retrieving files and old messages send
  13709. >  "help" to the same address.  Do not use quotes in your message.
  13710. > 
  13711.  
  13712. Brian Feeny (BF304)     signal@shreve.net   
  13713. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13714. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13715.  
  13716.  
  13717. -
  13718.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13719.  with "unsubscribe usr-tc" in the body of the message.
  13720.  For information on digests or retrieving files and old messages send
  13721.  "help" to the same address.  Do not use quotes in your message.
  13722.  
  13723.  
  13724. -------------------------------------------------------------------------------
  13725.  
  13726. From: Brian <signal@shreve.net>
  13727. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  13728. Date: 13 Oct 1999 22:50:54 -0500 (CDT)
  13729.  
  13730.  
  13731. I had the same shit happen.  She couldn't get it thru her head that we had
  13732. SOLD half the stuff they had us listed down for.  We SOLD it because it
  13733. was quad modem technology and its a good thing too, because we would be
  13734. screwed had we not sold, and 3com doesn't make a support contract to fix
  13735. you if you got a quad chassis.......not good enough anyways, its all
  13736. EOL'ed.
  13737.  
  13738. It took I want to say 18+ months of negotiations between our 3com rep, us,
  13739. and 3com support contract people.  To this day we have not been able to
  13740. get contracts because we can't come to an agreement on how the stuff
  13741. should be priced.
  13742.  
  13743.  
  13744. On Wed, 13 Oct 1999, Charles Sprickman wrote:
  13745.  
  13746. > 
  13747. > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  13748. > 
  13749. > > Unless I am mistaken they do offer software only contracts.  I've seen 
  13750. > > them on Tech Data's price listing.  They are generally less than half of 
  13751. > > the full service contracts.
  13752. > 
  13753. > They are still pricey.  And on top of the price, we started getting
  13754. > harrassing phone calls from some lackey in the 'service contract'
  13755. > department saying:
  13756. > 
  13757. > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  13758. > 
  13759. > -me: "Yes.  That's why I bought X contracts."
  13760. > 
  13761. > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  13762. > 
  13763. > -me: "Yes."
  13764. > 
  13765. > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  13766. > 
  13767. > -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  13768. > crap off."
  13769. > 
  13770. > I didn't even buy direct from 3Com, but via a reseller.  They apparently
  13771. > have the time and money to put losers like this on the phone to harass
  13772. > customers about the number of contracts they have versus the number of
  13773. > chassis they've purchased in the last 3 years.  What a waste.  What
  13774. > arrogance.
  13775. > 
  13776. > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  13777. > routers that cost LESS than putting full support with no
  13778. > "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  13779. > numerous Cisco employees; support, sales, engineering that they let people
  13780. > slide on most support/software issues.  They frown on 'version jumping'
  13781. > where you go and thieve say IOS w/Firewall support when you bought basic
  13782. > IP, but I've had so many instances where I've received support/software on
  13783. > equipment with no contract.  I've even told the guy on the phone "I have
  13784. > no contract" and the basic response is "We want you to be happy.  Your
  13785. > hardware fried?  We'll send you new...  You need IOS 12.x to fix this bug?
  13786. > Here it is."
  13787. > 
  13788. > Why can't 3Com adopt at least some of this attitude?  It's not like
  13789. > Pilgrim is feature-packed like IOS, we're all just looking for solid
  13790. > connects and standard routing features...
  13791. > 
  13792. > Charles
  13793. >  
  13794. > > Jeff Binkley
  13795. > > ASA Network Computing
  13796. > > 
  13797. > > 
  13798. > > U>I think Brian is on the right track here. Perhaps 3COM can split their
  13799. > > U>service contracts into 2 categories - firmware download only, and full
  13800. > > U>support with download and telephone support.
  13801. > > 
  13802. > > U>Those of us new to the platform (myself included) might benefit from
  13803. > > U>the convenience of knowing that phone support is available 24x7 when
  13804. > > U>you're staring at a box not taking calls at 2AM. But once you get the
  13805. > > U>hang of TC and know how to troubleshoot these things on your own (or
  13806. > > U>at least with the added help of those on this list), you can drop the
  13807. > > U>tel support, and just pay for code updates.
  13808. > > 
  13809. > > U>Does any of this matter to those on this list that are complaining
  13810. > > U>about 3COM's lack of timely response to code issues? Probably not.
  13811. > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  13812. > > U>Should they perhaps head-up a small team (1 person) to field code
  13813. > > U>enhancement and bug fix requests, both from an email/web input area on
  13814. > > U>the 3COM ISP pages, but also through monitoring of this list and the
  13815. > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  13816. > > U>"behind the scenes", quietly tracking and logging this stuff, but it's
  13817. > > U>apparent that the people who need to know the most that it's being
  13818. > > U>done and being worked on, the ISP customers, don't know that someone
  13819. > > U>has acknowledged the problem and it has been placed into an
  13820. > > U>engineering queue.
  13821. > > 
  13822. > > U>I think that things like this would greatly improve 3COM's image among
  13823. > > U>it's ISP customers, and even more so if they acted expediently on
  13824. > > U>these issues that trouble so many on this list. Give the telephone
  13825. > > U>support staff access to the database created as a result of these
  13826. > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  13827. > > U>contract). Tie the ER/SR releases to the database, so it's easier to
  13828. > > U>identify which bug is fixed with which release. And most importantly,
  13829. > > U>of allowing us to view this database to obtain the status a confirmed
  13830. > > U>of bug and it's up-to-date progress in getting resolved would be
  13831. > > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
  13832. > > U>SNMP issue by simply searching the database is comforting (knowing 
  13833. > > that 
  13834. > > U>it will be fixed QUICKLY is even better). Some of this status
  13835. > > U>information may already be in the 3KB, but a dedicated database for TC
  13836. > > U>code issues and status reports would be really great.
  13837. > > 
  13838. > > U>Scot
  13839. > > U>NJAccess
  13840. > > 
  13841. > > CMPQwk 1.42 9999
  13842. > > 
  13843. > > -
  13844. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13845. > >  with "unsubscribe usr-tc" in the body of the message.
  13846. > >  For information on digests or retrieving files and old messages send
  13847. > >  "help" to the same address.  Do not use quotes in your message.
  13848. > > 
  13849. > 
  13850. > 
  13851. > -
  13852. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13853. >  with "unsubscribe usr-tc" in the body of the message.
  13854. >  For information on digests or retrieving files and old messages send
  13855. >  "help" to the same address.  Do not use quotes in your message.
  13856. > 
  13857.  
  13858. Brian Feeny (BF304)     signal@shreve.net   
  13859. 318-222-2638 x 109    http://www.shreve.net/~signal      
  13860. Network Administrator   ShreveNet Inc. (ASN 11881)           
  13861.  
  13862.  
  13863. -
  13864.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13865.  with "unsubscribe usr-tc" in the body of the message.
  13866.  For information on digests or retrieving files and old messages send
  13867.  "help" to the same address.  Do not use quotes in your message.
  13868.  
  13869.  
  13870. -------------------------------------------------------------------------------
  13871.  
  13872. From: Brian <signal@shreve.net>
  13873. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  13874. Date: 13 Oct 1999 22:53:42 -0500 (CDT)
  13875.  
  13876. On Wed, 13 Oct 1999 farber@admin.f-tech.net wrote:
  13877.  
  13878. > I got one of them last week!  I tried to just cover a chassis that I
  13879. > wanted to test out the "newer" features with.  Like OSPF, tunneling, etc.
  13880. > They said you need all your chassis covered and you cannot get just the
  13881. > support you *WANT*.
  13882. > 
  13883. > Even though I just purchased 4 DPS's and have 90 days free support.. they
  13884. > (the nice 3com lady said that they don't do just certain cards.. and that
  13885. > she would need to see an inventory of all the cards I owned).
  13886. > 
  13887. > I think not.
  13888.  
  13889. They don't want to come to an agreement.  So you are forced into the back
  13890. alley 3com warez scene (which by the way is quite happening *jk*), and
  13891. using 90 day support.  I don't want to live from 90 days to 90 days at a
  13892. time.  I can do it though, all you have to do is add roughly 48 ports
  13893. every 3 months.......but i would rather have a good solid software
  13894. contract.......
  13895.  
  13896. > 
  13897. > Paul Farber
  13898. > Farber Technology
  13899. > farber@admin.f-tech.net
  13900. > Ph  570-628-5303
  13901. > Fax 570-628-5545
  13902. > 
  13903. > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  13904. > 
  13905. > > 
  13906. > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  13907. > > 
  13908. > > > Unless I am mistaken they do offer software only contracts.  I've seen 
  13909. > > > them on Tech Data's price listing.  They are generally less than half of 
  13910. > > > the full service contracts.
  13911. > > 
  13912. > > They are still pricey.  And on top of the price, we started getting
  13913. > > harrassing phone calls from some lackey in the 'service contract'
  13914. > > department saying:
  13915. > > 
  13916. > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  13917. > > 
  13918. > > -me: "Yes.  That's why I bought X contracts."
  13919. > > 
  13920. > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  13921. > > 
  13922. > > -me: "Yes."
  13923. > > 
  13924. > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  13925. > > 
  13926. > > -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  13927. > > crap off."
  13928. > > 
  13929. > > I didn't even buy direct from 3Com, but via a reseller.  They apparently
  13930. > > have the time and money to put losers like this on the phone to harass
  13931. > > customers about the number of contracts they have versus the number of
  13932. > > chassis they've purchased in the last 3 years.  What a waste.  What
  13933. > > arrogance.
  13934. > > 
  13935. > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  13936. > > routers that cost LESS than putting full support with no
  13937. > > "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  13938. > > numerous Cisco employees; support, sales, engineering that they let people
  13939. > > slide on most support/software issues.  They frown on 'version jumping'
  13940. > > where you go and thieve say IOS w/Firewall support when you bought basic
  13941. > > IP, but I've had so many instances where I've received support/software on
  13942. > > equipment with no contract.  I've even told the guy on the phone "I have
  13943. > > no contract" and the basic response is "We want you to be happy.  Your
  13944. > > hardware fried?  We'll send you new...  You need IOS 12.x to fix this bug?
  13945. > > Here it is."
  13946. > > 
  13947. > > Why can't 3Com adopt at least some of this attitude?  It's not like
  13948. > > Pilgrim is feature-packed like IOS, we're all just looking for solid
  13949. > > connects and standard routing features...
  13950. > > 
  13951. > > Charles
  13952. > >  
  13953. > > > Jeff Binkley
  13954. > > > ASA Network Computing
  13955. > > > 
  13956. > > > 
  13957. > > > U>I think Brian is on the right track here. Perhaps 3COM can split their
  13958. > > > U>service contracts into 2 categories - firmware download only, and full
  13959. > > > U>support with download and telephone support.
  13960. > > > 
  13961. > > > U>Those of us new to the platform (myself included) might benefit from
  13962. > > > U>the convenience of knowing that phone support is available 24x7 when
  13963. > > > U>you're staring at a box not taking calls at 2AM. But once you get the
  13964. > > > U>hang of TC and know how to troubleshoot these things on your own (or
  13965. > > > U>at least with the added help of those on this list), you can drop the
  13966. > > > U>tel support, and just pay for code updates.
  13967. > > > 
  13968. > > > U>Does any of this matter to those on this list that are complaining
  13969. > > > U>about 3COM's lack of timely response to code issues? Probably not.
  13970. > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  13971. > > > U>Should they perhaps head-up a small team (1 person) to field code
  13972. > > > U>enhancement and bug fix requests, both from an email/web input area on
  13973. > > > U>the 3COM ISP pages, but also through monitoring of this list and the
  13974. > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  13975. > > > U>"behind the scenes", quietly tracking and logging this stuff, but it's
  13976. > > > U>apparent that the people who need to know the most that it's being
  13977. > > > U>done and being worked on, the ISP customers, don't know that someone
  13978. > > > U>has acknowledged the problem and it has been placed into an
  13979. > > > U>engineering queue.
  13980. > > > 
  13981. > > > U>I think that things like this would greatly improve 3COM's image among
  13982. > > > U>it's ISP customers, and even more so if they acted expediently on
  13983. > > > U>these issues that trouble so many on this list. Give the telephone
  13984. > > > U>support staff access to the database created as a result of these
  13985. > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  13986. > > > U>contract). Tie the ER/SR releases to the database, so it's easier to
  13987. > > > U>identify which bug is fixed with which release. And most importantly,
  13988. > > > U>of allowing us to view this database to obtain the status a confirmed
  13989. > > > U>of bug and it's up-to-date progress in getting resolved would be
  13990. > > > U>tremendous benefit. To know that someone is actually WORKING on Jeff's
  13991. > > > U>SNMP issue by simply searching the database is comforting (knowing 
  13992. > > > that 
  13993. > > > U>it will be fixed QUICKLY is even better). Some of this status
  13994. > > > U>information may already be in the 3KB, but a dedicated database for TC
  13995. > > > U>code issues and status reports would be really great.
  13996. > > > 
  13997. > > > U>Scot
  13998. > > > U>NJAccess
  13999. > > > 
  14000. > > > CMPQwk 1.42 9999
  14001. > > > 
  14002. > > > -
  14003. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14004. > > >  with "unsubscribe usr-tc" in the body of the message.
  14005. > > >  For information on digests or retrieving files and old messages send
  14006. > > >  "help" to the same address.  Do not use quotes in your message.
  14007. > > > 
  14008. > > 
  14009. > > 
  14010. > > -
  14011. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14012. > >  with "unsubscribe usr-tc" in the body of the message.
  14013. > >  For information on digests or retrieving files and old messages send
  14014. > >  "help" to the same address.  Do not use quotes in your message.
  14015. > > 
  14016. > 
  14017. > 
  14018. > -
  14019. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14020. >  with "unsubscribe usr-tc" in the body of the message.
  14021. >  For information on digests or retrieving files and old messages send
  14022. >  "help" to the same address.  Do not use quotes in your message.
  14023. > 
  14024.  
  14025. Brian Feeny (BF304)     signal@shreve.net   
  14026. 318-222-2638 x 109    http://www.shreve.net/~signal      
  14027. Network Administrator   ShreveNet Inc. (ASN 11881)           
  14028.  
  14029.  
  14030. -
  14031.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14032.  with "unsubscribe usr-tc" in the body of the message.
  14033.  For information on digests or retrieving files and old messages send
  14034.  "help" to the same address.  Do not use quotes in your message.
  14035.  
  14036.  
  14037. -------------------------------------------------------------------------------
  14038.  
  14039. From: Brian <signal@shreve.net>
  14040. Subject: RE: (usr-tc) Funk Radius
  14041. Date: 13 Oct 1999 22:56:12 -0500 (CDT)
  14042.  
  14043.  
  14044. radiator    http://www.open.com.au/radiator
  14045.  
  14046. On Wed, 13 Oct 1999, Brian Hitchcock wrote:
  14047.  
  14048. > anyone have a URL for these radius servers?
  14049. > 
  14050. > Brian Hitchcock
  14051. > 
  14052. > 
  14053. > -----Original Message-----
  14054. > From: owner-usr-tc@lists.xmission.com
  14055. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  14056. > Sent: Wednesday, October 13, 1999 10:20 PM
  14057. > To: usr-tc@lists.xmission.com
  14058. > Subject: Re: (usr-tc) Funk Radius
  14059. > 
  14060. > 
  14061. > On Wed, 13 Oct 1999, Lon R. Stockton, Jr. wrote:
  14062. > 
  14063. > >
  14064. > > Don't know anything about that one, but if you're going to buy something,
  14065. > > I'd suggest taking a look at Radiator. It's written in perl, so it's not
  14066. > > the fastest you can get, but you get the source and can make it do
  14067. > > *anything* you want. Not that you have to; I've seen a feature request
  14068. > 
  14069. > I will second Radiator.  As for speed.........well, use the radpwtst
  14070. > program that comes with it, you will be impressed.  I know of ISP's with
  14071. > 80,000+ users using Radiator, and they don't seem to have any
  14072. > problems.....
  14073. > 
  14074. > > hit the support mailing list and the guys who wrote the package mentioning
  14075. > > that they've written it and tossed it on the ftp site...within *hours*.
  14076. > >
  14077. > > Supports USR style VSAs and interfaces to your favorite sql or odbc
  14078. > > database out of the box.
  14079. > >
  14080. > >
  14081. > > On Wed, 13 Oct 1999, Ed wrote:
  14082. > >
  14083. > > > We were referred to FUNK Software's Steel-Belted Radius (by a 3com
  14084. > > > technician). Does anyone have any experience in this and is it better
  14085. > than
  14086. > > > the current 6.0.9 3com Radius? Hard to believe it could be worse...
  14087. > >
  14088. > >
  14089. > > -
  14090. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14091. > >  with "unsubscribe usr-tc" in the body of the message.
  14092. > >  For information on digests or retrieving files and old messages send
  14093. > >  "help" to the same address.  Do not use quotes in your message.
  14094. > >
  14095. > 
  14096. > -----------------------------------------------------
  14097. > Brian Feeny (BF304)     signal@shreve.net
  14098. > 318-222-2638 x 109    http://www.shreve.net/~signal
  14099. > Network Administrator   ShreveNet Inc. (ASN 11881)
  14100. > 
  14101. > 
  14102. > -
  14103. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14104. >  with "unsubscribe usr-tc" in the body of the message.
  14105. >  For information on digests or retrieving files and old messages send
  14106. >  "help" to the same address.  Do not use quotes in your message.
  14107. > 
  14108. > 
  14109. > -
  14110. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14111. >  with "unsubscribe usr-tc" in the body of the message.
  14112. >  For information on digests or retrieving files and old messages send
  14113. >  "help" to the same address.  Do not use quotes in your message.
  14114. > 
  14115.  
  14116. Brian Feeny (BF304)     signal@shreve.net   
  14117. 318-222-2638 x 109    http://www.shreve.net/~signal      
  14118. Network Administrator   ShreveNet Inc. (ASN 11881)           
  14119.  
  14120.  
  14121. -
  14122.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14123.  with "unsubscribe usr-tc" in the body of the message.
  14124.  For information on digests or retrieving files and old messages send
  14125.  "help" to the same address.  Do not use quotes in your message.
  14126.  
  14127.  
  14128. -------------------------------------------------------------------------------
  14129.  
  14130. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  14131. Subject: RE: (usr-tc) Funk Radius
  14132. Date: 14 Oct 1999 01:24:05 -0400 (EDT)
  14133.  
  14134.  
  14135. On Wed, 13 Oct 1999, Brian Hitchcock wrote:
  14136.  
  14137. > anyone have a URL for these radius servers?
  14138.  
  14139. <http://www.open.com.au/radiator/> for Radiator
  14140.  
  14141.  
  14142. -
  14143.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14144.  with "unsubscribe usr-tc" in the body of the message.
  14145.  For information on digests or retrieving files and old messages send
  14146.  "help" to the same address.  Do not use quotes in your message.
  14147.  
  14148.  
  14149. -------------------------------------------------------------------------------
  14150.  
  14151. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  14152. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  14153. Date: 14 Oct 1999 01:28:33 -0400 (EDT)
  14154.  
  14155.  
  14156. On Wed, 13 Oct 1999, Brian wrote:
  14157.  
  14158. > They don't want to come to an agreement.  So you are forced into the back
  14159. > alley 3com warez scene (which by the way is quite happening *jk*)
  14160.  
  14161. I keep looking for alt.binaries.warez.3com, but never see it. (:
  14162.  
  14163.  
  14164.  
  14165. -
  14166.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14167.  with "unsubscribe usr-tc" in the body of the message.
  14168.  For information on digests or retrieving files and old messages send
  14169.  "help" to the same address.  Do not use quotes in your message.
  14170.  
  14171.  
  14172. -------------------------------------------------------------------------------
  14173.  
  14174. From: Jeff Mcadams <jeffm@iglou.com>
  14175. Subject: Re: (usr-tc) snmp pri
  14176. Date: 14 Oct 1999 07:57:17 -0400
  14177.  
  14178. Thus spake James Nessen
  14179. >Does anyone happen to know the oid for checking status on the pri cards on
  14180. >a arc?
  14181.  
  14182. Uhm...that seems to be contradictory...the arc has no knowledge of any
  14183. PRI's at all in the chassis (frame-relay wan ports, yes; PRI, no).  You
  14184. would need to query via the NMC to get information about the PRI cards.
  14185. -- 
  14186. Jeff McAdams                            Email: jeffm@iglou.com
  14187. Head Network Administrator              Voice: (502) 966-3848
  14188. IgLou Internet Services                        (800) 436-4456
  14189.  
  14190. -
  14191.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14192.  with "unsubscribe usr-tc" in the body of the message.
  14193.  For information on digests or retrieving files and old messages send
  14194.  "help" to the same address.  Do not use quotes in your message.
  14195.  
  14196.  
  14197. -------------------------------------------------------------------------------
  14198.  
  14199. From: Brian Elfert <brian@citilink.com>
  14200. Subject: (usr-tc) Upgrading to HiperDSP from quads
  14201. Date: 14 Oct 1999 10:22:40 -0500 (CDT)
  14202.  
  14203. Right now, I have 5 racks of USR Total Control with Netservers and quad
  14204. modems.  My leases are expiring over the next 6 months, so I need to
  14205. decide if I renew the leases or move to HiperDSPs.
  14206.  
  14207. How are the HiperDSPs working vs the quad modems?  Are the HiperDSPs every
  14208. bit as good as the quad modems?  Will every modem that works now continue
  14209. to work?
  14210.  
  14211. I'm not sure the Netserver cards aren't limiting the throughput of my
  14212. modems.  Would getting HiperARCs to go with the quad modems be the best of
  14213. both worlds?
  14214.  
  14215. Brian
  14216.  
  14217.  
  14218. -
  14219.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14220.  with "unsubscribe usr-tc" in the body of the message.
  14221.  For information on digests or retrieving files and old messages send
  14222.  "help" to the same address.  Do not use quotes in your message.
  14223.  
  14224.  
  14225. -------------------------------------------------------------------------------
  14226.  
  14227. From: Jeff Mcadams <jeffm@iglou.com>
  14228. Subject: Re: (usr-tc) Upgrading to HiperDSP from quads
  14229. Date: 14 Oct 1999 11:49:10 -0400
  14230.  
  14231. Thus spake Brian Elfert
  14232. >How are the HiperDSPs working vs the quad modems?  Are the HiperDSPs every
  14233. >bit as good as the quad modems?  
  14234.  
  14235. No...they're getting to be pretty good...but they do still have a few
  14236. shortcomings.
  14237.  
  14238. >Will every modem that works now continue to work?
  14239.  
  14240. Basically, yeah, just maybe not quite as well in all cases (from what
  14241. I've seen).
  14242.  
  14243. >I'm not sure the Netserver cards aren't limiting the throughput of my
  14244. >modems.  Would getting HiperARCs to go with the quad modems be the best of
  14245. >both worlds?
  14246.  
  14247. Yup...definitely would be the best.  I personally don't see any major
  14248. reason to move to DSP's from quads at this point.  We're running a mix
  14249. currently.  The only reason that I'm pressing to upgrade the quads to
  14250. DSPs here is purely for manageability reasons.  I find it easier to only
  14251. deal with one type of modem platform for troubleshooting, upgrades, etc.
  14252. than have to change the way I do things depending upon which type of
  14253. modem I hit.
  14254.  
  14255. The two types of modems are *largely* similar in their behavior, but
  14256. there are still a few differences that make having a mix a bit of a pain
  14257. at times.  :)
  14258. -- 
  14259. Jeff McAdams                            Email: jeffm@iglou.com
  14260. Head Network Administrator              Voice: (502) 966-3848
  14261. IgLou Internet Services                        (800) 436-4456
  14262.  
  14263. -
  14264.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14265.  with "unsubscribe usr-tc" in the body of the message.
  14266.  For information on digests or retrieving files and old messages send
  14267.  "help" to the same address.  Do not use quotes in your message.
  14268.  
  14269.  
  14270. -------------------------------------------------------------------------------
  14271.  
  14272. From: GTI x2 Tech <x2@apollo.gti.net>
  14273. Subject: (usr-tc) Microsoft VPN problems via TC 2nd
  14274. Date: 14 Oct 1999 12:33:25 -0400 (EDT)
  14275.  
  14276.  
  14277. We posted this awhile ago with one response but it still didnt work.  It
  14278. seems that the USR TC unit is "blocking" the VPN for some reason.  Any
  14279. ideas?
  14280.  
  14281.  
  14282. Objective:  To promote awareness of Microsoft Virtual Private Networking
  14283. (VPN) problems experienced with USR Total Control Manager Terminal
  14284. Servers.
  14285.  
  14286. Test Equipment for Experiment #1:
  14287.  
  14288.         VPN Server: Microsoft NT 4.0 (SP5) Server  100base-T Ethernet
  14289.         VPN Client: Windows 98  Standard Modem 33.6 kbps
  14290.  
  14291.         Environment:
  14292.  
  14293. a)      An NT user account was created with logon locally services rights.
  14294. b)      MS-VPN and Remote Access (RAS) was configured for remote        
  14295.         connectivity and VPN with 1 available network.
  14296. c)      Private class-c IPs were assigned to the VPN network for
  14297.         dynamically assigned addressing of remote clients.
  14298. d)      Network Domain was configured and named XYZ
  14299. e)      Win 98 machine was configured for Dial-up Networking including
  14300.         Dial-up adapter, TCP/IP and Microsoft Virtual Private Networking
  14301.         Dial-up adapter, and VPN Networking.
  14302. f)      Win 98 domain (workgroup) was set to XYZ. Dialup networking
  14303.  
  14304. Test Results: (Livingston Port Master 2e)
  14305.  
  14306.                 Using the standard Dial-up networking in Windows 98, I
  14307. established an Internet connection to GTI using the analog Livingston Port
  14308. Master 2e.  I verified my connectivity by the use of such utilities as
  14309. ping, traceroute and standard http, FTP and Telnet protocols. At that
  14310. point I launched the VPN Dialup networking connection to the VPN server.
  14311. The VPN server verified and authenticated my account and logged me in. I
  14312. then ran a netstat utility to display my current Internet IP as well as
  14313. the newly assigned private class-c IP provided by the VPN server.  I could
  14314. then go into Network Neighborhood and access every machine belonging to
  14315. the XYZ domain, based on my account privileges previously configured
  14316. at the VPN server user account manager.
  14317.  
  14318. Test Results: (USR Total Control)
  14319.  
  14320.                 Using the identical environments as above, I changed the
  14321. dial-up node number to connect to the USR Total Control Terminal Server.  
  14322. The VPN authenticated my user account and logged me in, but there was
  14323. absolutely NO connectively to the XYZ domain and the Internet connection
  14324. completely stalled.
  14325.  
  14326. Hypothesis:
  14327.    
  14328.                 I believe the USR units are prohibiting the use of VPN
  14329. somehow. Clients should be able to pass VPN packets regardless of what
  14330. dialup they use. The Livingston 2e does not have a problem with VPN at
  14331. all, so it looks like the USR is mis-configured somehow.
  14332.  
  14333. Any insight would be appriciated.
  14334.  
  14335.  
  14336.  
  14337.  
  14338. -
  14339.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14340.  with "unsubscribe usr-tc" in the body of the message.
  14341.  For information on digests or retrieving files and old messages send
  14342.  "help" to the same address.  Do not use quotes in your message.
  14343.  
  14344.  
  14345. -------------------------------------------------------------------------------
  14346.  
  14347. From: Robert von Bismarck <rvb@petrel.ch>
  14348. Subject: RE: (usr-tc) snmp pri
  14349. Date: 14 Oct 1999 19:15:08 +0200
  14350.  
  14351. check in the UDS1.mib that is included with TCM, you should find all the
  14352. OIDS you need for this, but your better off doing it by SNMP-Trap.
  14353.  
  14354. I have a cron job that checks .1.3.6.1.2.1.10.18.9 for errors on the PRI's
  14355. once a day.
  14356.  
  14357. Hope this helps,
  14358.  
  14359.  
  14360. --
  14361. Robert von Bismarck
  14362. Network Systems Engineer
  14363. Petrel Communications SA / SPAN
  14364. Tel : +41 22 304 47 47
  14365. Fax : +41 22 300 48 43
  14366. WWW : http://www.petrel.ch
  14367. e-mail : rvb@petrel.ch
  14368.  
  14369. > -----Original Message-----
  14370. > From:    James Nessen [SMTP:nessenj@directcon.net]
  14371. > Sent:    jeudi, 14. octobre 1999 01:05
  14372. > To:    usr-tc@lists.xmission.com
  14373. > Subject:    (usr-tc) snmp pri
  14374. > 
  14375. > Does anyone happen to know the oid for checking status on the pri cards on
  14376. > a arc?
  14377. > 
  14378. > Thanks!
  14379. > 
  14380. > Jim
  14381. > 
  14382. > --
  14383. > _.,+=~`^"-.,_.,+=~`^"-*.,_.,+=~'`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,
  14384. >   James Nessen                       .,.   Server Engineer/Administrator
  14385. >   Direct Connect Internet Services   .,.   Main Number:    (800) 711-9560
  14386. >   <nessenj@directcon.net>            .,.   Operations:     (530) 677-1712
  14387. >          "Linux: Because rebooting is for adding new hardware."
  14388. >    PGP fingerprint =  B9 99 1F 5D 68 27 BB 4D  7B DB 0A A2 97 35 98 AF
  14389. > _.,+=~`^"-.,_.,+=~`^"-.,_.,+=~`^"-.,_.,+*=~`^"-.,_.,+=%~`^"-.,_.,+=~`^"-.,
  14390. > 
  14391. > 
  14392. > -
  14393. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14394. >  with "unsubscribe usr-tc" in the body of the message.
  14395. >  For information on digests or retrieving files and old messages send
  14396. >  "help" to the same address.  Do not use quotes in your message.
  14397.  
  14398. -
  14399.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14400.  with "unsubscribe usr-tc" in the body of the message.
  14401.  For information on digests or retrieving files and old messages send
  14402.  "help" to the same address.  Do not use quotes in your message.
  14403.  
  14404.  
  14405. -------------------------------------------------------------------------------
  14406.  
  14407. From: Jeff Mcadams <jeffm@iglou.com>
  14408. Subject: (usr-tc) Ah...what the heck...
  14409. Date: 14 Oct 1999 14:50:26 -0400
  14410.  
  14411. *grab stick, stir some more*  ;)
  14412.  
  14413. Well...just got a response back from the individual within 3Com that I
  14414. reported the latest SNMP security bug to...his response to my request
  14415. for a status report?  Call tech support and give them your contract
  14416. number to ask about it.  Ayiyi!
  14417.  
  14418. So...here we go...the latest, greatest way to screw up your competitor's
  14419. Total Control gear.  ;)
  14420.  
  14421. As most of you are, no doubt, aware from previous discussions on the
  14422. list, and indeed, from my previous SNMP security bug report, the NMC
  14423. card is capable of acting as a "relay" agent for other cards in the
  14424. chassis.  Basically, you send your SNMP request to the NMC card, with
  14425. the NMC's community string, with "@xxxx" appended on the end of the
  14426. community string (xxxx is the entity number for the card, 16000 for the
  14427. card in slot 16, 5000 for the card in slot 5, etc.).
  14428.  
  14429. Here's the trick though...the NMC doesn't check the access of the
  14430. community string that its sent if its relay'ed.  It checks to make sure
  14431. that the community string *exists*, but not what its access level is.
  14432. So...you send the NMC's read-only community string to the NMC, with the
  14433. relay information attached to send it on to the Arc with an SNMP set
  14434. operation.  The set is taken without complaint.
  14435.  
  14436. So...if you have the read-only community string for the NMC, you can
  14437. make whatever changes you want in to other SNMP capable card in the rack
  14438. (note, you can't muck with DSP's or quads or anything like that as they
  14439. don't actually do SNMP, they use the NMC's agent directly, but Arc's,
  14440. and any other gateway type card...basically anything that runs the
  14441. Pilgrim code base...is able to be set).
  14442.  
  14443. Unfortunately, the NMC doesn't have any (that I could find) internal
  14444. access controls on where it will accept SNMP ops from, so about the only
  14445. thing I can say is filter on the next-hop, and make sure *all* of your
  14446. community strings are secret.
  14447. -- 
  14448. Jeff McAdams                            Email: jeffm@iglou.com
  14449. Head Network Administrator              Voice: (502) 966-3848
  14450. IgLou Internet Services                        (800) 436-4456
  14451.  
  14452. -
  14453.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14454.  with "unsubscribe usr-tc" in the body of the message.
  14455.  For information on digests or retrieving files and old messages send
  14456.  "help" to the same address.  Do not use quotes in your message.
  14457.  
  14458.  
  14459. -------------------------------------------------------------------------------
  14460.  
  14461. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  14462. Subject: Re: (usr-tc) Ah...what the heck...
  14463. Date: 14 Oct 1999 14:25:01 -0500
  14464.  
  14465.  
  14466.  
  14467. The NMC DOES have an Authorized Stations list, in which you can limit snmp
  14468. access to a given set of ip addresses.  It would be probably be a good idea to
  14469. use it.  WIthin TCM its uner Security | Authorized Stations.
  14470.  
  14471. STeve
  14472.  
  14473.  
  14474.  
  14475.  
  14476. Jeff Mcadams <jeffm@iglou.com> on 10/14/99 01:50:26 PM
  14477.  
  14478. Please respond to usr-tc@lists.xmission.com
  14479.  
  14480. Sent by:  Jeff Mcadams <jeffm@iglou.com>
  14481.  
  14482.  
  14483. cc:    (Steve Valiunas/MW/US/3Com)
  14484.  
  14485.  
  14486.  
  14487.  
  14488. *grab stick, stir some more*  ;)
  14489.  
  14490. Well...just got a response back from the individual within 3Com that I
  14491. reported the latest SNMP security bug to...his response to my request
  14492. for a status report?  Call tech support and give them your contract
  14493. number to ask about it.  Ayiyi!
  14494.  
  14495. So...here we go...the latest, greatest way to screw up your competitor's
  14496. Total Control gear.  ;)
  14497.  
  14498. As most of you are, no doubt, aware from previous discussions on the
  14499. list, and indeed, from my previous SNMP security bug report, the NMC
  14500. card is capable of acting as a "relay" agent for other cards in the
  14501. chassis.  Basically, you send your SNMP request to the NMC card, with
  14502. the NMC's community string, with "@xxxx" appended on the end of the
  14503. community string (xxxx is the entity number for the card, 16000 for the
  14504. card in slot 16, 5000 for the card in slot 5, etc.).
  14505.  
  14506. Here's the trick though...the NMC doesn't check the access of the
  14507. community string that its sent if its relay'ed.  It checks to make sure
  14508. that the community string *exists*, but not what its access level is.
  14509. So...you send the NMC's read-only community string to the NMC, with the
  14510. relay information attached to send it on to the Arc with an SNMP set
  14511. operation.  The set is taken without complaint.
  14512.  
  14513. So...if you have the read-only community string for the NMC, you can
  14514. make whatever changes you want in to other SNMP capable card in the rack
  14515. (note, you can't muck with DSP's or quads or anything like that as they
  14516. don't actually do SNMP, they use the NMC's agent directly, but Arc's,
  14517. and any other gateway type card...basically anything that runs the
  14518. Pilgrim code base...is able to be set).
  14519.  
  14520. Unfortunately, the NMC doesn't have any (that I could find) internal
  14521. access controls on where it will accept SNMP ops from, so about the only
  14522. thing I can say is filter on the next-hop, and make sure *all* of your
  14523. community strings are secret.
  14524. --
  14525. Jeff McAdams                            Email: jeffm@iglou.com
  14526. Head Network Administrator              Voice: (502) 966-3848
  14527. IgLou Internet Services                        (800) 436-4456
  14528.  
  14529. -
  14530.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14531.  with "unsubscribe usr-tc" in the body of the message.
  14532.  For information on digests or retrieving files and old messages send
  14533.  "help" to the same address.  Do not use quotes in your message.
  14534.  
  14535.  
  14536.  
  14537.  
  14538.  
  14539.  
  14540. -
  14541.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14542.  with "unsubscribe usr-tc" in the body of the message.
  14543.  For information on digests or retrieving files and old messages send
  14544.  "help" to the same address.  Do not use quotes in your message.
  14545.  
  14546.  
  14547. -------------------------------------------------------------------------------
  14548.  
  14549. From: Jeff Mcadams <jeffm@iglou.com>
  14550. Subject: Re: (usr-tc) Ah...what the heck...
  14551. Date: 14 Oct 1999 16:01:29 -0400
  14552.  
  14553. Thus spake Steve Valiunas
  14554. >The NMC DOES have an Authorized Stations list, in which you can limit snmp
  14555. >access to a given set of ip addresses.  It would be probably be a good idea to
  14556. >use it.  WIthin TCM its uner Security | Authorized Stations.
  14557.  
  14558. Hrmm...learn something new every day...
  14559.  
  14560. Was looking through the MIB for it and didn't see any reference to
  14561. it...did find it though.
  14562.  
  14563. nmcAuthAccTable is the table that controls it apparently...
  14564.  
  14565. An nmcAuthAccEntry consists of nmcAuthAccIpAddr, nmcAuthAccNetMask, and
  14566. nmcAuthAccDescr; with the obvious values for each.  (For the rest of you
  14567. who don't use TCM ;)
  14568. -- 
  14569. Jeff McAdams                            Email: jeffm@iglou.com
  14570. Head Network Administrator              Voice: (502) 966-3848
  14571. IgLou Internet Services                        (800) 436-4456
  14572.  
  14573. -
  14574.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14575.  with "unsubscribe usr-tc" in the body of the message.
  14576.  For information on digests or retrieving files and old messages send
  14577.  "help" to the same address.  Do not use quotes in your message.
  14578.  
  14579.  
  14580. -------------------------------------------------------------------------------
  14581.  
  14582. From: mmm3@cornell.edu
  14583. Subject: Re: (usr-tc) Ah...what the heck...
  14584. Date: 14 Oct 1999 17:00:34 -0400
  14585.  
  14586. >The NMC DOES have an Authorized Stations list, in which you can limit snmp
  14587. >access to a given set of ip addresses.  It would be probably be a good idea to
  14588. >use it.  WIthin TCM its uner Security | Authorized Stations.
  14589. >
  14590. >STeve
  14591.  
  14592. Is it possible to restrict access to a subnet or subnets such that any
  14593. machine on that subnet can access TCM?
  14594.  
  14595. *********************************************************
  14596. Michelle M. Mogil
  14597. Network and Computing Systems
  14598. 721 Rhodes Hall, Cornell University, Ithaca, NY 14853
  14599. vox: (607) 255-0516, fax: (607) 255-8420
  14600. email: mmm3@cornell.edu
  14601. **********************************************
  14602.  
  14603.  
  14604.  
  14605. -
  14606.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14607.  with "unsubscribe usr-tc" in the body of the message.
  14608.  For information on digests or retrieving files and old messages send
  14609.  "help" to the same address.  Do not use quotes in your message.
  14610.  
  14611.  
  14612. -------------------------------------------------------------------------------
  14613.  
  14614. From: Mike McHenry <mmchen@minn.net>
  14615. Subject: (usr-tc) Default routes disappearing
  14616. Date: 14 Oct 1999 19:20:37 -0500 (CDT)
  14617.  
  14618.  
  14619.  
  14620. For the last several days I have been having a problem with my default
  14621. route just disappearing from my HARC card. This card has been running
  14622. 4.2.32-1 for several weeks now without too many problems.
  14623.  
  14624. Several times a day my default route just disappears. I have manually
  14625. specified a default route on each HARC using set ip default_route gateway
  14626. 192.168.0.1
  14627.  
  14628. This problem is EXTREMELY annoying as it is happening to all of my USR
  14629. chassis. The only way to recover from it is a complete reboot of the HARC
  14630. card. If I try to manually add the default route back to the HARC I get
  14631. the error message that the network is not directly connected. (Which it
  14632. is...)
  14633.  
  14634. Has anyone else run into this or do I chalk it up as yet another bug? The
  14635. chassis is otherwise normal, all the routes are still shown if I do a show
  14636. ip routes EXCEPT the default route! This is getting extremely frustrating
  14637. for me, I have at least one serious problem with my USR TC chassis every
  14638. couple of months and I am really getting tired of it. Any suggestions
  14639. would be appreciated, thanks!
  14640.  
  14641. Mike McHenry
  14642.  Systems Administrator
  14643.  MinnNet Communications, Inc. 
  14644.  
  14645.  
  14646. -
  14647.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14648.  with "unsubscribe usr-tc" in the body of the message.
  14649.  For information on digests or retrieving files and old messages send
  14650.  "help" to the same address.  Do not use quotes in your message.
  14651.  
  14652.  
  14653. -------------------------------------------------------------------------------
  14654.  
  14655. From: "Sheldon Koehler" <sheldon@tenforward.com>
  14656. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  14657. Date: 14 Oct 1999 18:46:58 -0700
  14658.  
  14659. Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  14660. booth over to the Cisco booth and see if 3Com notices then...
  14661.  
  14662. ----- Original Message -----
  14663. Sent: Wednesday, October 13, 1999 8:50 PM
  14664.  
  14665.  
  14666. >
  14667. > I had the same shit happen.  She couldn't get it thru her head that we had
  14668. > SOLD half the stuff they had us listed down for.  We SOLD it because it
  14669. > was quad modem technology and its a good thing too, because we would be
  14670. > screwed had we not sold, and 3com doesn't make a support contract to fix
  14671. > you if you got a quad chassis.......not good enough anyways, its all
  14672. > EOL'ed.
  14673. >
  14674. > It took I want to say 18+ months of negotiations between our 3com rep, us,
  14675. > and 3com support contract people.  To this day we have not been able to
  14676. > get contracts because we can't come to an agreement on how the stuff
  14677. > should be priced.
  14678. >
  14679. >
  14680. > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  14681. >
  14682. > >
  14683. > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  14684. > >
  14685. > > > Unless I am mistaken they do offer software only contracts.  I've seen
  14686. > > > them on Tech Data's price listing.  They are generally less than half
  14687. of
  14688. > > > the full service contracts.
  14689. > >
  14690. > > They are still pricey.  And on top of the price, we started getting
  14691. > > harrassing phone calls from some lackey in the 'service contract'
  14692. > > department saying:
  14693. > >
  14694. > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  14695. > >
  14696. > > -me: "Yes.  That's why I bought X contracts."
  14697. > >
  14698. > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  14699. > >
  14700. > > -me: "Yes."
  14701. > >
  14702. > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  14703. > >
  14704. > > -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  14705. > > crap off."
  14706. > >
  14707. > > I didn't even buy direct from 3Com, but via a reseller.  They apparently
  14708. > > have the time and money to put losers like this on the phone to harass
  14709. > > customers about the number of contracts they have versus the number of
  14710. > > chassis they've purchased in the last 3 years.  What a waste.  What
  14711. > > arrogance.
  14712. > >
  14713. > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  14714. > > routers that cost LESS than putting full support with no
  14715. > > "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  14716. > > numerous Cisco employees; support, sales, engineering that they let
  14717. people
  14718. > > slide on most support/software issues.  They frown on 'version jumping'
  14719. > > where you go and thieve say IOS w/Firewall support when you bought basic
  14720. > > IP, but I've had so many instances where I've received support/software
  14721. on
  14722. > > equipment with no contract.  I've even told the guy on the phone "I have
  14723. > > no contract" and the basic response is "We want you to be happy.  Your
  14724. > > hardware fried?  We'll send you new...  You need IOS 12.x to fix this
  14725. bug?
  14726. > > Here it is."
  14727. > >
  14728. > > Why can't 3Com adopt at least some of this attitude?  It's not like
  14729. > > Pilgrim is feature-packed like IOS, we're all just looking for solid
  14730. > > connects and standard routing features...
  14731. > >
  14732. > > Charles
  14733. > >
  14734. > > > Jeff Binkley
  14735. > > > ASA Network Computing
  14736. > > >
  14737. > > >
  14738. > > > U>I think Brian is on the right track here. Perhaps 3COM can split
  14739. their
  14740. > > > U>service contracts into 2 categories - firmware download only, and
  14741. full
  14742. > > > U>support with download and telephone support.
  14743. > > >
  14744. > > > U>Those of us new to the platform (myself included) might benefit from
  14745. > > > U>the convenience of knowing that phone support is available 24x7 when
  14746. > > > U>you're staring at a box not taking calls at 2AM. But once you get
  14747. the
  14748. > > > U>hang of TC and know how to troubleshoot these things on your own (or
  14749. > > > U>at least with the added help of those on this list), you can drop
  14750. the
  14751. > > > U>tel support, and just pay for code updates.
  14752. > > >
  14753. > > > U>Does any of this matter to those on this list that are complaining
  14754. > > > U>about 3COM's lack of timely response to code issues? Probably not.
  14755. > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  14756. > > > U>Should they perhaps head-up a small team (1 person) to field code
  14757. > > > U>enhancement and bug fix requests, both from an email/web input area
  14758. on
  14759. > > > U>the 3COM ISP pages, but also through monitoring of this list and the
  14760. > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  14761. > > > U>"behind the scenes", quietly tracking and logging this stuff, but
  14762. it's
  14763. > > > U>apparent that the people who need to know the most that it's being
  14764. > > > U>done and being worked on, the ISP customers, don't know that someone
  14765. > > > U>has acknowledged the problem and it has been placed into an
  14766. > > > U>engineering queue.
  14767. > > >
  14768. > > > U>I think that things like this would greatly improve 3COM's image
  14769. among
  14770. > > > U>it's ISP customers, and even more so if they acted expediently on
  14771. > > > U>these issues that trouble so many on this list. Give the telephone
  14772. > > > U>support staff access to the database created as a result of these
  14773. > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  14774. > > > U>contract). Tie the ER/SR releases to the database, so it's easier to
  14775. > > > U>identify which bug is fixed with which release. And most
  14776. importantly,
  14777. > > > U>of allowing us to view this database to obtain the status a
  14778. confirmed
  14779. > > > U>of bug and it's up-to-date progress in getting resolved would be
  14780. > > > U>tremendous benefit. To know that someone is actually WORKING on
  14781. Jeff's
  14782. > > > U>SNMP issue by simply searching the database is comforting (knowing
  14783. > > > that
  14784. > > > U>it will be fixed QUICKLY is even better). Some of this status
  14785. > > > U>information may already be in the 3KB, but a dedicated database for
  14786. TC
  14787. > > > U>code issues and status reports would be really great.
  14788. > > >
  14789. > > > U>Scot
  14790. > > > U>NJAccess
  14791. > > >
  14792. > > > CMPQwk 1.42 9999
  14793. > > >
  14794. > > > -
  14795. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14796. > > >  with "unsubscribe usr-tc" in the body of the message.
  14797. > > >  For information on digests or retrieving files and old messages send
  14798. > > >  "help" to the same address.  Do not use quotes in your message.
  14799. > > >
  14800. > >
  14801. > >
  14802. > > -
  14803. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14804. > >  with "unsubscribe usr-tc" in the body of the message.
  14805. > >  For information on digests or retrieving files and old messages send
  14806. > >  "help" to the same address.  Do not use quotes in your message.
  14807. > >
  14808. >
  14809. > -----------------------------------------------------
  14810. > Brian Feeny (BF304)     signal@shreve.net
  14811. > 318-222-2638 x 109 http://www.shreve.net/~signal
  14812. > Network Administrator   ShreveNet Inc. (ASN 11881)
  14813. >
  14814. >
  14815. > -
  14816. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14817. >  with "unsubscribe usr-tc" in the body of the message.
  14818. >  For information on digests or retrieving files and old messages send
  14819. >  "help" to the same address.  Do not use quotes in your message.
  14820. >
  14821.  
  14822.  
  14823. -
  14824.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14825.  with "unsubscribe usr-tc" in the body of the message.
  14826.  For information on digests or retrieving files and old messages send
  14827.  "help" to the same address.  Do not use quotes in your message.
  14828.  
  14829.  
  14830. -------------------------------------------------------------------------------
  14831.  
  14832. From: "Ed" <ed@taylors.com>
  14833. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  14834. Date: 14 Oct 1999 22:04:21 -0400
  14835.  
  14836. Sounds like a Great Idea!
  14837.  
  14838.  
  14839. Ed
  14840.  
  14841. ----- Original Message -----
  14842. Sent: Thursday, October 14, 1999 9:46 PM
  14843.  
  14844.  
  14845. Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  14846. booth over to the Cisco booth and see if 3Com notices then...
  14847.  
  14848. ----- Original Message -----
  14849. Sent: Wednesday, October 13, 1999 8:50 PM
  14850.  
  14851.  
  14852. >
  14853. > I had the same shit happen.  She couldn't get it thru her head that we had
  14854. > SOLD half the stuff they had us listed down for.  We SOLD it because it
  14855. > was quad modem technology and its a good thing too, because we would be
  14856. > screwed had we not sold, and 3com doesn't make a support contract to fix
  14857. > you if you got a quad chassis.......not good enough anyways, its all
  14858. > EOL'ed.
  14859. >
  14860. > It took I want to say 18+ months of negotiations between our 3com rep, us,
  14861. > and 3com support contract people.  To this day we have not been able to
  14862. > get contracts because we can't come to an agreement on how the stuff
  14863. > should be priced.
  14864. >
  14865. >
  14866. > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  14867. >
  14868. > >
  14869. > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  14870. > >
  14871. > > > Unless I am mistaken they do offer software only contracts.  I've seen
  14872. > > > them on Tech Data's price listing.  They are generally less than half
  14873. of
  14874. > > > the full service contracts.
  14875. > >
  14876. > > They are still pricey.  And on top of the price, we started getting
  14877. > > harrassing phone calls from some lackey in the 'service contract'
  14878. > > department saying:
  14879. > >
  14880. > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  14881. > >
  14882. > > -me: "Yes.  That's why I bought X contracts."
  14883. > >
  14884. > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  14885. > >
  14886. > > -me: "Yes."
  14887. > >
  14888. > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  14889. > >
  14890. > > -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  14891. > > crap off."
  14892. > >
  14893. > > I didn't even buy direct from 3Com, but via a reseller.  They apparently
  14894. > > have the time and money to put losers like this on the phone to harass
  14895. > > customers about the number of contracts they have versus the number of
  14896. > > chassis they've purchased in the last 3 years.  What a waste.  What
  14897. > > arrogance.
  14898. > >
  14899. > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  14900. > > routers that cost LESS than putting full support with no
  14901. > > "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  14902. > > numerous Cisco employees; support, sales, engineering that they let
  14903. people
  14904. > > slide on most support/software issues.  They frown on 'version jumping'
  14905. > > where you go and thieve say IOS w/Firewall support when you bought basic
  14906. > > IP, but I've had so many instances where I've received support/software
  14907. on
  14908. > > equipment with no contract.  I've even told the guy on the phone "I have
  14909. > > no contract" and the basic response is "We want you to be happy.  Your
  14910. > > hardware fried?  We'll send you new...  You need IOS 12.x to fix this
  14911. bug?
  14912. > > Here it is."
  14913. > >
  14914. > > Why can't 3Com adopt at least some of this attitude?  It's not like
  14915. > > Pilgrim is feature-packed like IOS, we're all just looking for solid
  14916. > > connects and standard routing features...
  14917. > >
  14918. > > Charles
  14919. > >
  14920. > > > Jeff Binkley
  14921. > > > ASA Network Computing
  14922. > > >
  14923. > > >
  14924. > > > U>I think Brian is on the right track here. Perhaps 3COM can split
  14925. their
  14926. > > > U>service contracts into 2 categories - firmware download only, and
  14927. full
  14928. > > > U>support with download and telephone support.
  14929. > > >
  14930. > > > U>Those of us new to the platform (myself included) might benefit from
  14931. > > > U>the convenience of knowing that phone support is available 24x7 when
  14932. > > > U>you're staring at a box not taking calls at 2AM. But once you get
  14933. the
  14934. > > > U>hang of TC and know how to troubleshoot these things on your own (or
  14935. > > > U>at least with the added help of those on this list), you can drop
  14936. the
  14937. > > > U>tel support, and just pay for code updates.
  14938. > > >
  14939. > > > U>Does any of this matter to those on this list that are complaining
  14940. > > > U>about 3COM's lack of timely response to code issues? Probably not.
  14941. > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  14942. > > > U>Should they perhaps head-up a small team (1 person) to field code
  14943. > > > U>enhancement and bug fix requests, both from an email/web input area
  14944. on
  14945. > > > U>the 3COM ISP pages, but also through monitoring of this list and the
  14946. > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  14947. > > > U>"behind the scenes", quietly tracking and logging this stuff, but
  14948. it's
  14949. > > > U>apparent that the people who need to know the most that it's being
  14950. > > > U>done and being worked on, the ISP customers, don't know that someone
  14951. > > > U>has acknowledged the problem and it has been placed into an
  14952. > > > U>engineering queue.
  14953. > > >
  14954. > > > U>I think that things like this would greatly improve 3COM's image
  14955. among
  14956. > > > U>it's ISP customers, and even more so if they acted expediently on
  14957. > > > U>these issues that trouble so many on this list. Give the telephone
  14958. > > > U>support staff access to the database created as a result of these
  14959. > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  14960. > > > U>contract). Tie the ER/SR releases to the database, so it's easier to
  14961. > > > U>identify which bug is fixed with which release. And most
  14962. importantly,
  14963. > > > U>of allowing us to view this database to obtain the status a
  14964. confirmed
  14965. > > > U>of bug and it's up-to-date progress in getting resolved would be
  14966. > > > U>tremendous benefit. To know that someone is actually WORKING on
  14967. Jeff's
  14968. > > > U>SNMP issue by simply searching the database is comforting (knowing
  14969. > > > that
  14970. > > > U>it will be fixed QUICKLY is even better). Some of this status
  14971. > > > U>information may already be in the 3KB, but a dedicated database for
  14972. TC
  14973. > > > U>code issues and status reports would be really great.
  14974. > > >
  14975. > > > U>Scot
  14976. > > > U>NJAccess
  14977. > > >
  14978. > > > CMPQwk 1.42 9999
  14979. > > >
  14980. > > > -
  14981. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14982. > > >  with "unsubscribe usr-tc" in the body of the message.
  14983. > > >  For information on digests or retrieving files and old messages send
  14984. > > >  "help" to the same address.  Do not use quotes in your message.
  14985. > > >
  14986. > >
  14987. > >
  14988. > > -
  14989. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14990. > >  with "unsubscribe usr-tc" in the body of the message.
  14991. > >  For information on digests or retrieving files and old messages send
  14992. > >  "help" to the same address.  Do not use quotes in your message.
  14993. > >
  14994. >
  14995. > -----------------------------------------------------
  14996. > Brian Feeny (BF304)     signal@shreve.net
  14997. > 318-222-2638 x 109 http://www.shreve.net/~signal
  14998. > Network Administrator   ShreveNet Inc. (ASN 11881)
  14999. >
  15000. >
  15001. > -
  15002. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15003. >  with "unsubscribe usr-tc" in the body of the message.
  15004. >  For information on digests or retrieving files and old messages send
  15005. >  "help" to the same address.  Do not use quotes in your message.
  15006. >
  15007.  
  15008.  
  15009. -
  15010.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15011.  with "unsubscribe usr-tc" in the body of the message.
  15012.  For information on digests or retrieving files and old messages send
  15013.  "help" to the same address.  Do not use quotes in your message.
  15014.  
  15015.  
  15016.  
  15017. -
  15018.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15019.  with "unsubscribe usr-tc" in the body of the message.
  15020.  For information on digests or retrieving files and old messages send
  15021.  "help" to the same address.  Do not use quotes in your message.
  15022.  
  15023.  
  15024. -------------------------------------------------------------------------------
  15025.  
  15026. From: Rick <rickyz@mindspring.com>
  15027. Subject: (usr-tc) NMC daughter board ID...
  15028. Date: 14 Oct 1999 22:21:06 -0400
  15029.  
  15030. Hi,
  15031. Does anyone one know the purpose of the big green daughter board that is on 
  15032. most all crrent NMC's? The reason I ask is that we found and older NMC, and 
  15033. this one does not have the board on it. What is it, and what does it do?
  15034.  
  15035. Thanks in advance,
  15036. Rick
  15037.  
  15038.  
  15039. -
  15040.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15041.  with "unsubscribe usr-tc" in the body of the message.
  15042.  For information on digests or retrieving files and old messages send
  15043.  "help" to the same address.  Do not use quotes in your message.
  15044.  
  15045.  
  15046. -------------------------------------------------------------------------------
  15047.  
  15048. From: Richard Lorbieski <richard@alpha1.net>
  15049. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  15050. Date: 14 Oct 1999 21:40:44 -0500
  15051.  
  15052. Sorry, but only people with service contracts can visit the 3Com booth.
  15053.  
  15054. Sheldon Koehler wrote:
  15055. > 
  15056. > Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  15057. > booth over to the Cisco booth and see if 3Com notices then...
  15058. > 
  15059. > ----- Original Message -----
  15060. > From: Brian <signal@shreve.net>
  15061. > To: <usr-tc@lists.xmission.com>
  15062. > Sent: Wednesday, October 13, 1999 8:50 PM
  15063. > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  15064. > 
  15065. > >
  15066. > > I had the same shit happen.  She couldn't get it thru her head that we had
  15067. > > SOLD half the stuff they had us listed down for.  We SOLD it because it
  15068. > > was quad modem technology and its a good thing too, because we would be
  15069. > > screwed had we not sold, and 3com doesn't make a support contract to fix
  15070. > > you if you got a quad chassis.......not good enough anyways, its all
  15071. > > EOL'ed.
  15072. > >
  15073. > > It took I want to say 18+ months of negotiations between our 3com rep, us,
  15074. > > and 3com support contract people.  To this day we have not been able to
  15075. > > get contracts because we can't come to an agreement on how the stuff
  15076. > > should be priced.
  15077. > >
  15078. > >
  15079. > > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  15080. > >
  15081. > > >
  15082. > > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  15083. > > >
  15084. > > > > Unless I am mistaken they do offer software only contracts.  I've seen
  15085. > > > > them on Tech Data's price listing.  They are generally less than half
  15086. > of
  15087. > > > > the full service contracts.
  15088. > > >
  15089. > > > They are still pricey.  And on top of the price, we started getting
  15090. > > > harrassing phone calls from some lackey in the 'service contract'
  15091. > > > department saying:
  15092. > > >
  15093. > > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  15094. > > >
  15095. > > > -me: "Yes.  That's why I bought X contracts."
  15096. > > >
  15097. > > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  15098. > > >
  15099. > > > -me: "Yes."
  15100. > > >
  15101. > > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  15102. > > >
  15103. > > > -me: "Tell you what.  Put me down for one, I'm selling the rest of this
  15104. > > > crap off."
  15105. > > >
  15106. > > > I didn't even buy direct from 3Com, but via a reseller.  They apparently
  15107. > > > have the time and money to put losers like this on the phone to harass
  15108. > > > customers about the number of contracts they have versus the number of
  15109. > > > chassis they've purchased in the last 3 years.  What a waste.  What
  15110. > > > arrogance.
  15111. > > >
  15112. > > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  15113. > > > routers that cost LESS than putting full support with no
  15114. > > > "spare-in-the-air" support on all our TCH stuff.  And I've been told by
  15115. > > > numerous Cisco employees; support, sales, engineering that they let
  15116. > people
  15117. > > > slide on most support/software issues.  They frown on 'version jumping'
  15118. > > > where you go and thieve say IOS w/Firewall support when you bought basic
  15119. > > > IP, but I've had so many instances where I've received support/software
  15120. > on
  15121. > > > equipment with no contract.  I've even told the guy on the phone "I have
  15122. > > > no contract" and the basic response is "We want you to be happy.  Your
  15123. > > > hardware fried?  We'll send you new...  You need IOS 12.x to fix this
  15124. > bug?
  15125. > > > Here it is."
  15126. > > >
  15127. > > > Why can't 3Com adopt at least some of this attitude?  It's not like
  15128. > > > Pilgrim is feature-packed like IOS, we're all just looking for solid
  15129. > > > connects and standard routing features...
  15130. > > >
  15131. > > > Charles
  15132. > > >
  15133. > > > > Jeff Binkley
  15134. > > > > ASA Network Computing
  15135. > > > >
  15136. > > > >
  15137. > > > > U>I think Brian is on the right track here. Perhaps 3COM can split
  15138. > their
  15139. > > > > U>service contracts into 2 categories - firmware download only, and
  15140. > full
  15141. > > > > U>support with download and telephone support.
  15142. > > > >
  15143. > > > > U>Those of us new to the platform (myself included) might benefit from
  15144. > > > > U>the convenience of knowing that phone support is available 24x7 when
  15145. > > > > U>you're staring at a box not taking calls at 2AM. But once you get
  15146. > the
  15147. > > > > U>hang of TC and know how to troubleshoot these things on your own (or
  15148. > > > > U>at least with the added help of those on this list), you can drop
  15149. > the
  15150. > > > > U>tel support, and just pay for code updates.
  15151. > > > >
  15152. > > > > U>Does any of this matter to those on this list that are complaining
  15153. > > > > U>about 3COM's lack of timely response to code issues? Probably not.
  15154. > > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  15155. > > > > U>Should they perhaps head-up a small team (1 person) to field code
  15156. > > > > U>enhancement and bug fix requests, both from an email/web input area
  15157. > on
  15158. > > > > U>the 3COM ISP pages, but also through monitoring of this list and the
  15159. > > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  15160. > > > > U>"behind the scenes", quietly tracking and logging this stuff, but
  15161. > it's
  15162. > > > > U>apparent that the people who need to know the most that it's being
  15163. > > > > U>done and being worked on, the ISP customers, don't know that someone
  15164. > > > > U>has acknowledged the problem and it has been placed into an
  15165. > > > > U>engineering queue.
  15166. > > > >
  15167. > > > > U>I think that things like this would greatly improve 3COM's image
  15168. > among
  15169. > > > > U>it's ISP customers, and even more so if they acted expediently on
  15170. > > > > U>these issues that trouble so many on this list. Give the telephone
  15171. > > > > U>support staff access to the database created as a result of these
  15172. > > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  15173. > > > > U>contract). Tie the ER/SR releases to the database, so it's easier to
  15174. > > > > U>identify which bug is fixed with which release. And most
  15175. > importantly,
  15176. > > > > U>of allowing us to view this database to obtain the status a
  15177. > confirmed
  15178. > > > > U>of bug and it's up-to-date progress in getting resolved would be
  15179. > > > > U>tremendous benefit. To know that someone is actually WORKING on
  15180. > Jeff's
  15181. > > > > U>SNMP issue by simply searching the database is comforting (knowing
  15182. > > > > that
  15183. > > > > U>it will be fixed QUICKLY is even better). Some of this status
  15184. > > > > U>information may already be in the 3KB, but a dedicated database for
  15185. > TC
  15186. > > > > U>code issues and status reports would be really great.
  15187. > > > >
  15188. > > > > U>Scot
  15189. > > > > U>NJAccess
  15190. > > > >
  15191. > > > > CMPQwk 1.42 9999
  15192. > > > >
  15193. > > > > -
  15194. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15195. > > > >  with "unsubscribe usr-tc" in the body of the message.
  15196. > > > >  For information on digests or retrieving files and old messages send
  15197. > > > >  "help" to the same address.  Do not use quotes in your message.
  15198. > > > >
  15199. > > >
  15200. > > >
  15201. > > > -
  15202. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15203. > > >  with "unsubscribe usr-tc" in the body of the message.
  15204. > > >  For information on digests or retrieving files and old messages send
  15205. > > >  "help" to the same address.  Do not use quotes in your message.
  15206. > > >
  15207. > >
  15208. > > -----------------------------------------------------
  15209. > > Brian Feeny (BF304)     signal@shreve.net
  15210. > > 318-222-2638 x 109 http://www.shreve.net/~signal
  15211. > > Network Administrator   ShreveNet Inc. (ASN 11881)
  15212. > >
  15213. > >
  15214. > > -
  15215. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15216. > >  with "unsubscribe usr-tc" in the body of the message.
  15217. > >  For information on digests or retrieving files and old messages send
  15218. > >  "help" to the same address.  Do not use quotes in your message.
  15219. > >
  15220. > 
  15221. > -
  15222. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15223. >  with "unsubscribe usr-tc" in the body of the message.
  15224. >  For information on digests or retrieving files and old messages send
  15225. >  "help" to the same address.  Do not use quotes in your message.
  15226.  
  15227. -- 
  15228.  
  15229. Richard Lorbieski - richard@alpha1.net
  15230. Chief Technical Officer - Senior System Administrator
  15231. Alpha1 Internet  http://www.alpha1.net
  15232. 409.731.8236  - 877.4.alpha1 (877.425.7421)
  15233.  
  15234. -
  15235.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15236.  with "unsubscribe usr-tc" in the body of the message.
  15237.  For information on digests or retrieving files and old messages send
  15238.  "help" to the same address.  Do not use quotes in your message.
  15239.  
  15240.  
  15241. -------------------------------------------------------------------------------
  15242.  
  15243. From: "Ed" <ed@taylors.com>
  15244. Subject: (usr-tc) 3com Support Woes
  15245. Date: 14 Oct 1999 23:03:17 -0400
  15246.  
  15247. I cannot believe how many people keep coming out of the woodwork that feel
  15248. the same way about 3com's support issues. Seems like everyone is disgruntled
  15249. about it. When you speak to 3com they tell you people are happy and like the
  15250. changes being made and you are the only one complaining. What a smoke
  15251. screen.
  15252.  
  15253. I believe 3com Executives and Stockholders should actually read this list
  15254. sometime...
  15255.  
  15256.  
  15257. Ed
  15258.  
  15259. ----- Original Message -----
  15260. Sent: Thursday, October 14, 1999 10:40 PM
  15261.  
  15262.  
  15263. Sorry, but only people with service contracts can visit the 3Com booth.
  15264.  
  15265. Sheldon Koehler wrote:
  15266. >
  15267. > Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  15268. > booth over to the Cisco booth and see if 3Com notices then...
  15269. >
  15270. > ----- Original Message -----
  15271. > From: Brian <signal@shreve.net>
  15272. > To: <usr-tc@lists.xmission.com>
  15273. > Sent: Wednesday, October 13, 1999 8:50 PM
  15274. > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  15275. >
  15276. > >
  15277. > > I had the same shit happen.  She couldn't get it thru her head that we
  15278. had
  15279. > > SOLD half the stuff they had us listed down for.  We SOLD it because it
  15280. > > was quad modem technology and its a good thing too, because we would be
  15281. > > screwed had we not sold, and 3com doesn't make a support contract to fix
  15282. > > you if you got a quad chassis.......not good enough anyways, its all
  15283. > > EOL'ed.
  15284. > >
  15285. > > It took I want to say 18+ months of negotiations between our 3com rep,
  15286. us,
  15287. > > and 3com support contract people.  To this day we have not been able to
  15288. > > get contracts because we can't come to an agreement on how the stuff
  15289. > > should be priced.
  15290. > >
  15291. > >
  15292. > > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  15293. > >
  15294. > > >
  15295. > > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  15296. > > >
  15297. > > > > Unless I am mistaken they do offer software only contracts.  I've
  15298. seen
  15299. > > > > them on Tech Data's price listing.  They are generally less than
  15300. half
  15301. > of
  15302. > > > > the full service contracts.
  15303. > > >
  15304. > > > They are still pricey.  And on top of the price, we started getting
  15305. > > > harrassing phone calls from some lackey in the 'service contract'
  15306. > > > department saying:
  15307. > > >
  15308. > > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  15309. > > >
  15310. > > > -me: "Yes.  That's why I bought X contracts."
  15311. > > >
  15312. > > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  15313. > > >
  15314. > > > -me: "Yes."
  15315. > > >
  15316. > > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  15317. > > >
  15318. > > > -me: "Tell you what.  Put me down for one, I'm selling the rest of
  15319. this
  15320. > > > crap off."
  15321. > > >
  15322. > > > I didn't even buy direct from 3Com, but via a reseller.  They
  15323. apparently
  15324. > > > have the time and money to put losers like this on the phone to harass
  15325. > > > customers about the number of contracts they have versus the number of
  15326. > > > chassis they've purchased in the last 3 years.  What a waste.  What
  15327. > > > arrogance.
  15328. > > >
  15329. > > > I'll mention also that I have contracts (24x7x4) on our high-end Cisco
  15330. > > > routers that cost LESS than putting full support with no
  15331. > > > "spare-in-the-air" support on all our TCH stuff.  And I've been told
  15332. by
  15333. > > > numerous Cisco employees; support, sales, engineering that they let
  15334. > people
  15335. > > > slide on most support/software issues.  They frown on 'version
  15336. jumping'
  15337. > > > where you go and thieve say IOS w/Firewall support when you bought
  15338. basic
  15339. > > > IP, but I've had so many instances where I've received
  15340. support/software
  15341. > on
  15342. > > > equipment with no contract.  I've even told the guy on the phone "I
  15343. have
  15344. > > > no contract" and the basic response is "We want you to be happy.  Your
  15345. > > > hardware fried?  We'll send you new...  You need IOS 12.x to fix this
  15346. > bug?
  15347. > > > Here it is."
  15348. > > >
  15349. > > > Why can't 3Com adopt at least some of this attitude?  It's not like
  15350. > > > Pilgrim is feature-packed like IOS, we're all just looking for solid
  15351. > > > connects and standard routing features...
  15352. > > >
  15353. > > > Charles
  15354. > > >
  15355. > > > > Jeff Binkley
  15356. > > > > ASA Network Computing
  15357. > > > >
  15358. > > > >
  15359. > > > > U>I think Brian is on the right track here. Perhaps 3COM can split
  15360. > their
  15361. > > > > U>service contracts into 2 categories - firmware download only, and
  15362. > full
  15363. > > > > U>support with download and telephone support.
  15364. > > > >
  15365. > > > > U>Those of us new to the platform (myself included) might benefit
  15366. from
  15367. > > > > U>the convenience of knowing that phone support is available 24x7
  15368. when
  15369. > > > > U>you're staring at a box not taking calls at 2AM. But once you get
  15370. > the
  15371. > > > > U>hang of TC and know how to troubleshoot these things on your own
  15372. (or
  15373. > > > > U>at least with the added help of those on this list), you can drop
  15374. > the
  15375. > > > > U>tel support, and just pay for code updates.
  15376. > > > >
  15377. > > > > U>Does any of this matter to those on this list that are complaining
  15378. > > > > U>about 3COM's lack of timely response to code issues? Probably not.
  15379. > > > > U>Should 3COM redirect it's efforts to resolving these issues? Yep.
  15380. > > > > U>Should they perhaps head-up a small team (1 person) to field code
  15381. > > > > U>enhancement and bug fix requests, both from an email/web input
  15382. area
  15383. > on
  15384. > > > > U>the 3COM ISP pages, but also through monitoring of this list and
  15385. the
  15386. > > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing this
  15387. > > > > U>"behind the scenes", quietly tracking and logging this stuff, but
  15388. > it's
  15389. > > > > U>apparent that the people who need to know the most that it's being
  15390. > > > > U>done and being worked on, the ISP customers, don't know that
  15391. someone
  15392. > > > > U>has acknowledged the problem and it has been placed into an
  15393. > > > > U>engineering queue.
  15394. > > > >
  15395. > > > > U>I think that things like this would greatly improve 3COM's image
  15396. > among
  15397. > > > > U>it's ISP customers, and even more so if they acted expediently on
  15398. > > > > U>these issues that trouble so many on this list. Give the telephone
  15399. > > > > U>support staff access to the database created as a result of these
  15400. > > > > U>pages (hell, give us access to these pages as well, even WITHOUT a
  15401. > > > > U>contract). Tie the ER/SR releases to the database, so it's easier
  15402. to
  15403. > > > > U>identify which bug is fixed with which release. And most
  15404. > importantly,
  15405. > > > > U>of allowing us to view this database to obtain the status a
  15406. > confirmed
  15407. > > > > U>of bug and it's up-to-date progress in getting resolved would be
  15408. > > > > U>tremendous benefit. To know that someone is actually WORKING on
  15409. > Jeff's
  15410. > > > > U>SNMP issue by simply searching the database is comforting (knowing
  15411. > > > > that
  15412. > > > > U>it will be fixed QUICKLY is even better). Some of this status
  15413. > > > > U>information may already be in the 3KB, but a dedicated database
  15414. for
  15415. > TC
  15416. > > > > U>code issues and status reports would be really great.
  15417. > > > >
  15418. > > > > U>Scot
  15419. > > > > U>NJAccess
  15420. > > > >
  15421. > > > > CMPQwk 1.42 9999
  15422. > > > >
  15423. > > > > -
  15424. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15425. > > > >  with "unsubscribe usr-tc" in the body of the message.
  15426. > > > >  For information on digests or retrieving files and old messages
  15427. send
  15428. > > > >  "help" to the same address.  Do not use quotes in your message.
  15429. > > > >
  15430. > > >
  15431. > > >
  15432. > > > -
  15433. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15434. > > >  with "unsubscribe usr-tc" in the body of the message.
  15435. > > >  For information on digests or retrieving files and old messages send
  15436. > > >  "help" to the same address.  Do not use quotes in your message.
  15437. > > >
  15438. > >
  15439. > > -----------------------------------------------------
  15440. > > Brian Feeny (BF304)     signal@shreve.net
  15441. > > 318-222-2638 x 109 http://www.shreve.net/~signal
  15442. > > Network Administrator   ShreveNet Inc. (ASN 11881)
  15443. > >
  15444. > >
  15445. > > -
  15446. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15447. > >  with "unsubscribe usr-tc" in the body of the message.
  15448. > >  For information on digests or retrieving files and old messages send
  15449. > >  "help" to the same address.  Do not use quotes in your message.
  15450. > >
  15451. >
  15452. > -
  15453. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15454. >  with "unsubscribe usr-tc" in the body of the message.
  15455. >  For information on digests or retrieving files and old messages send
  15456. >  "help" to the same address.  Do not use quotes in your message.
  15457.  
  15458. --
  15459.  
  15460. Richard Lorbieski - richard@alpha1.net
  15461. Chief Technical Officer - Senior System Administrator
  15462. Alpha1 Internet  http://www.alpha1.net
  15463. 409.731.8236  - 877.4.alpha1 (877.425.7421)
  15464.  
  15465. -
  15466.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15467.  with "unsubscribe usr-tc" in the body of the message.
  15468.  For information on digests or retrieving files and old messages send
  15469.  "help" to the same address.  Do not use quotes in your message.
  15470.  
  15471.  
  15472.  
  15473. -
  15474.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15475.  with "unsubscribe usr-tc" in the body of the message.
  15476.  For information on digests or retrieving files and old messages send
  15477.  "help" to the same address.  Do not use quotes in your message.
  15478.  
  15479.  
  15480. -------------------------------------------------------------------------------
  15481.  
  15482. From: "Marshall Morgan" <marshall@netdoor.com>
  15483. Subject: (usr-tc) ISPCon/3Com Open Meeting
  15484. Date: 15 Oct 1999 01:10:20 -0500
  15485.  
  15486. Great Idea !!
  15487.  
  15488. Why don't we all have a mass (OPEN) meeting with 3com at ISPCon.  The other
  15489. vendors will send people in as well and will get plenty of ammo for their
  15490. executives that actually listen to their customer's complaints.  If 3com changes
  15491. everything that night with a big announcement (hint hint) about cost effective
  15492. hardware/technical support and software only support, then everyone, except the
  15493. snoops from other companies, will be happy!
  15494.  
  15495. A win-win for everyone if 3C want's our continued business.  Buy customer's
  15496. happiness through goodwill instead of ball parks.
  15497.  
  15498. Marshall Morgan
  15499. President
  15500.  
  15501. Internet Doorway, Inc (aka NETDOOR)
  15502. http://www.netdoor.com
  15503.  
  15504. 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  15505.  
  15506. > -----Original Message-----
  15507. > From: owner-usr-tc@lists.xmission.com
  15508. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
  15509. > Sent: Thursday, October 14, 1999 9:41 PM
  15510. > To: usr-tc@lists.xmission.com
  15511. > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  15512. >
  15513. >
  15514. > Sorry, but only people with service contracts can visit the 3Com booth.
  15515. >
  15516. > Sheldon Koehler wrote:
  15517. > >
  15518. > > Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  15519. > > booth over to the Cisco booth and see if 3Com notices then...
  15520. > >
  15521.  
  15522.  
  15523. -
  15524.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15525.  with "unsubscribe usr-tc" in the body of the message.
  15526.  For information on digests or retrieving files and old messages send
  15527.  "help" to the same address.  Do not use quotes in your message.
  15528.  
  15529.  
  15530. -------------------------------------------------------------------------------
  15531.  
  15532. From: "Ed" <ed@taylors.com>
  15533. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  15534. Date: 15 Oct 1999 03:04:43 -0400
  15535.  
  15536. Marshall wrote:
  15537. "Buy customer's happiness through goodwill instead of ball parks"
  15538.  
  15539. Thats a good one ;-)
  15540.  
  15541.  
  15542. Ed
  15543.  
  15544. ----- Original Message -----
  15545. Sent: Friday, October 15, 1999 2:10 AM
  15546.  
  15547.  
  15548. Great Idea !!
  15549.  
  15550. Why don't we all have a mass (OPEN) meeting with 3com at ISPCon.  The other
  15551. vendors will send people in as well and will get plenty of ammo for their
  15552. executives that actually listen to their customer's complaints.  If 3com
  15553. changes
  15554. everything that night with a big announcement (hint hint) about cost
  15555. effective
  15556. hardware/technical support and software only support, then everyone, except
  15557. the
  15558. snoops from other companies, will be happy!
  15559.  
  15560. A win-win for everyone if 3C want's our continued business.  Buy customer's
  15561. happiness through goodwill instead of ball parks.
  15562.  
  15563. Marshall Morgan
  15564. President
  15565.  
  15566. Internet Doorway, Inc (aka NETDOOR)
  15567. http://www.netdoor.com
  15568.  
  15569. 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  15570.  
  15571. > -----Original Message-----
  15572. > From: owner-usr-tc@lists.xmission.com
  15573. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
  15574. > Sent: Thursday, October 14, 1999 9:41 PM
  15575. > To: usr-tc@lists.xmission.com
  15576. > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  15577. >
  15578. >
  15579. > Sorry, but only people with service contracts can visit the 3Com booth.
  15580. >
  15581. > Sheldon Koehler wrote:
  15582. > >
  15583. > > Maybe we should all gang up at ISPCon and do a mass movement from the
  15584. 3Com
  15585. > > booth over to the Cisco booth and see if 3Com notices then...
  15586. > >
  15587.  
  15588.  
  15589. -
  15590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15591.  with "unsubscribe usr-tc" in the body of the message.
  15592.  For information on digests or retrieving files and old messages send
  15593.  "help" to the same address.  Do not use quotes in your message.
  15594.  
  15595.  
  15596.  
  15597. -
  15598.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15599.  with "unsubscribe usr-tc" in the body of the message.
  15600.  For information on digests or retrieving files and old messages send
  15601.  "help" to the same address.  Do not use quotes in your message.
  15602.  
  15603.  
  15604. -------------------------------------------------------------------------------
  15605.  
  15606. From: Blake Fithen <fithen@NetworksPlus.com>
  15607. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  15608. Date: 15 Oct 1999 02:34:00 -0500
  15609.  
  15610. What about "earn customers respect through display of
  15611. competence"?  The only change I've noticed in 3com's tech
  15612. support over the past year is the fact that someone from
  15613. 3Com calls me and asks me about how my tech support call
  15614. was handled.  "Do you feel the engineer was competent"? 
  15615. "Did the engineer fix the problem"?, etc...
  15616.  
  15617. Tonight I called in to 3Com tech support because I have
  15618. a problem of not remembering if channelized T1 can support
  15619. ISDN.   I had a 'feeling' that it would not but I wanted 
  15620. to get confirmation.  I asked the tech said question to 
  15621. which he replied, "yes channelized T1 will support ISDN
  15622. BRI calls, no problem."  To which I said, "are you sure?"
  15623. He went to "double-check" on this enigma and he came back
  15624. and said "no, I'm sorry, your customer cannot dial-in to
  15625. your CT1 circuit."
  15626.  
  15627. At least he double-checked.
  15628.  
  15629. The bottom line is that I think 3Com should be harshly
  15630. confronted about the quality of their tech-support and the
  15631. fact that it is not worth what they are billing customers.
  15632.  
  15633. blake
  15634.  
  15635. > -----Original Message-----
  15636. > From: Ed [mailto:ed@taylors.com]
  15637. > Sent: Friday, October 15, 1999 2:05 AM
  15638. > To: usr-tc@lists.xmission.com
  15639. > Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  15640. > 
  15641. > 
  15642. > Marshall wrote:
  15643. > "Buy customer's happiness through goodwill instead of ball parks"
  15644. > 
  15645. > Thats a good one ;-)
  15646. > 
  15647. > 
  15648. > Ed
  15649. > 
  15650. > ----- Original Message -----
  15651. > From: Marshall Morgan <marshall@netdoor.com>
  15652. > To: <usr-tc@lists.xmission.com>
  15653. > Sent: Friday, October 15, 1999 2:10 AM
  15654. > Subject: (usr-tc) ISPCon/3Com Open Meeting
  15655. > 
  15656. > 
  15657. > Great Idea !!
  15658. > 
  15659. > Why don't we all have a mass (OPEN) meeting with 3com at 
  15660. > ISPCon.  The other
  15661. > vendors will send people in as well and will get plenty of 
  15662. > ammo for their
  15663. > executives that actually listen to their customer's 
  15664. > complaints.  If 3com
  15665. > changes
  15666. > everything that night with a big announcement (hint hint) about cost
  15667. > effective
  15668. > hardware/technical support and software only support, then 
  15669. > everyone, except
  15670. > the
  15671. > snoops from other companies, will be happy!
  15672. > 
  15673. > A win-win for everyone if 3C want's our continued business.  
  15674. > Buy customer's
  15675. > happiness through goodwill instead of ball parks.
  15676. > 
  15677. > Marshall Morgan
  15678. > President
  15679. > 
  15680. > Internet Doorway, Inc (aka NETDOOR)
  15681. > http://www.netdoor.com
  15682. > 
  15683. > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 
  15684. > 601.969.3838
  15685. > 
  15686. > > -----Original Message-----
  15687. > > From: owner-usr-tc@lists.xmission.com
  15688. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of 
  15689. > Richard Lorbieski
  15690. > > Sent: Thursday, October 14, 1999 9:41 PM
  15691. > > To: usr-tc@lists.xmission.com
  15692. > > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  15693. > >
  15694. > >
  15695. > > Sorry, but only people with service contracts can visit the 
  15696. > 3Com booth.
  15697. > >
  15698. > > Sheldon Koehler wrote:
  15699. > > >
  15700. > > > Maybe we should all gang up at ISPCon and do a mass 
  15701. > movement from the
  15702. > 3Com
  15703. > > > booth over to the Cisco booth and see if 3Com notices then...
  15704. > > >
  15705. > 
  15706. > 
  15707. > -
  15708. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15709. >  with "unsubscribe usr-tc" in the body of the message.
  15710. >  For information on digests or retrieving files and old messages send
  15711. >  "help" to the same address.  Do not use quotes in your message.
  15712. > 
  15713. > 
  15714. > 
  15715. > -
  15716. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15717. >  with "unsubscribe usr-tc" in the body of the message.
  15718. >  For information on digests or retrieving files and old messages send
  15719. >  "help" to the same address.  Do not use quotes in your message.
  15720. > 
  15721.  
  15722. -
  15723.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15724.  with "unsubscribe usr-tc" in the body of the message.
  15725.  For information on digests or retrieving files and old messages send
  15726.  "help" to the same address.  Do not use quotes in your message.
  15727.  
  15728.  
  15729. -------------------------------------------------------------------------------
  15730.  
  15731. From: Robert von Bismarck <rvb@petrel.ch>
  15732. Subject: (usr-tc) BUG : add a framed route in ARC 4.1.59-6
  15733. Date: 15 Oct 1999 12:41:08 +0200
  15734.  
  15735. Hello,
  15736.  
  15737. I seem to have a problem adding a framed route to user on an ARC (not
  15738. through RADIUS)
  15739.  
  15740. Here's what I do:
  15741.  
  15742. HiPer > add user test password xxxx network_service PPP type network =
  15743. enabled
  15744. yes
  15745. HiPer > set network user test ip remote_address 123.123.123.1/H
  15746. HiPer > add framed_route user test ip_route 123.123.124.0/C gateway
  15747. 123.123.123.1 metric 1
  15748. CLI - Network Name: =B0@
  15749.     could not be resolved
  15750.     due to a problem interfacing with the NameServer.
  15751.  
  15752. I have checked and cross-checked the syntax in the ARC and in the 4.1
  15753. documentation and it is correct.
  15754.  
  15755. Now why the hell is a nameserver required to interact with a framed =
  15756. route
  15757. ????
  15758.  
  15759. Is this a bug ?? (it did work on 4.0.29 though...)
  15760.  
  15761. Is there another way to do it ? (except by doing it through radius....)
  15762.  
  15763. Thanks for any replies...
  15764.  
  15765.  
  15766. --
  15767. Robert von Bismarck
  15768. Network Systems Engineer
  15769. Petrel Communications SA / SPAN
  15770. Tel : +41 22 304 47 47
  15771. Fax : +41 22 300 48 43
  15772. WWW : http://www.petrel.ch
  15773. e-mail : rvb@petrel.ch
  15774.  
  15775.  
  15776. -
  15777.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15778.  with "unsubscribe usr-tc" in the body of the message.
  15779.  For information on digests or retrieving files and old messages send
  15780.  "help" to the same address.  Do not use quotes in your message.
  15781.  
  15782.  
  15783. -------------------------------------------------------------------------------
  15784.  
  15785. From: Brian <signal@shreve.net>
  15786. Subject: Re: (usr-tc) Ah...what the heck...
  15787. Date: 15 Oct 1999 08:30:36 -0500 (CDT)
  15788.  
  15789. On Thu, 14 Oct 1999, Jeff Mcadams wrote:
  15790.  
  15791. > *grab stick, stir some more*  ;)
  15792. > 
  15793. > Well...just got a response back from the individual within 3Com that I
  15794. > reported the latest SNMP security bug to...his response to my request
  15795. > for a status report?  Call tech support and give them your contract
  15796. > number to ask about it.  Ayiyi!
  15797.  
  15798. Unbeleivable.  You find the security bug, and aren't even paid by 3com,
  15799. and they won't even give you status?
  15800.  
  15801. If instead of reporting it, you just posted it to bugtraq, here, and a few
  15802. other places, the negative press will force them to jump right on it, and
  15803. make it publicaly known the status.  Emailing interactive week, and a few
  15804. other rags probably would help too.
  15805.  
  15806. But instead, you email an engineer, and are told to essentially get back
  15807. in line with everyone else.............
  15808.  
  15809. > 
  15810. > So...here we go...the latest, greatest way to screw up your competitor's
  15811. > Total Control gear.  ;)
  15812.  
  15813. Cool, I'll check on Totalservice for the "status report" in the next
  15814. 24-48hours :)
  15815.  
  15816. > 
  15817. > As most of you are, no doubt, aware from previous discussions on the
  15818. > list, and indeed, from my previous SNMP security bug report, the NMC
  15819. > card is capable of acting as a "relay" agent for other cards in the
  15820. > chassis.  Basically, you send your SNMP request to the NMC card, with
  15821. > the NMC's community string, with "@xxxx" appended on the end of the
  15822. > community string (xxxx is the entity number for the card, 16000 for the
  15823. > card in slot 16, 5000 for the card in slot 5, etc.).
  15824. > 
  15825. > Here's the trick though...the NMC doesn't check the access of the
  15826. > community string that its sent if its relay'ed.  It checks to make sure
  15827. > that the community string *exists*, but not what its access level is.
  15828. > So...you send the NMC's read-only community string to the NMC, with the
  15829. > relay information attached to send it on to the Arc with an SNMP set
  15830. > operation.  The set is taken without complaint.
  15831. > 
  15832. > So...if you have the read-only community string for the NMC, you can
  15833. > make whatever changes you want in to other SNMP capable card in the rack
  15834. > (note, you can't muck with DSP's or quads or anything like that as they
  15835. > don't actually do SNMP, they use the NMC's agent directly, but Arc's,
  15836. > and any other gateway type card...basically anything that runs the
  15837. > Pilgrim code base...is able to be set).
  15838. > 
  15839. > Unfortunately, the NMC doesn't have any (that I could find) internal
  15840. > access controls on where it will accept SNMP ops from, so about the only
  15841. > thing I can say is filter on the next-hop, and make sure *all* of your
  15842. > community strings are secret.
  15843. > -- 
  15844. > Jeff McAdams                            Email: jeffm@iglou.com
  15845. > Head Network Administrator              Voice: (502) 966-3848
  15846. > IgLou Internet Services                        (800) 436-4456
  15847. > 
  15848. > -
  15849. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15850. >  with "unsubscribe usr-tc" in the body of the message.
  15851. >  For information on digests or retrieving files and old messages send
  15852. >  "help" to the same address.  Do not use quotes in your message.
  15853. > 
  15854.  
  15855. Brian Feeny (BF304)     signal@shreve.net   
  15856. 318-222-2638 x 109    http://www.shreve.net/~signal      
  15857. Network Administrator   ShreveNet Inc. (ASN 11881)           
  15858.  
  15859.  
  15860. -
  15861.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15862.  with "unsubscribe usr-tc" in the body of the message.
  15863.  For information on digests or retrieving files and old messages send
  15864.  "help" to the same address.  Do not use quotes in your message.
  15865.  
  15866.  
  15867. -------------------------------------------------------------------------------
  15868.  
  15869. From: Brian <signal@shreve.net>
  15870. Subject: Re: (usr-tc) Default routes disappearing
  15871. Date: 15 Oct 1999 08:33:37 -0500 (CDT)
  15872.  
  15873.  
  15874.  
  15875. Are you running OSPF at all on those arcs?
  15876.  
  15877.  
  15878. On Thu, 14 Oct 1999, Mike McHenry wrote:
  15879.  
  15880. > 
  15881. > 
  15882. > For the last several days I have been having a problem with my default
  15883. > route just disappearing from my HARC card. This card has been running
  15884. > 4.2.32-1 for several weeks now without too many problems.
  15885. > 
  15886. > Several times a day my default route just disappears. I have manually
  15887. > specified a default route on each HARC using set ip default_route gateway
  15888. > 192.168.0.1
  15889. > 
  15890. > This problem is EXTREMELY annoying as it is happening to all of my USR
  15891. > chassis. The only way to recover from it is a complete reboot of the HARC
  15892. > card. If I try to manually add the default route back to the HARC I get
  15893. > the error message that the network is not directly connected. (Which it
  15894. > is...)
  15895. > 
  15896. > Has anyone else run into this or do I chalk it up as yet another bug? The
  15897. > chassis is otherwise normal, all the routes are still shown if I do a show
  15898. > ip routes EXCEPT the default route! This is getting extremely frustrating
  15899. > for me, I have at least one serious problem with my USR TC chassis every
  15900. > couple of months and I am really getting tired of it. Any suggestions
  15901. > would be appreciated, thanks!
  15902. > 
  15903. > Mike McHenry
  15904. >  Systems Administrator
  15905. >  MinnNet Communications, Inc. 
  15906. > 
  15907. > 
  15908. > -
  15909. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15910. >  with "unsubscribe usr-tc" in the body of the message.
  15911. >  For information on digests or retrieving files and old messages send
  15912. >  "help" to the same address.  Do not use quotes in your message.
  15913. > 
  15914.  
  15915. Brian Feeny (BF304)     signal@shreve.net   
  15916. 318-222-2638 x 109    http://www.shreve.net/~signal      
  15917. Network Administrator   ShreveNet Inc. (ASN 11881)           
  15918.  
  15919.  
  15920. -
  15921.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15922.  with "unsubscribe usr-tc" in the body of the message.
  15923.  For information on digests or retrieving files and old messages send
  15924.  "help" to the same address.  Do not use quotes in your message.
  15925.  
  15926.  
  15927. -------------------------------------------------------------------------------
  15928.  
  15929. From: Brian <signal@shreve.net>
  15930. Subject: Re: (usr-tc) Default routes disappearing
  15931. Date: 15 Oct 1999 08:33:37 -0500 (CDT)
  15932.  
  15933.  
  15934.  
  15935. Are you running OSPF at all on those arcs?
  15936.  
  15937.  
  15938. On Thu, 14 Oct 1999, Mike McHenry wrote:
  15939.  
  15940. > 
  15941. > 
  15942. > For the last several days I have been having a problem with my default
  15943. > route just disappearing from my HARC card. This card has been running
  15944. > 4.2.32-1 for several weeks now without too many problems.
  15945. > 
  15946. > Several times a day my default route just disappears. I have manually
  15947. > specified a default route on each HARC using set ip default_route gateway
  15948. > 192.168.0.1
  15949. > 
  15950. > This problem is EXTREMELY annoying as it is happening to all of my USR
  15951. > chassis. The only way to recover from it is a complete reboot of the HARC
  15952. > card. If I try to manually add the default route back to the HARC I get
  15953. > the error message that the network is not directly connected. (Which it
  15954. > is...)
  15955. > 
  15956. > Has anyone else run into this or do I chalk it up as yet another bug? The
  15957. > chassis is otherwise normal, all the routes are still shown if I do a show
  15958. > ip routes EXCEPT the default route! This is getting extremely frustrating
  15959. > for me, I have at least one serious problem with my USR TC chassis every
  15960. > couple of months and I am really getting tired of it. Any suggestions
  15961. > would be appreciated, thanks!
  15962. > 
  15963. > Mike McHenry
  15964. >  Systems Administrator
  15965. >  MinnNet Communications, Inc. 
  15966. > 
  15967. > 
  15968. > -
  15969. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15970. >  with "unsubscribe usr-tc" in the body of the message.
  15971. >  For information on digests or retrieving files and old messages send
  15972. >  "help" to the same address.  Do not use quotes in your message.
  15973. > 
  15974.  
  15975. Brian Feeny (BF304)     signal@shreve.net   
  15976. 318-222-2638 x 109    http://www.shreve.net/~signal      
  15977. Network Administrator   ShreveNet Inc. (ASN 11881)           
  15978.  
  15979.  
  15980. -
  15981.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15982.  with "unsubscribe usr-tc" in the body of the message.
  15983.  For information on digests or retrieving files and old messages send
  15984.  "help" to the same address.  Do not use quotes in your message.
  15985.  
  15986.  
  15987. -------------------------------------------------------------------------------
  15988.  
  15989. From: Brian <signal@shreve.net>
  15990. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  15991. Date: 15 Oct 1999 08:36:18 -0500 (CDT)
  15992.  
  15993.  
  15994. Alot of times its just customer reps there though.........they should send
  15995. more execs and engineers to those things.
  15996.  
  15997.  
  15998. On Fri, 15 Oct 1999, Marshall Morgan wrote:
  15999.  
  16000. > Great Idea !!
  16001. > 
  16002. > Why don't we all have a mass (OPEN) meeting with 3com at ISPCon.  The other
  16003. > vendors will send people in as well and will get plenty of ammo for their
  16004. > executives that actually listen to their customer's complaints.  If 3com changes
  16005. > everything that night with a big announcement (hint hint) about cost effective
  16006. > hardware/technical support and software only support, then everyone, except the
  16007. > snoops from other companies, will be happy!
  16008. > 
  16009. > A win-win for everyone if 3C want's our continued business.  Buy customer's
  16010. > happiness through goodwill instead of ball parks.
  16011. > 
  16012. > Marshall Morgan
  16013. > President
  16014. > 
  16015. > Internet Doorway, Inc (aka NETDOOR)
  16016. > http://www.netdoor.com
  16017. > 
  16018. > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  16019. > 
  16020. > > -----Original Message-----
  16021. > > From: owner-usr-tc@lists.xmission.com
  16022. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
  16023. > > Sent: Thursday, October 14, 1999 9:41 PM
  16024. > > To: usr-tc@lists.xmission.com
  16025. > > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  16026. > >
  16027. > >
  16028. > > Sorry, but only people with service contracts can visit the 3Com booth.
  16029. > >
  16030. > > Sheldon Koehler wrote:
  16031. > > >
  16032. > > > Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  16033. > > > booth over to the Cisco booth and see if 3Com notices then...
  16034. > > >
  16035. > 
  16036. > 
  16037. > -
  16038. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16039. >  with "unsubscribe usr-tc" in the body of the message.
  16040. >  For information on digests or retrieving files and old messages send
  16041. >  "help" to the same address.  Do not use quotes in your message.
  16042. > 
  16043.  
  16044. Brian Feeny (BF304)     signal@shreve.net   
  16045. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16046. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16047.  
  16048.  
  16049. -
  16050.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16051.  with "unsubscribe usr-tc" in the body of the message.
  16052.  For information on digests or retrieving files and old messages send
  16053.  "help" to the same address.  Do not use quotes in your message.
  16054.  
  16055.  
  16056. -------------------------------------------------------------------------------
  16057.  
  16058. From: "Mike McHenry" <mmchen@minn.net>
  16059. Subject: RE: (usr-tc) Default routes disappearing
  16060. Date: 15 Oct 1999 08:58:07 -0500
  16061.  
  16062. Yes, we are running OSPF on all the chassis. I forgot that important piece
  16063. of information :) However, they have been running relatively well for the
  16064. last several weeks with it.
  16065.  
  16066. Mike McHenry
  16067.  Systems Administrator
  16068.  MinnNet Communications, Inc.
  16069.  
  16070. -----Original Message-----
  16071. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  16072. Sent: Friday, October 15, 1999 8:34 AM
  16073. Cc: usr-tc@xmission.com
  16074.  
  16075.  
  16076.  
  16077.  
  16078. Are you running OSPF at all on those arcs?
  16079.  
  16080.  
  16081. On Thu, 14 Oct 1999, Mike McHenry wrote:
  16082.  
  16083. >
  16084. >
  16085. > For the last several days I have been having a problem with my default
  16086. > route just disappearing from my HARC card. This card has been running
  16087. > 4.2.32-1 for several weeks now without too many problems.
  16088. >
  16089. > Several times a day my default route just disappears. I have manually
  16090. > specified a default route on each HARC using set ip default_route gateway
  16091. > 192.168.0.1
  16092. >
  16093. > This problem is EXTREMELY annoying as it is happening to all of my USR
  16094. > chassis. The only way to recover from it is a complete reboot of the HARC
  16095. > card. If I try to manually add the default route back to the HARC I get
  16096. > the error message that the network is not directly connected. (Which it
  16097. > is...)
  16098. >
  16099. > Has anyone else run into this or do I chalk it up as yet another bug? The
  16100. > chassis is otherwise normal, all the routes are still shown if I do a show
  16101. > ip routes EXCEPT the default route! This is getting extremely frustrating
  16102. > for me, I have at least one serious problem with my USR TC chassis every
  16103. > couple of months and I am really getting tired of it. Any suggestions
  16104. > would be appreciated, thanks!
  16105. >
  16106. > Mike McHenry
  16107. >  Systems Administrator
  16108. >  MinnNet Communications, Inc.
  16109. >
  16110. >
  16111. > -
  16112. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16113. >  with "unsubscribe usr-tc" in the body of the message.
  16114. >  For information on digests or retrieving files and old messages send
  16115. >  "help" to the same address.  Do not use quotes in your message.
  16116. >
  16117.  
  16118. Brian Feeny (BF304)     signal@shreve.net
  16119. 318-222-2638 x 109    http://www.shreve.net/~signal
  16120. Network Administrator   ShreveNet Inc. (ASN 11881)
  16121.  
  16122.  
  16123. -
  16124.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16125.  with "unsubscribe usr-tc" in the body of the message.
  16126.  For information on digests or retrieving files and old messages send
  16127.  "help" to the same address.  Do not use quotes in your message.
  16128.  
  16129.  
  16130. -
  16131.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16132.  with "unsubscribe usr-tc" in the body of the message.
  16133.  For information on digests or retrieving files and old messages send
  16134.  "help" to the same address.  Do not use quotes in your message.
  16135.  
  16136.  
  16137. -------------------------------------------------------------------------------
  16138.  
  16139. From: jeff.binkley@asacomp.com (Jeff Binkley)
  16140. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16141. Date: 15 Oct 1999 10:09:00 -0500
  16142.  
  16143. -> Alot of times its just customer reps there though.........they should send
  16144. -> more execs and engineers to those things.
  16145.  
  16146. But those folks feel this kind of stuff in their wallets.  I suspect it would
  16147. get some folks attention.
  16148.  
  16149.  
  16150. Jeff Binkley
  16151. ASA Network Computing
  16152.  
  16153. -
  16154.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16155.  with "unsubscribe usr-tc" in the body of the message.
  16156.  For information on digests or retrieving files and old messages send
  16157.  "help" to the same address.  Do not use quotes in your message.
  16158.  
  16159.  
  16160. -------------------------------------------------------------------------------
  16161.  
  16162. From: Jeff Mcadams <jeffm@iglou.com>
  16163. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16164. Date: 15 Oct 1999 10:25:58 -0400
  16165.  
  16166. Thus spake Jeff Binkley
  16167. >-> Alot of times its just customer reps there though.........they should send
  16168. >-> more execs and engineers to those things.
  16169.  
  16170. >But those folks feel this kind of stuff in their wallets.  I suspect it would
  16171. >get some folks attention.
  16172.  
  16173. The problem being...I think the sales reps (for the most part, at
  16174. least...at least for those of us who have talked to them) already agree
  16175. with us and are (to some degree or other) already fighting our fight
  16176. along with us.  Unfortunately, they apparently aren't listened to much
  16177. either.  :/
  16178.  
  16179. I think its time to start putting together the Top 10 Gripe List - Round
  16180. 2.  I believe Brian Feeny compiled this last time...I'll certainly defer
  16181. if he wishes to do so again, but if he's not interested in taking this
  16182. project on, I'll volunteer to compile and write it up.  Let's see if we
  16183. can have this thing ready for ISPCON.
  16184. -- 
  16185. Jeff McAdams                            Email: jeffm@iglou.com
  16186. Head Network Administrator              Voice: (502) 966-3848
  16187. IgLou Internet Services                        (800) 436-4456
  16188.  
  16189. -
  16190.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16191.  with "unsubscribe usr-tc" in the body of the message.
  16192.  For information on digests or retrieving files and old messages send
  16193.  "help" to the same address.  Do not use quotes in your message.
  16194.  
  16195.  
  16196. -------------------------------------------------------------------------------
  16197.  
  16198. From: Allen Marsalis <am@shreve.net>
  16199. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16200. Date: 15 Oct 1999 09:47:05 -0500
  16201.  
  16202. At 10:25 AM 10/15/99 -0400, Jeff Mcadams wrote:
  16203.  
  16204. >I think its time to start putting together the Top 10 Gripe List - Round
  16205. >2.  I believe Brian Feeny compiled this last time...I'll certainly defer
  16206. >if he wishes to do so again, but if he's not interested in taking this
  16207. >project on, I'll volunteer to compile and write it up.  Let's see if we
  16208. >can have this thing ready for ISPCON.
  16209.  
  16210. Actually I compiled it last time.  After realizing the constant effort
  16211. that went into it, I decided to create some smartpages that would
  16212. compile the info consistently and automatically.  I called these pages
  16213. "TC Watcher" and posted the url here (http://www.shreve.net/tcs )
  16214. The site has been 90% complete for about a year now..  No one seems
  16215. to really like/use it so I never put in the effort to polish the site..
  16216. If I remember right, really the only thing left was the unresolved
  16217. issues list (a broken link) that compiled report for all the data 
  16218. put into the database by users (or was supposed to)..  I never got much
  16219. feedback on it..
  16220.  
  16221. In any event, I am willing to go ahead and finish it out if a few
  16222. people believe it to be worthwhile idea...  I haven't checked it out
  16223. in many months and I don't think it's been used in a long while.
  16224.  
  16225. I'm open to suggestions for improvement, otherwise I just need to go
  16226. "the last mile" with it and finish that one query (the unresolved
  16227. issues report).
  16228.  
  16229. I really don't mind supporting our efforts for quality product and
  16230. service from 3com, however I don't want to waste my time if it's
  16231. a lame concept or implemenation..  From my experience, maintaining 
  16232. "the list" with all the signatures is more work that it appears
  16233. to be by hand, at least over and over by one person..
  16234.  
  16235. Allen Marsalis
  16236.  
  16237. >-- 
  16238. >Jeff McAdams                            Email: jeffm@iglou.com
  16239. >Head Network Administrator              Voice: (502) 966-3848
  16240. >IgLou Internet Services                        (800) 436-4456
  16241. >
  16242.  
  16243.  
  16244. Allen Marsalis (AM1543)         ShreveNet, Inc.
  16245. President/CEO                   333 Texas St. Suite 175
  16246. http://www.shreve.net           Shreveport, LA  71106
  16247. am@shreve.net                   (318)222-2NET x102
  16248.  
  16249.  
  16250. -
  16251.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16252.  with "unsubscribe usr-tc" in the body of the message.
  16253.  For information on digests or retrieving files and old messages send
  16254.  "help" to the same address.  Do not use quotes in your message.
  16255.  
  16256.  
  16257. -------------------------------------------------------------------------------
  16258.  
  16259. From: Jeff Mcadams <jeffm@iglou.com>
  16260. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16261. Date: 15 Oct 1999 11:07:15 -0400
  16262.  
  16263. Thus spake Allen Marsalis
  16264. >Actually I compiled it last time.  
  16265.  
  16266. Ah...ok...couldn't remember who it was...certainly didn't intend to
  16267. steal your thunder.  :)
  16268.  
  16269. >After realizing the constant effort that went into it, I decided to
  16270. >create some smartpages that would compile the info consistently and
  16271. >automatically.  I called these pages "TC Watcher" and posted the url
  16272. >here (http://www.shreve.net/tcs )
  16273.  
  16274. Yup...I've still my bookmark for it...still check it periodically, but,
  16275. yeah...its been pretty stagnant.
  16276.  
  16277. I do see the TCWatcher type of thing being a useful tool (just getting
  16278. the critical mass to get it going and keep it going is the trick ;), but
  16279. I also see it being orthoganal to the (apparently periodic) need for a
  16280. Gripe List or the like.  Certainly the TCWatcher would be a good tool
  16281. for compiling a Gripe List, but I think a Gripe List would best be "hand
  16282. written" each time.  Quite a lot of work, but I think the payoff is
  16283. worth it.
  16284.  
  16285. Like I said...I'd certainly be willing to put the effort into putting
  16286. this one together.  I've been looking for a chance to put my
  16287. newly-formed SGML skillz to work...this would fit the bill.  ;)
  16288.  
  16289. >In any event, I am willing to go ahead and finish it out if a few
  16290. >people believe it to be worthwhile idea...  I haven't checked it out
  16291. >in many months and I don't think it's been used in a long while.
  16292.  
  16293. Well...as soon as our T3 comes back up (lovely UU.Net), and I have
  16294. bandwidth to spare again and it wouldn't be totally painful for me to
  16295. visit sites off our network, I'll head over there and put in some of the
  16296. issues that we currently have.  Certainly, TCWatcher would at least be a
  16297. good base to start a new Gripe List from.
  16298. -- 
  16299. Jeff McAdams                            Email: jeffm@iglou.com
  16300. Head Network Administrator              Voice: (502) 966-3848
  16301. IgLou Internet Services                        (800) 436-4456
  16302.  
  16303. -
  16304.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16305.  with "unsubscribe usr-tc" in the body of the message.
  16306.  For information on digests or retrieving files and old messages send
  16307.  "help" to the same address.  Do not use quotes in your message.
  16308.  
  16309.  
  16310. -------------------------------------------------------------------------------
  16311.  
  16312. From: Brian <signal@shreve.net>
  16313. Subject: RE: (usr-tc) Default routes disappearing
  16314. Date: 15 Oct 1999 10:12:50 -0500 (CDT)
  16315.  
  16316. On Fri, 15 Oct 1999, Mike McHenry wrote:
  16317.  
  16318. > Yes, we are running OSPF on all the chassis. I forgot that important piece
  16319. > of information :) However, they have been running relatively well for the
  16320. > last several weeks with it.
  16321.  
  16322. I'm just wondering if OSPF is removing your default route. I have heard
  16323. other complaints on this list of OSPF messing with static default
  16324. routes......................
  16325.  
  16326. Brian
  16327.  
  16328.  
  16329. > 
  16330. > Mike McHenry
  16331. >  Systems Administrator
  16332. >  MinnNet Communications, Inc.
  16333. > 
  16334. > -----Original Message-----
  16335. > From: owner-usr-tc@lists.xmission.com
  16336. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  16337. > Sent: Friday, October 15, 1999 8:34 AM
  16338. > To: usr-tc@lists.xmission.com
  16339. > Cc: usr-tc@xmission.com
  16340. > Subject: Re: (usr-tc) Default routes disappearing
  16341. > 
  16342. > 
  16343. > 
  16344. > 
  16345. > Are you running OSPF at all on those arcs?
  16346. > 
  16347. > 
  16348. > On Thu, 14 Oct 1999, Mike McHenry wrote:
  16349. > 
  16350. > >
  16351. > >
  16352. > > For the last several days I have been having a problem with my default
  16353. > > route just disappearing from my HARC card. This card has been running
  16354. > > 4.2.32-1 for several weeks now without too many problems.
  16355. > >
  16356. > > Several times a day my default route just disappears. I have manually
  16357. > > specified a default route on each HARC using set ip default_route gateway
  16358. > > 192.168.0.1
  16359. > >
  16360. > > This problem is EXTREMELY annoying as it is happening to all of my USR
  16361. > > chassis. The only way to recover from it is a complete reboot of the HARC
  16362. > > card. If I try to manually add the default route back to the HARC I get
  16363. > > the error message that the network is not directly connected. (Which it
  16364. > > is...)
  16365. > >
  16366. > > Has anyone else run into this or do I chalk it up as yet another bug? The
  16367. > > chassis is otherwise normal, all the routes are still shown if I do a show
  16368. > > ip routes EXCEPT the default route! This is getting extremely frustrating
  16369. > > for me, I have at least one serious problem with my USR TC chassis every
  16370. > > couple of months and I am really getting tired of it. Any suggestions
  16371. > > would be appreciated, thanks!
  16372. > >
  16373. > > Mike McHenry
  16374. > >  Systems Administrator
  16375. > >  MinnNet Communications, Inc.
  16376. > >
  16377. > >
  16378. > > -
  16379. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16380. > >  with "unsubscribe usr-tc" in the body of the message.
  16381. > >  For information on digests or retrieving files and old messages send
  16382. > >  "help" to the same address.  Do not use quotes in your message.
  16383. > >
  16384. > 
  16385. > -----------------------------------------------------
  16386. > Brian Feeny (BF304)     signal@shreve.net
  16387. > 318-222-2638 x 109    http://www.shreve.net/~signal
  16388. > Network Administrator   ShreveNet Inc. (ASN 11881)
  16389. > 
  16390. > 
  16391. > -
  16392. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16393. >  with "unsubscribe usr-tc" in the body of the message.
  16394. >  For information on digests or retrieving files and old messages send
  16395. >  "help" to the same address.  Do not use quotes in your message.
  16396. > 
  16397. > 
  16398. > -
  16399. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16400. >  with "unsubscribe usr-tc" in the body of the message.
  16401. >  For information on digests or retrieving files and old messages send
  16402. >  "help" to the same address.  Do not use quotes in your message.
  16403. > 
  16404.  
  16405. Brian Feeny (BF304)     signal@shreve.net   
  16406. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16407. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16408.  
  16409.  
  16410. -
  16411.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16412.  with "unsubscribe usr-tc" in the body of the message.
  16413.  For information on digests or retrieving files and old messages send
  16414.  "help" to the same address.  Do not use quotes in your message.
  16415.  
  16416.  
  16417. -------------------------------------------------------------------------------
  16418.  
  16419. From: Brian <signal@shreve.net>
  16420. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16421. Date: 15 Oct 1999 10:14:31 -0500 (CDT)
  16422.  
  16423. On Fri, 15 Oct 1999, Jeff Mcadams wrote:
  16424.  
  16425. > Thus spake Jeff Binkley
  16426. > >-> Alot of times its just customer reps there though.........they should send
  16427. > >-> more execs and engineers to those things.
  16428. > 
  16429. > >But those folks feel this kind of stuff in their wallets.  I suspect it would
  16430. > >get some folks attention.
  16431. > 
  16432. > The problem being...I think the sales reps (for the most part, at
  16433. > least...at least for those of us who have talked to them) already agree
  16434. > with us and are (to some degree or other) already fighting our fight
  16435. > along with us.  Unfortunately, they apparently aren't listened to much
  16436. > either.  :/
  16437. > 
  16438. > I think its time to start putting together the Top 10 Gripe List - Round
  16439. > 2.  I believe Brian Feeny compiled this last time...I'll certainly defer
  16440.  
  16441. It was actually Allen Marsalis............He assembled a database system
  16442. for this, so that as gripes are added they can be prioritized and
  16443. essentially it could construct the gripe list on the fly..........I
  16444. believe the system still exists.
  16445.  
  16446. > if he wishes to do so again, but if he's not interested in taking this
  16447. > project on, I'll volunteer to compile and write it up.  Let's see if we
  16448. > can have this thing ready for ISPCON.
  16449.  
  16450. that would be nice to have it ready by ISPcon.
  16451.  
  16452. > -- 
  16453. > Jeff McAdams                            Email: jeffm@iglou.com
  16454. > Head Network Administrator              Voice: (502) 966-3848
  16455. > IgLou Internet Services                        (800) 436-4456
  16456. > 
  16457. > -
  16458. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16459. >  with "unsubscribe usr-tc" in the body of the message.
  16460. >  For information on digests or retrieving files and old messages send
  16461. >  "help" to the same address.  Do not use quotes in your message.
  16462. > 
  16463.  
  16464. Brian Feeny (BF304)     signal@shreve.net   
  16465. 318-222-2638 x 109    http://www.shreve.net/~signal      
  16466. Network Administrator   ShreveNet Inc. (ASN 11881)           
  16467.  
  16468.  
  16469. -
  16470.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16471.  with "unsubscribe usr-tc" in the body of the message.
  16472.  For information on digests or retrieving files and old messages send
  16473.  "help" to the same address.  Do not use quotes in your message.
  16474.  
  16475.  
  16476. -------------------------------------------------------------------------------
  16477.  
  16478. From: "Mike McHenry" <mmchen@minn.net>
  16479. Subject: RE: (usr-tc) Default routes disappearing
  16480. Date: 15 Oct 1999 10:39:48 -0500
  16481.  
  16482. Well, originally I had been thinking along those lines so I disabled the
  16483. advertisement of the default route on all my routers. I also thought it
  16484. might be a dialup user with a crazy entry in radius but that is a no-go too.
  16485. If anyone at 3com is interested in taking a look I have a chassis that is
  16486. doing it right now although I am going to have to bring it back online by
  16487. tonight.
  16488.  
  16489. I have pruned my OSPF tables down, there are only about 150 table entries so
  16490. it is not (or should not) be a problem with the OSPF tables getting to big.
  16491. I have just disabled the iea_next_hop_routing as that is the only other
  16492. thing that comes to mind that would possibly cause problems.
  16493.  
  16494. When this happens I am even unable to readd the route which really leads me
  16495. to believe this is a bug of some kind. The eth:1 interface is directly on
  16496. the same class C as the gateway address and attempts to manually readd the
  16497. default route fail...hmmm odd, I just tried to manually readd the route for
  16498. a screen shot and it worked. Maybe the iea_next_hop_routing setting I just
  16499. fiddled with changed something.
  16500.  
  16501. I will keep everyone informed if I have a problem again or not, thanks for
  16502. the suggestions...
  16503.  
  16504. Mike McHenry
  16505.  Systems Administrator
  16506.  MinnNet Communications, Inc.
  16507.  
  16508. -----Original Message-----
  16509. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  16510. Sent: Friday, October 15, 1999 10:13 AM
  16511.  
  16512.  
  16513. On Fri, 15 Oct 1999, Mike McHenry wrote:
  16514.  
  16515. > Yes, we are running OSPF on all the chassis. I forgot that important piece
  16516. > of information :) However, they have been running relatively well for the
  16517. > last several weeks with it.
  16518.  
  16519. I'm just wondering if OSPF is removing your default route. I have heard
  16520. other complaints on this list of OSPF messing with static default
  16521. routes......................
  16522.  
  16523. Brian
  16524.  
  16525.  
  16526. >
  16527. > Mike McHenry
  16528. >  Systems Administrator
  16529. >  MinnNet Communications, Inc.
  16530. >
  16531. > -----Original Message-----
  16532. > From: owner-usr-tc@lists.xmission.com
  16533. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  16534. > Sent: Friday, October 15, 1999 8:34 AM
  16535. > To: usr-tc@lists.xmission.com
  16536. > Cc: usr-tc@xmission.com
  16537. > Subject: Re: (usr-tc) Default routes disappearing
  16538. >
  16539. >
  16540. >
  16541. >
  16542. > Are you running OSPF at all on those arcs?
  16543. >
  16544. >
  16545. > On Thu, 14 Oct 1999, Mike McHenry wrote:
  16546. >
  16547. > >
  16548. > >
  16549. > > For the last several days I have been having a problem with my default
  16550. > > route just disappearing from my HARC card. This card has been running
  16551. > > 4.2.32-1 for several weeks now without too many problems.
  16552. > >
  16553. > > Several times a day my default route just disappears. I have manually
  16554. > > specified a default route on each HARC using set ip default_route
  16555. gateway
  16556. > > 192.168.0.1
  16557. > >
  16558. > > This problem is EXTREMELY annoying as it is happening to all of my USR
  16559. > > chassis. The only way to recover from it is a complete reboot of the
  16560. HARC
  16561. > > card. If I try to manually add the default route back to the HARC I get
  16562. > > the error message that the network is not directly connected. (Which it
  16563. > > is...)
  16564. > >
  16565. > > Has anyone else run into this or do I chalk it up as yet another bug?
  16566. The
  16567. > > chassis is otherwise normal, all the routes are still shown if I do a
  16568. show
  16569. > > ip routes EXCEPT the default route! This is getting extremely
  16570. frustrating
  16571. > > for me, I have at least one serious problem with my USR TC chassis every
  16572. > > couple of months and I am really getting tired of it. Any suggestions
  16573. > > would be appreciated, thanks!
  16574. > >
  16575. > > Mike McHenry
  16576. > >  Systems Administrator
  16577. > >  MinnNet Communications, Inc.
  16578. > >
  16579. > >
  16580. > > -
  16581. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16582. > >  with "unsubscribe usr-tc" in the body of the message.
  16583. > >  For information on digests or retrieving files and old messages send
  16584. > >  "help" to the same address.  Do not use quotes in your message.
  16585. > >
  16586. >
  16587. > -----------------------------------------------------
  16588. > Brian Feeny (BF304)     signal@shreve.net
  16589. > 318-222-2638 x 109    http://www.shreve.net/~signal
  16590. > Network Administrator   ShreveNet Inc. (ASN 11881)
  16591. >
  16592. >
  16593. > -
  16594. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16595. >  with "unsubscribe usr-tc" in the body of the message.
  16596. >  For information on digests or retrieving files and old messages send
  16597. >  "help" to the same address.  Do not use quotes in your message.
  16598. >
  16599. >
  16600. > -
  16601. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16602. >  with "unsubscribe usr-tc" in the body of the message.
  16603. >  For information on digests or retrieving files and old messages send
  16604. >  "help" to the same address.  Do not use quotes in your message.
  16605. >
  16606.  
  16607. Brian Feeny (BF304)     signal@shreve.net
  16608. 318-222-2638 x 109    http://www.shreve.net/~signal
  16609. Network Administrator   ShreveNet Inc. (ASN 11881)
  16610.  
  16611.  
  16612. -
  16613.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16614.  with "unsubscribe usr-tc" in the body of the message.
  16615.  For information on digests or retrieving files and old messages send
  16616.  "help" to the same address.  Do not use quotes in your message.
  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: Allen Marsalis <am@shreve.net>
  16629. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16630. Date: 15 Oct 1999 10:52:31 -0500
  16631.  
  16632. At 11:07 AM 10/15/99 -0400, Jeff Mcadams wrote:
  16633. >Thus spake Allen Marsalis
  16634. >>Actually I compiled it last time.  
  16635. >
  16636. >Ah...ok...couldn't remember who it was...certainly didn't intend to
  16637. >steal your thunder.  :)
  16638.  
  16639. well...  I'm sure Brian helped me a lot..  He deserves more thunder
  16640. on this list that I do overall for sure..  I'm just a lowly president
  16641. who is concerned by the overall picture of things..  And I still
  16642. lurk..  8-)
  16643.  
  16644. >
  16645. >>After realizing the constant effort that went into it, I decided to
  16646. >>create some smartpages that would compile the info consistently and
  16647. >>automatically.  I called these pages "TC Watcher" and posted the url
  16648. >>here (http://www.shreve.net/tcs )
  16649. >
  16650. >Yup...I've still my bookmark for it...still check it periodically, but,
  16651. >yeah...its been pretty stagnant.
  16652.  
  16653. Well I see two problems perhaps..  first, it came about soon after
  16654. the original list and it was just to early to pick up again..  Also
  16655. I posted it too soon before completion in an effort to determine if
  16656. it was good/bad, and also to get data pouring in while I completed it..
  16657.  
  16658. >
  16659. >I do see the TCWatcher type of thing being a useful tool (just getting
  16660. >the critical mass to get it going and keep it going is the trick ;), but
  16661. >I also see it being orthoganal to the (apparently periodic) need for a
  16662. >Gripe List or the like.  Certainly the TCWatcher would be a good tool
  16663. >for compiling a Gripe List, but I think a Gripe List would best be "hand
  16664. >written" each time.  Quite a lot of work, but I think the payoff is
  16665. >worth it.
  16666.  
  16667. nod..  It might be a good tool for a manual report..  I just remember
  16668. all the list chatter saying "add me too" sort of thing..  It really
  16669. was time consuming monitoring the list and updating the report several
  16670. times a day...
  16671.  
  16672. >
  16673. >Like I said...I'd certainly be willing to put the effort into putting
  16674. >this one together.  I've been looking for a chance to put my
  16675. >newly-formed SGML skillz to work...this would fit the bill.  ;)
  16676.  
  16677. well just let me know if there is anything I can offer or do..
  16678. I don't mind completing the project in addition to you doing
  16679. the report..  I really don't want to do the report again, evident
  16680. by my work on tcwatcher.. 8-)
  16681.  
  16682. >
  16683. >>In any event, I am willing to go ahead and finish it out if a few
  16684. >>people believe it to be worthwhile idea...  I haven't checked it out
  16685. >>in many months and I don't think it's been used in a long while.
  16686. >
  16687. >Well...as soon as our T3 comes back up (lovely UU.Net), and I have
  16688. >bandwidth to spare again and it wouldn't be totally painful for me to
  16689. >visit sites off our network, I'll head over there and put in some of the
  16690. >issues that we currently have.  Certainly, TCWatcher would at least be a
  16691. >good base to start a new Gripe List from.
  16692.  
  16693. yeah I'll also give it another push..  I know it needs an option to
  16694. email forgotten passwords and that sort of thing..  Also the main
  16695. purpose was to compile a list.  It's the main link and I never finished
  16696. it.. (always have the best/hardest for last)
  16697.  
  16698. Allen
  16699.  
  16700. >-- 
  16701. >Jeff McAdams                            Email: jeffm@iglou.com
  16702. >Head Network Administrator              Voice: (502) 966-3848
  16703. >IgLou Internet Services                        (800) 436-4456
  16704. >
  16705. >-
  16706. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16707. > with "unsubscribe usr-tc" in the body of the message.
  16708. > For information on digests or retrieving files and old messages send
  16709. > "help" to the same address.  Do not use quotes in your message.
  16710.  
  16711.  
  16712. -
  16713.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16714.  with "unsubscribe usr-tc" in the body of the message.
  16715.  For information on digests or retrieving files and old messages send
  16716.  "help" to the same address.  Do not use quotes in your message.
  16717.  
  16718.  
  16719. -------------------------------------------------------------------------------
  16720.  
  16721. From: Jeff Mcadams <jeffm@iglou.com>
  16722. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  16723. Date: 15 Oct 1999 12:05:45 -0400
  16724.  
  16725. Thus spake Allen Marsalis
  16726. >>Like I said...I'd certainly be willing to put the effort into putting
  16727. >>this one together.  I've been looking for a chance to put my
  16728. >>newly-formed SGML skillz to work...this would fit the bill.  ;)
  16729.  
  16730. >well just let me know if there is anything I can offer or do..
  16731. >I don't mind completing the project in addition to you doing
  16732. >the report..  I really don't want to do the report again, evident
  16733. >by my work on tcwatcher.. 8-)
  16734.  
  16735. Heh...I can certainly understand your point.  I'll definitely put my
  16736. $.02 for seeing TCWatcher get some more functionality and
  16737. attention...that could very easily turn into a really good resource,
  16738. like I said, regardless of the Gripe List thing.  :)
  16739.  
  16740. >yeah I'll also give it another push..  I know it needs an option to
  16741. >email forgotten passwords and that sort of thing..  Also the main
  16742. >purpose was to compile a list.  It's the main link and I never finished
  16743. >it.. (always have the best/hardest for last)
  16744.  
  16745. Heh...I appreciate that for sure...
  16746.  
  16747. I'll start working on some text for a Gripe List or something...nothing
  16748. may come of it, but I can play with it and maybe something useful will
  16749. come out of it.  :)
  16750. -- 
  16751. Jeff McAdams                            Email: jeffm@iglou.com
  16752. Head Network Administrator              Voice: (502) 966-3848
  16753. IgLou Internet Services                        (800) 436-4456
  16754.  
  16755. -
  16756.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16757.  with "unsubscribe usr-tc" in the body of the message.
  16758.  For information on digests or retrieving files and old messages send
  16759.  "help" to the same address.  Do not use quotes in your message.
  16760.  
  16761.  
  16762. -------------------------------------------------------------------------------
  16763.  
  16764. From: andrew <smitha@mach3ww.com>
  16765. Subject: RE: (usr-tc) 2.0.60 HDM Code
  16766. Date: 15 Oct 1999 11:42:59 -0500 (CDT)
  16767.  
  16768.  
  16769. > O, they *do* offer software download only support.........its just that I
  16770. > am not entirely happy with that pricing either.
  16771.  
  16772. I love the hardware, but I'm not entirely happy with their software. A
  16773. version of arc code that fixes one problem breaks 3 other things! I think
  16774. 3com should make *all* their releases Beta, not just ERs. Because we seem
  16775. to be the Beta testers even with their production level code. Has 3com
  16776. considered a code freeze, so they can fix the problems in their existing
  16777. code and not keep adding broken features to already broken code? Maybe
  16778. 3com should do what Linux kernel developers do; have one version of
  16779. code-base that is stable, and yet another version for those individuals
  16780. who want to "live on the edge" with new features, but most importantly, 
  16781. keep working on and improving *both* versions at the same time.
  16782.  
  16783. I know it's not easy 3com, and I understand that everyone wants new
  16784. features right away. However, what makes me mad is the fact that 3com
  16785. charges *us* to fix *their* mistakes. I understand small bugs, everything
  16786. has small bugs, but *major* problems such as security flaws or bugs that
  16787. effect the basic functionality of their products should be fixed free of
  16788. charge. And when we do buy service contracts with software support, we
  16789. should be able to at least access the code and security updates
  16790. we had access to during our contracts after it expires on us. Because
  16791. after all, we did pay for it. Either that or I'll just have to start
  16792. mirroring.
  16793.  
  16794. Even Micro$oft offers free updates without a "service contract" for most
  16795. of their products when it comes to security issues; however, *like*
  16796. 3com, Microsoft never seems to find all the bugs. ;) I know things
  16797. will get better, because 3com has very smart people and they are
  16798. listening, right? I hope 3com does the right thing and develops
  16799. a more "customer friendly" approach when it comes to software updates and
  16800. support. 
  16801.  
  16802. -
  16803.     andrew
  16804.  
  16805.  
  16806. -
  16807.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16808.  with "unsubscribe usr-tc" in the body of the message.
  16809.  For information on digests or retrieving files and old messages send
  16810.  "help" to the same address.  Do not use quotes in your message.
  16811.  
  16812.  
  16813. -------------------------------------------------------------------------------
  16814.  
  16815. From: <dciresi@defunct.ae.usr.com>
  16816. Subject: Re: (usr-tc) Radius Effects...
  16817. Date: 15 Oct 1999 11:54:12 -0500 (CDT)
  16818.  
  16819. Scot,
  16820.  
  16821. Sounds like the Bay (or the Bay technician) is broken.  However, the
  16822. workaround you've sugested, should work fine.  Simply define the default
  16823. user's IP address and routing protocol (=none) on the ARC.  This template
  16824. will be applied to the user in place of attributes not actually sent.
  16825.  
  16826. There is a way to prescribe different attributes for different NAS-Types,
  16827. but it may require some RADIUS hacking.  And most likely, this will
  16828. require changes on the proxy server, as well.  The best bet would be to
  16829. correct the Bay NAS.
  16830.  
  16831. Dominic
  16832.  
  16833. On Wed, 13 Oct 1999, Scot Desort wrote:
  16834.  
  16835. > While we're all talking about Radius, we currently send the following
  16836. > attributes to our TC for our default user:
  16837. > 
  16838. > Framed-IPAddress = 255.255.255.254
  16839. > Framed-Routing = None
  16840. > 
  16841. > We recently signed up with Ziplink for wholesale nationwide dialup. A lot of
  16842. > their equipment is Bay. They claim that when the Bay receives these
  16843. > attributes, it chokes. It allows the connection, and the modem connect speed
  16844. > is fine, but throughput is horrible. Over 50% of the packets drop, and after
  16845. > a few minutes, the call will drop. They say we need to remove these
  16846. > attributes from the Radius profile we send. Huh? Bay doesn't like these 2
  16847. > *basic* attributes? They also said they don't like 'Port-limit=1', but I am
  16848. > NOT removing that one. For this one, they state that they have trouble with
  16849. > the Bay doing 128K ISDN anyway, so removing the attribute will have no
  16850. > effect. Double "huh?"
  16851. > 
  16852. > My question is, what effect will this have on our local dialup customers
  16853. > connecting to our TC? Will the TC happily work without receiving those 2
  16854. > attributes? We are currently not running RIP on the TC (we are small, so
  16855. > everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
  16856. > start sending RIP updates to the dialup clients without the
  16857. > Framed-Routing=none attribute set?
  16858. > 
  16859. > They also have some Max's out there, but a good portion of it's Bay. I don't
  16860. > know of any way to have my Radius server send a different profile to their
  16861. > proxy, so it has to be the same one I send to my TC.
  16862. > 
  16863. > Sorry for what might seem a stupid question - not real up to speed on RIP
  16864. > and exactly what the framed-routing attribute does.
  16865. > 
  16866. > -Scot
  16867. > NJAccess
  16868. > 
  16869. > 
  16870. > 
  16871. > -
  16872. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16873. >  with "unsubscribe usr-tc" in the body of the message.
  16874. >  For information on digests or retrieving files and old messages send
  16875. >  "help" to the same address.  Do not use quotes in your message.
  16876. > 
  16877.  
  16878.  
  16879. -
  16880.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16881.  with "unsubscribe usr-tc" in the body of the message.
  16882.  For information on digests or retrieving files and old messages send
  16883.  "help" to the same address.  Do not use quotes in your message.
  16884.  
  16885.  
  16886. -------------------------------------------------------------------------------
  16887.  
  16888. From: Marius Strom <marius@alpha1.net>
  16889. Subject: Re: (usr-tc) Radius Effects...
  16890. Date: 15 Oct 1999 11:59:54 -0500 (CDT)
  16891.  
  16892. Umm, let's see, we've also got some Bay 5399's running R16.0 software on
  16893. ROM Revision 1115..  We're sending port-limit=1 to all customers, no
  16894. problems.  We've got 128K ISDN connecting, no problems.
  16895.  
  16896. Can't speak from the Framed-Routing deal, but we are delegating static
  16897. IP's with Framed-IP-Address and blocks with Framed-IP-Route.
  16898.  
  16899. Runs like a champ -- I usually forget how to use it because I never have
  16900. to log into the box. =]
  16901.  
  16902. -- 
  16903. Marius Strom <marius@alpha1.net>
  16904. Professional Geek/Unix System Administrator
  16905. Alpha1 Internet <http://www.alpha1.net>
  16906. http://www.marius.org/marius.pgp 0x5645C228
  16907.  
  16908. In theory, there is no difference between theory and practice...
  16909. ...In practice, there is a big difference.
  16910.  
  16911.  
  16912. > On Wed, 13 Oct 1999, Scot Desort wrote:
  16913. > 
  16914. > > While we're all talking about Radius, we currently send the following
  16915. > > attributes to our TC for our default user:
  16916. > > 
  16917. > > Framed-IPAddress = 255.255.255.254
  16918. > > Framed-Routing = None
  16919. > > 
  16920. > > We recently signed up with Ziplink for wholesale nationwide dialup. A lot of
  16921. > > their equipment is Bay. They claim that when the Bay receives these
  16922. > > attributes, it chokes. It allows the connection, and the modem connect speed
  16923. > > is fine, but throughput is horrible. Over 50% of the packets drop, and after
  16924. > > a few minutes, the call will drop. They say we need to remove these
  16925. > > attributes from the Radius profile we send. Huh? Bay doesn't like these 2
  16926. > > *basic* attributes? They also said they don't like 'Port-limit=1', but I am
  16927. > > NOT removing that one. For this one, they state that they have trouble with
  16928. > > the Bay doing 128K ISDN anyway, so removing the attribute will have no
  16929. > > effect. Double "huh?"
  16930. > > 
  16931. > > My question is, what effect will this have on our local dialup customers
  16932. > > connecting to our TC? Will the TC happily work without receiving those 2
  16933. > > attributes? We are currently not running RIP on the TC (we are small, so
  16934. > > everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
  16935. > > start sending RIP updates to the dialup clients without the
  16936. > > Framed-Routing=none attribute set?
  16937. > > 
  16938. > > They also have some Max's out there, but a good portion of it's Bay. I don't
  16939. > > know of any way to have my Radius server send a different profile to their
  16940. > > proxy, so it has to be the same one I send to my TC.
  16941. > > 
  16942. > > Sorry for what might seem a stupid question - not real up to speed on RIP
  16943. > > and exactly what the framed-routing attribute does.
  16944. > > 
  16945. > > -Scot
  16946. > > NJAccess
  16947. > > 
  16948. > > 
  16949. > > 
  16950. > > -
  16951. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16952. > >  with "unsubscribe usr-tc" in the body of the message.
  16953. > >  For information on digests or retrieving files and old messages send
  16954. > >  "help" to the same address.  Do not use quotes in your message.
  16955. > > 
  16956. > 
  16957. > 
  16958. > -
  16959. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16960. >  with "unsubscribe usr-tc" in the body of the message.
  16961. >  For information on digests or retrieving files and old messages send
  16962. >  "help" to the same address.  Do not use quotes in your message.
  16963. > 
  16964.  
  16965.  
  16966. -
  16967.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16968.  with "unsubscribe usr-tc" in the body of the message.
  16969.  For information on digests or retrieving files and old messages send
  16970.  "help" to the same address.  Do not use quotes in your message.
  16971.  
  16972.  
  16973. -------------------------------------------------------------------------------
  16974.  
  16975. From: Greg Coffey <greg@coffey.com>
  16976. Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  16977. Date: 15 Oct 1999 11:25:46 -0600
  16978.  
  16979. Great idea.  Set up a date and time.  I doubt that it will do much good 
  16980. though.  We rant and rave about every 4 months regarding the same topics 
  16981. and 3Com remains silent.  I also liked the suggestion about discussing this 
  16982. in some public stock trading forums.  Perhaps if some of the 3Com moguls 
  16983. notice a drop in the stock prices/net worth, they might be inclined to 
  16984. investigate the cause.
  16985.  
  16986.  
  16987.  
  16988. At 06:46 PM 10/14/99 -0700, you wrote:
  16989. >Maybe we should all gang up at ISPCon and do a mass movement from the 3Com
  16990. >booth over to the Cisco booth and see if 3Com notices then...
  16991.  
  16992.  
  16993. Thanks, Greg Coffey                     <gcoffey@vcn.com>
  16994. Visionary Communications V 307-234-5443 F 307-234-5446
  16995. 100 N. Center, Casper, WY  82601         www.vcn.com
  16996.  
  16997. -
  16998.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16999.  with "unsubscribe usr-tc" in the body of the message.
  17000.  For information on digests or retrieving files and old messages send
  17001.  "help" to the same address.  Do not use quotes in your message.
  17002.  
  17003.  
  17004. -------------------------------------------------------------------------------
  17005.  
  17006. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  17007. Subject: Re: (usr-tc) Ah...what the heck...
  17008. Date: 15 Oct 1999 13:00:58 -0500
  17009.  
  17010.  
  17011.  
  17012.  
  17013. >Is it possible to restrict access to a subnet or subnets such that any
  17014. >machine on that subnet can access TCM?
  17015.  
  17016.    Yes, You are allowed up to ten entries, each containing an IP address and a
  17017. network mask.
  17018.  
  17019. If you mess up putting in the restrictions and can't get in from snmp/TCM
  17020. anymore, you can reset the list from the NMC Console port with  Command |
  17021. ReinitializeAccessList, or just reboot the NMC if you'd like, since you hadn't
  17022. saved the config yet.
  17023.  
  17024. STeve
  17025.  
  17026.  
  17027.  
  17028.  
  17029. mmm3@cornell.edu on 10/14/99 04:00:34 PM
  17030.  
  17031. Please respond to usr-tc@lists.xmission.com
  17032.  
  17033. Sent by:  mmm3@cornell.edu
  17034.  
  17035.  
  17036. cc:    (Steve Valiunas/MW/US/3Com)
  17037.  
  17038.  
  17039.  
  17040.  
  17041. >The NMC DOES have an Authorized Stations list, in which you can limit snmp
  17042. >access to a given set of ip addresses.  It would be probably be a good idea to
  17043. >use it.  WIthin TCM its uner Security | Authorized Stations.
  17044. >
  17045. >STeve
  17046.  
  17047. Is it possible to restrict access to a subnet or subnets such that any
  17048. machine on that subnet can access TCM?
  17049.  
  17050. *********************************************************
  17051. Michelle M. Mogil
  17052. Network and Computing Systems
  17053. 721 Rhodes Hall, Cornell University, Ithaca, NY 14853
  17054. vox: (607) 255-0516, fax: (607) 255-8420
  17055. email: mmm3@cornell.edu
  17056. **********************************************
  17057.  
  17058.  
  17059.  
  17060. -
  17061.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17062.  with "unsubscribe usr-tc" in the body of the message.
  17063.  For information on digests or retrieving files and old messages send
  17064.  "help" to the same address.  Do not use quotes in your message.
  17065.  
  17066.  
  17067.  
  17068.  
  17069.  
  17070.  
  17071. -
  17072.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17073.  with "unsubscribe usr-tc" in the body of the message.
  17074.  For information on digests or retrieving files and old messages send
  17075.  "help" to the same address.  Do not use quotes in your message.
  17076.  
  17077.  
  17078. -------------------------------------------------------------------------------
  17079.  
  17080. From: "Russ Miescke" <russm@powerweb.net>
  17081. Subject: Re: (usr-tc) 2.0.60 HDM Code
  17082. Date: 15 Oct 1999 13:41:48 -0700
  17083.  
  17084. Does 2.0.60 break any other things?  I am having a tough time with this
  17085. hanging DSP problem.  I am getting 2.0.60 sent to me, but am interested to
  17086. see what it breaks if anything.
  17087. Russ Miescke
  17088. Power Web Connect
  17089. ----- Original Message -----
  17090. Sent: Friday, October 15, 1999 9:42 AM
  17091.  
  17092.  
  17093. >
  17094. > > O, they *do* offer software download only support.........its just that
  17095. I
  17096. > > am not entirely happy with that pricing either.
  17097. >
  17098. > I love the hardware, but I'm not entirely happy with their software. A
  17099. > version of arc code that fixes one problem breaks 3 other things! I think
  17100. > 3com should make *all* their releases Beta, not just ERs. Because we seem
  17101. > to be the Beta testers even with their production level code. Has 3com
  17102. > considered a code freeze, so they can fix the problems in their existing
  17103. > code and not keep adding broken features to already broken code? Maybe
  17104. > 3com should do what Linux kernel developers do; have one version of
  17105. > code-base that is stable, and yet another version for those individuals
  17106. > who want to "live on the edge" with new features, but most importantly,
  17107. > keep working on and improving *both* versions at the same time.
  17108. >
  17109. > I know it's not easy 3com, and I understand that everyone wants new
  17110. > features right away. However, what makes me mad is the fact that 3com
  17111. > charges *us* to fix *their* mistakes. I understand small bugs, everything
  17112. > has small bugs, but *major* problems such as security flaws or bugs that
  17113. > effect the basic functionality of their products should be fixed free of
  17114. > charge. And when we do buy service contracts with software support, we
  17115. > should be able to at least access the code and security updates
  17116. > we had access to during our contracts after it expires on us. Because
  17117. > after all, we did pay for it. Either that or I'll just have to start
  17118. > mirroring.
  17119. >
  17120. > Even Micro$oft offers free updates without a "service contract" for most
  17121. > of their products when it comes to security issues; however, *like*
  17122. > 3com, Microsoft never seems to find all the bugs. ;) I know things
  17123. > will get better, because 3com has very smart people and they are
  17124. > listening, right? I hope 3com does the right thing and develops
  17125. > a more "customer friendly" approach when it comes to software updates and
  17126. > support.
  17127. >
  17128. > -
  17129. > andrew
  17130. >
  17131. >
  17132. > -
  17133. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17134. >  with "unsubscribe usr-tc" in the body of the message.
  17135. >  For information on digests or retrieving files and old messages send
  17136. >  "help" to the same address.  Do not use quotes in your message.
  17137. >
  17138.  
  17139.  
  17140. -
  17141.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17142.  with "unsubscribe usr-tc" in the body of the message.
  17143.  For information on digests or retrieving files and old messages send
  17144.  "help" to the same address.  Do not use quotes in your message.
  17145.  
  17146.  
  17147. -------------------------------------------------------------------------------
  17148.  
  17149. From: mmm3@cornell.edu
  17150. Subject: Re: (usr-tc) Ah...what the heck...
  17151. Date: 15 Oct 1999 15:02:41 -0400
  17152.  
  17153. >>Is it possible to restrict access to a subnet or subnets such that any
  17154. >>machine on that subnet can access TCM?
  17155. >
  17156. >   Yes, You are allowed up to ten entries, each containing an IP address and a
  17157. >network mask.
  17158.  
  17159. Right, but I was under the impression the IP address had to be of a
  17160. specific node machine, not set to--for example--128.253.180.0/24 so
  17161. that *any* machine, regardless of node address, could access TCM from
  17162. that subNet. Or am I being dense here?
  17163.  
  17164. >
  17165. >If you mess up putting in the restrictions and can't get in from snmp/TCM
  17166. >anymore, you can reset the list from the NMC Console port with  Command |
  17167. >ReinitializeAccessList, or just reboot the NMC if you'd like, since you hadn't
  17168. >saved the config yet.
  17169.  
  17170. Oh, I *never* mess up. 8-)
  17171.  
  17172. *********************************************************
  17173. Michelle M. Mogil
  17174. Network and Computing Systems
  17175. 721 Rhodes Hall, Cornell University, Ithaca, NY 14853
  17176. vox: (607) 255-0516, fax: (607) 255-8420
  17177. email: mmm3@cornell.edu
  17178. **********************************************
  17179.  
  17180.  
  17181.  
  17182. -
  17183.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17184.  with "unsubscribe usr-tc" in the body of the message.
  17185.  For information on digests or retrieving files and old messages send
  17186.  "help" to the same address.  Do not use quotes in your message.
  17187.  
  17188.  
  17189. -------------------------------------------------------------------------------
  17190.  
  17191. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  17192. Subject: Re: (usr-tc) Ah...what the heck...
  17193. Date: 15 Oct 1999 14:42:57 -0500
  17194.  
  17195.  
  17196.  
  17197. If you were to enter 128.253.180.0 / 255.255.255.0  then only those IPs from
  17198. 128.253.180.1 through 128.253.180.254  would be able to access the NMC.
  17199. You can still, as you said, enter an particular IP address- 128.253.180.12 /
  17200. 255.255.255.255 for example.
  17201.  
  17202. Steve
  17203.  
  17204.  
  17205.  
  17206.  
  17207. mmm3@cornell.edu on 10/15/99 02:02:41 PM
  17208.  
  17209. Please respond to usr-tc@lists.xmission.com
  17210.  
  17211. Sent by:  mmm3@cornell.edu
  17212.  
  17213.  
  17214. cc:    (Steve Valiunas/MW/US/3Com)
  17215.  
  17216.  
  17217.  
  17218.  
  17219. >>Is it possible to restrict access to a subnet or subnets such that any
  17220. >>machine on that subnet can access TCM?
  17221. >
  17222. >   Yes, You are allowed up to ten entries, each containing an IP address and a
  17223. >network mask.
  17224.  
  17225. Right, but I was under the impression the IP address had to be of a
  17226. specific node machine, not set to--for example--128.253.180.0/24 so
  17227. that *any* machine, regardless of node address, could access TCM from
  17228. that subNet. Or am I being dense here?
  17229.  
  17230. >
  17231. >If you mess up putting in the restrictions and can't get in from snmp/TCM
  17232. >anymore, you can reset the list from the NMC Console port with  Command |
  17233. >ReinitializeAccessList, or just reboot the NMC if you'd like, since you hadn't
  17234. >saved the config yet.
  17235.  
  17236. Oh, I *never* mess up. 8-)
  17237.  
  17238. *********************************************************
  17239. Michelle M. Mogil
  17240. Network and Computing Systems
  17241. 721 Rhodes Hall, Cornell University, Ithaca, NY 14853
  17242. vox: (607) 255-0516, fax: (607) 255-8420
  17243. email: mmm3@cornell.edu
  17244. **********************************************
  17245.  
  17246.  
  17247.  
  17248. -
  17249.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17250.  with "unsubscribe usr-tc" in the body of the message.
  17251.  For information on digests or retrieving files and old messages send
  17252.  "help" to the same address.  Do not use quotes in your message.
  17253.  
  17254.  
  17255.  
  17256.  
  17257.  
  17258.  
  17259. -
  17260.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17261.  with "unsubscribe usr-tc" in the body of the message.
  17262.  For information on digests or retrieving files and old messages send
  17263.  "help" to the same address.  Do not use quotes in your message.
  17264.  
  17265.  
  17266. -------------------------------------------------------------------------------
  17267.  
  17268. From: mmm3@cornell.edu
  17269. Subject: Re: (usr-tc) Ah...what the heck...
  17270. Date: 15 Oct 1999 16:01:39 -0400
  17271.  
  17272. >If you were to enter 128.253.180.0 / 255.255.255.0  then only those IPs from
  17273. >128.253.180.1 through 128.253.180.254  would be able to access the NMC.
  17274. >You can still, as you said, enter an particular IP address- 128.253.180.12 /
  17275. >255.255.255.255 for example.
  17276. >
  17277. >Steve
  17278.  
  17279. D'oh! Thanks.... 8-)
  17280.  
  17281. *********************************************************
  17282. Michelle M. Mogil
  17283. Network and Computing Systems
  17284. 721 Rhodes Hall, Cornell University, Ithaca, NY 14853
  17285. vox: (607) 255-0516, fax: (607) 255-8420
  17286. email: mmm3@cornell.edu
  17287. **********************************************
  17288.  
  17289.  
  17290.  
  17291. -
  17292.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17293.  with "unsubscribe usr-tc" in the body of the message.
  17294.  For information on digests or retrieving files and old messages send
  17295.  "help" to the same address.  Do not use quotes in your message.
  17296.  
  17297.  
  17298. -------------------------------------------------------------------------------
  17299.  
  17300. From: Richard Lorbieski <richard@alpha1.net>
  17301. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  17302. Date: 15 Oct 1999 15:01:26 -0500
  17303.  
  17304. Speaking of ball parks... What if 3Com really managed 3Com Park?
  17305.  
  17306. It should go like this:
  17307.  
  17308. Three friends and myself went to a baseball game at 3Com park. The
  17309. ticket prices were not only based on seating location, but also on your
  17310. size. So my ticket was 25.34, and my friends paid 12.56, 17.45, and
  17311. 21.92 (plus tax).
  17312.  
  17313. Concessions:
  17314.  
  17315. They ONLY served hots dogs, fries and Pepsi. 
  17316.  
  17317. Beer was available but only if you had a beer drinking permit for $5.00.
  17318. However, since I was with my 3 friends (2 of them don't drink beer), I
  17319. had to purchase a permit for all of us ($20 total).
  17320.  
  17321. They had two kinds of beer - 3Com and 3Com Lite. 3Com Lite was brewed
  17322. several years ago by a company call Livingston and it had a bitter after
  17323. taste but I learned about this AFTER I bought my 3Com Lite. I went back
  17324. to the counter wanting to get a fresher beer or at least get my money
  17325. back. I was told by the manager that they are phasing out 3Com Lite and
  17326. my only option was I could buy 2 regular 3Com beers and then trade in my
  17327. 3Com Lite and get the third 3Com beer for free.
  17328.  
  17329. Restrooms:
  17330.  
  17331. Restrooms were opened to the general public ONLY between innings. If you
  17332. needed to use the restroom during the game, you had to purchase a
  17333. restroom contract, however, if the game goes into extra innings, you
  17334. would have to pay extra. 
  17335.  
  17336. I had to go really bad during the third inning, so I purchased a
  17337. contract for $5. However, since I was with my 3 friends, I had to pay
  17338. $20.
  17339.  
  17340. Well, by the time I got my restroom contract, it was the end of the
  17341. third inning.
  17342. So I had to wait in line with everyone else even though I had a special
  17343. contract.
  17344.  
  17345. Once I made it through the restroom door, there was yet another door
  17346. with another 3Com rep.in front of it. This time I had to show receipts
  17347. for my food/drink I purchased at the game, otherwise I would have to pay
  17348. another special disposal fee.
  17349.  
  17350. I finally got to the toilet stall but notice there was shredded
  17351. newspaper instead of toilet paper. I asked what happened to the toilet
  17352. paper. I was told 3Com sells single ply non-perferated toilet paper at
  17353. the counter at the back of the restroom. "Single ply?", I said. "Yeah,
  17354. we are working on a 2 ply perferated paper and should have it available
  17355. next week.", the 3Com rep blurted. Moreover, since I had a restroom
  17356. contract, I could trade in my single ply for the 2 ply when it became
  17357. available!
  17358.  
  17359. The rolls were $2 dollars each, but since I was with my 3 friends, I had
  17360. to purchase 4 rolls. 
  17361.  
  17362. After I relieved myself, I went to wash my hands. Instead of paper
  17363. towels, there was shredded newspaper. I went back to the restroom
  17364. counter and asked about the towels. Great news! 3Com just released their
  17365. 50 pack paper towels. I can get them for $3 dollars a pack, but guess
  17366. what, I had to purchase 4 packs. I thought, screwed the towels, I'll use
  17367. toilet paper. Wrong! Someone beside me was being ejected from the
  17368. primises for drying his hands with toilet paper. I learned later his
  17369. restroom contract was canceled. Anyway, I paid for the paper towels...   
  17370.  
  17371. Just before I exited the restroom, I was reminded that the toilet paper
  17372. and paper towels could only be used at this restroom and if I went to a
  17373. different restroom, I would have to pay again. Oh yeah, the restroom
  17374. contract is only good for THAT restroom!
  17375.  
  17376. It was the start of the 6th inning. I decided to make another trip to
  17377. the restroom. I had all my paperwork in order this time so it wasn't a
  17378. long wait. But I was detained because it was less than 30 minutes since
  17379. my last restroom visit. I was pulled over to the side and questioned by
  17380. 2 other 3Com ushers. I was asked repeatedly if I was sure I'm going to
  17381. the restroom because the result of the 3Com food. They suspected that it
  17382. must be something other than their food or maybe I was ill.
  17383.  
  17384. So, I was examined by a 3Com doctor, but before he would EVEN talk to
  17385. me. I had to present him with my restroom contract and food receipts. He
  17386. determined there was nothing wrong on their end and I must purchase the
  17387. special desposal fee for $10 (but paid $40 because of my buddies). 
  17388.  
  17389. Now I had everything in order.
  17390.  
  17391. Just before I got to the urinal, I was grabbed by a 3Com usher. He told
  17392. me that I can only use the same toilet I used on my first visit and was
  17393. not allowed to use any of the other urinals or toilets. I had to wait 5
  17394. more minutes because "my stall" was used by another person - and he
  17395. didn't have a contract!
  17396.  
  17397. FINAL INSULT:
  17398.  
  17399. The game went into extra innings so we had to cough up $10 each plus $20
  17400. more for my other friends - even though they left early because of an
  17401. emergency.
  17402.  
  17403. You may think this is silly. But this is how I feel 3Com treats Total
  17404. Control Chassis owners.
  17405.  
  17406.  
  17407. Ed wrote:
  17408. > 
  17409. > Marshall wrote:
  17410. > "Buy customer's happiness through goodwill instead of ball parks"
  17411. > 
  17412. > Thats a good one ;-)
  17413. > 
  17414. > Ed
  17415. > 
  17416. > ----- Original Message -----
  17417. > From: Marshall Morgan <marshall@netdoor.com>
  17418. > To: <usr-tc@lists.xmission.com>
  17419. > Sent: Friday, October 15, 1999 2:10 AM
  17420. > Subject: (usr-tc) ISPCon/3Com Open Meeting
  17421. > 
  17422. > Great Idea !!
  17423. > 
  17424. > Why don't we all have a mass (OPEN) meeting with 3com at ISPCon.  The other
  17425. > vendors will send people in as well and will get plenty of ammo for their
  17426. > executives that actually listen to their customer's complaints.  If 3com
  17427. > changes
  17428. > everything that night with a big announcement (hint hint) about cost
  17429. > effective
  17430. > hardware/technical support and software only support, then everyone, except
  17431. > the
  17432. > snoops from other companies, will be happy!
  17433. > 
  17434. > A win-win for everyone if 3C want's our continued business.  Buy customer's
  17435. > happiness through goodwill instead of ball parks.
  17436. > 
  17437. > Marshall Morgan
  17438. > President
  17439. > 
  17440. > Internet Doorway, Inc (aka NETDOOR)
  17441. > http://www.netdoor.com
  17442. > 
  17443. > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  17444. > 
  17445. > > -----Original Message-----
  17446. > > From: owner-usr-tc@lists.xmission.com
  17447. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski
  17448. > > Sent: Thursday, October 14, 1999 9:41 PM
  17449. > > To: usr-tc@lists.xmission.com
  17450. > > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  17451. > >
  17452. > >
  17453. > > Sorry, but only people with service contracts can visit the 3Com booth.
  17454. > >
  17455. > > Sheldon Koehler wrote:
  17456. > > >
  17457. > > > Maybe we should all gang up at ISPCon and do a mass movement from the
  17458. > 3Com
  17459. > > > booth over to the Cisco booth and see if 3Com notices then...
  17460. > > >
  17461. > 
  17462. > -
  17463. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17464. >  with "unsubscribe usr-tc" in the body of the message.
  17465. >  For information on digests or retrieving files and old messages send
  17466. >  "help" to the same address.  Do not use quotes in your message.
  17467. > 
  17468. > -
  17469. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17470. >  with "unsubscribe usr-tc" in the body of the message.
  17471. >  For information on digests or retrieving files and old messages send
  17472. >  "help" to the same address.  Do not use quotes in your message.
  17473.  
  17474. -- 
  17475.  
  17476. Richard Lorbieski - richard@alpha1.net
  17477. Chief Technical Officer - Senior System Administrator
  17478. Alpha1 Internet  http://www.alpha1.net
  17479. 409.731.8236  - 877.4.alpha1 (877.425.7421)
  17480.  
  17481. -
  17482.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17483.  with "unsubscribe usr-tc" in the body of the message.
  17484.  For information on digests or retrieving files and old messages send
  17485.  "help" to the same address.  Do not use quotes in your message.
  17486.  
  17487.  
  17488. -------------------------------------------------------------------------------
  17489.  
  17490. From: Greg Coffey <greg@coffey.com>
  17491. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  17492. Date: 15 Oct 1999 14:34:34 -0600
  17493.  
  17494. Great analogy, if only someone from 3Com gave a damn!!  This should be on 
  17495. every bulletin board in every 3Com building.
  17496.  
  17497.  
  17498. At 03:01 PM 10/15/99 -0500, you wrote:
  17499. >Speaking of ball parks... What if 3Com really managed 3Com Park?
  17500. >
  17501. >It should go like this:
  17502. >
  17503. >Three friends and myself went to a baseball game at 3Com park. The
  17504. >ticket prices were not only based on seating location, but also on your
  17505. >size. So my ticket was 25.34, and my friends paid 12.56, 17.45, and
  17506. >21.92 (plus tax).
  17507. >
  17508. >Concessions:
  17509.  
  17510.  
  17511. Thanks, Greg Coffey                     <gcoffey@vcn.com>
  17512. Visionary Communications V 307-234-5443 F 307-234-5446
  17513. 100 N. Center, Casper, WY  82601         www.vcn.com
  17514.  
  17515. -
  17516.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17517.  with "unsubscribe usr-tc" in the body of the message.
  17518.  For information on digests or retrieving files and old messages send
  17519.  "help" to the same address.  Do not use quotes in your message.
  17520.  
  17521.  
  17522. -------------------------------------------------------------------------------
  17523.  
  17524. From: Kevin Benton <s1kevin@tims.net>
  17525. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  17526. Date: 15 Oct 1999 17:48:39 -0400 (EDT)
  17527.  
  17528. On Fri, 15 Oct 1999, Blake Fithen wrote:
  17529.  
  17530. > What about "earn customers respect through display of
  17531. > competence"?  The only change I've noticed in 3com's tech
  17532. > support over the past year is the fact that someone from
  17533. > 3Com calls me and asks me about how my tech support call
  17534. > was handled.  "Do you feel the engineer was competent"? 
  17535. > "Did the engineer fix the problem"?, etc...
  17536. > 
  17537. > Tonight I called in to 3Com tech support because I have
  17538. > a problem of not remembering if channelized T1 can support
  17539. > ISDN.   I had a 'feeling' that it would not but I wanted 
  17540. > to get confirmation.  I asked the tech said question to 
  17541. > which he replied, "yes channelized T1 will support ISDN
  17542. > BRI calls, no problem."  To which I said, "are you sure?"
  17543. > He went to "double-check" on this enigma and he came back
  17544. > and said "no, I'm sorry, your customer cannot dial-in to
  17545. > your CT1 circuit."
  17546. > 
  17547. > At least he double-checked.
  17548. > 
  17549. > The bottom line is that I think 3Com should be harshly
  17550. > confronted about the quality of their tech-support and the
  17551. > fact that it is not worth what they are billing customers.
  17552.  
  17553. Well, our policy is that when we get garbage responses from 3Com, we call
  17554. our NC and sales rep to let him know 1) who the support rep was, 2) what
  17555. time the call was made, 3) what the ticket number was, and 4) what we were
  17556. told that was obviously wrong.
  17557.  
  17558. Kevin
  17559.  
  17560. E-Mail:  s1kevin@tims.net
  17561. Web:     http://users.sota-oh.com/~s1kevin/
  17562. Unsolicited advertisements processing fee: $50 subject to change without notice
  17563.  
  17564.  
  17565. -
  17566.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17567.  with "unsubscribe usr-tc" in the body of the message.
  17568.  For information on digests or retrieving files and old messages send
  17569.  "help" to the same address.  Do not use quotes in your message.
  17570.  
  17571.  
  17572. -------------------------------------------------------------------------------
  17573.  
  17574. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  17575. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  17576. Date: 15 Oct 1999 18:29:22 -0400 (EDT)
  17577.  
  17578.  
  17579. On Fri, 15 Oct 1999, Richard Lorbieski wrote:
  17580.  
  17581. > You may think this is silly. But this is how I feel 3Com treats Total
  17582. > Control Chassis owners.
  17583.  
  17584. I've mentioned my theory of 3com's attitude on here before, but maybe
  17585. time to do so again, working it into your analogy....
  17586.  
  17587. You see, this 3com Park ballfield really isn't designed for individual
  17588. fans....a guy bringing a couple friends to the game is just rif-raf;
  17589. troublesome whiners who always complain about dirty seats and always
  17590. having to scrape their change up to buy a hot dog. At 3com Park, there's
  17591. a new business model, y'see. There's a lot of BigTime companies who have
  17592. vast amounts of money to toss around....companies who are quite used to
  17593. (and even expect) expensive service contracts. And these companies aren't
  17594. interested in four seats at a ball game, they are interested in buying
  17595. blocks of seats for the entire season. Sometimes as much as a third of
  17596. the entire stadium. And that's the market 3com Park wants to go for;
  17597. it's more profitable than the pesky individual fans and their buds who
  17598. got them to where they are now, whos' money built the new ballpark.
  17599.  
  17600. In other words, it's my theory that 3com is now more interested in big
  17601. telcos. Integrating the TC and phone switches and stuff like putting
  17602. ADSL and traditional dialup in the CO. $Billions is an understatement
  17603. for their target here....imagine TC racks in every telco CO everywhere,
  17604. all bought and owned by companies who are quite used to paying way too
  17605. much for eqipment and service contracts, companies who have entire
  17606. departments to keep all the proper paperwork straight. Companies who
  17607. don't whine when charged $10 to go to the bathroom because they can
  17608. just file for a rate increase to cover the operating costs.
  17609.  
  17610. So you can see the rapid loss of interest in ISPs who "only" have a
  17611. few hundred TC racks...or especially those piddling little guys who
  17612. only have a couple. If you can play ball by the BigTime rules, fine,
  17613. you'll be put up with and used to beta test all the hardware they
  17614. want to sell to the BigBoyz....if not, oh well, c'est la vie. Moot
  17615. point really, because if they hit the target of selling to the telcos,
  17616. most of those "small" players will be going out of business anyway.
  17617.  
  17618. Not surprising, really....I mean, consider how much NorTel would care
  17619. about you if you wanted only one DMS-10 (or just one barebones DMS100).
  17620. Or how much Boeing would cater to your wishes because you own just one
  17621. or two of their airplanes.
  17622.  
  17623. [rant]
  17624.  
  17625. But it is sad. Unlike the other two examples, it's a case of turning
  17626. their backs on the market that put them where they are today. NorTel
  17627. didn't start by targeting the hobbiest market, USR did. That they are
  17628. even a player now is directly due to the small BBS market and later the
  17629. ISP market. I can easily remember a time, not *that* many years ago,
  17630. when even a single-line BBS operator could call USR, identify himself as
  17631. a sysop, and get a direct line to engineering. You could report a bug
  17632. in your 14.4k Courier, and not only would they burn a new ROM for you
  17633. and fedex it to you (even if it was alpha or beta code), but you'd be
  17634. sincerely *thanked* for finding it for 'em and testing out the new
  17635. ROM that you'd get the next day. It was this level of support which
  17636. garnered them the BBS market, and then the consumer market (who needed
  17637. the same kind of modem that their favorite BBS used). The BBS operators
  17638. also started spec'ing USR stuff at their workplace, and then a good
  17639. number of BBS sysops started ISPs, continuing the trend. At the time,
  17640. a rack full of dual 28.8k Couriers was deserving of the pure lust it
  17641. inspired in the hearts of people involved with dialup.
  17642.  
  17643. Once upon a time, us "small time" operators were USR's favorite children.
  17644. 3com came in and pointed out that we've got red hair, freckles, and were
  17645. actually a product of a previous marriage. Currently, I don't know of
  17646. any other company that has made me feel so unwanted; it's like they're
  17647. actively trying to chase me away.
  17648.  
  17649. My only wish is that I didn't pick up on this earlier....like when I
  17650. was at the 3com booth at a convention, looking to purchase, and it was
  17651. hinted that I was too small to talk to, and was directly told that I
  17652. needed to go to a resellers booth for info. [funny thing was...the
  17653. reseller they told me to go to told me I didn't want 3com, that I should
  17654. buy Ascend]. Another funny thing is that the folks at the Nortel booth
  17655. chatted with me for a good while about telco switches...and I told them
  17656. directly at the beginning that I was small fry and had no immediate
  17657. need to buy, and probably never would be able to.
  17658.  
  17659. The only saving grace is that at least in my case, I love my HARC and
  17660. HDSPs....I'm running old code, but they still kick serious ass in my
  17661. case. In the past year, one HDSP rebooted itself for no apparent reason,
  17662. one modem hung up and needed a reset, and one HDSP suddenly decided that
  17663. the D-channel was down (but a reboot fixed that...the D-channel was fine).
  17664. The old code I'm running has problems with some old Rockwell stuff and
  17665. other crappy no-name modems, but it doesn't have a lot of the problems
  17666. I hear about on the list nowadays.
  17667.  
  17668. The other saving grace is this mailing list, and the handful of 3com
  17669. people that populate it. I actually hesitate in bashing 3com on here
  17670. because the 3com people that actually see it aren't the problem, and
  17671. they're more deserving of praise rather than seeing stuff that'll just
  17672. alienate them more and make 'em think I'm an ingrate. My biggest worry
  17673. at the moment is that someday, some 3com exec will learn that support
  17674. is being doled out on this list for *shudder* FREE, and order the other
  17675. 3com employees to not participate here (or require a service contract
  17676. to subscribe to the list where they do participate).
  17677.  
  17678. The thing is, it's not like my desires here are out of touch with
  17679. reality. I want a *reasonably priced* service contract that gives me
  17680. access to the code and spare-in-the-air replacement. I want the
  17681. requirement that all chassis' I own be covered to be dropped (I own
  17682. a spare, it's sitting in my closet...I resent having to actively cover
  17683. it, especially since it's only there because 'spare-in-the-air' is about
  17684. 24-48 hours too late for me). And by "reasonably priced", I *don't* mean
  17685. 20 friggin percent of the purchase price per annum, either. I may even
  17686. be tempted to buy support, if said support was better than my part-time
  17687. theatre-major can deliver....even she can tell me to try rebooting the
  17688. chassis. Give me a test or something, and give me direct access to
  17689. support commensurate with my score.  75%, direct to level 2, 100% direct
  17690. to eng. or somesuch. Leave your level 1 tech support in place for people
  17691. like my so-called competition, who retired from the National Guard and
  17692. started an ISP on a whim with no prior computer or networking experience.
  17693.  
  17694. [/rant]
  17695.  
  17696. Thanks, listpeople, I feel much better now. (:
  17697.  
  17698. Lon Stockton
  17699.  
  17700.  
  17701.  
  17702. -
  17703.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17704.  with "unsubscribe usr-tc" in the body of the message.
  17705.  For information on digests or retrieving files and old messages send
  17706.  "help" to the same address.  Do not use quotes in your message.
  17707.  
  17708.  
  17709. -------------------------------------------------------------------------------
  17710.  
  17711. From: Allen Marsalis <am@shreve.net>
  17712. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  17713. Date: 15 Oct 1999 18:38:55 -0500
  17714.  
  17715. At 06:29 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
  17716.  
  17717. >In other words, it's my theory that 3com is now more interested in big
  17718. >telcos. Integrating the TC and phone switches and stuff like putting
  17719. >ADSL and traditional dialup in the CO. $Billions is an understatement
  17720.  
  17721. Bingo.  Last year, our 3com rep told us that if they sold one contract
  17722. to a single <unnamed> telco that they were working with, the sale would
  17723. constitute as many ports as they have sold in their history to date..
  17724. I doubt the deal ever happened though..
  17725.  
  17726. During the 80's recession, our local government spent millions trying
  17727. to lure McDonald Douglas into building a new factory at our city.
  17728. We lost the 'beauty contest' hosted by a dozen cities. In fact, the
  17729. new factory was never built at all.  What about the little guy?  The
  17730. ones who really keep the city going?  Where is our tax abatement?
  17731. and other incentives?  If only they had spend their efforts and money
  17732. in a way that would have really helped people in our area...
  17733.  
  17734. >
  17735. >My only wish is that I didn't pick up on this earlier....
  17736.  
  17737. I have no regrets..  x2 was a big deal in our area (we certainly helped)
  17738. and being the first 56k provider in our area was a big win for us.
  17739. USR made that happen..  I liked USR..  It's 3com that I feel ill about.
  17740. USR designed nearly all the hardware before the merger.  It's been
  17741. nearly 2 years now..  What has 3com created or added to the mix
  17742. to make it a good merger?  OSPF?  great!  only took 3-4 years..
  17743. Where is the SS7 gateway?  higher density modems per DSP?  VoIP?
  17744. cool PPC code features and all that jazz?  Aren't 2 of the 3 PPC's
  17745. on the board doing nothing?  Do we use 3com switches or routers?
  17746. no we use cisco, foundry, etc..  I just don't see the overall
  17747. purpose/benefit of the merger..
  17748.  
  17749. Perhaps it's not only about humongous telcos on the one side, but
  17750. about CPE on the other..  something we buy very little of.. and we
  17751. are stuck in the middle... 
  17752.  
  17753.  
  17754. >
  17755. >The other saving grace is this mailing list, and the handful of 3com
  17756. >people that populate it. I actually hesitate in bashing 3com on here
  17757. >because the 3com people that actually see it aren't the problem, and
  17758. >they're more deserving of praise rather than seeing stuff that'll just
  17759. >alienate them more and make 'em think I'm an ingrate.
  17760.  
  17761. agreed.
  17762.  
  17763. Allen
  17764.  
  17765.  
  17766.  
  17767. -
  17768.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17769.  with "unsubscribe usr-tc" in the body of the message.
  17770.  For information on digests or retrieving files and old messages send
  17771.  "help" to the same address.  Do not use quotes in your message.
  17772.  
  17773.  
  17774. -------------------------------------------------------------------------------
  17775.  
  17776. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  17777. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  17778. Date: 15 Oct 1999 21:15:14 -0400 (EDT)
  17779.  
  17780.  
  17781. On Fri, 15 Oct 1999, Allen Marsalis wrote:
  17782.  
  17783. > I have no regrets..  x2 was a big deal in our area (we certainly helped)
  17784. > and being the first 56k provider in our area was a big win for us.
  17785. > USR made that happen..  I liked USR..  It's 3com that I feel ill about.
  17786.  
  17787. Agreed here too. Getting my TC rack was a big win for us, and having it
  17788. still is. We were first with x2, first with v.90, and our v.90 *still*
  17789. walks all over my competitions' PM-based dialup pools. And we're still
  17790. the only provider in town doing ISDN, which is the best thing you can
  17791. get here aside from a dedicated line. (and we're served by Sprint, who
  17792. has some really good ISDN BRI pricing...only about $5 more than two
  17793. regular phone lines and flat-rate to boot...not to mention that inbound
  17794. PRIs are about 1/2 the cost of CT1's).
  17795.  
  17796.  
  17797. > Do we use 3com switches or routers?  no we use cisco, foundry, etc..
  17798.  
  17799. I'm actually a fan of their switches. But one doesn't have the same
  17800. problems...either a ethernet switch works or it doesn't. If it's
  17801. broken, either it's under warranty or it's not. No contracts, no
  17802. tech support needed. But yeah, we're using Cisco routers...but even that
  17803. may change. Am looking at all the PCI-based WAN cards nowadays and
  17804. great strides in Linux networking (or the already good networking in
  17805. the *BSD stuff) with great interest.
  17806.  
  17807. Not to mention the product brochure I got the other day...PCI based
  17808. card that works like a HDSP...plug in a PRI and get 23 modem ports
  17809. available to your Linux or NT box. Definately on my list of 'keep an
  17810. eye on' products.
  17811.  
  17812.  
  17813.  
  17814. -
  17815.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17816.  with "unsubscribe usr-tc" in the body of the message.
  17817.  For information on digests or retrieving files and old messages send
  17818.  "help" to the same address.  Do not use quotes in your message.
  17819.  
  17820.  
  17821. -------------------------------------------------------------------------------
  17822.  
  17823. From: K Mitchell <mitch@keyconn.net>
  17824. Subject: (usr-tc) badmodems.pl
  17825. Date: 15 Oct 1999 21:53:04 -0400
  17826.  
  17827.   I got Eric Billeter's badmodems.pl script to work checking failure rates,
  17828. but I'm having 2 issues with it;
  17829. 1. The output file isn't being named/placed correctly. The line
  17830. my $outputfile - "e:\inetpub\mrtg\modem-fail.htm";
  17831. puts a file named inetpubmrtgmodem-fail.htm directly on the e:\ drive.
  17832. 2. I would like to either schedule it to run when called by a webpage link
  17833. or button, or, failing that, schedule it to run every so often.
  17834.   Any ideas for either?
  17835.  
  17836. Thanks,
  17837.  
  17838. -- 
  17839. Kirk Mitchell-General Manager        mitch@keyconn.net
  17840. Keystone Connect                     Unlock Your World
  17841. Altoona, PA   814-941-5000      http://www.keyconn.net
  17842.  
  17843.  
  17844. -
  17845.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17846.  with "unsubscribe usr-tc" in the body of the message.
  17847.  For information on digests or retrieving files and old messages send
  17848.  "help" to the same address.  Do not use quotes in your message.
  17849.  
  17850.  
  17851. -------------------------------------------------------------------------------
  17852.  
  17853. From: Brian <signal@shreve.net>
  17854. Subject: Re: (usr-tc) badmodems.pl
  17855. Date: 15 Oct 1999 21:19:57 -0500 (CDT)
  17856.  
  17857.  
  17858. did you try escaping the backslashes like:
  17859.  
  17860. my $outputfile = "e:\\inetpub\\mrtg\\modem-fail.htm";
  17861.  
  17862. On Fri, 15 Oct 1999, K Mitchell wrote:
  17863.  
  17864. >   I got Eric Billeter's badmodems.pl script to work checking failure rates,
  17865. > but I'm having 2 issues with it;
  17866. > 1. The output file isn't being named/placed correctly. The line
  17867. > my $outputfile - "e:\inetpub\mrtg\modem-fail.htm";
  17868. > puts a file named inetpubmrtgmodem-fail.htm directly on the e:\ drive.
  17869. > 2. I would like to either schedule it to run when called by a webpage link
  17870. > or button, or, failing that, schedule it to run every so often.
  17871. >   Any ideas for either?
  17872. > 
  17873. > Thanks,
  17874. > 
  17875. > -- 
  17876. > Kirk Mitchell-General Manager        mitch@keyconn.net
  17877. > Keystone Connect                     Unlock Your World
  17878. > Altoona, PA   814-941-5000      http://www.keyconn.net
  17879. > 
  17880. > 
  17881. > -
  17882. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17883. >  with "unsubscribe usr-tc" in the body of the message.
  17884. >  For information on digests or retrieving files and old messages send
  17885. >  "help" to the same address.  Do not use quotes in your message.
  17886. > 
  17887.  
  17888. Brian Feeny (BF304)     signal@shreve.net   
  17889. 318-222-2638 x 109    http://www.shreve.net/~signal      
  17890. Network Administrator   ShreveNet Inc. (ASN 11881)           
  17891.  
  17892.  
  17893. -
  17894.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17895.  with "unsubscribe usr-tc" in the body of the message.
  17896.  For information on digests or retrieving files and old messages send
  17897.  "help" to the same address.  Do not use quotes in your message.
  17898.  
  17899.  
  17900. -------------------------------------------------------------------------------
  17901.  
  17902. From: K Mitchell <mitch@keyconn.net>
  17903. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  17904. Date: 15 Oct 1999 22:21:33 -0400
  17905.  
  17906. At 03:01 PM 10/15/99 -0500, Richard Lorbieski <richard@alpha1.net> wrote:
  17907. >Speaking of ball parks... What if 3Com really managed 3Com Park?
  17908. >
  17909. >It should go like this:
  17910. >
  17911. >Three friends and myself went to a baseball game at 3Com park. The
  17912. >ticket prices were not only based on seating location, but also on your
  17913. >size. So my ticket was 25.34, and my friends paid 12.56, 17.45, and
  17914. >21.92 (plus tax).
  17915. >
  17916. [snip]
  17917. >
  17918. >FINAL INSULT:
  17919. >
  17920. >The game went into extra innings so we had to cough up $10 each plus $20
  17921. >more for my other friends - even though they left early because of an
  17922. >emergency.
  17923.  
  17924. Yes, but who won the game??  ;o)
  17925.  
  17926.  
  17927. -- 
  17928. Kirk Mitchell-General Manager        mitch@keyconn.net
  17929. Keystone Connect                     Unlock Your World
  17930. Altoona, PA   814-941-5000      http://www.keyconn.net
  17931.  
  17932.  
  17933. -
  17934.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17935.  with "unsubscribe usr-tc" in the body of the message.
  17936.  For information on digests or retrieving files and old messages send
  17937.  "help" to the same address.  Do not use quotes in your message.
  17938.  
  17939.  
  17940. -------------------------------------------------------------------------------
  17941.  
  17942. From: K Mitchell <mitch@keyconn.net>
  17943. Subject: Re: (usr-tc) badmodems.pl
  17944. Date: 15 Oct 1999 22:34:03 -0400
  17945.  
  17946. At 09:19 PM 10/15/99 -0500, Brian wrote:
  17947. >
  17948. >did you try escaping the backslashes like:
  17949. >
  17950. >my $outputfile = "e:\\inetpub\\mrtg\\modem-fail.htm";
  17951.  
  17952. I hadn't tried that, it worked. I had tried e:%\inetpub%\mrtg... and just
  17953. ended up with the same name including %'s.
  17954.  
  17955. Thanks a bunch,
  17956.  
  17957. -- 
  17958. Kirk Mitchell-General Manager        mitch@keyconn.net
  17959. Keystone Connect                     Unlock Your World
  17960. Altoona, PA   814-941-5000      http://www.keyconn.net
  17961.  
  17962.  
  17963. -
  17964.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17965.  with "unsubscribe usr-tc" in the body of the message.
  17966.  For information on digests or retrieving files and old messages send
  17967.  "help" to the same address.  Do not use quotes in your message.
  17968.  
  17969.  
  17970. -------------------------------------------------------------------------------
  17971.  
  17972. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  17973. Subject: RE: (usr-tc) badmodems.pl
  17974. Date: 15 Oct 1999 23:42:20 -0300
  17975.  
  17976.  
  17977. You could rewrite part of the script to make it output HTML directly to
  17978. STDOUT so that it generates your stats real-time.  I'm doing this with some
  17979. other SNMP scripts I wrote but, depending on the stats, you might be sitting
  17980. there a while waiting for it to do something.  If you want to run it
  17981. periodically you might want to consider using WINAT to schedule it if you're
  17982. on NT.
  17983.  
  17984. > -----Original Message-----
  17985. > From:    K Mitchell [SMTP:mitch@keyconn.net]
  17986. > Sent:    Friday, October 15, 1999 10:53 PM
  17987. > To:    usr-tc@lists.xmission.com
  17988. > Subject:    (usr-tc) badmodems.pl
  17989. > 
  17990. >   I got Eric Billeter's badmodems.pl script to work checking failure
  17991. > rates,
  17992. > but I'm having 2 issues with it;
  17993. > 1. The output file isn't being named/placed correctly. The line
  17994. > my $outputfile - "e:\inetpub\mrtg\modem-fail.htm";
  17995. > puts a file named inetpubmrtgmodem-fail.htm directly on the e:\ drive.
  17996. > 2. I would like to either schedule it to run when called by a webpage link
  17997. > or button, or, failing that, schedule it to run every so often.
  17998. >   Any ideas for either?
  17999. > 
  18000. > Thanks,
  18001. > 
  18002. > -- 
  18003. > Kirk Mitchell-General Manager        mitch@keyconn.net
  18004. > Keystone Connect                     Unlock Your World
  18005. > Altoona, PA   814-941-5000      http://www.keyconn.net
  18006. > 
  18007. > 
  18008. > -
  18009. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18010. >  with "unsubscribe usr-tc" in the body of the message.
  18011. >  For information on digests or retrieving files and old messages send
  18012. >  "help" to the same address.  Do not use quotes in your message.
  18013.  
  18014. -
  18015.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18016.  with "unsubscribe usr-tc" in the body of the message.
  18017.  For information on digests or retrieving files and old messages send
  18018.  "help" to the same address.  Do not use quotes in your message.
  18019.  
  18020.  
  18021. -------------------------------------------------------------------------------
  18022.  
  18023. From: K Mitchell <mitch@keyconn.net>
  18024. Subject: RE: (usr-tc) badmodems.pl
  18025. Date: 15 Oct 1999 23:19:56 -0400
  18026.  
  18027. At 11:42 PM 10/15/99 -0300, you wrote:
  18028. >
  18029. >You could rewrite part of the script to make it output HTML directly to
  18030. >STDOUT so that it generates your stats real-time.  I'm doing this with some
  18031. >other SNMP scripts I wrote but, depending on the stats, you might be sitting
  18032. >there a while waiting for it to do something.  If you want to run it
  18033. >periodically you might want to consider using WINAT to schedule it if you're
  18034. >on NT.
  18035.  
  18036. One other thing, I'd like to include the date/time the report was
  18037. generated. Is there an OID for getting this from the ARC or NMC?
  18038.  
  18039. -- 
  18040. Kirk Mitchell-General Manager        mitch@keyconn.net
  18041. Keystone Connect                     Unlock Your World
  18042. Altoona, PA   814-941-5000      http://www.keyconn.net
  18043.  
  18044.  
  18045. -
  18046.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18047.  with "unsubscribe usr-tc" in the body of the message.
  18048.  For information on digests or retrieving files and old messages send
  18049.  "help" to the same address.  Do not use quotes in your message.
  18050.  
  18051.  
  18052. -------------------------------------------------------------------------------
  18053.  
  18054. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  18055. Subject: RE: (usr-tc) badmodems.pl
  18056. Date: 16 Oct 1999 00:40:36 -0300
  18057.  
  18058.  
  18059. if your time is correct on the server where the report is generated it's
  18060. pretty trivial.
  18061.  
  18062. $time = localtime(time());
  18063. print "Report generated $time\n";
  18064.  
  18065. yields
  18066.  
  18067. Report generated Fri Oct 15 04:38:28 1999
  18068.  
  18069. > -----Original Message-----
  18070. > From:    K Mitchell [SMTP:mitch@keyconn.net]
  18071. > Sent:    Saturday, October 16, 1999 12:20 AM
  18072. > To:    usr-tc@lists.xmission.com
  18073. > Subject:    RE: (usr-tc) badmodems.pl
  18074. > 
  18075. > At 11:42 PM 10/15/99 -0300, you wrote:
  18076. > >
  18077. > >You could rewrite part of the script to make it output HTML directly to
  18078. > >STDOUT so that it generates your stats real-time.  I'm doing this with
  18079. > some
  18080. > >other SNMP scripts I wrote but, depending on the stats, you might be
  18081. > sitting
  18082. > >there a while waiting for it to do something.  If you want to run it
  18083. > >periodically you might want to consider using WINAT to schedule it if
  18084. > you're
  18085. > >on NT.
  18086. > 
  18087. > One other thing, I'd like to include the date/time the report was
  18088. > generated. Is there an OID for getting this from the ARC or NMC?
  18089. > 
  18090. > -- 
  18091. > Kirk Mitchell-General Manager        mitch@keyconn.net
  18092. > Keystone Connect                     Unlock Your World
  18093. > Altoona, PA   814-941-5000      http://www.keyconn.net
  18094. > 
  18095. > 
  18096. > -
  18097. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18098. >  with "unsubscribe usr-tc" in the body of the message.
  18099. >  For information on digests or retrieving files and old messages send
  18100. >  "help" to the same address.  Do not use quotes in your message.
  18101.  
  18102. -
  18103.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18104.  with "unsubscribe usr-tc" in the body of the message.
  18105.  For information on digests or retrieving files and old messages send
  18106.  "help" to the same address.  Do not use quotes in your message.
  18107.  
  18108.  
  18109. -------------------------------------------------------------------------------
  18110.  
  18111. From: K Mitchell <mitch@keyconn.net>
  18112. Subject: RE: (usr-tc) badmodems.pl
  18113. Date: 15 Oct 1999 23:53:47 -0400
  18114.  
  18115. At 12:40 AM 10/16/99 -0300, Matthew wrote:
  18116. >
  18117. >if your time is correct on the server where the report is generated it's
  18118. >pretty trivial.
  18119. >
  18120. >$time = localtime(time());
  18121. >print "Report generated $time\n";
  18122.  
  18123. That got it, Thanks.
  18124.  
  18125.  
  18126. -- 
  18127. Kirk Mitchell-General Manager        mitch@keyconn.net
  18128. Keystone Connect                     Unlock Your World
  18129. Altoona, PA   814-941-5000      http://www.keyconn.net
  18130.  
  18131.  
  18132. -
  18133.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18134.  with "unsubscribe usr-tc" in the body of the message.
  18135.  For information on digests or retrieving files and old messages send
  18136.  "help" to the same address.  Do not use quotes in your message.
  18137.  
  18138.  
  18139. -------------------------------------------------------------------------------
  18140.  
  18141. From: moore@bcsnet.net (Mike Moore)
  18142. Subject: (usr-tc) S/A database cleanup?
  18143. Date: 16 Oct 1999 11:48:39 -0500
  18144.  
  18145. I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the database? It
  18146. is getting quite large. TIA!!!!!
  18147.  
  18148. Mike Moore
  18149. BCSNet
  18150.  
  18151.  
  18152. -
  18153.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18154.  with "unsubscribe usr-tc" in the body of the message.
  18155.  For information on digests or retrieving files and old messages send
  18156.  "help" to the same address.  Do not use quotes in your message.
  18157.  
  18158.  
  18159. -------------------------------------------------------------------------------
  18160.  
  18161. From: "Alex Bernal" <alex@chiriqui.com>
  18162. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18163. Date: 16 Oct 1999 13:12:37 -0600
  18164.  
  18165. I agree with you.
  18166.  
  18167. Alexander
  18168.  
  18169. ----- Original Message -----
  18170. Sent: Friday, October 15, 1999 4:29 PM
  18171.  
  18172.  
  18173. >
  18174. > On Fri, 15 Oct 1999, Richard Lorbieski wrote:
  18175. >
  18176. > > You may think this is silly. But this is how I feel 3Com treats Total
  18177. > > Control Chassis owners.
  18178. >
  18179. > I've mentioned my theory of 3com's attitude on here before, but maybe
  18180. > time to do so again, working it into your analogy....
  18181. >
  18182. > You see, this 3com Park ballfield really isn't designed for individual
  18183. > fans....a guy bringing a couple friends to the game is just rif-raf;
  18184. > troublesome whiners who always complain about dirty seats and always
  18185. > having to scrape their change up to buy a hot dog. At 3com Park, there's
  18186. > a new business model, y'see. There's a lot of BigTime companies who have
  18187. > vast amounts of money to toss around....companies who are quite used to
  18188. > (and even expect) expensive service contracts. And these companies aren't
  18189. > interested in four seats at a ball game, they are interested in buying
  18190. > blocks of seats for the entire season. Sometimes as much as a third of
  18191. > the entire stadium. And that's the market 3com Park wants to go for;
  18192. > it's more profitable than the pesky individual fans and their buds who
  18193. > got them to where they are now, whos' money built the new ballpark.
  18194. >
  18195. > In other words, it's my theory that 3com is now more interested in big
  18196. > telcos. Integrating the TC and phone switches and stuff like putting
  18197. > ADSL and traditional dialup in the CO. $Billions is an understatement
  18198. > for their target here....imagine TC racks in every telco CO everywhere,
  18199. > all bought and owned by companies who are quite used to paying way too
  18200. > much for eqipment and service contracts, companies who have entire
  18201. > departments to keep all the proper paperwork straight. Companies who
  18202. > don't whine when charged $10 to go to the bathroom because they can
  18203. > just file for a rate increase to cover the operating costs.
  18204. >
  18205. > So you can see the rapid loss of interest in ISPs who "only" have a
  18206. > few hundred TC racks...or especially those piddling little guys who
  18207. > only have a couple. If you can play ball by the BigTime rules, fine,
  18208. > you'll be put up with and used to beta test all the hardware they
  18209. > want to sell to the BigBoyz....if not, oh well, c'est la vie. Moot
  18210. > point really, because if they hit the target of selling to the telcos,
  18211. > most of those "small" players will be going out of business anyway.
  18212. >
  18213. > Not surprising, really....I mean, consider how much NorTel would care
  18214. > about you if you wanted only one DMS-10 (or just one barebones DMS100).
  18215. > Or how much Boeing would cater to your wishes because you own just one
  18216. > or two of their airplanes.
  18217. >
  18218. > [rant]
  18219. >
  18220. > But it is sad. Unlike the other two examples, it's a case of turning
  18221. > their backs on the market that put them where they are today. NorTel
  18222. > didn't start by targeting the hobbiest market, USR did. That they are
  18223. > even a player now is directly due to the small BBS market and later the
  18224. > ISP market. I can easily remember a time, not *that* many years ago,
  18225. > when even a single-line BBS operator could call USR, identify himself as
  18226. > a sysop, and get a direct line to engineering. You could report a bug
  18227. > in your 14.4k Courier, and not only would they burn a new ROM for you
  18228. > and fedex it to you (even if it was alpha or beta code), but you'd be
  18229. > sincerely *thanked* for finding it for 'em and testing out the new
  18230. > ROM that you'd get the next day. It was this level of support which
  18231. > garnered them the BBS market, and then the consumer market (who needed
  18232. > the same kind of modem that their favorite BBS used). The BBS operators
  18233. > also started spec'ing USR stuff at their workplace, and then a good
  18234. > number of BBS sysops started ISPs, continuing the trend. At the time,
  18235. > a rack full of dual 28.8k Couriers was deserving of the pure lust it
  18236. > inspired in the hearts of people involved with dialup.
  18237. >
  18238. > Once upon a time, us "small time" operators were USR's favorite children.
  18239. > 3com came in and pointed out that we've got red hair, freckles, and were
  18240. > actually a product of a previous marriage. Currently, I don't know of
  18241. > any other company that has made me feel so unwanted; it's like they're
  18242. > actively trying to chase me away.
  18243. >
  18244. > My only wish is that I didn't pick up on this earlier....like when I
  18245. > was at the 3com booth at a convention, looking to purchase, and it was
  18246. > hinted that I was too small to talk to, and was directly told that I
  18247. > needed to go to a resellers booth for info. [funny thing was...the
  18248. > reseller they told me to go to told me I didn't want 3com, that I should
  18249. > buy Ascend]. Another funny thing is that the folks at the Nortel booth
  18250. > chatted with me for a good while about telco switches...and I told them
  18251. > directly at the beginning that I was small fry and had no immediate
  18252. > need to buy, and probably never would be able to.
  18253. >
  18254. > The only saving grace is that at least in my case, I love my HARC and
  18255. > HDSPs....I'm running old code, but they still kick serious ass in my
  18256. > case. In the past year, one HDSP rebooted itself for no apparent reason,
  18257. > one modem hung up and needed a reset, and one HDSP suddenly decided that
  18258. > the D-channel was down (but a reboot fixed that...the D-channel was fine).
  18259. > The old code I'm running has problems with some old Rockwell stuff and
  18260. > other crappy no-name modems, but it doesn't have a lot of the problems
  18261. > I hear about on the list nowadays.
  18262. >
  18263. > The other saving grace is this mailing list, and the handful of 3com
  18264. > people that populate it. I actually hesitate in bashing 3com on here
  18265. > because the 3com people that actually see it aren't the problem, and
  18266. > they're more deserving of praise rather than seeing stuff that'll just
  18267. > alienate them more and make 'em think I'm an ingrate. My biggest worry
  18268. > at the moment is that someday, some 3com exec will learn that support
  18269. > is being doled out on this list for *shudder* FREE, and order the other
  18270. > 3com employees to not participate here (or require a service contract
  18271. > to subscribe to the list where they do participate).
  18272. >
  18273. > The thing is, it's not like my desires here are out of touch with
  18274. > reality. I want a *reasonably priced* service contract that gives me
  18275. > access to the code and spare-in-the-air replacement. I want the
  18276. > requirement that all chassis' I own be covered to be dropped (I own
  18277. > a spare, it's sitting in my closet...I resent having to actively cover
  18278. > it, especially since it's only there because 'spare-in-the-air' is about
  18279. > 24-48 hours too late for me). And by "reasonably priced", I *don't* mean
  18280. > 20 friggin percent of the purchase price per annum, either. I may even
  18281. > be tempted to buy support, if said support was better than my part-time
  18282. > theatre-major can deliver....even she can tell me to try rebooting the
  18283. > chassis. Give me a test or something, and give me direct access to
  18284. > support commensurate with my score.  75%, direct to level 2, 100% direct
  18285. > to eng. or somesuch. Leave your level 1 tech support in place for people
  18286. > like my so-called competition, who retired from the National Guard and
  18287. > started an ISP on a whim with no prior computer or networking experience.
  18288. >
  18289. > [/rant]
  18290. >
  18291. > Thanks, listpeople, I feel much better now. (:
  18292. >
  18293. > Lon Stockton
  18294. >
  18295. >
  18296. >
  18297. > -
  18298. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18299. >  with "unsubscribe usr-tc" in the body of the message.
  18300. >  For information on digests or retrieving files and old messages send
  18301. >  "help" to the same address.  Do not use quotes in your message.
  18302. >
  18303.  
  18304.  
  18305. -
  18306.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18307.  with "unsubscribe usr-tc" in the body of the message.
  18308.  For information on digests or retrieving files and old messages send
  18309.  "help" to the same address.  Do not use quotes in your message.
  18310.  
  18311.  
  18312. -------------------------------------------------------------------------------
  18313.  
  18314. From: "D. Randy Cosby" <dcosby@infowest.com>
  18315. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18316. Date: 16 Oct 1999 12:51:24 -0600 (MDT)
  18317.  
  18318. AMEN!
  18319.  
  18320. -
  18321.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18322.  with "unsubscribe usr-tc" in the body of the message.
  18323.  For information on digests or retrieving files and old messages send
  18324.  "help" to the same address.  Do not use quotes in your message.
  18325.  
  18326.  
  18327. -------------------------------------------------------------------------------
  18328.  
  18329. From: Allen Marsalis <am@shreve.net>
  18330. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18331. Date: 16 Oct 1999 17:11:12 -0500
  18332.  
  18333. At 09:15 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
  18334. >On Fri, 15 Oct 1999, Allen Marsalis wrote:
  18335. >
  18336. >> I have no regrets..  x2 was a big deal in our area (we certainly helped)
  18337. >> and being the first 56k provider in our area was a big win for us.
  18338. >> USR made that happen..  I liked USR..  It's 3com that I feel ill about.
  18339. >
  18340. >Agreed here too. Getting my TC rack was a big win for us, and having it
  18341. >still is. We were first with x2, first with v.90, and our v.90 *still*
  18342. >walks all over my competitions' PM-based dialup pools. And we're still
  18343. >the only provider in town doing ISDN, which is the best thing you can
  18344. >get here aside from a dedicated line. (and we're served by Sprint, who
  18345. >has some really good ISDN BRI pricing...only about $5 more than two
  18346. >regular phone lines and flat-rate to boot...not to mention that inbound
  18347. >PRIs are about 1/2 the cost of CT1's).
  18348.  
  18349. Same here.  That's pretty much exactly how we feel about it.  However
  18350. we occationally find a user with a good sportster/3com modem who can't
  18351. get v.90 on our TCS but can on our TNT (eval) and more importantly,
  18352. can with our competitors.  Users won't stay with 28.8 when they can
  18353. get 48k elsewhere..  If there were no modem code issues, I'd be more
  18354. than happy to send the eval back.  Instead, I'll probably get an invoice...
  18355.  
  18356. >
  18357. >> Do we use 3com switches or routers?  no we use cisco, foundry, etc..
  18358. >
  18359. >I'm actually a fan of their switches. But one doesn't have the same
  18360. >problems...either a ethernet switch works or it doesn't. If it's
  18361.  
  18362. Well back when we started, we bought a superstack and it worked of course
  18363. but when I found out it was half-duplex on all 10T ports, we sent it back
  18364. and opted for a catalyst..  But nowadays I'm sure things are different.
  18365. We outgrew the catalyst and now have a fastiron and we love it..
  18366.  
  18367. I realize that switches don't call for much support, but we did have
  18368. some issues with the catalyst.  Ciscos support as amazing and they
  18369. even called back again just to make sure we were happy.  3com on the
  18370. otherhand wanted to charge us for support on a 1 day old switch!
  18371. I just wanted to double check to see that their was no fdx on
  18372. the ports before sending it back.  They could have cared less whether
  18373. I returned it or not..  So I did!  
  18374.  
  18375. Allen
  18376.  
  18377.  
  18378. -
  18379.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18380.  with "unsubscribe usr-tc" in the body of the message.
  18381.  For information on digests or retrieving files and old messages send
  18382.  "help" to the same address.  Do not use quotes in your message.
  18383.  
  18384.  
  18385. -------------------------------------------------------------------------------
  18386.  
  18387. From: "Ed" <ed@taylors.com>
  18388. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18389. Date: 16 Oct 1999 19:45:53 -0400
  18390.  
  18391. Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
  18392. a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
  18393. problem that has been addressed but not resolved. You would think this would
  18394. concern 3com more than it does... just like all the complaints about support
  18395. on this list.
  18396.  
  18397. Oh well when everyone is switching to a different platform they may care but
  18398. it will be too late.
  18399.  
  18400.  
  18401. Ed
  18402.  
  18403. ----- Original Message -----
  18404. Sent: Saturday, October 16, 1999 6:11 PM
  18405.  
  18406.  
  18407. Same here.  That's pretty much exactly how we feel about it.  However
  18408. we occationally find a user with a good sportster/3com modem who can't
  18409. get v.90 on our TCS but can on our TNT (eval) and more importantly,
  18410. can with our competitors.  Users won't stay with 28.8 when they can
  18411. get 48k elsewhere..  If there were no modem code issues, I'd be more
  18412. than happy to send the eval back.  Instead, I'll probably get an invoice...
  18413.  
  18414. Well back when we started, we bought a superstack and it worked of course
  18415. but when I found out it was half-duplex on all 10T ports, we sent it back
  18416. and opted for a catalyst..  But nowadays I'm sure things are different.
  18417. We outgrew the catalyst and now have a fastiron and we love it..
  18418.  
  18419. I realize that switches don't call for much support, but we did have
  18420. some issues with the catalyst.  Ciscos support as amazing and they
  18421. even called back again just to make sure we were happy.  3com on the
  18422. otherhand wanted to charge us for support on a 1 day old switch!
  18423. I just wanted to double check to see that their was no fdx on
  18424. the ports before sending it back.  They could have cared less whether
  18425. I returned it or not..  So I did!
  18426.  
  18427. Allen
  18428.  
  18429.  
  18430. -
  18431.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18432.  with "unsubscribe usr-tc" in the body of the message.
  18433.  For information on digests or retrieving files and old messages send
  18434.  "help" to the same address.  Do not use quotes in your message.
  18435.  
  18436.  
  18437.  
  18438. -
  18439.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18440.  with "unsubscribe usr-tc" in the body of the message.
  18441.  For information on digests or retrieving files and old messages send
  18442.  "help" to the same address.  Do not use quotes in your message.
  18443.  
  18444.  
  18445. -------------------------------------------------------------------------------
  18446.  
  18447. From: Allen Marsalis <am@shreve.net>
  18448. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18449. Date: 16 Oct 1999 19:45:14 -0500
  18450.  
  18451. At 07:45 PM 10/16/99 -0400, Ed wrote:
  18452. >Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
  18453. >a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
  18454. >problem that has been addressed but not resolved. You would think this would
  18455. >concern 3com more than it does... just like all the complaints about support
  18456. >on this list.
  18457.  
  18458. Agreed.  I am certainly willing to replicate the problem for 3com and
  18459. arrange a meeting between a 3com engineer, a specific customer, and
  18460. ourselves..  They can watch the customer dial in a 3com chassis and
  18461. the TNT and pull all the stats they wish from both chassis as well as
  18462. the customers modem..  The data should be there to analzye if they
  18463. cared to do so.  I'll even swap spans and show them how the problem
  18464. follows the chassis and not the PRI's..
  18465.  
  18466. Unless they know what the problem already is and *can't* do anything
  18467. about it (like netserver UDP lag).
  18468.  
  18469. >
  18470. >Oh well when everyone is switching to a different platform they may care but
  18471. >it will be too late.
  18472.  
  18473. But that's not going to happen because of our investment in 3com gear.
  18474. Although I've done it once, most ISP's can't sell 100% of their modems
  18475. and just switch to a different platform.  We might merge in another
  18476. platform into our network to keep the problem users from quitting but
  18477. weve also noticed their are cases where the 3com performs better..
  18478. (i.e. the reverse is true).  I guess you can't win em all..
  18479.  
  18480. Allen
  18481.  
  18482.  
  18483. >
  18484. >
  18485. >Ed
  18486. >
  18487. >----- Original Message -----
  18488. >From: Allen Marsalis <am@shreve.net>
  18489. >To: <usr-tc@lists.xmission.com>
  18490. >Sent: Saturday, October 16, 1999 6:11 PM
  18491. >Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18492. >
  18493. >
  18494. >Same here.  That's pretty much exactly how we feel about it.  However
  18495. >we occationally find a user with a good sportster/3com modem who can't
  18496. >get v.90 on our TCS but can on our TNT (eval) and more importantly,
  18497. >can with our competitors.  Users won't stay with 28.8 when they can
  18498. >get 48k elsewhere..  If there were no modem code issues, I'd be more
  18499. >than happy to send the eval back.  Instead, I'll probably get an invoice...
  18500. >
  18501. >Well back when we started, we bought a superstack and it worked of course
  18502. >but when I found out it was half-duplex on all 10T ports, we sent it back
  18503. >and opted for a catalyst..  But nowadays I'm sure things are different.
  18504. >We outgrew the catalyst and now have a fastiron and we love it..
  18505. >
  18506. >I realize that switches don't call for much support, but we did have
  18507. >some issues with the catalyst.  Ciscos support as amazing and they
  18508. >even called back again just to make sure we were happy.  3com on the
  18509. >otherhand wanted to charge us for support on a 1 day old switch!
  18510. >I just wanted to double check to see that their was no fdx on
  18511. >the ports before sending it back.  They could have cared less whether
  18512. >I returned it or not..  So I did!
  18513. >
  18514. >Allen
  18515. >
  18516. >
  18517. >-
  18518. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18519. > with "unsubscribe usr-tc" in the body of the message.
  18520. > For information on digests or retrieving files and old messages send
  18521. > "help" to the same address.  Do not use quotes in your message.
  18522. >
  18523. >
  18524. >
  18525. >-
  18526. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18527. > with "unsubscribe usr-tc" in the body of the message.
  18528. > For information on digests or retrieving files and old messages send
  18529. > "help" to the same address.  Do not use quotes in your message.
  18530.  
  18531.  
  18532. -
  18533.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18534.  with "unsubscribe usr-tc" in the body of the message.
  18535.  For information on digests or retrieving files and old messages send
  18536.  "help" to the same address.  Do not use quotes in your message.
  18537.  
  18538.  
  18539. -------------------------------------------------------------------------------
  18540.  
  18541. From: Greg Coffey <greg@coffey.com>
  18542. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  18543. Date: 16 Oct 1999 19:04:34 -0600
  18544.  
  18545. The anomaly is that the clients are 3Com modems in all our cases.  I've
  18546. lost a couple dozen customers that I am aware of and 3Com remains silent on
  18547. the issue.  If they are investigating it, I would like to know about it.
  18548. Perhaps they can fix it, perhaps they can't but it sure would be nice to
  18549. know SOME status.
  18550.  
  18551.  
  18552.  
  18553. >Agreed.  I am certainly willing to replicate the problem for 3com and
  18554. >arrange a meeting between a 3com engineer, a specific customer, and
  18555. >ourselves..  They can watch the customer dial in a 3com chassis and
  18556. >the TNT and pull all the stats they wish from both chassis as well as
  18557. >the customers modem..  The data should be there to analzye if they
  18558. >cared to do so.  I'll even swap spans and show them how the problem
  18559. >follows the chassis and not the PRI's..
  18560.  
  18561.  
  18562. Thanks,
  18563.  
  18564. Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  18565. =====================================================================
  18566. 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  18567.  
  18568.  
  18569. -
  18570.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18571.  with "unsubscribe usr-tc" in the body of the message.
  18572.  For information on digests or retrieving files and old messages send
  18573.  "help" to the same address.  Do not use quotes in your message.
  18574.  
  18575.  
  18576. -------------------------------------------------------------------------------
  18577.  
  18578. From: Brian <signal@shreve.net>
  18579. Subject: (usr-tc) some help needed
  18580. Date: 16 Oct 1999 21:33:29 -0500 (CDT)
  18581.  
  18582.  
  18583. I am in a bit of a situation and need some advice/help on how to "fix it".
  18584. Basically bellsouth, in a very rural town, installed us 3 CT1 circuits.
  18585. We ordered these all provisioned the same.  They had to reprovision them
  18586. multiple times, because they couldn't get it right, and its really costed
  18587. me alot of time, and our customers alot of patience in that particular
  18588. pop.
  18589.  
  18590. So, finally Bell is saying the provisioned right.  I am not able to
  18591. complete call on it however, the calls arrive, but don't complete.  Smells
  18592. of a bad start type to me........I can plug the other 2 CT1's into that
  18593. same equipment and it works fine (3 hdm's all configured the same, 3 CT1's
  18594. all configured the same).
  18595.  
  18596. So basically, on Tuesday, I am having to go onsite with a bunch of
  18597. engineers, which I know is just going to be one big pissing contest.  I
  18598. have assembled a list of information off the chassis/dsp's, to help me
  18599. battle this, but I don't know if perhaps I am leaving out something
  18600. critical that can really be of help.
  18601.  
  18602. Some of the info I got is:
  18603.  
  18604. Trunk Settings 
  18605.     This shows all 3 CT1's configured identical
  18606.  
  18607. Timeslot Service Configuration
  18608.     This shows all 3 CT1's channels inService
  18609.  
  18610. Performance Monitor
  18611.     Physical States - All 3 psF1Operational
  18612.     Line Status - All 3 "1"
  18613.     No Idle Modem Available - All 3 "0"
  18614.     Transmit / Receive Carrier Levels
  18615.         The good channels all show about 1820 transmit and 1820
  18616.         receive.
  18617.     
  18618.         The third CT1 shows 0 for transmit and 0 for receive
  18619.     Incoming Connecions established vs. terminated
  18620.         Good spans show about 900 for these
  18621.  
  18622.         Third span shows very messed up numbers for these
  18623.     Signal to Noise Ratios
  18624.         Third span shows signal to noise at like 65536!!!
  18625.  
  18626.  
  18627. Whats the best data to throw at the telco?  
  18628.  
  18629. And as if this isn't enough.  The 3 CT1's are in a hunt, first available.
  18630. This town takes very few calls.  But I can watch literally 5-10 calls per
  18631. second come in on CT1 #3, yet 1 and 2 have idle channels!  The amount of
  18632. calls arriving on span3 HAVE to be a call simulator that the telco has
  18633. hooked up to the line to test it........something they are doing without
  18634. my permission, and something they are denying, I think they left it turned
  18635. on and forgot to turn it off.  At the end of the day, spans1 and 2 saw
  18636. like maybe 500 calls, and span3 has seen like 50,000 calls.  This is in an
  18637. area with about 300 customers........sigh.  I have no way of even dialing
  18638. into span3, its only got 1 DID into the hunt.  Which like I said is first
  18639. available.
  18640.  
  18641. Brian Feeny (BF304)     signal@shreve.net   
  18642. 318-222-2638 x 109    http://www.shreve.net/~signal      
  18643. Network Administrator   ShreveNet Inc. (ASN 11881)           
  18644.  
  18645.  
  18646.  
  18647. -
  18648.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18649.  with "unsubscribe usr-tc" in the body of the message.
  18650.  For information on digests or retrieving files and old messages send
  18651.  "help" to the same address.  Do not use quotes in your message.
  18652.  
  18653.  
  18654. -------------------------------------------------------------------------------
  18655.  
  18656. From: Brian <signal@shreve.net>
  18657. Subject: (usr-tc) More telco madness
  18658. Date: 16 Oct 1999 22:25:12 -0500 (CDT)
  18659.  
  18660.  
  18661. O, I forgot to mention in my previous post, that the telco who is blaming
  18662. us for our problematic CT1, said the circuit was showing "high and wet"
  18663. and that could only mean it was the end user that was at fault.
  18664.  
  18665. What is high and wet, and does it really mean it has to be the end user?
  18666.  
  18667. Brian
  18668.  
  18669.  
  18670. Brian Feeny (BF304)     signal@shreve.net   
  18671. 318-222-2638 x 109    http://www.shreve.net/~signal      
  18672. Network Administrator   ShreveNet Inc. (ASN 11881)           
  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.  
  18684. From: jeff.binkley@asacomp.com (Jeff Binkley)
  18685. Subject: (usr-tc) (USR-TC) S/A DATABASE CLE
  18686. Date: 17 Oct 1999 06:48:00 -0500
  18687.  
  18688.  
  18689.  
  18690.  
  18691. Mike,
  18692.  
  18693. What I do, since S/A yet supports SQL, is I have an SQL server and two 
  18694. linked tables for events and calls.  I have an ASP job which I run 
  18695. periodically which copies records out of the normal calls and events 
  18696. tables into the SQL server calls and events tables, then deletes the 
  18697. records in the Access database.  All you need to do then is periodically 
  18698. use the MS Access database compress option to shrink the database down 
  18699. to something resonable.  Of course if 3Com would ever support an SQL 
  18700. server, this would be a mute point.
  18701.  
  18702. Jeff Binkley
  18703. ASA Network Computing 
  18704.  
  18705.  
  18706. U>I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the
  18707. U>database? It is getting quite large. TIA!!!!!
  18708.  
  18709. U>Mike Moore
  18710. U>BCSNet
  18711.  
  18712.  
  18713. U>-
  18714. U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18715. U> with "unsubscribe usr-tc" in the body of the message.
  18716. U> For information on digests or retrieving files and old messages send
  18717. U> "help" to the same address.  Do not use quotes in your message.
  18718.  
  18719. CMPQwk 1.42-21 9999
  18720.  
  18721.  
  18722.  
  18723. -
  18724.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18725.  with "unsubscribe usr-tc" in the body of the message.
  18726.  For information on digests or retrieving files and old messages send
  18727.  "help" to the same address.  Do not use quotes in your message.
  18728.  
  18729.  
  18730. -------------------------------------------------------------------------------
  18731.  
  18732. From: "Ed" <ed@taylors.com>
  18733. Subject: (usr-tc) 3com V90 Problems
  18734. Date: 17 Oct 1999 12:41:17 -0400
  18735.  
  18736. Greg Coffey wrote:
  18737. "The anomaly is that the clients are 3Com modems in all our cases.  I've
  18738. lost a couple dozen customers that I am aware of and 3Com remains silent on
  18739. the issue.  If they are investigating it, I would like to know about it.
  18740. Perhaps they can fix it, perhaps they can't but it sure would be nice to
  18741. know SOME status."
  18742.  
  18743. Problem is 3com knows about it... and they know what is causing it. However
  18744. they have thus far refused to resolve it.
  18745.  
  18746. Anyone having these problems needs to contact George Ebert immediately at
  18747. George_Ebert@mw.3com.com
  18748.  
  18749. Let him know you are having the 3com V90 problems and you want it resolved.
  18750. I think they believe it is a rare scenerio not effecting very many people.
  18751. We told them it was more widespread than they knew... and that if 3com
  18752. client modems connect to Ascends they should darn well connect to a 3com TC.
  18753. No ifs ands or buts.
  18754.  
  18755.  
  18756. Ed
  18757.  
  18758.  
  18759. -
  18760.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18761.  with "unsubscribe usr-tc" in the body of the message.
  18762.  For information on digests or retrieving files and old messages send
  18763.  "help" to the same address.  Do not use quotes in your message.
  18764.  
  18765.  
  18766. -------------------------------------------------------------------------------
  18767.  
  18768. From: "Ed" <ed@taylors.com>
  18769. Subject: (usr-tc) Bad Modems...BIG Issues
  18770. Date: 17 Oct 1999 13:00:43 -0400
  18771.  
  18772. Is everyone else having individual modem problems on the latest DSP code? We
  18773. seem to have modems always causing problems and going out on us. We never
  18774. had modems do this in the past and never even considered a Bad Modem Script
  18775. to let us know modems were out or having problems. Now it is something we
  18776. HAVE to have or we can't sleep at nights... constantly getting calls from
  18777. customers letting us know there are fast busy signals, no tone, terrible
  18778. speeds, or just cannot connect.
  18779.  
  18780. What is going on? Anyone know? Is this a bug in the latest code? Or better
  18781. yet should 3com just scratch everything and give us all our money back?
  18782. (getting thoroughly disgusted) BTW, we have been dealing in 3com TC's for
  18783. almost 4 years so we are fairly aware if it is Telco, TC or a config
  18784. issue.... it's definitely the TC code or Hardware. Any work arounds or
  18785. solutions known?
  18786.  
  18787. Between the bad modems, the V90 issue and the support issues I don't see how
  18788. anyone is happy with 3com right now... it's giving us one hell of a
  18789. headache!
  18790.  
  18791. Ed
  18792.  
  18793.  
  18794.  
  18795. -
  18796.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18797.  with "unsubscribe usr-tc" in the body of the message.
  18798.  For information on digests or retrieving files and old messages send
  18799.  "help" to the same address.  Do not use quotes in your message.
  18800.  
  18801.  
  18802. -------------------------------------------------------------------------------
  18803.  
  18804. From: Jeff Mcadams <jeffm@iglou.com>
  18805. Subject: Re: (usr-tc) 3com V90 Problems
  18806. Date: 17 Oct 1999 13:02:49 -0400
  18807.  
  18808. Thus spake Ed
  18809. >Problem is 3com knows about it... and they know what is causing it. However
  18810. >they have thus far refused to resolve it.
  18811.  
  18812. Can you share with us what's causing it (assuming you know of course)?
  18813. I'm only just now beginning to really dig into real modem
  18814. functionality...I'd be interested in hearing the explanation.
  18815. -- 
  18816. Jeff McAdams                            Email: jeffm@iglou.com
  18817. Head Network Administrator              Voice: (502) 966-3848
  18818. IgLou Internet Services                        (800) 436-4456
  18819.  
  18820. -
  18821.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18822.  with "unsubscribe usr-tc" in the body of the message.
  18823.  For information on digests or retrieving files and old messages send
  18824.  "help" to the same address.  Do not use quotes in your message.
  18825.  
  18826.  
  18827. -------------------------------------------------------------------------------
  18828.  
  18829. From: "Ed" <ed@taylors.com>
  18830. Subject: Re: (usr-tc) 3com V90 Problems
  18831. Date: 17 Oct 1999 14:07:19 -0400
  18832.  
  18833. Jeff McAdams wrote:
  18834. "Can you share with us what's causing it (assuming you know of course)? I'm
  18835. only just now beginning to really dig into real modem functionality...I'd be
  18836. interested in hearing the explanation."
  18837.  
  18838. Why certainly...will tell you what we know thus far.
  18839.  
  18840. Depending on the signal level differences (i.e. if the dB down at a certain
  18841. frequency was at a certain value it would train based on that criteria). Our
  18842. understanding is that they just tuned the algorithms to attempt V90
  18843. connections under conditions that they didn't necessarily feel were the best
  18844. conditions for V90, for the sake of allowing a V90 connection. They would
  18845. measure the signal rolloff at certain frequency levels and if the rollover
  18846. was more than a certain value it would not attempt to negotiate V90.
  18847.  
  18848. If you were to use a 3com Sportster and dial up to the Ascend unit plugged
  18849. into the same PRI, it would show a hotter signal at crucial frequencies -- I
  18850. believe 3com may also have experimented with modifying the signal levels on
  18851. the DSP modems themselves as well. However still no solution... and the
  18852. Ascend DOES negotiates V90 in more situations.
  18853.  
  18854.  
  18855. Ed
  18856.  
  18857. ----- Original Message -----
  18858. Sent: Sunday, October 17, 1999 1:02 PM
  18859.  
  18860.  
  18861. Thus spake Ed
  18862. >Problem is 3com knows about it... and they know what is causing it. However
  18863. >they have thus far refused to resolve it.
  18864.  
  18865. Can you share with us what's causing it (assuming you know of course)?
  18866. I'm only just now beginning to really dig into real modem
  18867. functionality...I'd be interested in hearing the explanation.
  18868. --
  18869. Jeff McAdams                            Email: jeffm@iglou.com
  18870. Head Network Administrator              Voice: (502) 966-3848
  18871. IgLou Internet Services                        (800) 436-4456
  18872.  
  18873. -
  18874.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18875.  with "unsubscribe usr-tc" in the body of the message.
  18876.  For information on digests or retrieving files and old messages send
  18877.  "help" to the same address.  Do not use quotes in your message.
  18878.  
  18879.  
  18880.  
  18881. -
  18882.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18883.  with "unsubscribe usr-tc" in the body of the message.
  18884.  For information on digests or retrieving files and old messages send
  18885.  "help" to the same address.  Do not use quotes in your message.
  18886.  
  18887.  
  18888. -------------------------------------------------------------------------------
  18889.  
  18890. From: Aaron Nabil <nabil@spiritone.com>
  18891. Subject: Re: (usr-tc) 3com V90 Problems
  18892. Date: 17 Oct 1999 11:15:43 -0700 (PDT)
  18893.  
  18894. Ed writes...
  18895. > . . .
  18896. >Let him know you are having the 3com V90 problems and you want it resolved.
  18897. >I think they believe it is a rare scenerio not effecting very many people.
  18898. >We told them it was more widespread than they knew... and that if 3com
  18899. >client modems connect to Ascends they should darn well connect to a 3com TC.
  18900. >No ifs ands or buts.
  18901.  
  18902. If modem X connects at an unreliable V.90 speed to an Ascend, and 
  18903. connects at a reliable v.34 rate to a 3com, that's a problem?
  18904.  
  18905.  
  18906. -- 
  18907. Aaron Nabil
  18908.  
  18909. -
  18910.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18911.  with "unsubscribe usr-tc" in the body of the message.
  18912.  For information on digests or retrieving files and old messages send
  18913.  "help" to the same address.  Do not use quotes in your message.
  18914.  
  18915.  
  18916. -------------------------------------------------------------------------------
  18917.  
  18918. From: "Jason A. Nunnelley" <interests@linkfast.net>
  18919. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  18920. Date: 17 Oct 1999 13:25:35 -0700
  18921.  
  18922. I hear a lot of complaints about 3COM on this list. Is the general idea that
  18923. 3COM should not be used? I used PM3s, with a lot of connection issues, but
  18924. little management headaches. I have considered CISCO (even tried one out),
  18925. but have heard the nightmare stories about connection issues. Is there a
  18926. feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
  18927. back to LT. I got excellent support there. I have never even been able to
  18928. get 3COM to give me the TC Software, and I paid for the support contract.
  18929. They tell me I have to prove I have a support contract every time I call. Do
  18930. they just SUCK? That is the feeling I am getting from this list. Is that
  18931. what you guys mean to say: "Run from 3COM, they SUCK!"
  18932.  
  18933. Jason
  18934.  
  18935. -----Original Message-----
  18936. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
  18937. Sent: Saturday, October 16, 1999 4:46 PM
  18938.  
  18939.  
  18940. Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
  18941. a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
  18942. problem that has been addressed but not resolved. You would think this would
  18943. concern 3com more than it does... just like all the complaints about support
  18944. on this list.
  18945.  
  18946. Oh well when everyone is switching to a different platform they may care but
  18947. it will be too late.
  18948.  
  18949.  
  18950. Ed
  18951.  
  18952. ----- Original Message -----
  18953. Sent: Saturday, October 16, 1999 6:11 PM
  18954.  
  18955.  
  18956. Same here.  That's pretty much exactly how we feel about it.  However
  18957. we occationally find a user with a good sportster/3com modem who can't
  18958. get v.90 on our TCS but can on our TNT (eval) and more importantly,
  18959. can with our competitors.  Users won't stay with 28.8 when they can
  18960. get 48k elsewhere..  If there were no modem code issues, I'd be more
  18961. than happy to send the eval back.  Instead, I'll probably get an invoice...
  18962.  
  18963. Well back when we started, we bought a superstack and it worked of course
  18964. but when I found out it was half-duplex on all 10T ports, we sent it back
  18965. and opted for a catalyst..  But nowadays I'm sure things are different.
  18966. We outgrew the catalyst and now have a fastiron and we love it..
  18967.  
  18968. I realize that switches don't call for much support, but we did have
  18969. some issues with the catalyst.  Ciscos support as amazing and they
  18970. even called back again just to make sure we were happy.  3com on the
  18971. otherhand wanted to charge us for support on a 1 day old switch!
  18972. I just wanted to double check to see that their was no fdx on
  18973. the ports before sending it back.  They could have cared less whether
  18974. I returned it or not..  So I did!
  18975.  
  18976. Allen
  18977.  
  18978.  
  18979. -
  18980.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18981.  with "unsubscribe usr-tc" in the body of the message.
  18982.  For information on digests or retrieving files and old messages send
  18983.  "help" to the same address.  Do not use quotes in your message.
  18984.  
  18985.  
  18986.  
  18987. -
  18988.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18989.  with "unsubscribe usr-tc" in the body of the message.
  18990.  For information on digests or retrieving files and old messages send
  18991.  "help" to the same address.  Do not use quotes in your message.
  18992.  
  18993.  
  18994. -
  18995.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18996.  with "unsubscribe usr-tc" in the body of the message.
  18997.  For information on digests or retrieving files and old messages send
  18998.  "help" to the same address.  Do not use quotes in your message.
  18999.  
  19000.  
  19001. -------------------------------------------------------------------------------
  19002.  
  19003. From: "Ed" <ed@taylors.com>
  19004. Subject: Re: (usr-tc) 3com V90 Problems
  19005. Date: 17 Oct 1999 14:31:37 -0400
  19006.  
  19007. The problem is that the connection is just as stable on Ascend v90 as 3com
  19008. v34. So YES it is a PROBLEM.
  19009.  
  19010. We have tested extensively with both Ascend and 3com TC... again it IS a
  19011. known problem and 3com acknowledged it.
  19012.  
  19013. (People have to get out of the mindset that 3com is ultimately superior...
  19014. they do have flaws) We believe it to until recently...
  19015.  
  19016.  
  19017. Ed
  19018.  
  19019. ----- Original Message -----
  19020. Sent: Sunday, October 17, 1999 2:15 PM
  19021.  
  19022.  
  19023. Ed writes...
  19024. > . . .
  19025. >Let him know you are having the 3com V90 problems and you want it resolved.
  19026. >I think they believe it is a rare scenerio not effecting very many people.
  19027. >We told them it was more widespread than they knew... and that if 3com
  19028. >client modems connect to Ascends they should darn well connect to a 3com
  19029. TC.
  19030. >No ifs ands or buts.
  19031.  
  19032. If modem X connects at an unreliable V.90 speed to an Ascend, and
  19033. connects at a reliable v.34 rate to a 3com, that's a problem?
  19034.  
  19035.  
  19036. --
  19037. Aaron Nabil
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19049.  with "unsubscribe usr-tc" in the body of the message.
  19050.  For information on digests or retrieving files and old messages send
  19051.  "help" to the same address.  Do not use quotes in your message.
  19052.  
  19053.  
  19054. -------------------------------------------------------------------------------
  19055.  
  19056. From: Greg Coffey <greg@coffey.com>
  19057. Subject: Re: (usr-tc) 3com V90 Problems
  19058. Date: 17 Oct 1999 13:12:20 -0600
  19059.  
  19060. I've never had a customer call the v90 connection "unreliable" to the
  19061. competition's Ascends.  The feedback that I've got from customers is that
  19062. they get better throughput and are not dissatified with the connects to the
  19063. Ascends.  They are using USR modems to dial and they connect consistently
  19064. with Ascends at v90 rates, usually 40something.  They never connect at v90
  19065. to our TC racks from the same location, using the same PC, software, phone
  19066. lines, config, etc.  I don't know the exact cause, they seem to be on the
  19067. fringe of the v90 availability area.  3Com described it to me as a "bug" in
  19068. the Ascend server firmware.  All I know is that it has cost me customers in
  19069. the past and continues to be an issue that I have no answer for when it
  19070. comes up.  I have gone to great lengths to explain to them what I have
  19071. learned many months ago from 3Com but I don't think they believe me.  Would
  19072. you believe that 3Com/USR modems connect better to the competition than
  19073. their own racks?  Thankfully, it is a somewhat rare occurance and I only
  19074. have to explain once or twice a month.  I really don't know for sure to
  19075. what extent it really occurs.  I do know that I have lost customers over
  19076. this and it continues to be an issue.  I am getting tired of no news to
  19077. update the situation though.  I'm also afraid that it will harm our
  19078. reputation if this continues as is.  Word of mouth is still our best
  19079. marketing and this will grow in significance with time.  
  19080.  
  19081.  
  19082.  
  19083. At 11:15 AM 10/17/99 -0700, you wrote:
  19084. >Ed writes...
  19085. >> . . .
  19086. >>Let him know you are having the 3com V90 problems and you want it resolved.
  19087. >>I think they believe it is a rare scenerio not effecting very many people.
  19088. >>We told them it was more widespread than they knew... and that if 3com
  19089. >>client modems connect to Ascends they should darn well connect to a 3com TC.
  19090. >>No ifs ands or buts.
  19091. >
  19092. >If modem X connects at an unreliable V.90 speed to an Ascend, and 
  19093. >connects at a reliable v.34 rate to a 3com, that's a problem?
  19094. >
  19095. >
  19096. >-- 
  19097. >Aaron Nabil
  19098. >
  19099. >-
  19100. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19101. > with "unsubscribe usr-tc" in the body of the message.
  19102. > For information on digests or retrieving files and old messages send
  19103. > "help" to the same address.  Do not use quotes in your message.
  19104. >
  19105. >
  19106.  
  19107. Thanks,
  19108.  
  19109. Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  19110. =====================================================================
  19111. 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  19112.  
  19113.  
  19114. -
  19115.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19116.  with "unsubscribe usr-tc" in the body of the message.
  19117.  For information on digests or retrieving files and old messages send
  19118.  "help" to the same address.  Do not use quotes in your message.
  19119.  
  19120.  
  19121. -------------------------------------------------------------------------------
  19122.  
  19123. From: Aaron Nabil <nabil@spiritone.com>
  19124. Subject: Re: (usr-tc) 3com V90 Problems
  19125. Date: 17 Oct 1999 12:58:34 -0700 (PDT)
  19126.  
  19127. Greg Coffey writes...
  19128. >I've never had a customer call the v90 connection "unreliable" to the
  19129. >competition's Ascends.
  19130.  
  19131. Why would a "customer" being describing to you the nature of connection
  19132. to your competition's equipment?
  19133.  
  19134. I have _own_ both Max's and Hiperdsps.  
  19135.  
  19136. > . . .
  19137.  
  19138. >Would you believe that 3Com/USR modems connect better to the competition than
  19139. >their own racks?  Thankfully, it is a somewhat rare occurance and I only
  19140. >have to explain once or twice a month.
  19141.  
  19142. So the occurance of people getting solid v.34 connections on a 3com 
  19143. instead of unstable v.90 connections on Ascend is a "rare occurance", but you
  19144. are expecting some flood of reports, from your customers, about calling
  19145. into your _competitors_ equipment, to judge if the Ascend connections
  19146. are stable or not?
  19147.  
  19148. If you are going to pursue this rather dubious argument, why not just
  19149. say what you really want?  You want 3com chassis to _connect_ at some
  19150. outrageously high rate, say, 53k, and then silently fall back to a slower
  19151. speed since it's unlikely the customer will notice the fallback.
  19152.  
  19153. Hey 3com, how about that?   Make all v.90 connections, regardless of quality,
  19154. always "CONNECT 53000" and then fall back to 40k or V.34 later?  Please
  19155. make sure it's an option that can be disabled, I'd don't need any more
  19156. "mysterious disconnects" or "neglible throughput" trouble calls than I
  19157. already get.
  19158.  
  19159. >At 11:15 AM 10/17/99 -0700, you wrote:
  19160. >>Ed writes...
  19161. >>> . . .
  19162. >>>Let him know you are having the 3com V90 problems and you want it resolved.
  19163. >>>I think they believe it is a rare scenerio not effecting very many people.
  19164. >>>We told them it was more widespread than they knew... and that if 3com
  19165. >>>client modems connect to Ascends they should darn well connect to a 3com TC.
  19166. >>>No ifs ands or buts.
  19167. >>
  19168. >>If modem X connects at an unreliable V.90 speed to an Ascend, and 
  19169. >>connects at a reliable v.34 rate to a 3com, that's a problem?
  19170. >>
  19171. >>
  19172.  
  19173.  
  19174. -- 
  19175. Aaron Nabil
  19176.  
  19177. -
  19178.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19179.  with "unsubscribe usr-tc" in the body of the message.
  19180.  For information on digests or retrieving files and old messages send
  19181.  "help" to the same address.  Do not use quotes in your message.
  19182.  
  19183.  
  19184. -------------------------------------------------------------------------------
  19185.  
  19186. From: Greg Coffey <greg@coffey.com>
  19187. Subject: Re: (usr-tc) 3com V90 Problems
  19188. Date: 17 Oct 1999 14:38:49 -0600
  19189.  
  19190. If it comes down to significantly degrading other connections to our system
  19191. in order to enhance some on the fringe to get them v90, no, I don't want
  19192. that.  I would like to hear it from someone at 3Com that this is the
  19193. current thinking on the matter.  
  19194.  
  19195. >
  19196. >If you are going to pursue this rather dubious argument, why not just
  19197. >say what you really want?  You want 3com chassis to _connect_ at some
  19198. >outrageously high rate, say, 53k, and then silently fall back to a slower
  19199. >speed since it's unlikely the customer will notice the fallback.
  19200. >
  19201. >Hey 3com, how about that?   Make all v.90 connections, regardless of quality,
  19202. >always "CONNECT 53000" and then fall back to 40k or V.34 later?  Please
  19203. >make sure it's an option that can be disabled, I'd don't need any more
  19204. >"mysterious disconnects" or "neglible throughput" trouble calls than I
  19205. >already get.
  19206.  
  19207.  
  19208. Thanks,
  19209.  
  19210. Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  19211. =====================================================================
  19212. 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  19213.  
  19214.  
  19215. -
  19216.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19217.  with "unsubscribe usr-tc" in the body of the message.
  19218.  For information on digests or retrieving files and old messages send
  19219.  "help" to the same address.  Do not use quotes in your message.
  19220.  
  19221.  
  19222. -------------------------------------------------------------------------------
  19223.  
  19224. From: Brian <signal@shreve.net>
  19225. Subject: Re: (usr-tc) 3com V90 Problems
  19226. Date: 17 Oct 1999 16:14:43 -0500 (CDT)
  19227.  
  19228.  
  19229. So this scenerio, where modem X connects to Ascend, and only v.34 to 3com,
  19230. the modem does not retrain down to lower levels, it doesn't exhibate any
  19231. indications of  a "problematic" v90 connection?
  19232.  
  19233.  
  19234. On Sun, 17 Oct 1999, Ed wrote:
  19235.  
  19236. > The problem is that the connection is just as stable on Ascend v90 as 3com
  19237. > v34. So YES it is a PROBLEM.
  19238. > 
  19239. > We have tested extensively with both Ascend and 3com TC... again it IS a
  19240. > known problem and 3com acknowledged it.
  19241. > 
  19242. > (People have to get out of the mindset that 3com is ultimately superior...
  19243. > they do have flaws) We believe it to until recently...
  19244. > 
  19245. > 
  19246. > Ed
  19247. > 
  19248. > ----- Original Message -----
  19249. > From: Aaron Nabil <nabil@spiritone.com>
  19250. > To: <usr-tc@lists.xmission.com>
  19251. > Sent: Sunday, October 17, 1999 2:15 PM
  19252. > Subject: Re: (usr-tc) 3com V90 Problems
  19253. > 
  19254. > 
  19255. > Ed writes...
  19256. > > . . .
  19257. > >Let him know you are having the 3com V90 problems and you want it resolved.
  19258. > >I think they believe it is a rare scenerio not effecting very many people.
  19259. > >We told them it was more widespread than they knew... and that if 3com
  19260. > >client modems connect to Ascends they should darn well connect to a 3com
  19261. > TC.
  19262. > >No ifs ands or buts.
  19263. > 
  19264. > If modem X connects at an unreliable V.90 speed to an Ascend, and
  19265. > connects at a reliable v.34 rate to a 3com, that's a problem?
  19266. > 
  19267. > 
  19268. > --
  19269. > Aaron Nabil
  19270. > 
  19271. > -
  19272. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19273. >  with "unsubscribe usr-tc" in the body of the message.
  19274. >  For information on digests or retrieving files and old messages send
  19275. >  "help" to the same address.  Do not use quotes in your message.
  19276. > 
  19277. > 
  19278. > 
  19279. > -
  19280. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19281. >  with "unsubscribe usr-tc" in the body of the message.
  19282. >  For information on digests or retrieving files and old messages send
  19283. >  "help" to the same address.  Do not use quotes in your message.
  19284. > 
  19285.  
  19286. Brian Feeny (BF304)     signal@shreve.net   
  19287. 318-222-2638 x 109    http://www.shreve.net/~signal      
  19288. Network Administrator   ShreveNet Inc. (ASN 11881)           
  19289.  
  19290.  
  19291. -
  19292.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19293.  with "unsubscribe usr-tc" in the body of the message.
  19294.  For information on digests or retrieving files and old messages send
  19295.  "help" to the same address.  Do not use quotes in your message.
  19296.  
  19297.  
  19298. -------------------------------------------------------------------------------
  19299.  
  19300. From: Brian <signal@shreve.net>
  19301. Subject: Re: (usr-tc) 3com V90 Problems
  19302. Date: 17 Oct 1999 16:18:46 -0500 (CDT)
  19303.  
  19304. I wonder how much of it is pschological vs. real.  For example, ever post
  19305. to your customers about how you made an upgrade to something like your
  19306. mail server, and then they start calling tech support and say things like
  19307. "ever since you all upgraded the server, I can't connect fast".  I often
  19308. thought, if you told the customers all of them, that you were upgrading
  19309. your modem code tonight, and wanted their feedback the following day,and
  19310. you really didn't touch anything, I am betting 25% would say they connect
  19311. faster, 25% would say they connect slower, and 50% would notice no
  19312. change.........i'm telling you I believe in this :)
  19313.  
  19314. Its like those customers who's modems report the DTE speed of 115,200, and
  19315. when you fix them up, it only reports say 28800, yet they swear the
  19316. connection is not as fast anymore.
  19317.  
  19318. Well if a customer visually sees a v90 connect, and its a terrible
  19319. connection, would they claim that connection was faster than a really
  19320. solid v.34 connect?
  19321.  
  19322. What I am getting at, is raw data and numbers are the best, rather than
  19323. the more subjective data of customers opinions about their connections.
  19324.  
  19325.  
  19326.  
  19327. On Sun, 17 Oct 1999, Greg Coffey wrote:
  19328.  
  19329. > I've never had a customer call the v90 connection "unreliable" to the
  19330. > competition's Ascends.  The feedback that I've got from customers is that
  19331. > they get better throughput and are not dissatified with the connects to the
  19332. > Ascends.  They are using USR modems to dial and they connect consistently
  19333. > with Ascends at v90 rates, usually 40something.  They never connect at v90
  19334. > to our TC racks from the same location, using the same PC, software, phone
  19335. > lines, config, etc.  I don't know the exact cause, they seem to be on the
  19336. > fringe of the v90 availability area.  3Com described it to me as a "bug" in
  19337. > the Ascend server firmware.  All I know is that it has cost me customers in
  19338. > the past and continues to be an issue that I have no answer for when it
  19339. > comes up.  I have gone to great lengths to explain to them what I have
  19340. > learned many months ago from 3Com but I don't think they believe me.  Would
  19341. > you believe that 3Com/USR modems connect better to the competition than
  19342. > their own racks?  Thankfully, it is a somewhat rare occurance and I only
  19343. > have to explain once or twice a month.  I really don't know for sure to
  19344. > what extent it really occurs.  I do know that I have lost customers over
  19345. > this and it continues to be an issue.  I am getting tired of no news to
  19346. > update the situation though.  I'm also afraid that it will harm our
  19347. > reputation if this continues as is.  Word of mouth is still our best
  19348. > marketing and this will grow in significance with time.  
  19349. > 
  19350. > 
  19351. > 
  19352. > At 11:15 AM 10/17/99 -0700, you wrote:
  19353. > >Ed writes...
  19354. > >> . . .
  19355. > >>Let him know you are having the 3com V90 problems and you want it resolved.
  19356. > >>I think they believe it is a rare scenerio not effecting very many people.
  19357. > >>We told them it was more widespread than they knew... and that if 3com
  19358. > >>client modems connect to Ascends they should darn well connect to a 3com TC.
  19359. > >>No ifs ands or buts.
  19360. > >
  19361. > >If modem X connects at an unreliable V.90 speed to an Ascend, and 
  19362. > >connects at a reliable v.34 rate to a 3com, that's a problem?
  19363. > >
  19364. > >
  19365. > >-- 
  19366. > >Aaron Nabil
  19367. > >
  19368. > >-
  19369. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19370. > > with "unsubscribe usr-tc" in the body of the message.
  19371. > > For information on digests or retrieving files and old messages send
  19372. > > "help" to the same address.  Do not use quotes in your message.
  19373. > >
  19374. > >
  19375. > 
  19376. > Thanks,
  19377. > 
  19378. > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  19379. > =====================================================================
  19380. > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  19381. > 
  19382. > 
  19383. > -
  19384. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19385. >  with "unsubscribe usr-tc" in the body of the message.
  19386. >  For information on digests or retrieving files and old messages send
  19387. >  "help" to the same address.  Do not use quotes in your message.
  19388. > 
  19389.  
  19390. Brian Feeny (BF304)     signal@shreve.net   
  19391. 318-222-2638 x 109    http://www.shreve.net/~signal      
  19392. Network Administrator   ShreveNet Inc. (ASN 11881)           
  19393.  
  19394.  
  19395. -
  19396.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19397.  with "unsubscribe usr-tc" in the body of the message.
  19398.  For information on digests or retrieving files and old messages send
  19399.  "help" to the same address.  Do not use quotes in your message.
  19400.  
  19401.  
  19402. -------------------------------------------------------------------------------
  19403.  
  19404. From: Brian <signal@shreve.net>
  19405. Subject: Re: (usr-tc) 3com V90 Problems
  19406. Date: 17 Oct 1999 16:22:33 -0500 (CDT)
  19407.  
  19408.  
  19409. I think (and perhaps someone can refresh my memory) that 3com actually
  19410. responded to this ascend phenomenon, and said that its actually more or
  19411. less a bug in the ascend code, and not a problem in the 3com code, in that
  19412. the ascend picks piss poor connections to negotiate v90 with.  But I would
  19413. be interested in knowing the stability of the connection, the number of
  19414. retrains, and the ongoing average xmit/rcv rates of such a connection, raw
  19415. thruput tests would be cool too.  I don't know if anyone has done this.
  19416.  
  19417. I would imagine, actually hope, that 3com's tests labs, have done many
  19418. tests against their own stuff and against competitors.  I would think they
  19419. would not make a policy of releasing such data, unless of course 3com was
  19420. best in every case, which I doubt it was, but certainly coudln't have done
  19421. too poor.
  19422.  
  19423. Brian
  19424.  
  19425.  
  19426. On Sun, 17 Oct 1999, Greg Coffey wrote:
  19427.  
  19428. > If it comes down to significantly degrading other connections to our system
  19429. > in order to enhance some on the fringe to get them v90, no, I don't want
  19430. > that.  I would like to hear it from someone at 3Com that this is the
  19431. > current thinking on the matter.  
  19432. > 
  19433. > >
  19434. > >If you are going to pursue this rather dubious argument, why not just
  19435. > >say what you really want?  You want 3com chassis to _connect_ at some
  19436. > >outrageously high rate, say, 53k, and then silently fall back to a slower
  19437. > >speed since it's unlikely the customer will notice the fallback.
  19438. > >
  19439. > >Hey 3com, how about that?   Make all v.90 connections, regardless of quality,
  19440. > >always "CONNECT 53000" and then fall back to 40k or V.34 later?  Please
  19441. > >make sure it's an option that can be disabled, I'd don't need any more
  19442. > >"mysterious disconnects" or "neglible throughput" trouble calls than I
  19443. > >already get.
  19444. > 
  19445. > 
  19446. > Thanks,
  19447. > 
  19448. > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  19449. > =====================================================================
  19450. > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  19451. > 
  19452. > 
  19453. > -
  19454. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19455. >  with "unsubscribe usr-tc" in the body of the message.
  19456. >  For information on digests or retrieving files and old messages send
  19457. >  "help" to the same address.  Do not use quotes in your message.
  19458. > 
  19459.  
  19460. Brian Feeny (BF304)     signal@shreve.net   
  19461. 318-222-2638 x 109    http://www.shreve.net/~signal      
  19462. Network Administrator   ShreveNet Inc. (ASN 11881)           
  19463.  
  19464.  
  19465. -
  19466.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19467.  with "unsubscribe usr-tc" in the body of the message.
  19468.  For information on digests or retrieving files and old messages send
  19469.  "help" to the same address.  Do not use quotes in your message.
  19470.  
  19471.  
  19472. -------------------------------------------------------------------------------
  19473.  
  19474. From: "Jason A. Nunnelley" <interests@linkfast.net>
  19475. Subject: RE: (usr-tc) 3com V90 Problems
  19476. Date: 17 Oct 1999 17:02:36 -0700
  19477.  
  19478. Less than 1 in 50 customers know the difference between a connection that
  19479. says 56K and only downloads 2-3K, and a good strong 34K connection
  19480. delivering a 5-6K download speed. I actually still get better connections
  19481. through v34 on 60% of my customers. But, they insist on V.90. Do they know
  19482. better? No. Does it really matter? No. You have to sell what they want. That
  19483. is why Ascend connects to crappy connections. That's what the customers
  19484. want. My question is will 3COM out perform the others where the customer
  19485. looks. That is really all that matters. If they think the competition is
  19486. better - they are, cause they now have your money to grow.
  19487.  
  19488. As for relying on customers' comments to make Network Decisions... does
  19489. anyone really do that? I know my customers don't know the difference. I rely
  19490. on data that makes sense. I know I told no one when I first switched to 3COM
  19491. and yet, I did get positive feedback immediately.
  19492.  
  19493. Jason
  19494.  
  19495. -----Original Message-----
  19496. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  19497. Sent: Sunday, October 17, 1999 2:19 PM
  19498.  
  19499.  
  19500. I wonder how much of it is pschological vs. real.  For example, ever post
  19501. to your customers about how you made an upgrade to something like your
  19502. mail server, and then they start calling tech support and say things like
  19503. "ever since you all upgraded the server, I can't connect fast".  I often
  19504. thought, if you told the customers all of them, that you were upgrading
  19505. your modem code tonight, and wanted their feedback the following day,and
  19506. you really didn't touch anything, I am betting 25% would say they connect
  19507. faster, 25% would say they connect slower, and 50% would notice no
  19508. change.........i'm telling you I believe in this :)
  19509.  
  19510. Its like those customers who's modems report the DTE speed of 115,200, and
  19511. when you fix them up, it only reports say 28800, yet they swear the
  19512. connection is not as fast anymore.
  19513.  
  19514. Well if a customer visually sees a v90 connect, and its a terrible
  19515. connection, would they claim that connection was faster than a really
  19516. solid v.34 connect?
  19517.  
  19518. What I am getting at, is raw data and numbers are the best, rather than
  19519. the more subjective data of customers opinions about their connections.
  19520.  
  19521.  
  19522.  
  19523. On Sun, 17 Oct 1999, Greg Coffey wrote:
  19524.  
  19525. > I've never had a customer call the v90 connection "unreliable" to the
  19526. > competition's Ascends.  The feedback that I've got from customers is that
  19527. > they get better throughput and are not dissatified with the connects to
  19528. the
  19529. > Ascends.  They are using USR modems to dial and they connect consistently
  19530. > with Ascends at v90 rates, usually 40something.  They never connect at v90
  19531. > to our TC racks from the same location, using the same PC, software, phone
  19532. > lines, config, etc.  I don't know the exact cause, they seem to be on the
  19533. > fringe of the v90 availability area.  3Com described it to me as a "bug"
  19534. in
  19535. > the Ascend server firmware.  All I know is that it has cost me customers
  19536. in
  19537. > the past and continues to be an issue that I have no answer for when it
  19538. > comes up.  I have gone to great lengths to explain to them what I have
  19539. > learned many months ago from 3Com but I don't think they believe me.
  19540. Would
  19541. > you believe that 3Com/USR modems connect better to the competition than
  19542. > their own racks?  Thankfully, it is a somewhat rare occurance and I only
  19543. > have to explain once or twice a month.  I really don't know for sure to
  19544. > what extent it really occurs.  I do know that I have lost customers over
  19545. > this and it continues to be an issue.  I am getting tired of no news to
  19546. > update the situation though.  I'm also afraid that it will harm our
  19547. > reputation if this continues as is.  Word of mouth is still our best
  19548. > marketing and this will grow in significance with time.
  19549. >
  19550. >
  19551. >
  19552. > At 11:15 AM 10/17/99 -0700, you wrote:
  19553. > >Ed writes...
  19554. > >> . . .
  19555. > >>Let him know you are having the 3com V90 problems and you want it
  19556. resolved.
  19557. > >>I think they believe it is a rare scenerio not effecting very many
  19558. people.
  19559. > >>We told them it was more widespread than they knew... and that if 3com
  19560. > >>client modems connect to Ascends they should darn well connect to a 3com
  19561. TC.
  19562. > >>No ifs ands or buts.
  19563. > >
  19564. > >If modem X connects at an unreliable V.90 speed to an Ascend, and
  19565. > >connects at a reliable v.34 rate to a 3com, that's a problem?
  19566. > >
  19567. > >
  19568. > >--
  19569. > >Aaron Nabil
  19570. > >
  19571. > >-
  19572. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19573. > > with "unsubscribe usr-tc" in the body of the message.
  19574. > > For information on digests or retrieving files and old messages send
  19575. > > "help" to the same address.  Do not use quotes in your message.
  19576. > >
  19577. > >
  19578. >
  19579. > Thanks,
  19580. >
  19581. > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446
  19582. > =====================================================================
  19583. > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM
  19584. >
  19585. >
  19586. > -
  19587. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19588. >  with "unsubscribe usr-tc" in the body of the message.
  19589. >  For information on digests or retrieving files and old messages send
  19590. >  "help" to the same address.  Do not use quotes in your message.
  19591. >
  19592.  
  19593. Brian Feeny (BF304)     signal@shreve.net
  19594. 318-222-2638 x 109    http://www.shreve.net/~signal
  19595. Network Administrator   ShreveNet Inc. (ASN 11881)
  19596.  
  19597.  
  19598. -
  19599.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19600.  with "unsubscribe usr-tc" in the body of the message.
  19601.  For information on digests or retrieving files and old messages send
  19602.  "help" to the same address.  Do not use quotes in your message.
  19603.  
  19604.  
  19605. -
  19606.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19607.  with "unsubscribe usr-tc" in the body of the message.
  19608.  For information on digests or retrieving files and old messages send
  19609.  "help" to the same address.  Do not use quotes in your message.
  19610.  
  19611.  
  19612. -------------------------------------------------------------------------------
  19613.  
  19614. From: Richard Lorbieski <richard@alpha1.net>
  19615. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  19616. Date: 17 Oct 1999 17:15:23 -0500
  19617.  
  19618. COMPLETELY UNTRUE!
  19619.  
  19620. If you are an ISP in Texas, Iowa, Wisconsin, Indiana, or California, I
  19621. encourage you to gut whatever terminal servers you are using and go with
  19622. 3Com. In fact I'll sell you one! If you don't want my Hiper DSP chassis,
  19623. buy a quad modem setup.
  19624.  
  19625. Don't listen to anything posted on this list - it's a pack of lies. With
  19626. 3Com, you will be a class all to yourself, you will set a new standard.
  19627.  
  19628. With 3Com, your staff's morale will change for the better. My staff now
  19629. gladly helps non-3Com chassis users. Friday, we had 4 calls waiting -
  19630. one was a lady who trying to do a floppy installation of Netscape 4.7 on
  19631. her 4 meg RAM 286 with Windows 3.1, the other callers where customers
  19632. having trouble getting on one of our 3Com chassis. I never witnessed
  19633. such devotion in my staff to help one person. I mean all of my staff
  19634. pleaded if they could help this lady. Before we used 3Com, they wouldn't
  19635. touch this lady's problem with a ten foot pole. Thanks 3Com!   
  19636.  
  19637. Your local government will thank you for creating more jobs because of
  19638. the tech staff you'll need to handle the growing customer "feedback". I
  19639. kid you not! Your customers will show their gratitude that you went with
  19640. 3Com! 
  19641.  
  19642. You will learn the meaning of customer interaction, and I guarantee you
  19643. will get to know every customer not only by their first name, but their
  19644. modem type. 
  19645.  
  19646. Also, tell you high end customers buy only 3Com "Office Connect" ISDN
  19647. modems/routers. I assure you that your customer's employees will be
  19648. happy to know that their jobs will be secure and they'll be in high
  19649. demand. They'll thank you for the sudden boost in OT pay too.
  19650.  
  19651. Other 3Com advantages:
  19652.  
  19653. * You'll know your service contract number better than your birthday,
  19654. phone number, or wedding anniversary.
  19655. * It's the only support vendor that you have programmed in your speed
  19656. dial.
  19657. * You'll master the music on hold options.
  19658. * 3Com is the only company that uses revisions number on new software
  19659. releases that are lower than the previous software release.
  19660. * Tamper proof. Because of so many revisions within revisions, a hacker
  19661. would have no frickin idea what revision are using - neither will your
  19662. admins.
  19663.  
  19664.  
  19665. Trust me! Go with 3Com. Let 3Com take you "down" to a new dimension!
  19666.  
  19667. Richard Lorbieski
  19668.  
  19669. PS.
  19670. This message is not a flame against any 3Com employee. Most of them are
  19671. extremely talented and qualified people. I especially appreciate the
  19672. 3Com employees that contribute their time on this list. It's 3Com upper
  19673. management, bureaucracy, and policies that I have a problem with.
  19674.  
  19675.  
  19676.  
  19677.  
  19678. "Jason A. Nunnelley" wrote:
  19679. > 
  19680. > I hear a lot of complaints about 3COM on this list. Is the general idea that
  19681. > 3COM should not be used? I used PM3s, with a lot of connection issues, but
  19682. > little management headaches. I have considered CISCO (even tried one out),
  19683. > but have heard the nightmare stories about connection issues. Is there a
  19684. > feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
  19685. > back to LT. I got excellent support there. I have never even been able to
  19686. > get 3COM to give me the TC Software, and I paid for the support contract.
  19687. > They tell me I have to prove I have a support contract every time I call. Do
  19688. > they just SUCK? That is the feeling I am getting from this list. Is that
  19689. > what you guys mean to say: "Run from 3COM, they SUCK!"
  19690. > 
  19691. > Jason
  19692. > 
  19693. > -----Original Message-----
  19694. > From: owner-usr-tc@lists.xmission.com
  19695. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
  19696. > Sent: Saturday, October 16, 1999 4:46 PM
  19697. > To: usr-tc@lists.xmission.com
  19698. > Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  19699. > 
  19700. > Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
  19701. > a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
  19702. > problem that has been addressed but not resolved. You would think this would
  19703. > concern 3com more than it does... just like all the complaints about support
  19704. > on this list.
  19705. > 
  19706. > Oh well when everyone is switching to a different platform they may care but
  19707. > it will be too late.
  19708. > 
  19709. > Ed
  19710. > 
  19711. > ----- Original Message -----
  19712. > From: Allen Marsalis <am@shreve.net>
  19713. > To: <usr-tc@lists.xmission.com>
  19714. > Sent: Saturday, October 16, 1999 6:11 PM
  19715. > Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  19716. > 
  19717. > Same here.  That's pretty much exactly how we feel about it.  However
  19718. > we occationally find a user with a good sportster/3com modem who can't
  19719. > get v.90 on our TCS but can on our TNT (eval) and more importantly,
  19720. > can with our competitors.  Users won't stay with 28.8 when they can
  19721. > get 48k elsewhere..  If there were no modem code issues, I'd be more
  19722. > than happy to send the eval back.  Instead, I'll probably get an invoice...
  19723. > 
  19724. > Well back when we started, we bought a superstack and it worked of course
  19725. > but when I found out it was half-duplex on all 10T ports, we sent it back
  19726. > and opted for a catalyst..  But nowadays I'm sure things are different.
  19727. > We outgrew the catalyst and now have a fastiron and we love it..
  19728. > 
  19729. > I realize that switches don't call for much support, but we did have
  19730. > some issues with the catalyst.  Ciscos support as amazing and they
  19731. > even called back again just to make sure we were happy.  3com on the
  19732. > otherhand wanted to charge us for support on a 1 day old switch!
  19733. > I just wanted to double check to see that their was no fdx on
  19734. > the ports before sending it back.  They could have cared less whether
  19735. > I returned it or not..  So I did!
  19736. > 
  19737. > Allen
  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: Allen Marsalis <am@shreve.net>
  19749. Subject: Re: (usr-tc) 3com V90 Problems
  19750. Date: 17 Oct 1999 17:30:34 -0500
  19751.  
  19752. At 04:22 PM 10/17/99 -0500, Brian wrote:
  19753.  
  19754. >I would imagine, actually hope, that 3com's tests labs, have done many
  19755. >tests against their own stuff and against competitors.  I would think they
  19756. >would not make a policy of releasing such data, unless of course 3com was
  19757. >best in every case, which I doubt it was, but certainly coudln't have done
  19758. >too poor.
  19759.  
  19760. Conversely, I would imagine that ascend's test labs have done
  19761. tests against their competitors..  And that they wouldn't release
  19762. such data unless they were best..  IOW, you would think that one
  19763. manufacturer (at least) would come out of the closet with data
  19764. proving that they were the best.  :)
  19765.  
  19766. I've always been disappointed that so few tests have been done
  19767. to rate 56k..  The only test I remember comparing x2 to kflex was
  19768. the boardwatch fiasco..  nothing totally unbiased and largely
  19769. scientific seems to be done on a regular basis..
  19770.  
  19771. What is keeping us from polling both chassis every hour and logging
  19772. the actual connect speeds into an SQL database?  If the scripts (telnet,
  19773. snmp, whatever) could be written, they could be passed around by ISP's
  19774. giving some pretty good 'real world' data to support or refute our
  19775. perceptions of modem performance.  Has anyone out there ever done
  19776. anything like this?
  19777.  
  19778. Allen
  19779.  
  19780.  
  19781. >
  19782. >Brian
  19783. >
  19784.  
  19785.  
  19786.  
  19787. -
  19788.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19789.  with "unsubscribe usr-tc" in the body of the message.
  19790.  For information on digests or retrieving files and old messages send
  19791.  "help" to the same address.  Do not use quotes in your message.
  19792.  
  19793.  
  19794. -------------------------------------------------------------------------------
  19795.  
  19796. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  19797. Subject: Re: (usr-tc) 3com V90 Problems
  19798. Date: 17 Oct 1999 18:51:37 -0400 (EDT)
  19799.  
  19800.  
  19801. On Sun, 17 Oct 1999, Brian wrote:
  19802.  
  19803. > What I am getting at, is raw data and numbers are the best, rather than
  19804. > the more subjective data of customers opinions about their connections.
  19805.  
  19806. No doubt about that; I've seen the stuff you mentioned happening...one
  19807. can't really read *too* much into customer complaints (or praises) except
  19808. a feeling of customer satisfaction. But if a customer is unsatisfied for
  19809. the wrong (or misunderstood) reasons, the question is where you want to
  19810. stand on it.
  19811.  
  19812. For example...I had a 3rd party actively test us vs. our competition WRT
  19813. dialup connect speeds/xfer rates. The downside is that they found that
  19814. for most client-side modems, our initial connect speed was lower than
  19815. the competition. Funny thing was, in many cases, the competition's higher
  19816. initial speed would get retrained down....while ours either remained the
  19817. same or retrained up.
  19818.  
  19819. The other huge point that was found was that we had faster overall xfer
  19820. rates, even with our lower connect speeds. This point was pursued further,
  19821. and it was found that a 33.6k connection thru us gave faster xfer rates
  19822. than our competitors' 43-46k rates!  Rather interesting what a solid
  19823. connection with no retransmits can do up against a shaky, albeit faster,
  19824. connection with a bunch of retransmits.
  19825.  
  19826. The above results made me feel good, but there's still the question of
  19827. what to do about it. The only thing the average customer sees is the
  19828. initial connect speed, and in the majority of cases, it's quite useless
  19829. to start telling them about retraining, retransmits, and how the real
  19830. measure is xfer rate anyway. Most just think you're shooting them a load
  19831. of bull, trying to swamp them with computer-talk to cover yourself.
  19832.  
  19833. Me, I give it a shot anyway...if they understand, great, if not, oh well,
  19834. they're not really my target customer anyway. That may sound like the
  19835. age-old 'sour grapes' attitude, but know that I'm not in biz to get the
  19836. biggest part of the market...I'm here to skim the cream and garner the
  19837. best customers. When you're targeting power-users and businesses, you
  19838. wind up with people who understand more of the details.
  19839.  
  19840. But much harder if your target is the average joe, my guess would be to
  19841. switch to whatever platform gave you the highest initial connect so that
  19842. all the ones who guage everything by their initial speed will be happy.
  19843. Or plunge into the murky deep and switch their connect speed reporting
  19844. to the DTE rate so they can be amazed at your super 115k connects. (:
  19845.  
  19846. But as your message said, it's hard to trust customer appraisals of your
  19847. speeds. If you want to know the scoop, get a 3rd party who a) knows what
  19848. they're doing, and b) has no interest in the outcome to run tests and
  19849. report back.
  19850.  
  19851. PS. No probs here with 3com client modem connections that I can tell.
  19852. But then again, I don't have any Ascends to compare to. This is with
  19853. the following:
  19854.  
  19855.    HARC:  h/w ver. 1.0.0   s/w ver. 4.0.30
  19856.    HDSP:  h/w ver. 0.49.0  s/w ver. 1.2.5
  19857.  
  19858.  
  19859.  
  19860. -
  19861.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19862.  with "unsubscribe usr-tc" in the body of the message.
  19863.  For information on digests or retrieving files and old messages send
  19864.  "help" to the same address.  Do not use quotes in your message.
  19865.  
  19866.  
  19867. -------------------------------------------------------------------------------
  19868.  
  19869. From: "Jason A. Nunnelley" <interests@linkfast.net>
  19870. Subject: RE: (usr-tc) 3com V90 Problems
  19871. Date: 17 Oct 1999 17:45:04 -0700
  19872.  
  19873. well, that sounds good - and add that you need to test with a few different
  19874. switches and telcos. that makes an impact also.
  19875.  
  19876. -----Original Message-----
  19877. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Allen Marsalis
  19878. Sent: Sunday, October 17, 1999 3:31 PM
  19879.  
  19880.  
  19881. At 04:22 PM 10/17/99 -0500, Brian wrote:
  19882.  
  19883. >I would imagine, actually hope, that 3com's tests labs, have done many
  19884. >tests against their own stuff and against competitors.  I would think they
  19885. >would not make a policy of releasing such data, unless of course 3com was
  19886. >best in every case, which I doubt it was, but certainly coudln't have done
  19887. >too poor.
  19888.  
  19889. Conversely, I would imagine that ascend's test labs have done
  19890. tests against their competitors..  And that they wouldn't release
  19891. such data unless they were best..  IOW, you would think that one
  19892. manufacturer (at least) would come out of the closet with data
  19893. proving that they were the best.  :)
  19894.  
  19895. I've always been disappointed that so few tests have been done
  19896. to rate 56k..  The only test I remember comparing x2 to kflex was
  19897. the boardwatch fiasco..  nothing totally unbiased and largely
  19898. scientific seems to be done on a regular basis..
  19899.  
  19900. What is keeping us from polling both chassis every hour and logging
  19901. the actual connect speeds into an SQL database?  If the scripts (telnet,
  19902. snmp, whatever) could be written, they could be passed around by ISP's
  19903. giving some pretty good 'real world' data to support or refute our
  19904. perceptions of modem performance.  Has anyone out there ever done
  19905. anything like this?
  19906.  
  19907. Allen
  19908.  
  19909.  
  19910. >
  19911. >Brian
  19912. >
  19913.  
  19914.  
  19915.  
  19916. -
  19917.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19918.  with "unsubscribe usr-tc" in the body of the message.
  19919.  For information on digests or retrieving files and old messages send
  19920.  "help" to the same address.  Do not use quotes in your message.
  19921.  
  19922.  
  19923. -
  19924.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19925.  with "unsubscribe usr-tc" in the body of the message.
  19926.  For information on digests or retrieving files and old messages send
  19927.  "help" to the same address.  Do not use quotes in your message.
  19928.  
  19929.  
  19930. -------------------------------------------------------------------------------
  19931.  
  19932. From: "Jason A. Nunnelley" <interests@linkfast.net>
  19933. Subject: RE: (usr-tc) 3com V90 Problems
  19934. Date: 17 Oct 1999 17:50:24 -0700
  19935.  
  19936. What you can count on is Churn. If customers leave you - you can see the
  19937. difference. I have lost fewer customers with connection issues with 3COM
  19938. than Livingston (with the PM3 that is). I have never had a connection issue
  19939. with the PM2e30 (analog). It is 100%!
  19940.  
  19941. So, what should I use when my 3COM contract runs out? Any sugestions? I
  19942. guess everyone considers 3COM a loser when it comes to support. Yet, the
  19943. largest ISPs use it. Why? M$pring, MCI, etc.
  19944.  
  19945. Why?
  19946.  
  19947. -----Original Message-----
  19948. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
  19949. Jr.
  19950. Sent: Sunday, October 17, 1999 3:52 PM
  19951.  
  19952.  
  19953.  
  19954. On Sun, 17 Oct 1999, Brian wrote:
  19955.  
  19956. > What I am getting at, is raw data and numbers are the best, rather than
  19957. > the more subjective data of customers opinions about their connections.
  19958.  
  19959. No doubt about that; I've seen the stuff you mentioned happening...one
  19960. can't really read *too* much into customer complaints (or praises) except
  19961. a feeling of customer satisfaction. But if a customer is unsatisfied for
  19962. the wrong (or misunderstood) reasons, the question is where you want to
  19963. stand on it.
  19964.  
  19965. For example...I had a 3rd party actively test us vs. our competition WRT
  19966. dialup connect speeds/xfer rates. The downside is that they found that
  19967. for most client-side modems, our initial connect speed was lower than
  19968. the competition. Funny thing was, in many cases, the competition's higher
  19969. initial speed would get retrained down....while ours either remained the
  19970. same or retrained up.
  19971.  
  19972. The other huge point that was found was that we had faster overall xfer
  19973. rates, even with our lower connect speeds. This point was pursued further,
  19974. and it was found that a 33.6k connection thru us gave faster xfer rates
  19975. than our competitors' 43-46k rates!  Rather interesting what a solid
  19976. connection with no retransmits can do up against a shaky, albeit faster,
  19977. connection with a bunch of retransmits.
  19978.  
  19979. The above results made me feel good, but there's still the question of
  19980. what to do about it. The only thing the average customer sees is the
  19981. initial connect speed, and in the majority of cases, it's quite useless
  19982. to start telling them about retraining, retransmits, and how the real
  19983. measure is xfer rate anyway. Most just think you're shooting them a load
  19984. of bull, trying to swamp them with computer-talk to cover yourself.
  19985.  
  19986. Me, I give it a shot anyway...if they understand, great, if not, oh well,
  19987. they're not really my target customer anyway. That may sound like the
  19988. age-old 'sour grapes' attitude, but know that I'm not in biz to get the
  19989. biggest part of the market...I'm here to skim the cream and garner the
  19990. best customers. When you're targeting power-users and businesses, you
  19991. wind up with people who understand more of the details.
  19992.  
  19993. But much harder if your target is the average joe, my guess would be to
  19994. switch to whatever platform gave you the highest initial connect so that
  19995. all the ones who guage everything by their initial speed will be happy.
  19996. Or plunge into the murky deep and switch their connect speed reporting
  19997. to the DTE rate so they can be amazed at your super 115k connects. (:
  19998.  
  19999. But as your message said, it's hard to trust customer appraisals of your
  20000. speeds. If you want to know the scoop, get a 3rd party who a) knows what
  20001. they're doing, and b) has no interest in the outcome to run tests and
  20002. report back.
  20003.  
  20004. PS. No probs here with 3com client modem connections that I can tell.
  20005. But then again, I don't have any Ascends to compare to. This is with
  20006. the following:
  20007.  
  20008.    HARC:  h/w ver. 1.0.0   s/w ver. 4.0.30
  20009.    HDSP:  h/w ver. 0.49.0  s/w ver. 1.2.5
  20010.  
  20011.  
  20012.  
  20013. -
  20014.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20015.  with "unsubscribe usr-tc" in the body of the message.
  20016.  For information on digests or retrieving files and old messages send
  20017.  "help" to the same address.  Do not use quotes in your message.
  20018.  
  20019.  
  20020. -
  20021.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20022.  with "unsubscribe usr-tc" in the body of the message.
  20023.  For information on digests or retrieving files and old messages send
  20024.  "help" to the same address.  Do not use quotes in your message.
  20025.  
  20026.  
  20027. -------------------------------------------------------------------------------
  20028.  
  20029. From: Allen Marsalis <am@shreve.net>
  20030. Subject: RE: (usr-tc) 3com V90 Problems
  20031. Date: 17 Oct 1999 17:59:08 -0500
  20032.  
  20033. At 05:02 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  20034. >Less than 1 in 50 customers know the difference between a connection that
  20035. >says 56K and only downloads 2-3K, and a good strong 34K connection
  20036. >delivering a 5-6K download speed.
  20037.  
  20038. I disagree.  first, I've never seen a v.34 connection sustain 5-6K on
  20039. a binary transfer.  ascii maybe.. but even if it did, that's totally
  20040. dependant on compression algorithms and the character of the data.  It
  20041. has nothing to do with the actual number of bits xfered.. 
  20042.  
  20043. Next, a v.90 connection by definition has to yield better than 2-3kps
  20044. (actual bits) downstream..
  20045.  
  20046. Last, even lusers can read dialog boxes when they download a windows
  20047. upgrade, ftp a file, or read binary newsgroups..  You underestimate
  20048. your customers ability to make an observation or judgement..
  20049.  
  20050. Furthermore, I'm not willing to lose 1 in 50 customers..  that's
  20051. 2% of our customer base..
  20052.  
  20053. >
  20054. >As for relying on customers' comments to make Network Decisions... does
  20055. >anyone really do that?
  20056.  
  20057. absolutely..  otherwise I might chose 1200 baud modems to save money.. ;)
  20058.  
  20059. >I know my customers don't know the difference.
  20060.  
  20061. <sigh>
  20062.  
  20063. >I rely
  20064. >on data that makes sense.
  20065.  
  20066. and what *data* is that?
  20067.  
  20068. >I know I told no one when I first switched to 3COM
  20069. >and yet, I did get positive feedback immediately.
  20070.  
  20071. But I thought that customers don't know the difference?  And
  20072. that it doesn't matter what customers feedback is because
  20073. the comments don't impact network decision making..
  20074.  
  20075. Allen
  20076.  
  20077. >
  20078. >Jason
  20079. >
  20080. >-----Original Message-----
  20081. >From: owner-usr-tc@lists.xmission.com
  20082. >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  20083. >Sent: Sunday, October 17, 1999 2:19 PM
  20084. >To: usr-tc@lists.xmission.com
  20085. >Subject: Re: (usr-tc) 3com V90 Problems
  20086. >
  20087. >
  20088. >I wonder how much of it is pschological vs. real.  For example, ever post
  20089. >to your customers about how you made an upgrade to something like your
  20090. >mail server, and then they start calling tech support and say things like
  20091. >"ever since you all upgraded the server, I can't connect fast".  I often
  20092. >thought, if you told the customers all of them, that you were upgrading
  20093. >your modem code tonight, and wanted their feedback the following day,and
  20094. >you really didn't touch anything, I am betting 25% would say they connect
  20095. >faster, 25% would say they connect slower, and 50% would notice no
  20096. >change.........i'm telling you I believe in this :)
  20097. >
  20098. >Its like those customers who's modems report the DTE speed of 115,200, and
  20099. >when you fix them up, it only reports say 28800, yet they swear the
  20100. >connection is not as fast anymore.
  20101. >
  20102. >Well if a customer visually sees a v90 connect, and its a terrible
  20103. >connection, would they claim that connection was faster than a really
  20104. >solid v.34 connect?
  20105. >
  20106. >What I am getting at, is raw data and numbers are the best, rather than
  20107. >the more subjective data of customers opinions about their connections.
  20108. >
  20109. >
  20110. >
  20111. >On Sun, 17 Oct 1999, Greg Coffey wrote:
  20112. >
  20113. >> I've never had a customer call the v90 connection "unreliable" to the
  20114. >> competition's Ascends.  The feedback that I've got from customers is that
  20115. >> they get better throughput and are not dissatified with the connects to
  20116. >the
  20117. >> Ascends.  They are using USR modems to dial and they connect consistently
  20118. >> with Ascends at v90 rates, usually 40something.  They never connect at v90
  20119. >> to our TC racks from the same location, using the same PC, software, phone
  20120. >> lines, config, etc.  I don't know the exact cause, they seem to be on the
  20121. >> fringe of the v90 availability area.  3Com described it to me as a "bug"
  20122. >in
  20123. >> the Ascend server firmware.  All I know is that it has cost me customers
  20124. >in
  20125. >> the past and continues to be an issue that I have no answer for when it
  20126. >> comes up.  I have gone to great lengths to explain to them what I have
  20127. >> learned many months ago from 3Com but I don't think they believe me.
  20128. >Would
  20129. >> you believe that 3Com/USR modems connect better to the competition than
  20130. >> their own racks?  Thankfully, it is a somewhat rare occurance and I only
  20131. >> have to explain once or twice a month.  I really don't know for sure to
  20132. >> what extent it really occurs.  I do know that I have lost customers over
  20133. >> this and it continues to be an issue.  I am getting tired of no news to
  20134. >> update the situation though.  I'm also afraid that it will harm our
  20135. >> reputation if this continues as is.  Word of mouth is still our best
  20136. >> marketing and this will grow in significance with time.
  20137. >>
  20138. >>
  20139. >>
  20140. >> At 11:15 AM 10/17/99 -0700, you wrote:
  20141. >> >Ed writes...
  20142. >> >> . . .
  20143. >> >>Let him know you are having the 3com V90 problems and you want it
  20144. >resolved.
  20145. >> >>I think they believe it is a rare scenerio not effecting very many
  20146. >people.
  20147. >> >>We told them it was more widespread than they knew... and that if 3com
  20148. >> >>client modems connect to Ascends they should darn well connect to a 3com
  20149. >TC.
  20150. >> >>No ifs ands or buts.
  20151. >> >
  20152. >> >If modem X connects at an unreliable V.90 speed to an Ascend, and
  20153. >> >connects at a reliable v.34 rate to a 3com, that's a problem?
  20154. >> >
  20155. >> >
  20156. >> >--
  20157. >> >Aaron Nabil
  20158. >> >
  20159. >> >-
  20160. >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20161. >> > with "unsubscribe usr-tc" in the body of the message.
  20162. >> > For information on digests or retrieving files and old messages send
  20163. >> > "help" to the same address.  Do not use quotes in your message.
  20164. >> >
  20165. >> >
  20166. >>
  20167. >> Thanks,
  20168. >>
  20169. >> Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446
  20170. >> =====================================================================
  20171. >> 100 N. Center St., Casper, WY  82601     WWW.VCN.COM
  20172. >>
  20173. >>
  20174. >> -
  20175. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20176. >>  with "unsubscribe usr-tc" in the body of the message.
  20177. >>  For information on digests or retrieving files and old messages send
  20178. >>  "help" to the same address.  Do not use quotes in your message.
  20179. >>
  20180. >
  20181. >-----------------------------------------------------
  20182. >Brian Feeny (BF304)     signal@shreve.net
  20183. >318-222-2638 x 109    http://www.shreve.net/~signal
  20184. >Network Administrator   ShreveNet Inc. (ASN 11881)
  20185. >
  20186. >
  20187. >-
  20188. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20189. > with "unsubscribe usr-tc" in the body of the message.
  20190. > For information on digests or retrieving files and old messages send
  20191. > "help" to the same address.  Do not use quotes in your message.
  20192. >
  20193. >
  20194. >-
  20195. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20196. > with "unsubscribe usr-tc" in the body of the message.
  20197. > For information on digests or retrieving files and old messages send
  20198. > "help" to the same address.  Do not use quotes in your message.
  20199.  
  20200.  
  20201. -
  20202.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20203.  with "unsubscribe usr-tc" in the body of the message.
  20204.  For information on digests or retrieving files and old messages send
  20205.  "help" to the same address.  Do not use quotes in your message.
  20206.  
  20207.  
  20208. -------------------------------------------------------------------------------
  20209.  
  20210. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  20211. Subject: RE: (usr-tc) 3com V90 Problems
  20212. Date: 17 Oct 1999 19:30:09 -0400 (EDT)
  20213.  
  20214.  
  20215. On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
  20216.  
  20217. > What you can count on is Churn. If customers leave you - you can see the
  20218. > difference.
  20219.  
  20220. Yep, that's why I target power-users and businesses. They understand
  20221. the myriad issues of the speed thing and are willing to look deeper than
  20222. that initial connect into what they're actually getting. My churn rate
  20223. is less than 0.5%, despite the fact that I'm more expensive ($25/mo for
  20224. limited-150hour vs competitions <$20 unlimited). Our largest reason for
  20225. account termination is 'moving out of area'; we only lose about 1 customer
  20226. every three months to our competition. Conversely, we gain about 5-10 per
  20227. month from them...always their best customers too...skimmin' the cream,
  20228. as it were. Lower tech support costs because our customers generally
  20229. have more, umm, intelligence.  [on the other hand, when they're power
  20230. users and businesses, especially when they're paying higher prices, when
  20231. they do have a problem you gotta jump on it quick, and you can't bullshit
  20232. your way through *anything*.  The other thing is that you'll *never* have
  20233. the biggest slice of the market...just the best slice.]
  20234.  
  20235. BTW, for anyone interested, a good way to get more accurate stats on
  20236. where your customers are going when they leave you is to provide free
  20237. email forwarding for customers who terminate. We give any customer who
  20238. terminates (for any reason) free email forwarding to their new address
  20239. for a month. Of course, to activate it, they have to give us their new
  20240. address. (:  Doesn't make it 100% perfect, of course, but will cut through
  20241. the ones who say 'terminating because we don't need internet/our computer
  20242. is broken' and then give an email address at the competition. (:
  20243.  
  20244.  
  20245. > -----Original Message-----
  20246. > From: owner-usr-tc@lists.xmission.com
  20247. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
  20248. > Jr.
  20249. > Sent: Sunday, October 17, 1999 3:52 PM
  20250. > To: usr-tc@lists.xmission.com
  20251. > Subject: Re: (usr-tc) 3com V90 Problems
  20252. > 
  20253. > 
  20254. > 
  20255. > On Sun, 17 Oct 1999, Brian wrote:
  20256. > 
  20257. > > What I am getting at, is raw data and numbers are the best, rather than
  20258. > > the more subjective data of customers opinions about their connections.
  20259. > 
  20260. > No doubt about that; I've seen the stuff you mentioned happening...one
  20261. > can't really read *too* much into customer complaints (or praises) except
  20262. > a feeling of customer satisfaction. But if a customer is unsatisfied for
  20263. > the wrong (or misunderstood) reasons, the question is where you want to
  20264. > stand on it.
  20265. > 
  20266. > For example...I had a 3rd party actively test us vs. our competition WRT
  20267. > dialup connect speeds/xfer rates. The downside is that they found that
  20268. > for most client-side modems, our initial connect speed was lower than
  20269. > the competition. Funny thing was, in many cases, the competition's higher
  20270. > initial speed would get retrained down....while ours either remained the
  20271. > same or retrained up.
  20272. > 
  20273. > The other huge point that was found was that we had faster overall xfer
  20274. > rates, even with our lower connect speeds. This point was pursued further,
  20275. > and it was found that a 33.6k connection thru us gave faster xfer rates
  20276. > than our competitors' 43-46k rates!  Rather interesting what a solid
  20277. > connection with no retransmits can do up against a shaky, albeit faster,
  20278. > connection with a bunch of retransmits.
  20279. > 
  20280. > The above results made me feel good, but there's still the question of
  20281. > what to do about it. The only thing the average customer sees is the
  20282. > initial connect speed, and in the majority of cases, it's quite useless
  20283. > to start telling them about retraining, retransmits, and how the real
  20284. > measure is xfer rate anyway. Most just think you're shooting them a load
  20285. > of bull, trying to swamp them with computer-talk to cover yourself.
  20286. > 
  20287. > Me, I give it a shot anyway...if they understand, great, if not, oh well,
  20288. > they're not really my target customer anyway. That may sound like the
  20289. > age-old 'sour grapes' attitude, but know that I'm not in biz to get the
  20290. > biggest part of the market...I'm here to skim the cream and garner the
  20291. > best customers. When you're targeting power-users and businesses, you
  20292. > wind up with people who understand more of the details.
  20293. > 
  20294. > But much harder if your target is the average joe, my guess would be to
  20295. > switch to whatever platform gave you the highest initial connect so that
  20296. > all the ones who guage everything by their initial speed will be happy.
  20297. > Or plunge into the murky deep and switch their connect speed reporting
  20298. > to the DTE rate so they can be amazed at your super 115k connects. (:
  20299. > 
  20300. > But as your message said, it's hard to trust customer appraisals of your
  20301. > speeds. If you want to know the scoop, get a 3rd party who a) knows what
  20302. > they're doing, and b) has no interest in the outcome to run tests and
  20303. > report back.
  20304. > 
  20305. > PS. No probs here with 3com client modem connections that I can tell.
  20306. > But then again, I don't have any Ascends to compare to. This is with
  20307. > the following:
  20308. > 
  20309. >    HARC:  h/w ver. 1.0.0   s/w ver. 4.0.30
  20310. >    HDSP:  h/w ver. 0.49.0  s/w ver. 1.2.5
  20311. > 
  20312. > 
  20313. > 
  20314. > -
  20315. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20316. >  with "unsubscribe usr-tc" in the body of the message.
  20317. >  For information on digests or retrieving files and old messages send
  20318. >  "help" to the same address.  Do not use quotes in your message.
  20319. > 
  20320. > 
  20321. > -
  20322. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20323. >  with "unsubscribe usr-tc" in the body of the message.
  20324. >  For information on digests or retrieving files and old messages send
  20325. >  "help" to the same address.  Do not use quotes in your message.
  20326. > 
  20327.  
  20328.  
  20329. -
  20330.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20331.  with "unsubscribe usr-tc" in the body of the message.
  20332.  For information on digests or retrieving files and old messages send
  20333.  "help" to the same address.  Do not use quotes in your message.
  20334.  
  20335.  
  20336. -------------------------------------------------------------------------------
  20337.  
  20338. From: "Jason A. Nunnelley" <interests@linkfast.net>
  20339. Subject: RE: (usr-tc) 3com V90 Problems
  20340. Date: 17 Oct 1999 18:16:39 -0700
  20341.  
  20342. OK, ouch! You made good points off a reaction note, not a well thought out
  20343. explanation of procedural decision making. Let me clarify: Often a customer
  20344. response is reactionary and not factual. EX: you get a call from a customer
  20345. telling you that your upgrade has screwed up their connection. Now, you
  20346. suck! It turns out that they couldn't get their modem to say 56K, and they
  20347. think that makes the difference. So, without doing in depth research as to
  20348. the real data speed they connect at (looking at the data transfer rate or
  20349. connection rate by polling the modems), you assume this one comment means
  20350. you have a bad deal. Or, perhaps it is several calls. We got a rash of
  20351. K-Flex callers right after setting up the 3COM. So, we assumed there was a
  20352. 3COM issue. In a way there was. We had a truckload of people that old techs
  20353. had helped get K-Flex working. Guess what!? It did not work all that hot
  20354. with the 3COM. Upgrades to v.90 - no more trouble. Now, if I see a chunk
  20355. leaving me (more than before) with 3COM - screw 3COM. I am loyal to whomever
  20356. get's me paid. I totally agree that 2% loss of customers is unacceptable.
  20357. They know that when they can't download ICQ in under 30 minutes, you have a
  20358. speed issue. And, of course I listen to my customers. It is not my sole and
  20359. only mode of information gathering. The fact is: most of my customers own
  20360. 3COM or USR modems. They connect Much Better to 3COM than LT (Livingston).
  20361. As a matter of fact, I can't get certain modems to connect to Livingston at
  20362. all (without an overhall of the factory drivers).
  20363.  
  20364. So, good point! I was being general and assuming. I really do listen to my
  20365. customers (why I have v.90 - good point). I also know that 2% loss is way to
  20366. much. And, I also understand that most customers recognize a serious drop in
  20367. quality connections. However, I really meant to comment more on the
  20368. knee-jerk reactions to a hand full of customer complaints and the idea that
  20369. they understand a few data bit per second change in speed. They just want to
  20370. connect every time without a connection issue.
  20371.  
  20372. I am seeing a bunch of drops. Now, that is what concerns me! When I see 5%
  20373. drops, I get to wondering if I am about to lose 5% of my customer base due
  20374. to 3COM. You don't see this stuff on Livingston's groups. There is not a
  20375. constant impaling of the programmers and support crew. Why?! Because they do
  20376. a great job - that's why. I am seriously thinking about dumping 3COM. So,
  20377. make a public or private suggestion based on numbers. Who should I trade in
  20378. for? I do not want to ride a sinking ship to loser-ville.
  20379.  
  20380. BTW, once I get my DNA results to get technical support from 3COM, I rather
  20381. like their tech support. I just prefer the response LT support gives you.
  20382. They don't have to complete a ID Proofing contest before sharing important
  20383. information or software.
  20384.  
  20385. Jason
  20386.  
  20387. -----Original Message-----
  20388. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Allen Marsalis
  20389. Sent: Sunday, October 17, 1999 3:59 PM
  20390.  
  20391.  
  20392. At 05:02 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  20393. >Less than 1 in 50 customers know the difference between a connection that
  20394. >says 56K and only downloads 2-3K, and a good strong 34K connection
  20395. >delivering a 5-6K download speed.
  20396.  
  20397. I disagree.  first, I've never seen a v.34 connection sustain 5-6K on
  20398. a binary transfer.  ascii maybe.. but even if it did, that's totally
  20399. dependant on compression algorithms and the character of the data.  It
  20400. has nothing to do with the actual number of bits xfered..
  20401.  
  20402. Next, a v.90 connection by definition has to yield better than 2-3kps
  20403. (actual bits) downstream..
  20404.  
  20405. Last, even lusers can read dialog boxes when they download a windows
  20406. upgrade, ftp a file, or read binary newsgroups..  You underestimate
  20407. your customers ability to make an observation or judgement..
  20408.  
  20409. Furthermore, I'm not willing to lose 1 in 50 customers..  that's
  20410. 2% of our customer base..
  20411.  
  20412. >
  20413. >As for relying on customers' comments to make Network Decisions... does
  20414. >anyone really do that?
  20415.  
  20416. absolutely..  otherwise I might chose 1200 baud modems to save money.. ;)
  20417.  
  20418. >I know my customers don't know the difference.
  20419.  
  20420. <sigh>
  20421.  
  20422. >I rely
  20423. >on data that makes sense.
  20424.  
  20425. and what *data* is that?
  20426.  
  20427. >I know I told no one when I first switched to 3COM
  20428. >and yet, I did get positive feedback immediately.
  20429.  
  20430. But I thought that customers don't know the difference?  And
  20431. that it doesn't matter what customers feedback is because
  20432. the comments don't impact network decision making..
  20433.  
  20434. Allen
  20435.  
  20436. >
  20437. >Jason
  20438. >
  20439. >-----Original Message-----
  20440. >From: owner-usr-tc@lists.xmission.com
  20441. >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  20442. >Sent: Sunday, October 17, 1999 2:19 PM
  20443. >To: usr-tc@lists.xmission.com
  20444. >Subject: Re: (usr-tc) 3com V90 Problems
  20445. >
  20446. >
  20447. >I wonder how much of it is pschological vs. real.  For example, ever post
  20448. >to your customers about how you made an upgrade to something like your
  20449. >mail server, and then they start calling tech support and say things like
  20450. >"ever since you all upgraded the server, I can't connect fast".  I often
  20451. >thought, if you told the customers all of them, that you were upgrading
  20452. >your modem code tonight, and wanted their feedback the following day,and
  20453. >you really didn't touch anything, I am betting 25% would say they connect
  20454. >faster, 25% would say they connect slower, and 50% would notice no
  20455. >change.........i'm telling you I believe in this :)
  20456. >
  20457. >Its like those customers who's modems report the DTE speed of 115,200, and
  20458. >when you fix them up, it only reports say 28800, yet they swear the
  20459. >connection is not as fast anymore.
  20460. >
  20461. >Well if a customer visually sees a v90 connect, and its a terrible
  20462. >connection, would they claim that connection was faster than a really
  20463. >solid v.34 connect?
  20464. >
  20465. >What I am getting at, is raw data and numbers are the best, rather than
  20466. >the more subjective data of customers opinions about their connections.
  20467. >
  20468. >
  20469. >
  20470. >On Sun, 17 Oct 1999, Greg Coffey wrote:
  20471. >
  20472. >> I've never had a customer call the v90 connection "unreliable" to the
  20473. >> competition's Ascends.  The feedback that I've got from customers is that
  20474. >> they get better throughput and are not dissatified with the connects to
  20475. >the
  20476. >> Ascends.  They are using USR modems to dial and they connect consistently
  20477. >> with Ascends at v90 rates, usually 40something.  They never connect at
  20478. v90
  20479. >> to our TC racks from the same location, using the same PC, software,
  20480. phone
  20481. >> lines, config, etc.  I don't know the exact cause, they seem to be on the
  20482. >> fringe of the v90 availability area.  3Com described it to me as a "bug"
  20483. >in
  20484. >> the Ascend server firmware.  All I know is that it has cost me customers
  20485. >in
  20486. >> the past and continues to be an issue that I have no answer for when it
  20487. >> comes up.  I have gone to great lengths to explain to them what I have
  20488. >> learned many months ago from 3Com but I don't think they believe me.
  20489. >Would
  20490. >> you believe that 3Com/USR modems connect better to the competition than
  20491. >> their own racks?  Thankfully, it is a somewhat rare occurance and I only
  20492. >> have to explain once or twice a month.  I really don't know for sure to
  20493. >> what extent it really occurs.  I do know that I have lost customers over
  20494. >> this and it continues to be an issue.  I am getting tired of no news to
  20495. >> update the situation though.  I'm also afraid that it will harm our
  20496. >> reputation if this continues as is.  Word of mouth is still our best
  20497. >> marketing and this will grow in significance with time.
  20498. >>
  20499. >>
  20500. >>
  20501. >> At 11:15 AM 10/17/99 -0700, you wrote:
  20502. >> >Ed writes...
  20503. >> >> . . .
  20504. >> >>Let him know you are having the 3com V90 problems and you want it
  20505. >resolved.
  20506. >> >>I think they believe it is a rare scenerio not effecting very many
  20507. >people.
  20508. >> >>We told them it was more widespread than they knew... and that if 3com
  20509. >> >>client modems connect to Ascends they should darn well connect to a
  20510. 3com
  20511. >TC.
  20512. >> >>No ifs ands or buts.
  20513. >> >
  20514. >> >If modem X connects at an unreliable V.90 speed to an Ascend, and
  20515. >> >connects at a reliable v.34 rate to a 3com, that's a problem?
  20516. >> >
  20517. >> >
  20518. >> >--
  20519. >> >Aaron Nabil
  20520. >> >
  20521. >> >-
  20522. >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20523. >> > with "unsubscribe usr-tc" in the body of the message.
  20524. >> > For information on digests or retrieving files and old messages send
  20525. >> > "help" to the same address.  Do not use quotes in your message.
  20526. >> >
  20527. >> >
  20528. >>
  20529. >> Thanks,
  20530. >>
  20531. >> Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446
  20532. >> =====================================================================
  20533. >> 100 N. Center St., Casper, WY  82601     WWW.VCN.COM
  20534. >>
  20535. >>
  20536. >> -
  20537. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20538. >>  with "unsubscribe usr-tc" in the body of the message.
  20539. >>  For information on digests or retrieving files and old messages send
  20540. >>  "help" to the same address.  Do not use quotes in your message.
  20541. >>
  20542. >
  20543. >-----------------------------------------------------
  20544. >Brian Feeny (BF304)     signal@shreve.net
  20545. >318-222-2638 x 109    http://www.shreve.net/~signal
  20546. >Network Administrator   ShreveNet Inc. (ASN 11881)
  20547. >
  20548. >
  20549. >-
  20550. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20551. > with "unsubscribe usr-tc" in the body of the message.
  20552. > For information on digests or retrieving files and old messages send
  20553. > "help" to the same address.  Do not use quotes in your message.
  20554. >
  20555. >
  20556. >-
  20557. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20558. > with "unsubscribe usr-tc" in the body of the message.
  20559. > For information on digests or retrieving files and old messages send
  20560. > "help" to the same address.  Do not use quotes in your message.
  20561.  
  20562.  
  20563. -
  20564.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20565.  with "unsubscribe usr-tc" in the body of the message.
  20566.  For information on digests or retrieving files and old messages send
  20567.  "help" to the same address.  Do not use quotes in your message.
  20568.  
  20569.  
  20570. -
  20571.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20572.  with "unsubscribe usr-tc" in the body of the message.
  20573.  For information on digests or retrieving files and old messages send
  20574.  "help" to the same address.  Do not use quotes in your message.
  20575.  
  20576.  
  20577. -------------------------------------------------------------------------------
  20578.  
  20579. From: "Scot Desort" <scot@njaccess.net>
  20580. Subject: RE: (usr-tc) 3com V90 Problems
  20581. Date: 17 Oct 1999 20:06:49 -0400
  20582.  
  20583. Aaron-
  20584.  
  20585. Since you own both, and seem to be in the upper percentile of technically
  20586. savy telecom people on this list, have YOU personally been able to gather
  20587. any significant data showing that the Ascend offers a greater percentage of
  20588. your customers a "better" connection than on the Hiper?
  20589.  
  20590. (By better, it may even mean a "subjective" quality of the connection, where
  20591. the connect speed to both NAS's is the same, but the connection throughput
  20592. is better, or just "seems and feels" faster to the end user)
  20593.  
  20594. -Scot
  20595.  
  20596.  
  20597.  
  20598. -----Original Message-----
  20599. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  20600. Sent: Sunday, October 17, 1999 3:59 PM
  20601.  
  20602.  
  20603.  
  20604. I have _own_ both Max's and Hiperdsps.
  20605.  
  20606. > . . .
  20607.  
  20608.  
  20609.  
  20610. -
  20611.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20612.  with "unsubscribe usr-tc" in the body of the message.
  20613.  For information on digests or retrieving files and old messages send
  20614.  "help" to the same address.  Do not use quotes in your message.
  20615.  
  20616.  
  20617. -------------------------------------------------------------------------------
  20618.  
  20619. From: "Scot Desort" <scot@njaccess.net>
  20620. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  20621. Date: 17 Oct 1999 20:13:47 -0400
  20622.  
  20623. I have only been a 3COM customer for a few months, and I do not regret my
  20624. decision, YET. Many on this list have been jilted by 3COM for a long time.
  20625. It will take a lot to win these folks back. I was previously using a
  20626. Microcom modem platform, and my end user connect issues have virtually been
  20627. eliminated. But I am small, and new to 3COM, so my voice has little weight
  20628. on this subject. And I cannot compare 3COM to Ascend or LT NAS's.
  20629.  
  20630. I was thinking -- while the DSP and Hiper code controls almost all of the
  20631. cards' functions, is it possible that the physical hardware on the DSP cards
  20632. is playing a role in these problems? My cards are all less than 3 months
  20633. old, and I've NEVER experienced the modem-pair hanging problem that plagues
  20634. many here. I also have very, very few connect issues. Could it be the
  20635. HARDWARE revisions on the DSP cards are also effecting performance and
  20636. stability?
  20637.  
  20638. Just a thought...
  20639.  
  20640. -Scot
  20641.  
  20642.  
  20643. -----Original Message-----
  20644. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
  20645. Sent: Sunday, October 17, 1999 4:26 PM
  20646.  
  20647.  
  20648. I hear a lot of complaints about 3COM on this list. Is the general idea that
  20649. 3COM should not be used? I used PM3s, with a lot of connection issues, but
  20650. little management headaches. I have considered CISCO (even tried one out),
  20651. but have heard the nightmare stories about connection issues. Is there a
  20652. feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
  20653. back to LT. I got excellent support there. I have never even been able to
  20654. get 3COM to give me the TC Software, and I paid for the support contract.
  20655. They tell me I have to prove I have a support contract every time I call. Do
  20656. they just SUCK? That is the feeling I am getting from this list. Is that
  20657. what you guys mean to say: "Run from 3COM, they SUCK!"
  20658.  
  20659. Jason
  20660.  
  20661. -----Original Message-----
  20662. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
  20663. Sent: Saturday, October 16, 1999 4:46 PM
  20664.  
  20665.  
  20666. Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
  20667. a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
  20668. problem that has been addressed but not resolved. You would think this would
  20669. concern 3com more than it does... just like all the complaints about support
  20670. on this list.
  20671.  
  20672. Oh well when everyone is switching to a different platform they may care but
  20673. it will be too late.
  20674.  
  20675.  
  20676. Ed
  20677.  
  20678. ----- Original Message -----
  20679. Sent: Saturday, October 16, 1999 6:11 PM
  20680.  
  20681.  
  20682. Same here.  That's pretty much exactly how we feel about it.  However
  20683. we occationally find a user with a good sportster/3com modem who can't
  20684. get v.90 on our TCS but can on our TNT (eval) and more importantly,
  20685. can with our competitors.  Users won't stay with 28.8 when they can
  20686. get 48k elsewhere..  If there were no modem code issues, I'd be more
  20687. than happy to send the eval back.  Instead, I'll probably get an invoice...
  20688.  
  20689. Well back when we started, we bought a superstack and it worked of course
  20690. but when I found out it was half-duplex on all 10T ports, we sent it back
  20691. and opted for a catalyst..  But nowadays I'm sure things are different.
  20692. We outgrew the catalyst and now have a fastiron and we love it..
  20693.  
  20694. I realize that switches don't call for much support, but we did have
  20695. some issues with the catalyst.  Ciscos support as amazing and they
  20696. even called back again just to make sure we were happy.  3com on the
  20697. otherhand wanted to charge us for support on a 1 day old switch!
  20698. I just wanted to double check to see that their was no fdx on
  20699. the ports before sending it back.  They could have cared less whether
  20700. I returned it or not..  So I did!
  20701.  
  20702. Allen
  20703.  
  20704.  
  20705. -
  20706.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20707.  with "unsubscribe usr-tc" in the body of the message.
  20708.  For information on digests or retrieving files and old messages send
  20709.  "help" to the same address.  Do not use quotes in your message.
  20710.  
  20711.  
  20712.  
  20713. -
  20714.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20715.  with "unsubscribe usr-tc" in the body of the message.
  20716.  For information on digests or retrieving files and old messages send
  20717.  "help" to the same address.  Do not use quotes in your message.
  20718.  
  20719.  
  20720. -
  20721.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20722.  with "unsubscribe usr-tc" in the body of the message.
  20723.  For information on digests or retrieving files and old messages send
  20724.  "help" to the same address.  Do not use quotes in your message.
  20725.  
  20726.  
  20727. -
  20728.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20729.  with "unsubscribe usr-tc" in the body of the message.
  20730.  For information on digests or retrieving files and old messages send
  20731.  "help" to the same address.  Do not use quotes in your message.
  20732.  
  20733.  
  20734. -------------------------------------------------------------------------------
  20735.  
  20736. From: "Scot Desort" <scot@njaccess.net>
  20737. Subject: RE: (usr-tc) Radius Effects...
  20738. Date: 17 Oct 1999 20:23:51 -0400
  20739.  
  20740. I'm going to try dropping the attributes and see what happens. Not thrilled
  20741. about it, but let's see if that fixes it...
  20742.  
  20743. -----Original Message-----
  20744. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  20745. dciresi@defunct.ae.usr.com
  20746. Sent: Friday, October 15, 1999 12:54 PM
  20747.  
  20748.  
  20749. Scot,
  20750.  
  20751. Sounds like the Bay (or the Bay technician) is broken.  However, the
  20752. workaround you've sugested, should work fine.  Simply define the default
  20753. user's IP address and routing protocol (=none) on the ARC.  This template
  20754. will be applied to the user in place of attributes not actually sent.
  20755.  
  20756. There is a way to prescribe different attributes for different NAS-Types,
  20757. but it may require some RADIUS hacking.  And most likely, this will
  20758. require changes on the proxy server, as well.  The best bet would be to
  20759. correct the Bay NAS.
  20760.  
  20761. Dominic
  20762.  
  20763. On Wed, 13 Oct 1999, Scot Desort wrote:
  20764.  
  20765. > While we're all talking about Radius, we currently send the following
  20766. > attributes to our TC for our default user:
  20767. >
  20768. > Framed-IPAddress = 255.255.255.254
  20769. > Framed-Routing = None
  20770. >
  20771. > We recently signed up with Ziplink for wholesale nationwide dialup. A lot
  20772. of
  20773. > their equipment is Bay. They claim that when the Bay receives these
  20774. > attributes, it chokes. It allows the connection, and the modem connect
  20775. speed
  20776. > is fine, but throughput is horrible. Over 50% of the packets drop, and
  20777. after
  20778. > a few minutes, the call will drop. They say we need to remove these
  20779. > attributes from the Radius profile we send. Huh? Bay doesn't like these 2
  20780. > *basic* attributes? They also said they don't like 'Port-limit=1', but I
  20781. am
  20782. > NOT removing that one. For this one, they state that they have trouble
  20783. with
  20784. > the Bay doing 128K ISDN anyway, so removing the attribute will have no
  20785. > effect. Double "huh?"
  20786. >
  20787. > My question is, what effect will this have on our local dialup customers
  20788. > connecting to our TC? Will the TC happily work without receiving those 2
  20789. > attributes? We are currently not running RIP on the TC (we are small, so
  20790. > everything is static) - but we plan on enabling RIPv2 shortly. Will the TC
  20791. > start sending RIP updates to the dialup clients without the
  20792. > Framed-Routing=none attribute set?
  20793. >
  20794. > They also have some Max's out there, but a good portion of it's Bay. I
  20795. don't
  20796. > know of any way to have my Radius server send a different profile to their
  20797. > proxy, so it has to be the same one I send to my TC.
  20798. >
  20799. > Sorry for what might seem a stupid question - not real up to speed on RIP
  20800. > and exactly what the framed-routing attribute does.
  20801. >
  20802. > -Scot
  20803. > NJAccess
  20804. >
  20805. >
  20806. >
  20807. > -
  20808. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20809. >  with "unsubscribe usr-tc" in the body of the message.
  20810. >  For information on digests or retrieving files and old messages send
  20811. >  "help" to the same address.  Do not use quotes in your message.
  20812. >
  20813.  
  20814.  
  20815. -
  20816.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20817.  with "unsubscribe usr-tc" in the body of the message.
  20818.  For information on digests or retrieving files and old messages send
  20819.  "help" to the same address.  Do not use quotes in your message.
  20820.  
  20821.  
  20822. -
  20823.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20824.  with "unsubscribe usr-tc" in the body of the message.
  20825.  For information on digests or retrieving files and old messages send
  20826.  "help" to the same address.  Do not use quotes in your message.
  20827.  
  20828.  
  20829. -------------------------------------------------------------------------------
  20830.  
  20831. From: "Scot Desort" <scot@njaccess.net>
  20832. Subject: RE: (usr-tc) Radius Effects...
  20833. Date: 17 Oct 1999 20:27:39 -0400
  20834.  
  20835. I have no idea what hardware and software rev's they are on, but there is
  20836. definitely something wrong when I connect, and when I described the problem
  20837. to their "Unix Administrator" they knew exactly what was wrong and told me
  20838. to drop the attributes.
  20839.  
  20840. I could not *believe* how bad the connection was. Packets dropping
  20841. everywhere, traces timing out, it was a nightmare, and definitely made me
  20842. wonder if I made the right decision signing up with them.
  20843.  
  20844. -Scot
  20845.  
  20846.  
  20847. -----Original Message-----
  20848. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marius Strom
  20849. Sent: Friday, October 15, 1999 1:00 PM
  20850.  
  20851.  
  20852. Umm, let's see, we've also got some Bay 5399's running R16.0 software on
  20853. ROM Revision 1115..  We're sending port-limit=1 to all customers, no
  20854. problems.  We've got 128K ISDN connecting, no problems.
  20855.  
  20856. Can't speak from the Framed-Routing deal, but we are delegating static
  20857. IP's with Framed-IP-Address and blocks with Framed-IP-Route.
  20858.  
  20859. Runs like a champ -- I usually forget how to use it because I never have
  20860. to log into the box. =]
  20861.  
  20862. --
  20863. Marius Strom <marius@alpha1.net>
  20864. Professional Geek/Unix System Administrator
  20865. Alpha1 Internet <http://www.alpha1.net>
  20866. http://www.marius.org/marius.pgp 0x5645C228
  20867.  
  20868. In theory, there is no difference between theory and practice...
  20869. ...In practice, there is a big difference.
  20870.  
  20871.  
  20872. > On Wed, 13 Oct 1999, Scot Desort wrote:
  20873. >
  20874. > > While we're all talking about Radius, we currently send the following
  20875. > > attributes to our TC for our default user:
  20876. > >
  20877. > > Framed-IPAddress = 255.255.255.254
  20878. > > Framed-Routing = None
  20879. > >
  20880. > > We recently signed up with Ziplink for wholesale nationwide dialup. A
  20881. lot of
  20882. > > their equipment is Bay. They claim that when the Bay receives these
  20883. > > attributes, it chokes. It allows the connection, and the modem connect
  20884. speed
  20885. > > is fine, but throughput is horrible. Over 50% of the packets drop, and
  20886. after
  20887. > > a few minutes, the call will drop. They say we need to remove these
  20888. > > attributes from the Radius profile we send. Huh? Bay doesn't like these
  20889. 2
  20890. > > *basic* attributes? They also said they don't like 'Port-limit=1', but I
  20891. am
  20892. > > NOT removing that one. For this one, they state that they have trouble
  20893. with
  20894. > > the Bay doing 128K ISDN anyway, so removing the attribute will have no
  20895. > > effect. Double "huh?"
  20896. > >
  20897. > > My question is, what effect will this have on our local dialup customers
  20898. > > connecting to our TC? Will the TC happily work without receiving those 2
  20899. > > attributes? We are currently not running RIP on the TC (we are small, so
  20900. > > everything is static) - but we plan on enabling RIPv2 shortly. Will the
  20901. TC
  20902. > > start sending RIP updates to the dialup clients without the
  20903. > > Framed-Routing=none attribute set?
  20904. > >
  20905. > > They also have some Max's out there, but a good portion of it's Bay. I
  20906. don't
  20907. > > know of any way to have my Radius server send a different profile to
  20908. their
  20909. > > proxy, so it has to be the same one I send to my TC.
  20910. > >
  20911. > > Sorry for what might seem a stupid question - not real up to speed on
  20912. RIP
  20913. > > and exactly what the framed-routing attribute does.
  20914. > >
  20915. > > -Scot
  20916. > > NJAccess
  20917. > >
  20918. > >
  20919. > >
  20920. > > -
  20921. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20922. > >  with "unsubscribe usr-tc" in the body of the message.
  20923. > >  For information on digests or retrieving files and old messages send
  20924. > >  "help" to the same address.  Do not use quotes in your message.
  20925. > >
  20926. >
  20927. >
  20928. > -
  20929. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20930. >  with "unsubscribe usr-tc" in the body of the message.
  20931. >  For information on digests or retrieving files and old messages send
  20932. >  "help" to the same address.  Do not use quotes in your message.
  20933. >
  20934.  
  20935.  
  20936. -
  20937.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20938.  with "unsubscribe usr-tc" in the body of the message.
  20939.  For information on digests or retrieving files and old messages send
  20940.  "help" to the same address.  Do not use quotes in your message.
  20941.  
  20942.  
  20943. -
  20944.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20945.  with "unsubscribe usr-tc" in the body of the message.
  20946.  For information on digests or retrieving files and old messages send
  20947.  "help" to the same address.  Do not use quotes in your message.
  20948.  
  20949.  
  20950. -------------------------------------------------------------------------------
  20951.  
  20952. From: "Jason A. Nunnelley" <interests@linkfast.net>
  20953. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  20954. Date: 17 Oct 1999 19:26:02 -0700
  20955.  
  20956. It would seem that admitting this (on 3COM's part) would be financially
  20957. impossible. There would be an outcry for replacement cards, especially those
  20958. who are under support and guaranteed contracts. You do have a good point.
  20959. Mine have never had the hanging issues at all. However, I have seen the lost
  20960. connection issues. I am personally concerned about that. I also do not
  20961. upgrade my code until I see how it effects everyone else first. My rule is:
  20962. I can keep them with OK services. I can't with experimenting with services
  20963. that don't work at all. BTW, my actual connected users get OK service from
  20964. the 3COM chasis. However, I do know about the support failures. Coming from
  20965. LT, with ausome support, I am missing them already. Fortunite for me, LT
  20966. owns my support contract through my retailer.
  20967.  
  20968. Jason
  20969.  
  20970. -----Original Message-----
  20971. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scot Desort
  20972. Sent: Sunday, October 17, 1999 5:14 PM
  20973.  
  20974.  
  20975. I have only been a 3COM customer for a few months, and I do not regret my
  20976. decision, YET. Many on this list have been jilted by 3COM for a long time.
  20977. It will take a lot to win these folks back. I was previously using a
  20978. Microcom modem platform, and my end user connect issues have virtually been
  20979. eliminated. But I am small, and new to 3COM, so my voice has little weight
  20980. on this subject. And I cannot compare 3COM to Ascend or LT NAS's.
  20981.  
  20982. I was thinking -- while the DSP and Hiper code controls almost all of the
  20983. cards' functions, is it possible that the physical hardware on the DSP cards
  20984. is playing a role in these problems? My cards are all less than 3 months
  20985. old, and I've NEVER experienced the modem-pair hanging problem that plagues
  20986. many here. I also have very, very few connect issues. Could it be the
  20987. HARDWARE revisions on the DSP cards are also effecting performance and
  20988. stability?
  20989.  
  20990. Just a thought...
  20991.  
  20992. -Scot
  20993.  
  20994.  
  20995. -----Original Message-----
  20996. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
  20997. Sent: Sunday, October 17, 1999 4:26 PM
  20998.  
  20999.  
  21000. I hear a lot of complaints about 3COM on this list. Is the general idea that
  21001. 3COM should not be used? I used PM3s, with a lot of connection issues, but
  21002. little management headaches. I have considered CISCO (even tried one out),
  21003. but have heard the nightmare stories about connection issues. Is there a
  21004. feeling that the Ascend is better? Hmmm. Why don't I dump my 3COM and go
  21005. back to LT. I got excellent support there. I have never even been able to
  21006. get 3COM to give me the TC Software, and I paid for the support contract.
  21007. They tell me I have to prove I have a support contract every time I call. Do
  21008. they just SUCK? That is the feeling I am getting from this list. Is that
  21009. what you guys mean to say: "Run from 3COM, they SUCK!"
  21010.  
  21011. Jason
  21012.  
  21013. -----Original Message-----
  21014. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
  21015. Sent: Saturday, October 16, 1999 4:46 PM
  21016.  
  21017.  
  21018. Again yes there is a problem with V90 on 3com. Ascend units will do V90 with
  21019. a client 3com modem in cases where 3com TC won't... this is DEFINITELY a
  21020. problem that has been addressed but not resolved. You would think this would
  21021. concern 3com more than it does... just like all the complaints about support
  21022. on this list.
  21023.  
  21024. Oh well when everyone is switching to a different platform they may care but
  21025. it will be too late.
  21026.  
  21027.  
  21028. Ed
  21029.  
  21030. ----- Original Message -----
  21031. Sent: Saturday, October 16, 1999 6:11 PM
  21032.  
  21033.  
  21034. Same here.  That's pretty much exactly how we feel about it.  However
  21035. we occationally find a user with a good sportster/3com modem who can't
  21036. get v.90 on our TCS but can on our TNT (eval) and more importantly,
  21037. can with our competitors.  Users won't stay with 28.8 when they can
  21038. get 48k elsewhere..  If there were no modem code issues, I'd be more
  21039. than happy to send the eval back.  Instead, I'll probably get an invoice...
  21040.  
  21041. Well back when we started, we bought a superstack and it worked of course
  21042. but when I found out it was half-duplex on all 10T ports, we sent it back
  21043. and opted for a catalyst..  But nowadays I'm sure things are different.
  21044. We outgrew the catalyst and now have a fastiron and we love it..
  21045.  
  21046. I realize that switches don't call for much support, but we did have
  21047. some issues with the catalyst.  Ciscos support as amazing and they
  21048. even called back again just to make sure we were happy.  3com on the
  21049. otherhand wanted to charge us for support on a 1 day old switch!
  21050. I just wanted to double check to see that their was no fdx on
  21051. the ports before sending it back.  They could have cared less whether
  21052. I returned it or not..  So I did!
  21053.  
  21054. Allen
  21055.  
  21056.  
  21057. -
  21058.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21059.  with "unsubscribe usr-tc" in the body of the message.
  21060.  For information on digests or retrieving files and old messages send
  21061.  "help" to the same address.  Do not use quotes in your message.
  21062.  
  21063.  
  21064.  
  21065. -
  21066.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21067.  with "unsubscribe usr-tc" in the body of the message.
  21068.  For information on digests or retrieving files and old messages send
  21069.  "help" to the same address.  Do not use quotes in your message.
  21070.  
  21071.  
  21072. -
  21073.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21074.  with "unsubscribe usr-tc" in the body of the message.
  21075.  For information on digests or retrieving files and old messages send
  21076.  "help" to the same address.  Do not use quotes in your message.
  21077.  
  21078.  
  21079. -
  21080.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21081.  with "unsubscribe usr-tc" in the body of the message.
  21082.  For information on digests or retrieving files and old messages send
  21083.  "help" to the same address.  Do not use quotes in your message.
  21084.  
  21085.  
  21086. -
  21087.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21088.  with "unsubscribe usr-tc" in the body of the message.
  21089.  For information on digests or retrieving files and old messages send
  21090.  "help" to the same address.  Do not use quotes in your message.
  21091.  
  21092.  
  21093. -------------------------------------------------------------------------------
  21094.  
  21095. From: Luke Gain <luke@erinet.com>
  21096. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  21097. Date: 17 Oct 1999 20:57:25 -0400 (EDT)
  21098.  
  21099. I also suspect that the hanging modem issue is related to hardware.
  21100.  
  21101. recently I have been watching this very closly. Every time a dsp hangs
  21102. it is the same ones. SRO the dsps and the replacement ones do not exhibit
  21103. the problem. I don't think it is revision related as I have had failures on
  21104. both .49 and .53
  21105.  
  21106. Anyone else see this, or is it just a concidence? (My sample size is fairly
  21107. small ~200 DSP with 5 that exhibited the modem hanging problem)
  21108.  
  21109. Along these lines, what do people use to stress-test/burn in their chassis
  21110. before they deploy them?
  21111.  
  21112. -Luke
  21113.  
  21114. > I was thinking -- while the DSP and Hiper code controls almost all of the
  21115. > cards' functions, is it possible that the physical hardware on the DSP cards
  21116. > is playing a role in these problems? My cards are all less than 3 months
  21117. > old, and I've NEVER experienced the modem-pair hanging problem that plagues
  21118. > many here. I also have very, very few connect issues. Could it be the
  21119. > HARDWARE revisions on the DSP cards are also effecting performance and
  21120. > stability?
  21121. > 
  21122. > Just a thought...
  21123. > 
  21124. > -Scot
  21125. > 
  21126. > 
  21127.  
  21128. -
  21129.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21130.  with "unsubscribe usr-tc" in the body of the message.
  21131.  For information on digests or retrieving files and old messages send
  21132.  "help" to the same address.  Do not use quotes in your message.
  21133.  
  21134.  
  21135. -------------------------------------------------------------------------------
  21136.  
  21137. From: "Scot Desort" <scot@njaccess.net>
  21138. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  21139. Date: 17 Oct 1999 21:21:08 -0400
  21140.  
  21141. Again, since I am small, and new to TC, I can't give any statistically
  21142. relevant data regarding connect issues, but so far, the only significant
  21143. issues I have with client modems are (in order)
  21144. 1. HCF
  21145. 2. Old Lucent Winmodems (pre 5.x code)
  21146.  
  21147. Sportster & WinSportster work like champs. I go out of my way to ask
  21148. Sportster customers what their connect rates are, and providing they are on
  21149. the latest code, v90 is established almost 100% of the time and at rates of
  21150. 45K or better. But this is only representative of those who I've come across
  21151. in our database where we know exactly what modem they are using, and I've
  21152. taken the time to call them. But they are geographically dispersed
  21153. throughout our service area.
  21154.  
  21155. This may not hold true over time as we expand, but for now, I cannot say
  21156. that we have a connect rate issue that is troubling me in any way. Something
  21157. deep down inside tells me it's more of a hardware revision problem, than DSP
  21158. code revision problems. If you read many of the posts from users who are
  21159. having these problems widepsread, most of them have been with USR/3COM for
  21160. many years. I venture to guess that many of their cards have been in service
  21161. for some time now, thus the older hardware revisions. I may be completely
  21162. off here, but even if I'm not, there very well be no way for 3COM to
  21163. financially or legally solve the problem, other than sitting back and
  21164. waiting for all of the older cards to be phased out of service to be
  21165. replaced with the new cards. By then, it may be too late.
  21166.  
  21167. -Scot
  21168.  
  21169.  
  21170. -----Original Message-----
  21171. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
  21172. Sent: Sunday, October 17, 1999 10:26 PM
  21173.  
  21174.  
  21175. It would seem that admitting this (on 3COM's part) would be financially
  21176. impossible. There would be an outcry for replacement cards, especially those
  21177. who are under support and guaranteed contracts. You do have a good point.
  21178. Mine have never had the hanging issues at all. However, I have seen the lost
  21179. connection issues. I am personally concerned about that. I also do not
  21180. upgrade my code until I see how it effects everyone else first. My rule is:
  21181. I can keep them with OK services. I can't with experimenting with services
  21182. that don't work at all. BTW, my actual connected users get OK service from
  21183. the 3COM chasis. However, I do know about the support failures. Coming from
  21184. LT, with ausome support, I am missing them already. Fortunite for me, LT
  21185. owns my support contract through my retailer.
  21186.  
  21187. Jason
  21188.  
  21189.  
  21190.  
  21191. -
  21192.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21193.  with "unsubscribe usr-tc" in the body of the message.
  21194.  For information on digests or retrieving files and old messages send
  21195.  "help" to the same address.  Do not use quotes in your message.
  21196.  
  21197.  
  21198. -------------------------------------------------------------------------------
  21199.  
  21200. From: Aaron Nabil <nabil@spiritone.com>
  21201. Subject: Re: (usr-tc) 3com V90 Problems
  21202. Date: 17 Oct 1999 18:23:13 -0700 (PDT)
  21203.  
  21204. Scot Desort writes...
  21205. >Aaron-
  21206. >
  21207. >Since you own both, and seem to be in the upper percentile of technically
  21208. >savy telecom people on this list, have YOU personally been able to gather
  21209. >any significant data showing that the Ascend offers a greater percentage of
  21210. >your customers a "better" connection than on the Hiper?
  21211.  
  21212. Unfortunatly in our network we have a number of problems that prevent
  21213. us from comparing the two with any statistical rigor.  First is the lack 
  21214. of (or I don't know how to get at them) the same connection quality indicators
  21215. on the Maxes that we have on the USR's (block error rate, retrains, etc).  Second
  21216. is that our Maxes are on phone numbers that we have allowed our customers
  21217. to self-select in using.  Most are probably Macs, people with rockwell
  21218. modems, and we've our CLEC has has some inter-office trunking issues
  21219. that cause people to use the Maxes (they are still on the ILEC).
  21220.  
  21221. We do have some maxes on our CLEC, it might be fun sometime to set up
  21222. a peecee to continuously make test calls to the USR's and Maxes, record 
  21223. the results (by dumping the modem registers) and compare the two.  I wonder if 
  21224. anyone has a program to do this?
  21225.  
  21226. >(By better, it may even mean a "subjective" quality of the connection, where
  21227. >the connect speed to both NAS's is the same, but the connection throughput
  21228. >is better, or just "seems and feels" faster to the end user)
  21229.  
  21230. The few tests we've made have the 3com's handily beating the Ascends in
  21231. throughput (FTP of a random-data file) for the same current connection 
  21232. rate.  But for some reason the 3com's have some problems in MPP performance
  21233. that makes the Ascends faster, the last time we tested (at least 6 months
  21234. ago).
  21235.  
  21236.  
  21237. -- 
  21238. Aaron Nabil
  21239.  
  21240. -
  21241.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21242.  with "unsubscribe usr-tc" in the body of the message.
  21243.  For information on digests or retrieving files and old messages send
  21244.  "help" to the same address.  Do not use quotes in your message.
  21245.  
  21246.  
  21247. -------------------------------------------------------------------------------
  21248.  
  21249. From: "Kent Tambling" <Kent@acceleration.net>
  21250. Subject: (usr-tc) Eicon Diva TA to DSP
  21251. Date: 17 Oct 1999 21:26:29 -0400
  21252.  
  21253. I know this was raised once before with no answer, but does
  21254. anyone know of any problems/solution using this adapter?
  21255.  
  21256. One client gets maximum 3KB/s download (on both channels)
  21257. and it inevitably hangs (stops moving data) after 1 to 20 minutes.
  21258.  
  21259. BellSouth recommends these and I think it may be because they
  21260. have success with then and the rest of us may not(USR crowd)
  21261.  
  21262. Thanks,
  21263.  
  21264. Kent Tambling
  21265. kent@acceleration.net
  21266. System Administrator
  21267. www.acceleration.net
  21268.  
  21269.  
  21270.  
  21271.  
  21272. -
  21273.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21274.  with "unsubscribe usr-tc" in the body of the message.
  21275.  For information on digests or retrieving files and old messages send
  21276.  "help" to the same address.  Do not use quotes in your message.
  21277.  
  21278.  
  21279. -------------------------------------------------------------------------------
  21280.  
  21281. From: "Ed" <ed@taylors.com>
  21282. Subject: Re: (usr-tc) 3com V90 Problems
  21283. Date: 17 Oct 1999 22:00:45 -0400
  21284.  
  21285. We also own both and have definitely seen more frequent V90 connects using
  21286. Ascend. This was not always the case... however now it definitely is.
  21287.  
  21288. As stated again and again 3com has acknowledged the fact that Ascend's
  21289. connect in cases where the 3com TC will not. There is an open issue on it
  21290. and they had attempted to resolve it however it seems they have put on a
  21291. back burner because it's not an easy fix. One high level Tech on this sort
  21292. of situation is not going to resolve it and it seems this is what they want
  21293. to commit since a ton of Customers aren't complaining. The reason people
  21294. aren't complaining is because most ISP's do not have both Ascend and 3com to
  21295. compare back to back... if more did I am sure they would be scared.
  21296.  
  21297.  
  21298. Ed
  21299.  
  21300. ----- Original Message -----
  21301. Sent: Sunday, October 17, 1999 8:06 PM
  21302.  
  21303.  
  21304. Aaron-
  21305.  
  21306. Since you own both, and seem to be in the upper percentile of technically
  21307. savy telecom people on this list, have YOU personally been able to gather
  21308. any significant data showing that the Ascend offers a greater percentage of
  21309. your customers a "better" connection than on the Hiper?
  21310.  
  21311. (By better, it may even mean a "subjective" quality of the connection, where
  21312. the connect speed to both NAS's is the same, but the connection throughput
  21313. is better, or just "seems and feels" faster to the end user)
  21314.  
  21315. -Scot
  21316.  
  21317.  
  21318.  
  21319. -----Original Message-----
  21320. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  21321. Sent: Sunday, October 17, 1999 3:59 PM
  21322.  
  21323.  
  21324.  
  21325. I have _own_ both Max's and Hiperdsps.
  21326.  
  21327. > . . .
  21328.  
  21329.  
  21330.  
  21331. -
  21332.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21333.  with "unsubscribe usr-tc" in the body of the message.
  21334.  For information on digests or retrieving files and old messages send
  21335.  "help" to the same address.  Do not use quotes in your message.
  21336.  
  21337.  
  21338.  
  21339. -
  21340.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21341.  with "unsubscribe usr-tc" in the body of the message.
  21342.  For information on digests or retrieving files and old messages send
  21343.  "help" to the same address.  Do not use quotes in your message.
  21344.  
  21345.  
  21346. -------------------------------------------------------------------------------
  21347.  
  21348. From: Brian <signal@shreve.net>
  21349. Subject: Re: (usr-tc) 3com V90 Problems
  21350. Date: 17 Oct 1999 21:03:09 -0500 (CDT)
  21351.  
  21352.  
  21353.  
  21354. On Sun, 17 Oct 1999, Lon R. Stockton, Jr. wrote:
  21355.  
  21356. > 
  21357. > On Sun, 17 Oct 1999, Brian wrote:
  21358. > 
  21359. > > What I am getting at, is raw data and numbers are the best, rather than
  21360. > > the more subjective data of customers opinions about their connections.
  21361. > 
  21362. <much deleted>
  21363.  
  21364. They have those java applets on the web where you can hit a submit and it
  21365. tests the speed of your connection (thruput), but even those are flawed:
  21366.  
  21367. 1. caches can play tricks with these things
  21368. 2. it tests your connectivity into wherever the file is being downloaded
  21369. more than testing your modems thruput.
  21370.  
  21371. Brian
  21372.  
  21373.  
  21374. > 
  21375. > But as your message said, it's hard to trust customer appraisals of your
  21376. > speeds. If you want to know the scoop, get a 3rd party who a) knows what
  21377. > they're doing, and b) has no interest in the outcome to run tests and
  21378. > report back.
  21379. > 
  21380. > PS. No probs here with 3com client modem connections that I can tell.
  21381. > But then again, I don't have any Ascends to compare to. This is with
  21382. > the following:
  21383. > 
  21384. >    HARC:  h/w ver. 1.0.0   s/w ver. 4.0.30
  21385. >    HDSP:  h/w ver. 0.49.0  s/w ver. 1.2.5
  21386. > 
  21387. > 
  21388. > 
  21389. > -
  21390. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21391. >  with "unsubscribe usr-tc" in the body of the message.
  21392. >  For information on digests or retrieving files and old messages send
  21393. >  "help" to the same address.  Do not use quotes in your message.
  21394. > 
  21395.  
  21396. Brian Feeny (BF304)     signal@shreve.net   
  21397. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21398. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21399.  
  21400.  
  21401. -
  21402.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21403.  with "unsubscribe usr-tc" in the body of the message.
  21404.  For information on digests or retrieving files and old messages send
  21405.  "help" to the same address.  Do not use quotes in your message.
  21406.  
  21407.  
  21408. -------------------------------------------------------------------------------
  21409.  
  21410. From: Brian <signal@shreve.net>
  21411. Subject: RE: (usr-tc) 3com V90 Problems
  21412. Date: 17 Oct 1999 21:06:35 -0500 (CDT)
  21413.  
  21414. On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
  21415.  
  21416. > What you can count on is Churn. If customers leave you - you can see the
  21417. > difference. I have lost fewer customers with connection issues with 3COM
  21418. > than Livingston (with the PM3 that is). I have never had a connection issue
  21419. > with the PM2e30 (analog). It is 100%!
  21420. > 
  21421. > So, what should I use when my 3COM contract runs out? Any sugestions? I
  21422. > guess everyone considers 3COM a loser when it comes to support. Yet, the
  21423. > largest ISPs use it. Why? M$pring, MCI, etc.
  21424.  
  21425. In its heyday, one could say the AOL(ans), mindspring, earthlink(?) used
  21426. TC's........but companies do switch sometimes, and alot now run Ascend
  21427. gear.  worldcom i know is ascend, and I believe AOL is moving in more
  21428. ascend.  AOL always had ascend to do their kflex stuff.
  21429.  
  21430. But this is a good point, who are the large guys and what are they using
  21431. today?  Can anyone help fill in the chart?
  21432.  
  21433. AOL            3com/ascend (percentages?)
  21434. splitrock(prodigy)    Bay
  21435. Worldcom(uunet)        Ascend
  21436. Mindspring        3com
  21437. Cybergate        3com
  21438.  
  21439.  
  21440. anyone know abou the other big players?
  21441.  
  21442.  
  21443. > 
  21444. > Why?
  21445. > 
  21446. > -----Original Message-----
  21447. > From: owner-usr-tc@lists.xmission.com
  21448. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton,
  21449. > Jr.
  21450. > Sent: Sunday, October 17, 1999 3:52 PM
  21451. > To: usr-tc@lists.xmission.com
  21452. > Subject: Re: (usr-tc) 3com V90 Problems
  21453. > 
  21454. > 
  21455. > 
  21456. > On Sun, 17 Oct 1999, Brian wrote:
  21457. > 
  21458. > > What I am getting at, is raw data and numbers are the best, rather than
  21459. > > the more subjective data of customers opinions about their connections.
  21460. > 
  21461. > No doubt about that; I've seen the stuff you mentioned happening...one
  21462. > can't really read *too* much into customer complaints (or praises) except
  21463. > a feeling of customer satisfaction. But if a customer is unsatisfied for
  21464. > the wrong (or misunderstood) reasons, the question is where you want to
  21465. > stand on it.
  21466. > 
  21467. > For example...I had a 3rd party actively test us vs. our competition WRT
  21468. > dialup connect speeds/xfer rates. The downside is that they found that
  21469. > for most client-side modems, our initial connect speed was lower than
  21470. > the competition. Funny thing was, in many cases, the competition's higher
  21471. > initial speed would get retrained down....while ours either remained the
  21472. > same or retrained up.
  21473. > 
  21474. > The other huge point that was found was that we had faster overall xfer
  21475. > rates, even with our lower connect speeds. This point was pursued further,
  21476. > and it was found that a 33.6k connection thru us gave faster xfer rates
  21477. > than our competitors' 43-46k rates!  Rather interesting what a solid
  21478. > connection with no retransmits can do up against a shaky, albeit faster,
  21479. > connection with a bunch of retransmits.
  21480. > 
  21481. > The above results made me feel good, but there's still the question of
  21482. > what to do about it. The only thing the average customer sees is the
  21483. > initial connect speed, and in the majority of cases, it's quite useless
  21484. > to start telling them about retraining, retransmits, and how the real
  21485. > measure is xfer rate anyway. Most just think you're shooting them a load
  21486. > of bull, trying to swamp them with computer-talk to cover yourself.
  21487. > 
  21488. > Me, I give it a shot anyway...if they understand, great, if not, oh well,
  21489. > they're not really my target customer anyway. That may sound like the
  21490. > age-old 'sour grapes' attitude, but know that I'm not in biz to get the
  21491. > biggest part of the market...I'm here to skim the cream and garner the
  21492. > best customers. When you're targeting power-users and businesses, you
  21493. > wind up with people who understand more of the details.
  21494. > 
  21495. > But much harder if your target is the average joe, my guess would be to
  21496. > switch to whatever platform gave you the highest initial connect so that
  21497. > all the ones who guage everything by their initial speed will be happy.
  21498. > Or plunge into the murky deep and switch their connect speed reporting
  21499. > to the DTE rate so they can be amazed at your super 115k connects. (:
  21500. > 
  21501. > But as your message said, it's hard to trust customer appraisals of your
  21502. > speeds. If you want to know the scoop, get a 3rd party who a) knows what
  21503. > they're doing, and b) has no interest in the outcome to run tests and
  21504. > report back.
  21505. > 
  21506. > PS. No probs here with 3com client modem connections that I can tell.
  21507. > But then again, I don't have any Ascends to compare to. This is with
  21508. > the following:
  21509. > 
  21510. >    HARC:  h/w ver. 1.0.0   s/w ver. 4.0.30
  21511. >    HDSP:  h/w ver. 0.49.0  s/w ver. 1.2.5
  21512. > 
  21513. > 
  21514. > 
  21515. > -
  21516. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21517. >  with "unsubscribe usr-tc" in the body of the message.
  21518. >  For information on digests or retrieving files and old messages send
  21519. >  "help" to the same address.  Do not use quotes in your message.
  21520. > 
  21521. > 
  21522. > -
  21523. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21524. >  with "unsubscribe usr-tc" in the body of the message.
  21525. >  For information on digests or retrieving files and old messages send
  21526. >  "help" to the same address.  Do not use quotes in your message.
  21527. > 
  21528.  
  21529. Brian Feeny (BF304)     signal@shreve.net   
  21530. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21531. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21532.  
  21533.  
  21534. -
  21535.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21536.  with "unsubscribe usr-tc" in the body of the message.
  21537.  For information on digests or retrieving files and old messages send
  21538.  "help" to the same address.  Do not use quotes in your message.
  21539.  
  21540.  
  21541. -------------------------------------------------------------------------------
  21542.  
  21543. From: Brian <signal@shreve.net>
  21544. Subject: RE: (usr-tc) 3com V90 Problems
  21545. Date: 17 Oct 1999 21:09:31 -0500 (CDT)
  21546.  
  21547.  
  21548. Yes I would be very interested in Aaron's comments on Ascend vs. 3com, he
  21549. is very telco savvy and it would seem that if their was a problem, he
  21550. probably would have seen it.
  21551.  
  21552.  
  21553. On Sun, 17 Oct 1999, Scot Desort wrote:
  21554.  
  21555. > Aaron-
  21556. > 
  21557. > Since you own both, and seem to be in the upper percentile of technically
  21558. > savy telecom people on this list, have YOU personally been able to gather
  21559. > any significant data showing that the Ascend offers a greater percentage of
  21560. > your customers a "better" connection than on the Hiper?
  21561. > 
  21562. > (By better, it may even mean a "subjective" quality of the connection, where
  21563. > the connect speed to both NAS's is the same, but the connection throughput
  21564. > is better, or just "seems and feels" faster to the end user)
  21565. > 
  21566. > -Scot
  21567. > 
  21568. > 
  21569. > 
  21570. > -----Original Message-----
  21571. > From: owner-usr-tc@lists.xmission.com
  21572. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  21573. > Sent: Sunday, October 17, 1999 3:59 PM
  21574. > To: usr-tc@lists.xmission.com
  21575. > Subject: Re: (usr-tc) 3com V90 Problems
  21576. > 
  21577. > 
  21578. > 
  21579. > I have _own_ both Max's and Hiperdsps.
  21580. > 
  21581. > > . . .
  21582. > 
  21583. > 
  21584. > 
  21585. > -
  21586. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21587. >  with "unsubscribe usr-tc" in the body of the message.
  21588. >  For information on digests or retrieving files and old messages send
  21589. >  "help" to the same address.  Do not use quotes in your message.
  21590. > 
  21591.  
  21592. Brian Feeny (BF304)     signal@shreve.net   
  21593. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21594. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21595.  
  21596.  
  21597. -
  21598.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21599.  with "unsubscribe usr-tc" in the body of the message.
  21600.  For information on digests or retrieving files and old messages send
  21601.  "help" to the same address.  Do not use quotes in your message.
  21602.  
  21603.  
  21604. -------------------------------------------------------------------------------
  21605.  
  21606. From: "Jason A. Nunnelley" <interests@linkfast.net>
  21607. Subject: RE: (usr-tc) 3com V90 Problems
  21608. Date: 17 Oct 1999 21:09:18 -0700
  21609.  
  21610. So, if I understand you correctly: Your experience says Ascend is just a
  21611. better web browsing customer Access Server. And, you can't really get a good
  21612. data spread due to the local line issues being a tad different. I wonder,
  21613. why would the PPP be slower on the 3COM?
  21614.  
  21615. Any ideas 3COM guys?
  21616.  
  21617. Jason
  21618.  
  21619. -----Original Message-----
  21620. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  21621. Sent: Sunday, October 17, 1999 6:23 PM
  21622.  
  21623.  
  21624. Scot Desort writes...
  21625. >Aaron-
  21626. >
  21627. >Since you own both, and seem to be in the upper percentile of technically
  21628. >savy telecom people on this list, have YOU personally been able to gather
  21629. >any significant data showing that the Ascend offers a greater percentage of
  21630. >your customers a "better" connection than on the Hiper?
  21631.  
  21632. Unfortunatly in our network we have a number of problems that prevent
  21633. us from comparing the two with any statistical rigor.  First is the lack
  21634. of (or I don't know how to get at them) the same connection quality
  21635. indicators
  21636. on the Maxes that we have on the USR's (block error rate, retrains, etc).
  21637. Second
  21638. is that our Maxes are on phone numbers that we have allowed our customers
  21639. to self-select in using.  Most are probably Macs, people with rockwell
  21640. modems, and we've our CLEC has has some inter-office trunking issues
  21641. that cause people to use the Maxes (they are still on the ILEC).
  21642.  
  21643. We do have some maxes on our CLEC, it might be fun sometime to set up
  21644. a peecee to continuously make test calls to the USR's and Maxes, record
  21645. the results (by dumping the modem registers) and compare the two.  I wonder
  21646. if
  21647. anyone has a program to do this?
  21648.  
  21649. >(By better, it may even mean a "subjective" quality of the connection,
  21650. where
  21651. >the connect speed to both NAS's is the same, but the connection throughput
  21652. >is better, or just "seems and feels" faster to the end user)
  21653.  
  21654. The few tests we've made have the 3com's handily beating the Ascends in
  21655. throughput (FTP of a random-data file) for the same current connection
  21656. rate.  But for some reason the 3com's have some problems in MPP performance
  21657. that makes the Ascends faster, the last time we tested (at least 6 months
  21658. ago).
  21659.  
  21660.  
  21661. --
  21662. Aaron Nabil
  21663.  
  21664. -
  21665.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21666.  with "unsubscribe usr-tc" in the body of the message.
  21667.  For information on digests or retrieving files and old messages send
  21668.  "help" to the same address.  Do not use quotes in your message.
  21669.  
  21670.  
  21671. -
  21672.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21673.  with "unsubscribe usr-tc" in the body of the message.
  21674.  For information on digests or retrieving files and old messages send
  21675.  "help" to the same address.  Do not use quotes in your message.
  21676.  
  21677.  
  21678. -------------------------------------------------------------------------------
  21679.  
  21680. From: "Jason A. Nunnelley" <interests@linkfast.net>
  21681. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  21682. Date: 17 Oct 1999 21:12:57 -0700
  21683.  
  21684. I too have had the same experience with the 3COM. I am disatisfied with the
  21685. company's attitude toward customers. It seems to have an "avoid them or bill
  21686. them" philosophy. I did not buy the 3COM for the support, although it is
  21687. important. LT has the best support because they have their goals set right.
  21688. They want everyone using a LT Product to get good support. They are not
  21689. concerned about contracts, etc. You would think the price we pay for support
  21690. would give us incredible support. I have yet to even get the latest codes
  21691. directly from 3COM for the hassle I have to go through. I had an LT Support
  21692. guy help me with mine. But, the 3COM seems to be a better box than the PM3.
  21693. And, I have not personally tried the ASCEND products for Access Servers,
  21694. only routers. I know that pre-LT involvement, ASCEND was harder to get
  21695. support from than 3COM. So, I was never excited about looking that way.
  21696. Maybe I should try them out for a month.
  21697.  
  21698. Jason
  21699.  
  21700. -----Original Message-----
  21701. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scot Desort
  21702. Sent: Sunday, October 17, 1999 6:21 PM
  21703.  
  21704.  
  21705. Again, since I am small, and new to TC, I can't give any statistically
  21706. relevant data regarding connect issues, but so far, the only significant
  21707. issues I have with client modems are (in order)
  21708. 1. HCF
  21709. 2. Old Lucent Winmodems (pre 5.x code)
  21710.  
  21711. Sportster & WinSportster work like champs. I go out of my way to ask
  21712. Sportster customers what their connect rates are, and providing they are on
  21713. the latest code, v90 is established almost 100% of the time and at rates of
  21714. 45K or better. But this is only representative of those who I've come across
  21715. in our database where we know exactly what modem they are using, and I've
  21716. taken the time to call them. But they are geographically dispersed
  21717. throughout our service area.
  21718.  
  21719. This may not hold true over time as we expand, but for now, I cannot say
  21720. that we have a connect rate issue that is troubling me in any way. Something
  21721. deep down inside tells me it's more of a hardware revision problem, than DSP
  21722. code revision problems. If you read many of the posts from users who are
  21723. having these problems widepsread, most of them have been with USR/3COM for
  21724. many years. I venture to guess that many of their cards have been in service
  21725. for some time now, thus the older hardware revisions. I may be completely
  21726. off here, but even if I'm not, there very well be no way for 3COM to
  21727. financially or legally solve the problem, other than sitting back and
  21728. waiting for all of the older cards to be phased out of service to be
  21729. replaced with the new cards. By then, it may be too late.
  21730.  
  21731. -Scot
  21732.  
  21733.  
  21734. -----Original Message-----
  21735. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason A. Nunnelley
  21736. Sent: Sunday, October 17, 1999 10:26 PM
  21737.  
  21738.  
  21739. It would seem that admitting this (on 3COM's part) would be financially
  21740. impossible. There would be an outcry for replacement cards, especially those
  21741. who are under support and guaranteed contracts. You do have a good point.
  21742. Mine have never had the hanging issues at all. However, I have seen the lost
  21743. connection issues. I am personally concerned about that. I also do not
  21744. upgrade my code until I see how it effects everyone else first. My rule is:
  21745. I can keep them with OK services. I can't with experimenting with services
  21746. that don't work at all. BTW, my actual connected users get OK service from
  21747. the 3COM chasis. However, I do know about the support failures. Coming from
  21748. LT, with ausome support, I am missing them already. Fortunite for me, LT
  21749. owns my support contract through my retailer.
  21750.  
  21751. Jason
  21752.  
  21753.  
  21754.  
  21755. -
  21756.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21757.  with "unsubscribe usr-tc" in the body of the message.
  21758.  For information on digests or retrieving files and old messages send
  21759.  "help" to the same address.  Do not use quotes in your message.
  21760.  
  21761.  
  21762. -
  21763.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21764.  with "unsubscribe usr-tc" in the body of the message.
  21765.  For information on digests or retrieving files and old messages send
  21766.  "help" to the same address.  Do not use quotes in your message.
  21767.  
  21768.  
  21769. -------------------------------------------------------------------------------
  21770.  
  21771. From: "Scot Desort" <scot@njaccess.net>
  21772. Subject: RE: (usr-tc) 3com V90 Problems
  21773. Date: 17 Oct 1999 22:19:20 -0400
  21774.  
  21775. This table is from 808hi.com. Don't know how up-to-date it is, but here it
  21776. is anyway:
  21777.  
  21778.  
  21779. 24-Seven Access Numbers V.90, K56Flex **
  21780. AltaVista Free Access+ V.90, K56Flex Bay Networks
  21781. America On-Line V.90, K56Flex Ascend
  21782. AT&T Worldnet Access Numbers V.90 3Com
  21783. BellSouth.net V.90 Cisco
  21784. Cable & Wireless   **
  21785. Compuserve very limited 56k availability   **
  21786. Concentric Access Numbers V.90, K56Flex Bay Networks
  21787. CWIA Access Numbers V.90, K56Flex **
  21788. Dotnow.com+ V.90,K56Flex Bay Networks
  21789. Earthlink Access Numbers V.90, K56Flex Ascend
  21790. Erol's Access Numbers V.90, K56Flex **
  21791. FreeI.net V.90 **
  21792. GridNet (WorldCom) V.90, x2 3Com
  21793. GTE Internet Access Numbers V.90, K56Flex Ascend
  21794. IBM Global Network Access Numbers V.90, x2 3Com
  21795. MCI WorldCom V.90
  21796. Microsoft MSN V.90, K56Flex Ascend
  21797. Mindspring Access Numbers V.90, x2 3Com
  21798. Netcom Access Numbers V.90 **
  21799. Netzero V.90, K56Flex **
  21800. NTR.net Access Numbers V.90 **
  21801. Pacific Bell Internet K56Flex **
  21802. Prodigy Internet+ V.90, x2 Bay Networks
  21803. Sprynet Access Numbers V.90 **
  21804. Toast.net Access Numbers V.90 **
  21805. UUNet Access Numbers V.90, K56Flex Ascend
  21806.  
  21807. + - AltaVista Free Access and Dotnow allow you to set up a free access
  21808. account; Along with Prodigy, the same access #s, provided by Splitrock are
  21809. used. Users may experience busies, network bottlenecks/failures, and
  21810. interoperability problems with any of these services.
  21811. * - Not all providers have 56k access on all numbers
  21812. ** - Not known; If you know, please let me know!
  21813.  
  21814. -Scot
  21815.  
  21816. -----Original Message-----
  21817. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
  21818. Sent: Sunday, October 17, 1999 10:07 PM
  21819.  
  21820.  
  21821.  
  21822. In its heyday, one could say the AOL(ans), mindspring, earthlink(?) used
  21823. TC's........but companies do switch sometimes, and alot now run Ascend
  21824. gear.  worldcom i know is ascend, and I believe AOL is moving in more
  21825. ascend.  AOL always had ascend to do their kflex stuff.
  21826.  
  21827. But this is a good point, who are the large guys and what are they using
  21828. today?  Can anyone help fill in the chart?
  21829.  
  21830. AOL            3com/ascend (percentages?)
  21831. splitrock(prodigy)    Bay
  21832. Worldcom(uunet)        Ascend
  21833. Mindspring        3com
  21834. Cybergate        3com
  21835.  
  21836.  
  21837. anyone know abou the other big players?
  21838.  
  21839.  
  21840.  
  21841.  
  21842. -
  21843.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21844.  with "unsubscribe usr-tc" in the body of the message.
  21845.  For information on digests or retrieving files and old messages send
  21846.  "help" to the same address.  Do not use quotes in your message.
  21847.  
  21848.  
  21849. -------------------------------------------------------------------------------
  21850.  
  21851. From: Ronald Kushner <ron@glis.net>
  21852. Subject: Re: (usr-tc) 3com V90 Problems
  21853. Date: 17 Oct 1999 22:44:44 -0400
  21854.  
  21855. Brian wrote:
  21856.  
  21857. > In its heyday, one could say the AOL(ans), mindspring, earthlink(?) used
  21858. > TC's........but companies do switch sometimes, and alot now run Ascend
  21859. > gear.  worldcom i know is ascend, and I believe AOL is moving in more
  21860. > ascend.  AOL always had ascend to do their kflex stuff.
  21861. > 
  21862. > But this is a good point, who are the large guys and what are they using
  21863. > today?  Can anyone help fill in the chart?
  21864. > 
  21865. > AOL                     3com/ascend (percentages?)
  21866. > splitrock(prodigy)      Bay
  21867. > Worldcom(uunet)         Ascend
  21868. > Mindspring              3com
  21869. > Cybergate               3com
  21870. > 
  21871. > anyone know abou the other big players?
  21872.  
  21873. AT&T (former IBM Global Network) uses 3Com and is migrating their entire
  21874. Worldnet dialup to 3Com from what I have been told by AT&T. AT&T said they
  21875. did extensive research after buying the IBM Global Network and determined
  21876. that the 3Com NAS was superior on first time connections and overall
  21877. throughput.
  21878.  
  21879. Voyager switched from Cisco AS5248's to TC chassis (old Quads and new
  21880. HiPers) in their Detroit POP since their IPO.
  21881.  
  21882. Concentric uses Bay 5399, but Nortel is a major stockholder.
  21883.  
  21884. Ziplink uses the Bay 5399, and again Nortel is a major stockholder.
  21885.  
  21886. AOL no longer runs their network - they use WorldCom managed modem ports
  21887. which run on Lucent Max TNT.
  21888.  
  21889. Level3 uses Lucent Max TNT for their managed modem pools.
  21890.  
  21891. FlashNet uses Lucent Max.
  21892.  
  21893. Ameritech.net used to use 3Com, haven't seen one of their pops in a long
  21894. time.
  21895.  
  21896. MegaPop uses Lucent Max.
  21897.  
  21898.  
  21899. BTW: The Bay is the worse NAS on the market, IMHO. If you want to talk about
  21900. connection problems, buy a 5399.
  21901.  
  21902. -Ron
  21903. GLISnet, Inc.
  21904. +1 810/939.9885
  21905.  
  21906. -
  21907.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21908.  with "unsubscribe usr-tc" in the body of the message.
  21909.  For information on digests or retrieving files and old messages send
  21910.  "help" to the same address.  Do not use quotes in your message.
  21911.  
  21912.  
  21913. -------------------------------------------------------------------------------
  21914.  
  21915. From: Aaron Nabil <nabil@spiritone.com>
  21916. Subject: Re: (usr-tc) 3com V90 Problems
  21917. Date: 17 Oct 1999 19:55:51 -0700 (PDT)
  21918.  
  21919. Jason A. Nunnelley writes...
  21920. >So, if I understand you correctly: Your experience says Ascend is just a
  21921. >better web browsing customer Access Server.
  21922.  
  21923. I didn't say that.
  21924.  
  21925. >And, you can't really get a good
  21926. >data spread due to the local line issues being a tad different.
  21927.  
  21928. I said that I couldn't draw statically valid conclusions because I
  21929. couldn't get useful data on connection quality from the Ascends, that
  21930. our customers had already self-selected between Ascends and 3coms
  21931. based on their own subjective interpretations of which one "worked
  21932. better", and that they were on different LECs.
  21933.  
  21934. As for the local lines being a "tad" different, they are much, 
  21935. much more than a "tad" different.
  21936.  
  21937. >I wonder, why would the PPP be slower on the 3COM?
  21938.  
  21939. Is PPP slower on your 3com chassis?  PPP is faster on my 3com than 
  21940. my maxen.
  21941.  
  21942. >
  21943. >Any ideas 3COM guys?
  21944. >
  21945. >Jason
  21946. >
  21947. >-----Original Message-----
  21948. >From: owner-usr-tc@lists.xmission.com
  21949. >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  21950. >Sent: Sunday, October 17, 1999 6:23 PM
  21951. >To: usr-tc@lists.xmission.com
  21952. >Subject: Re: (usr-tc) 3com V90 Problems
  21953. >
  21954. >
  21955. >Scot Desort writes...
  21956. >>Aaron-
  21957. >>
  21958. >>Since you own both, and seem to be in the upper percentile of technically
  21959. >>savy telecom people on this list, have YOU personally been able to gather
  21960. >>any significant data showing that the Ascend offers a greater percentage of
  21961. >>your customers a "better" connection than on the Hiper?
  21962. >
  21963. >Unfortunatly in our network we have a number of problems that prevent
  21964. >us from comparing the two with any statistical rigor.  First is the lack
  21965. >of (or I don't know how to get at them) the same connection quality
  21966. >indicators
  21967. >on the Maxes that we have on the USR's (block error rate, retrains, etc).
  21968. >Second
  21969. >is that our Maxes are on phone numbers that we have allowed our customers
  21970. >to self-select in using.  Most are probably Macs, people with rockwell
  21971. >modems, and we've our CLEC has has some inter-office trunking issues
  21972. >that cause people to use the Maxes (they are still on the ILEC).
  21973. >
  21974. >We do have some maxes on our CLEC, it might be fun sometime to set up
  21975. >a peecee to continuously make test calls to the USR's and Maxes, record
  21976. >the results (by dumping the modem registers) and compare the two.  I wonder
  21977. >if
  21978. >anyone has a program to do this?
  21979. >
  21980. >>(By better, it may even mean a "subjective" quality of the connection,
  21981. >where
  21982. >>the connect speed to both NAS's is the same, but the connection throughput
  21983. >>is better, or just "seems and feels" faster to the end user)
  21984. >
  21985. >The few tests we've made have the 3com's handily beating the Ascends in
  21986. >throughput (FTP of a random-data file) for the same current connection
  21987. >rate.  But for some reason the 3com's have some problems in MPP performance
  21988. >that makes the Ascends faster, the last time we tested (at least 6 months
  21989. >ago).
  21990. >
  21991.  
  21992.  
  21993. -- 
  21994. Aaron Nabil
  21995.  
  21996. -
  21997.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21998.  with "unsubscribe usr-tc" in the body of the message.
  21999.  For information on digests or retrieving files and old messages send
  22000.  "help" to the same address.  Do not use quotes in your message.
  22001.  
  22002.  
  22003. -------------------------------------------------------------------------------
  22004.  
  22005. From: <vanhalen@coredcs.com>
  22006. Subject: (usr-tc) How far are we from...
  22007. Date: 17 Oct 1999 22:03:38 -0500 (CDT)
  22008.  
  22009. Hello-
  22010. A while back I posted a message(and have seen other posts) in regards to
  22011. getting bytes transferred & sent per session via the command line
  22012. interface on a hiperarc/hiperdsp based box.  At that time the code for
  22013. that feature was in an engineering release(?).  I'm curious if that code
  22014. has been released and I missed it(which could very easily happen) or if
  22015. that is forthcoming and roughly when it would be available?
  22016.  
  22017. Thanks!
  22018.  
  22019.  
  22020. -
  22021.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22022.  with "unsubscribe usr-tc" in the body of the message.
  22023.  For information on digests or retrieving files and old messages send
  22024.  "help" to the same address.  Do not use quotes in your message.
  22025.  
  22026.  
  22027. -------------------------------------------------------------------------------
  22028.  
  22029. From: "Jason A. Nunnelley" <interests@linkfast.net>
  22030. Subject: RE: (usr-tc) 3com V90 Problems
  22031. Date: 17 Oct 1999 22:07:48 -0700
  22032.  
  22033. OK, this means: "I can't tell anything useful as a comparison between the 2,
  22034. due to the conditions of my use." I understand that now. I thought you were
  22035. saying there were documented or data-supported PPP diferences between the 2.
  22036.  
  22037. -----Original Message-----
  22038. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  22039. Sent: Sunday, October 17, 1999 7:56 PM
  22040.  
  22041.  
  22042. Jason A. Nunnelley writes...
  22043. >So, if I understand you correctly: Your experience says Ascend is just a
  22044. >better web browsing customer Access Server.
  22045.  
  22046. I didn't say that.
  22047.  
  22048. >And, you can't really get a good
  22049. >data spread due to the local line issues being a tad different.
  22050.  
  22051. I said that I couldn't draw statically valid conclusions because I
  22052. couldn't get useful data on connection quality from the Ascends, that
  22053. our customers had already self-selected between Ascends and 3coms
  22054. based on their own subjective interpretations of which one "worked
  22055. better", and that they were on different LECs.
  22056.  
  22057. As for the local lines being a "tad" different, they are much,
  22058. much more than a "tad" different.
  22059.  
  22060. >I wonder, why would the PPP be slower on the 3COM?
  22061.  
  22062. Is PPP slower on your 3com chassis?  PPP is faster on my 3com than
  22063. my maxen.
  22064.  
  22065. >
  22066. >Any ideas 3COM guys?
  22067. >
  22068. >Jason
  22069. >
  22070. >-----Original Message-----
  22071. >From: owner-usr-tc@lists.xmission.com
  22072. >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  22073. >Sent: Sunday, October 17, 1999 6:23 PM
  22074. >To: usr-tc@lists.xmission.com
  22075. >Subject: Re: (usr-tc) 3com V90 Problems
  22076. >
  22077. >
  22078. >Scot Desort writes...
  22079. >>Aaron-
  22080. >>
  22081. >>Since you own both, and seem to be in the upper percentile of technically
  22082. >>savy telecom people on this list, have YOU personally been able to gather
  22083. >>any significant data showing that the Ascend offers a greater percentage
  22084. of
  22085. >>your customers a "better" connection than on the Hiper?
  22086. >
  22087. >Unfortunatly in our network we have a number of problems that prevent
  22088. >us from comparing the two with any statistical rigor.  First is the lack
  22089. >of (or I don't know how to get at them) the same connection quality
  22090. >indicators
  22091. >on the Maxes that we have on the USR's (block error rate, retrains, etc).
  22092. >Second
  22093. >is that our Maxes are on phone numbers that we have allowed our customers
  22094. >to self-select in using.  Most are probably Macs, people with rockwell
  22095. >modems, and we've our CLEC has has some inter-office trunking issues
  22096. >that cause people to use the Maxes (they are still on the ILEC).
  22097. >
  22098. >We do have some maxes on our CLEC, it might be fun sometime to set up
  22099. >a peecee to continuously make test calls to the USR's and Maxes, record
  22100. >the results (by dumping the modem registers) and compare the two.  I wonder
  22101. >if
  22102. >anyone has a program to do this?
  22103. >
  22104. >>(By better, it may even mean a "subjective" quality of the connection,
  22105. >where
  22106. >>the connect speed to both NAS's is the same, but the connection throughput
  22107. >>is better, or just "seems and feels" faster to the end user)
  22108. >
  22109. >The few tests we've made have the 3com's handily beating the Ascends in
  22110. >throughput (FTP of a random-data file) for the same current connection
  22111. >rate.  But for some reason the 3com's have some problems in MPP performance
  22112. >that makes the Ascends faster, the last time we tested (at least 6 months
  22113. >ago).
  22114. >
  22115.  
  22116.  
  22117. --
  22118. Aaron Nabil
  22119.  
  22120. -
  22121.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22122.  with "unsubscribe usr-tc" in the body of the message.
  22123.  For information on digests or retrieving files and old messages send
  22124.  "help" to the same address.  Do not use quotes in your message.
  22125.  
  22126.  
  22127. -
  22128.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22129.  with "unsubscribe usr-tc" in the body of the message.
  22130.  For information on digests or retrieving files and old messages send
  22131.  "help" to the same address.  Do not use quotes in your message.
  22132.  
  22133.  
  22134. -------------------------------------------------------------------------------
  22135.  
  22136. From: K Mitchell <mitch@keyconn.net>
  22137. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  22138. Date: 17 Oct 1999 23:16:07 -0400
  22139.  
  22140. At 08:13 PM 10/17/99 -0400, Scot Desort wrote:
  22141. >I was thinking -- while the DSP and Hiper code controls almost all of the
  22142. >cards' functions, is it possible that the physical hardware on the DSP cards
  22143. >is playing a role in these problems? My cards are all less than 3 months
  22144. >old, and I've NEVER experienced the modem-pair hanging problem that plagues
  22145. >many here. I also have very, very few connect issues. Could it be the
  22146. >HARDWARE revisions on the DSP cards are also effecting performance and
  22147. >stability?
  22148.  
  22149. That's a possibility I would have liked to investigate, but wasn't able to.
  22150. The last card I got was a newer hardware version than my others, however it
  22151. was DOA. The replacement I got was the same hardware version as my others.
  22152.  
  22153.  
  22154. -- 
  22155. Kirk Mitchell-General Manager        mitch@keyconn.net
  22156. Keystone Connect                     Unlock Your World
  22157. Altoona, PA   814-941-5000      http://www.keyconn.net
  22158.  
  22159.  
  22160. -
  22161.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22162.  with "unsubscribe usr-tc" in the body of the message.
  22163.  For information on digests or retrieving files and old messages send
  22164.  "help" to the same address.  Do not use quotes in your message.
  22165.  
  22166.  
  22167. -------------------------------------------------------------------------------
  22168.  
  22169. From: Aaron Nabil <nabil@spiritone.com>
  22170. Subject: Re: (usr-tc) 3com V90 Problems
  22171. Date: 17 Oct 1999 20:27:56 -0700 (PDT)
  22172.  
  22173. Jason A. Nunnelley writes...
  22174. >OK, this means: "I can't tell anything useful as a comparison between the 2,
  22175. >due to the conditions of my use." I understand that now.
  22176.  
  22177. I didn't say that either.  Why the desire to put words in my 
  22178. mouth?  Everyone here can read what I wrote directly, they don't need
  22179. it paraphrased.
  22180.  
  22181. The question was if I had "...significant data showing that the Ascend 
  22182. offers a greater percentage of your customers a "better" connection 
  22183. than on the Hiper?", to which I was trying to explain why I neither had
  22184. nor could I collect such data with any degree of confidence.
  22185.  
  22186. >I thought you were saying there were documented or data-supported PPP 
  22187. >diferences between the 2.
  22188.  
  22189. When I measured PPP performance, the 3com's were faster.  When I 
  22190. measured MPP performance, the 3com were slower.  
  22191.  
  22192.  
  22193. >
  22194. >-----Original Message-----
  22195. >From: owner-usr-tc@lists.xmission.com
  22196. >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  22197. >Sent: Sunday, October 17, 1999 7:56 PM
  22198. >To: usr-tc@lists.xmission.com
  22199. >Subject: Re: (usr-tc) 3com V90 Problems
  22200. >
  22201. >
  22202. >Jason A. Nunnelley writes...
  22203. >>So, if I understand you correctly: Your experience says Ascend is just a
  22204. >>better web browsing customer Access Server.
  22205. >
  22206. >I didn't say that.
  22207. >
  22208. >>And, you can't really get a good
  22209. >>data spread due to the local line issues being a tad different.
  22210. >
  22211. >I said that I couldn't draw statically valid conclusions because I
  22212. >couldn't get useful data on connection quality from the Ascends, that
  22213. >our customers had already self-selected between Ascends and 3coms
  22214. >based on their own subjective interpretations of which one "worked
  22215. >better", and that they were on different LECs.
  22216. >
  22217. >As for the local lines being a "tad" different, they are much,
  22218. >much more than a "tad" different.
  22219. >
  22220. >>I wonder, why would the PPP be slower on the 3COM?
  22221. >
  22222. >Is PPP slower on your 3com chassis?  PPP is faster on my 3com than
  22223. >my maxen.
  22224. >
  22225. >>
  22226. >>Any ideas 3COM guys?
  22227. >>
  22228. >>Jason
  22229. >>
  22230. >>-----Original Message-----
  22231. >>From: owner-usr-tc@lists.xmission.com
  22232. >>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil
  22233. >>Sent: Sunday, October 17, 1999 6:23 PM
  22234. >>To: usr-tc@lists.xmission.com
  22235. >>Subject: Re: (usr-tc) 3com V90 Problems
  22236. >>
  22237. >>
  22238. >>Scot Desort writes...
  22239. >>>Aaron-
  22240. >>>
  22241. >>>Since you own both, and seem to be in the upper percentile of technically
  22242. >>>savy telecom people on this list, have YOU personally been able to gather
  22243. >>>any significant data showing that the Ascend offers a greater percentage
  22244. >of
  22245. >>>your customers a "better" connection than on the Hiper?
  22246. >>
  22247. >>Unfortunatly in our network we have a number of problems that prevent
  22248. >>us from comparing the two with any statistical rigor.  First is the lack
  22249. >>of (or I don't know how to get at them) the same connection quality
  22250. >>indicators
  22251. >>on the Maxes that we have on the USR's (block error rate, retrains, etc).
  22252. >>Second
  22253. >>is that our Maxes are on phone numbers that we have allowed our customers
  22254. >>to self-select in using.  Most are probably Macs, people with rockwell
  22255. >>modems, and we've our CLEC has has some inter-office trunking issues
  22256. >>that cause people to use the Maxes (they are still on the ILEC).
  22257. >>
  22258. >>We do have some maxes on our CLEC, it might be fun sometime to set up
  22259. >>a peecee to continuously make test calls to the USR's and Maxes, record
  22260. >>the results (by dumping the modem registers) and compare the two.  I wonder
  22261. >>if
  22262. >>anyone has a program to do this?
  22263. >>
  22264. >>>(By better, it may even mean a "subjective" quality of the connection,
  22265. >>where
  22266. >>>the connect speed to both NAS's is the same, but the connection throughput
  22267. >>>is better, or just "seems and feels" faster to the end user)
  22268. >>
  22269. >>The few tests we've made have the 3com's handily beating the Ascends in
  22270. >>throughput (FTP of a random-data file) for the same current connection
  22271. >>rate.  But for some reason the 3com's have some problems in MPP performance
  22272. >>that makes the Ascends faster, the last time we tested (at least 6 months
  22273. >>ago).
  22274. >>
  22275. >
  22276. >
  22277. >--
  22278. >Aaron Nabil
  22279. >
  22280. >-
  22281. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22282. > with "unsubscribe usr-tc" in the body of the message.
  22283. > For information on digests or retrieving files and old messages send
  22284. > "help" to the same address.  Do not use quotes in your message.
  22285. >
  22286. >
  22287. >-
  22288. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22289. > with "unsubscribe usr-tc" in the body of the message.
  22290. > For information on digests or retrieving files and old messages send
  22291. > "help" to the same address.  Do not use quotes in your message.
  22292. >
  22293.  
  22294.  
  22295. -- 
  22296. Aaron Nabil
  22297.  
  22298. -
  22299.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22300.  with "unsubscribe usr-tc" in the body of the message.
  22301.  For information on digests or retrieving files and old messages send
  22302.  "help" to the same address.  Do not use quotes in your message.
  22303.  
  22304.  
  22305. -------------------------------------------------------------------------------
  22306.  
  22307. From: K Mitchell <mitch@keyconn.net>
  22308. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  22309. Date: 17 Oct 1999 23:33:56 -0400
  22310.  
  22311. At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  22312. >It would seem that admitting this (on 3COM's part) would be financially
  22313. >impossible.
  22314.  
  22315. Far cheaper than loosing a bunch of customers, I'd bet. Actually, were they
  22316. to announce that early DSPs were bad and ship out free replacements, they'd
  22317. likely sell enough product to new customers to cover the replacement costs.
  22318. A move like that could lock in tons of business from companies that like
  22319. 3Com equipment, but are hesitant to buy because of their support reputation.
  22320.  
  22321.  
  22322. -- 
  22323. Kirk Mitchell-General Manager        mitch@keyconn.net
  22324. Keystone Connect                     Unlock Your World
  22325. Altoona, PA   814-941-5000      http://www.keyconn.net
  22326.  
  22327.  
  22328. -
  22329.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22330.  with "unsubscribe usr-tc" in the body of the message.
  22331.  For information on digests or retrieving files and old messages send
  22332.  "help" to the same address.  Do not use quotes in your message.
  22333.  
  22334.  
  22335. -------------------------------------------------------------------------------
  22336.  
  22337. From: "Sheldon Koehler" <sheldon@tenforward.com>
  22338. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  22339. Date: 17 Oct 1999 20:40:39 -0700
  22340.  
  22341. I have not had the hanging modems with my cards yet, and I hope I don't.
  22342. Since 3Com loves to screw with numbers, what is the newer DSP hardware
  22343. version? 0.53.0 or 0.49.0?
  22344.  
  22345. ----- Original Message -----
  22346. Sent: Sunday, October 17, 1999 8:16 PM
  22347.  
  22348.  
  22349. > At 08:13 PM 10/17/99 -0400, Scot Desort wrote:
  22350. > >I was thinking -- while the DSP and Hiper code controls almost all of the
  22351. > >cards' functions, is it possible that the physical hardware on the DSP
  22352. cards
  22353. > >is playing a role in these problems? My cards are all less than 3 months
  22354. > >old, and I've NEVER experienced the modem-pair hanging problem that
  22355. plagues
  22356. > >many here. I also have very, very few connect issues. Could it be the
  22357. > >HARDWARE revisions on the DSP cards are also effecting performance and
  22358. > >stability?
  22359. >
  22360. > That's a possibility I would have liked to investigate, but wasn't able
  22361. to.
  22362. > The last card I got was a newer hardware version than my others, however
  22363. it
  22364. > was DOA. The replacement I got was the same hardware version as my others.
  22365. >
  22366. >
  22367. > --
  22368. > Kirk Mitchell-General Manager        mitch@keyconn.net
  22369. > Keystone Connect                     Unlock Your World
  22370. > Altoona, PA   814-941-5000      http://www.keyconn.net
  22371. >
  22372. >
  22373. > -
  22374. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22375. >  with "unsubscribe usr-tc" in the body of the message.
  22376. >  For information on digests or retrieving files and old messages send
  22377. >  "help" to the same address.  Do not use quotes in your message.
  22378. >
  22379.  
  22380.  
  22381. -
  22382.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22383.  with "unsubscribe usr-tc" in the body of the message.
  22384.  For information on digests or retrieving files and old messages send
  22385.  "help" to the same address.  Do not use quotes in your message.
  22386.  
  22387.  
  22388. -------------------------------------------------------------------------------
  22389.  
  22390. From: K Mitchell <mitch@keyconn.net>
  22391. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  22392. Date: 17 Oct 1999 23:54:21 -0400
  22393.  
  22394. At 08:40 PM 10/17/99 -0700, you wrote:
  22395. >I have not had the hanging modems with my cards yet, and I hope I don't.
  22396. >Since 3Com loves to screw with numbers, what is the newer DSP hardware
  22397. >version? 0.53.0 or 0.49.0?
  22398.  
  22399. 0.53.0 is newer, they don't appear to have the "number backwards if
  22400. released on a Tuesday, Wednesday, or before noon Friday" fetish that the
  22401. software guys do  :)
  22402.  
  22403.  
  22404. -- 
  22405. Kirk Mitchell-General Manager        mitch@keyconn.net
  22406. Keystone Connect                     Unlock Your World
  22407. Altoona, PA   814-941-5000      http://www.keyconn.net
  22408.  
  22409.  
  22410. -
  22411.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22412.  with "unsubscribe usr-tc" in the body of the message.
  22413.  For information on digests or retrieving files and old messages send
  22414.  "help" to the same address.  Do not use quotes in your message.
  22415.  
  22416.  
  22417. -------------------------------------------------------------------------------
  22418.  
  22419. From: Richard Lorbieski <richard@alpha1.net>
  22420. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  22421. Date: 17 Oct 1999 23:48:21 -0500
  22422.  
  22423. We had the "hanging" modem problem last year. If a modem hung, the last
  22424. caller was a MAC user. I , and I mean "I" worked around the problem by
  22425. switching from PRI to CT1 and kept 2 of the PRIs for ISDN. I rarely get
  22426. a hung modem.
  22427.  
  22428. Anyway that was about 3 PM3's, 1 Bay 5399 with 3 blades ago, PM25 and  a
  22429. PM2e30 ago.
  22430.  
  22431. I still have a 3Com in operation with 6 DSP cards, but we will replace
  22432. it in January. 
  22433.  
  22434. Sheldon Koehler wrote:
  22435. > 
  22436. > I have not had the hanging modems with my cards yet, and I hope I don't.
  22437. > Since 3Com loves to screw with numbers, what is the newer DSP hardware
  22438. > version? 0.53.0 or 0.49.0?
  22439. > 
  22440. > ----- Original Message -----
  22441. > From: K Mitchell <mitch@keyconn.net>
  22442. > To: <usr-tc@lists.xmission.com>
  22443. > Sent: Sunday, October 17, 1999 8:16 PM
  22444. > Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  22445. > 
  22446. > > At 08:13 PM 10/17/99 -0400, Scot Desort wrote:
  22447. > > >I was thinking -- while the DSP and Hiper code controls almost all of the
  22448. > > >cards' functions, is it possible that the physical hardware on the DSP
  22449. > cards
  22450. > > >is playing a role in these problems? My cards are all less than 3 months
  22451. > > >old, and I've NEVER experienced the modem-pair hanging problem that
  22452. > plagues
  22453. > > >many here. I also have very, very few connect issues. Could it be the
  22454. > > >HARDWARE revisions on the DSP cards are also effecting performance and
  22455. > > >stability?
  22456. > >
  22457. > > That's a possibility I would have liked to investigate, but wasn't able
  22458. > to.
  22459. > > The last card I got was a newer hardware version than my others, however
  22460. > it
  22461. > > was DOA. The replacement I got was the same hardware version as my others.
  22462. > >
  22463. > >
  22464. > > --
  22465. > > Kirk Mitchell-General Manager        mitch@keyconn.net
  22466. > > Keystone Connect                     Unlock Your World
  22467. > > Altoona, PA   814-941-5000      http://www.keyconn.net
  22468. > >
  22469. > >
  22470. > > -
  22471. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22472. > >  with "unsubscribe usr-tc" in the body of the message.
  22473. > >  For information on digests or retrieving files and old messages send
  22474. > >  "help" to the same address.  Do not use quotes in your message.
  22475. > >
  22476. > 
  22477. > -
  22478. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22479. >  with "unsubscribe usr-tc" in the body of the message.
  22480. >  For information on digests or retrieving files and old messages send
  22481. >  "help" to the same address.  Do not use quotes in your message.
  22482.  
  22483. -
  22484.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22485.  with "unsubscribe usr-tc" in the body of the message.
  22486.  For information on digests or retrieving files and old messages send
  22487.  "help" to the same address.  Do not use quotes in your message.
  22488.  
  22489.  
  22490. -------------------------------------------------------------------------------
  22491.  
  22492. From: Ken Kirchner <kenk@shreve.net>
  22493. Subject: (usr-tc) Ascend vs. 3Com
  22494. Date: 18 Oct 1999 00:34:24 -0500 (CDT)
  22495.  
  22496.  
  22497. Well here is an illustration from a users e-mail to me:
  22498.  
  22499. "Ken, been connecting very nicely lately with that new number.  I've been
  22500. connecting at 38.8 and 40.0!  :-)  Problem is when I play Quake I get the
  22501. "phone jack" quite often, much more often than when I use the other 
  22502. number. I can browse the net and download files much better, but it is
  22503. pretty useless with Quake.  What do you reckon the problem could be?"
  22504.  
  22505. Now for some of the pertinant details:
  22506.  
  22507.     This customer has a USR 3Com modem.
  22508.     He used to dial into our TC gear ("other number").
  22509.     He is now dialing into our Max TNT ("new number").
  22510.     The best he ever got with TC was 28.8K.
  22511.  
  22512. Infer from this what you will.  I have details such as our HDM/ARC
  22513. revisons as well as his FLASH/DSP dates/revisions if anyone cares.
  22514. I am working with other cases (The v.90 X-files) who have similar
  22515. experiences and will let you know if there's a pattern.  Tedious work, no
  22516. wonder no one else has done it. :-P
  22517.  
  22518. -----
  22519.                         .~.
  22520.   Ken Kirchner          /V\       L   I   N   U   X
  22521.   Asst SysAdmin        // \  > Don't fear the penguin <
  22522.   ShreveNet, Inc.     /(   )\
  22523.                        ^^-^^
  22524.  
  22525.  
  22526. -
  22527.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22528.  with "unsubscribe usr-tc" in the body of the message.
  22529.  For information on digests or retrieving files and old messages send
  22530.  "help" to the same address.  Do not use quotes in your message.
  22531.  
  22532.  
  22533. -------------------------------------------------------------------------------
  22534.  
  22535. From: "Ed" <ed@taylors.com>
  22536. Subject: Re: (usr-tc) Ascend vs. 3Com
  22537. Date: 18 Oct 1999 01:54:21 -0400
  22538.  
  22539. Yes have seen it ourselves over and over.
  22540.  
  22541. BTW, reason he is having the problem with Quake probably has to do with MTU
  22542. settings on the Ascend... or he has incorrect error control and thus his
  22543. packets are resending. (correct me someone if I am incorrect)
  22544.  
  22545. Ed
  22546.  
  22547. ----- Original Message -----
  22548. Sent: Monday, October 18, 1999 1:34 AM
  22549.  
  22550.  
  22551.  
  22552. Well here is an illustration from a users e-mail to me:
  22553.  
  22554. "Ken, been connecting very nicely lately with that new number.  I've been
  22555. connecting at 38.8 and 40.0!  :-)  Problem is when I play Quake I get the
  22556. "phone jack" quite often, much more often than when I use the other
  22557. number. I can browse the net and download files much better, but it is
  22558. pretty useless with Quake.  What do you reckon the problem could be?"
  22559.  
  22560. Now for some of the pertinant details:
  22561.  
  22562. This customer has a USR 3Com modem.
  22563. He used to dial into our TC gear ("other number").
  22564. He is now dialing into our Max TNT ("new number").
  22565. The best he ever got with TC was 28.8K.
  22566.  
  22567. Infer from this what you will.  I have details such as our HDM/ARC
  22568. revisons as well as his FLASH/DSP dates/revisions if anyone cares.
  22569. I am working with other cases (The v.90 X-files) who have similar
  22570. experiences and will let you know if there's a pattern.  Tedious work, no
  22571. wonder no one else has done it. :-P
  22572.  
  22573. -----
  22574.                         .~.
  22575.   Ken Kirchner          /V\       L   I   N   U   X
  22576.   Asst SysAdmin        // \  > Don't fear the penguin <
  22577.   ShreveNet, Inc.     /(   )\
  22578.                        ^^-^^
  22579.  
  22580.  
  22581. -
  22582.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22583.  with "unsubscribe usr-tc" in the body of the message.
  22584.  For information on digests or retrieving files and old messages send
  22585.  "help" to the same address.  Do not use quotes in your message.
  22586.  
  22587.  
  22588.  
  22589. -
  22590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22591.  with "unsubscribe usr-tc" in the body of the message.
  22592.  For information on digests or retrieving files and old messages send
  22593.  "help" to the same address.  Do not use quotes in your message.
  22594.  
  22595.  
  22596. -------------------------------------------------------------------------------
  22597.  
  22598. From: Jeff Mcadams <jeffm@iglou.com>
  22599. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  22600. Date: 18 Oct 1999 09:06:44 -0400
  22601.  
  22602. Thus spake Jason A. Nunnelley
  22603. >It would seem that admitting this (on 3COM's part) would be financially
  22604. >impossible. There would be an outcry for replacement cards, especially those
  22605. >who are under support and guaranteed contracts. 
  22606.  
  22607. In MegaZone's absence, I'll point out that Livingston did exactly
  22608. this...actually...they went one step farther.  Livingston had been
  22609. shipping modems saying they would be upgradeable to v.90 when v.90 was
  22610. designed.  They weren't.  Livingston replaced any and all of the old
  22611. modem cards free of charge with the new ones that were capable of v.90.
  22612.  
  22613. 3Com doesn't even, apparently, have the willingness (almost said "guts")
  22614. to replace cards when the *current* functionality is broken.  This is,
  22615. at least, borderline illegal.  As another example of this, harken back
  22616. to ye ol' days of NETServers and broken MPIP (many of you will remember
  22617. all of this) and 3Com, to this day, refuses to make this situation
  22618. right.
  22619.  
  22620. Again...I truly believe its beaurocracy getting in the way here.  The
  22621. people that are in the position to make the decision to "do the right
  22622. thing," are so *totally* insulated from the customers by layer upon
  22623. layer of beaurocracy, that they don't even *realize* how their decisions
  22624. for 3Com are royally screwing over their customer base...and may even be
  22625. illegal!
  22626. -- 
  22627. Jeff McAdams                            Email: jeffm@iglou.com
  22628. Head Network Administrator              Voice: (502) 966-3848
  22629. IgLou Internet Services                        (800) 436-4456
  22630.  
  22631. -
  22632.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22633.  with "unsubscribe usr-tc" in the body of the message.
  22634.  For information on digests or retrieving files and old messages send
  22635.  "help" to the same address.  Do not use quotes in your message.
  22636.  
  22637.  
  22638. -------------------------------------------------------------------------------
  22639.  
  22640. From: Jeff Mcadams <jeffm@iglou.com>
  22641. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  22642. Date: 18 Oct 1999 09:09:08 -0400
  22643.  
  22644. Thus spake K Mitchell
  22645. >At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  22646. >>It would seem that admitting this (on 3COM's part) would be
  22647. >>financially impossible.
  22648.  
  22649. >Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
  22650. >they to announce that early DSPs were bad and ship out free
  22651. >replacements, they'd likely sell enough product to new customers to
  22652. >cover the replacement costs.  A move like that could lock in tons of
  22653. >business from companies that like 3Com equipment, but are hesitant to
  22654. >buy because of their support reputation.
  22655.  
  22656. Agreed...3Com needs to do some *serious* work on their support
  22657. reputation.  While its never been good, and *some* issues with support
  22658. have been worked on (hold times for tech support are down, for sure) but
  22659. the quality of tech support is still pitiful, and the *overall* support
  22660. issues (and this isn't just restricted to tech support...its having to
  22661. do with 3Com's overall customer service attitudes) still really sucks
  22662. swamp water.
  22663. -- 
  22664. Jeff McAdams                            Email: jeffm@iglou.com
  22665. Head Network Administrator              Voice: (502) 966-3848
  22666. IgLou Internet Services                        (800) 436-4456
  22667.  
  22668. -
  22669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22670.  with "unsubscribe usr-tc" in the body of the message.
  22671.  For information on digests or retrieving files and old messages send
  22672.  "help" to the same address.  Do not use quotes in your message.
  22673.  
  22674.  
  22675. -------------------------------------------------------------------------------
  22676.  
  22677. From:  <farber@admin.f-tech.net>
  22678. Subject: Re: (usr-tc) Bad Modems...BIG Issues
  22679. Date: 18 Oct 1999 09:35:28 -0400 (EDT)
  22680.  
  22681. My experience is that modems will no pick up/hang in ANY code.  I just
  22682. went from 2.0.19 to 2.0.81 and a modem hung this weekend.  1125 calls
  22683. failed.
  22684.  
  22685. Looking at the release notes for 2.0.81 they did fix the software reset
  22686. issue (big plus) but you should expect to see a modem hang every now and
  22687. then.  Monitor the equipment (simple perl script) or have the NMC card
  22688. fire off a trap or syslog and look at that.
  22689.  
  22690.  
  22691.  
  22692. Paul Farber
  22693. Farber Technology
  22694. farber@admin.f-tech.net
  22695. Ph  570-628-5303
  22696. Fax 570-628-5545
  22697.  
  22698. On Sun, 17 Oct 1999, Ed wrote:
  22699.  
  22700. > Is everyone else having individual modem problems on the latest DSP code? We
  22701. > seem to have modems always causing problems and going out on us. We never
  22702. > had modems do this in the past and never even considered a Bad Modem Script
  22703. > to let us know modems were out or having problems. Now it is something we
  22704. > HAVE to have or we can't sleep at nights... constantly getting calls from
  22705. > customers letting us know there are fast busy signals, no tone, terrible
  22706. > speeds, or just cannot connect.
  22707. > 
  22708. > What is going on? Anyone know? Is this a bug in the latest code? Or better
  22709. > yet should 3com just scratch everything and give us all our money back?
  22710. > (getting thoroughly disgusted) BTW, we have been dealing in 3com TC's for
  22711. > almost 4 years so we are fairly aware if it is Telco, TC or a config
  22712. > issue.... it's definitely the TC code or Hardware. Any work arounds or
  22713. > solutions known?
  22714. > 
  22715. > Between the bad modems, the V90 issue and the support issues I don't see how
  22716. > anyone is happy with 3com right now... it's giving us one hell of a
  22717. > headache!
  22718. > 
  22719. > Ed
  22720. > 
  22721. > 
  22722. > 
  22723. > -
  22724. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22725. >  with "unsubscribe usr-tc" in the body of the message.
  22726. >  For information on digests or retrieving files and old messages send
  22727. >  "help" to the same address.  Do not use quotes in your message.
  22728. > 
  22729.  
  22730.  
  22731. -
  22732.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22733.  with "unsubscribe usr-tc" in the body of the message.
  22734.  For information on digests or retrieving files and old messages send
  22735.  "help" to the same address.  Do not use quotes in your message.
  22736.  
  22737.  
  22738. -------------------------------------------------------------------------------
  22739.  
  22740. From:  <farber@admin.f-tech.net>
  22741. Subject: Re: (usr-tc) 3com V90 Problems
  22742. Date: 18 Oct 1999 09:39:31 -0400 (EDT)
  22743.  
  22744. Customers don't care!  I have fixed many a problem by turning off v.90 in
  22745. off brand modems.  But try and explain your reasoning to joe blow and his
  22746. new computer.
  22747.  
  22748.  
  22749. Paul Farber
  22750. Farber Technology
  22751. farber@admin.f-tech.net
  22752. Ph  570-628-5303
  22753. Fax 570-628-5545
  22754.  
  22755. > If modem X connects at an unreliable V.90 speed to an Ascend, and 
  22756. > connects at a reliable v.34 rate to a 3com, that's a problem?
  22757. > 
  22758. > 
  22759. > -- 
  22760. > Aaron Nabil
  22761. > 
  22762. > -
  22763. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22764. >  with "unsubscribe usr-tc" in the body of the message.
  22765. >  For information on digests or retrieving files and old messages send
  22766. >  "help" to the same address.  Do not use quotes in your message.
  22767. > 
  22768.  
  22769.  
  22770. -
  22771.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22772.  with "unsubscribe usr-tc" in the body of the message.
  22773.  For information on digests or retrieving files and old messages send
  22774.  "help" to the same address.  Do not use quotes in your message.
  22775.  
  22776.  
  22777. -------------------------------------------------------------------------------
  22778.  
  22779. From:  <farber@admin.f-tech.net>
  22780. Subject: Re: (usr-tc) 3com V90 Problems
  22781. Date: 18 Oct 1999 09:45:17 -0400 (EDT)
  22782.  
  22783. BINGO!  We have a winner.
  22784.  
  22785. I have had a lot of good experiences with making a "Connection Page" that
  22786. shows connection speeds lifted from the NMC card.  Most people hit that
  22787. page after they log in and see what the DSP's say they are getting.
  22788. Ususally they are happy to see that they are "in the green" even though
  22789. the band is from 37K to 53K.
  22790.  
  22791. Kinda like stroking thier ego.
  22792.  
  22793. Paul Farber
  22794. Farber Technology
  22795. farber@admin.f-tech.net
  22796. Ph  570-628-5303
  22797. Fax 570-628-5545
  22798.  
  22799. On Sun, 17 Oct 1999, Brian wrote:
  22800.  
  22801. > I wonder how much of it is pschological vs. real.  For example, ever post
  22802. > to your customers about how you made an upgrade to something like your
  22803. > mail server, and then they start calling tech support and say things like
  22804. > "ever since you all upgraded the server, I can't connect fast".  I often
  22805. > thought, if you told the customers all of them, that you were upgrading
  22806. > your modem code tonight, and wanted their feedback the following day,and
  22807. > you really didn't touch anything, I am betting 25% would say they connect
  22808. > faster, 25% would say they connect slower, and 50% would notice no
  22809. > change.........i'm telling you I believe in this :)
  22810. > 
  22811. > Its like those customers who's modems report the DTE speed of 115,200, and
  22812. > when you fix them up, it only reports say 28800, yet they swear the
  22813. > connection is not as fast anymore.
  22814. > 
  22815. > Well if a customer visually sees a v90 connect, and its a terrible
  22816. > connection, would they claim that connection was faster than a really
  22817. > solid v.34 connect?
  22818. > 
  22819. > What I am getting at, is raw data and numbers are the best, rather than
  22820. > the more subjective data of customers opinions about their connections.
  22821. > 
  22822. > 
  22823. > 
  22824. > On Sun, 17 Oct 1999, Greg Coffey wrote:
  22825. > 
  22826. > > I've never had a customer call the v90 connection "unreliable" to the
  22827. > > competition's Ascends.  The feedback that I've got from customers is that
  22828. > > they get better throughput and are not dissatified with the connects to the
  22829. > > Ascends.  They are using USR modems to dial and they connect consistently
  22830. > > with Ascends at v90 rates, usually 40something.  They never connect at v90
  22831. > > to our TC racks from the same location, using the same PC, software, phone
  22832. > > lines, config, etc.  I don't know the exact cause, they seem to be on the
  22833. > > fringe of the v90 availability area.  3Com described it to me as a "bug" in
  22834. > > the Ascend server firmware.  All I know is that it has cost me customers in
  22835. > > the past and continues to be an issue that I have no answer for when it
  22836. > > comes up.  I have gone to great lengths to explain to them what I have
  22837. > > learned many months ago from 3Com but I don't think they believe me.  Would
  22838. > > you believe that 3Com/USR modems connect better to the competition than
  22839. > > their own racks?  Thankfully, it is a somewhat rare occurance and I only
  22840. > > have to explain once or twice a month.  I really don't know for sure to
  22841. > > what extent it really occurs.  I do know that I have lost customers over
  22842. > > this and it continues to be an issue.  I am getting tired of no news to
  22843. > > update the situation though.  I'm also afraid that it will harm our
  22844. > > reputation if this continues as is.  Word of mouth is still our best
  22845. > > marketing and this will grow in significance with time.  
  22846. > > 
  22847. > > 
  22848. > > 
  22849. > > At 11:15 AM 10/17/99 -0700, you wrote:
  22850. > > >Ed writes...
  22851. > > >> . . .
  22852. > > >>Let him know you are having the 3com V90 problems and you want it resolved.
  22853. > > >>I think they believe it is a rare scenerio not effecting very many people.
  22854. > > >>We told them it was more widespread than they knew... and that if 3com
  22855. > > >>client modems connect to Ascends they should darn well connect to a 3com TC.
  22856. > > >>No ifs ands or buts.
  22857. > > >
  22858. > > >If modem X connects at an unreliable V.90 speed to an Ascend, and 
  22859. > > >connects at a reliable v.34 rate to a 3com, that's a problem?
  22860. > > >
  22861. > > >
  22862. > > >-- 
  22863. > > >Aaron Nabil
  22864. > > >
  22865. > > >-
  22866. > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22867. > > > with "unsubscribe usr-tc" in the body of the message.
  22868. > > > For information on digests or retrieving files and old messages send
  22869. > > > "help" to the same address.  Do not use quotes in your message.
  22870. > > >
  22871. > > >
  22872. > > 
  22873. > > Thanks,
  22874. > > 
  22875. > > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  22876. > > =====================================================================
  22877. > > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  22878. > > 
  22879. > > 
  22880. > > -
  22881. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22882. > >  with "unsubscribe usr-tc" in the body of the message.
  22883. > >  For information on digests or retrieving files and old messages send
  22884. > >  "help" to the same address.  Do not use quotes in your message.
  22885. > > 
  22886. > 
  22887. > -----------------------------------------------------
  22888. > Brian Feeny (BF304)     signal@shreve.net   
  22889. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  22890. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  22891. > 
  22892. > 
  22893. > -
  22894. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22895. >  with "unsubscribe usr-tc" in the body of the message.
  22896. >  For information on digests or retrieving files and old messages send
  22897. >  "help" to the same address.  Do not use quotes in your message.
  22898. > 
  22899.  
  22900.  
  22901. -
  22902.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22903.  with "unsubscribe usr-tc" in the body of the message.
  22904.  For information on digests or retrieving files and old messages send
  22905.  "help" to the same address.  Do not use quotes in your message.
  22906.  
  22907.  
  22908. -------------------------------------------------------------------------------
  22909.  
  22910. From: "Ed" <ed@taylors.com>
  22911. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  22912. Date: 18 Oct 1999 09:40:57 -0400
  22913.  
  22914. The ONLY reason Hold times are down is because everyone has stopped calling.
  22915. They get the 3rd degree about a support contract everytime and then even if
  22916. they have a contract they ask if it's the right chassis for the contract and
  22917. drill them if they are sure they don't have 20 chassis' and a contract for
  22918. 5.
  22919.  
  22920.  
  22921. Ed
  22922.  
  22923. ----- Original Message -----
  22924. Sent: Monday, October 18, 1999 9:09 AM
  22925.  
  22926.  
  22927. Thus spake K Mitchell
  22928. >At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  22929. >>It would seem that admitting this (on 3COM's part) would be
  22930. >>financially impossible.
  22931.  
  22932. >Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
  22933. >they to announce that early DSPs were bad and ship out free
  22934. >replacements, they'd likely sell enough product to new customers to
  22935. >cover the replacement costs.  A move like that could lock in tons of
  22936. >business from companies that like 3Com equipment, but are hesitant to
  22937. >buy because of their support reputation.
  22938.  
  22939. Agreed...3Com needs to do some *serious* work on their support
  22940. reputation.  While its never been good, and *some* issues with support
  22941. have been worked on (hold times for tech support are down, for sure) but
  22942. the quality of tech support is still pitiful, and the *overall* support
  22943. issues (and this isn't just restricted to tech support...its having to
  22944. do with 3Com's overall customer service attitudes) still really sucks
  22945. swamp water.
  22946. --
  22947. Jeff McAdams                            Email: jeffm@iglou.com
  22948. Head Network Administrator              Voice: (502) 966-3848
  22949. IgLou Internet Services                        (800) 436-4456
  22950.  
  22951. -
  22952.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22953.  with "unsubscribe usr-tc" in the body of the message.
  22954.  For information on digests or retrieving files and old messages send
  22955.  "help" to the same address.  Do not use quotes in your message.
  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: K Mitchell <mitch@keyconn.net>
  22969. Subject: Re: (usr-tc) 3com V90 Problems
  22970. Date: 18 Oct 1999 09:58:42 -0400
  22971.  
  22972. At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
  22973. >BINGO!  We have a winner.
  22974. >
  22975. >I have had a lot of good experiences with making a "Connection Page" that
  22976. >shows connection speeds lifted from the NMC card.  Most people hit that
  22977. >page after they log in and see what the DSP's say they are getting.
  22978. >Ususally they are happy to see that they are "in the green" even though
  22979. >the band is from 37K to 53K.
  22980.  
  22981. Care to share your mrtg.cfg entry for this?  :)
  22982.  
  22983.  
  22984. -- 
  22985. Kirk Mitchell-General Manager        mitch@keyconn.net
  22986. Keystone Connect                     Unlock Your World
  22987. Altoona, PA   814-941-5000      http://www.keyconn.net
  22988.  
  22989.  
  22990. -
  22991.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22992.  with "unsubscribe usr-tc" in the body of the message.
  22993.  For information on digests or retrieving files and old messages send
  22994.  "help" to the same address.  Do not use quotes in your message.
  22995.  
  22996.  
  22997. -------------------------------------------------------------------------------
  22998.  
  22999. From: "Jason A. Nunnelley" <interests@linkfast.net>
  23000. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  23001. Date: 18 Oct 1999 09:08:59 -0700
  23002.  
  23003. I have given up on 3COM support myself. I am scared to call for the hassle I
  23004. will go through proving I have the right to call them. I agree. This is a
  23005. company who's goal#1 is to NOT support you. If you get through the DNS tests
  23006. to prove you deserve help, then the techs have done OK with my needs. I
  23007. still ahven't figured out how to get software from the company directly
  23008. without wasting a day proving who I am and what my contract says.
  23009.  
  23010. -----Original Message-----
  23011. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ed
  23012. Sent: Monday, October 18, 1999 6:41 AM
  23013.  
  23014.  
  23015. The ONLY reason Hold times are down is because everyone has stopped calling.
  23016. They get the 3rd degree about a support contract everytime and then even if
  23017. they have a contract they ask if it's the right chassis for the contract and
  23018. drill them if they are sure they don't have 20 chassis' and a contract for
  23019. 5.
  23020.  
  23021.  
  23022. Ed
  23023.  
  23024. ----- Original Message -----
  23025. Sent: Monday, October 18, 1999 9:09 AM
  23026.  
  23027.  
  23028. Thus spake K Mitchell
  23029. >At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  23030. >>It would seem that admitting this (on 3COM's part) would be
  23031. >>financially impossible.
  23032.  
  23033. >Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
  23034. >they to announce that early DSPs were bad and ship out free
  23035. >replacements, they'd likely sell enough product to new customers to
  23036. >cover the replacement costs.  A move like that could lock in tons of
  23037. >business from companies that like 3Com equipment, but are hesitant to
  23038. >buy because of their support reputation.
  23039.  
  23040. Agreed...3Com needs to do some *serious* work on their support
  23041. reputation.  While its never been good, and *some* issues with support
  23042. have been worked on (hold times for tech support are down, for sure) but
  23043. the quality of tech support is still pitiful, and the *overall* support
  23044. issues (and this isn't just restricted to tech support...its having to
  23045. do with 3Com's overall customer service attitudes) still really sucks
  23046. swamp water.
  23047. --
  23048. Jeff McAdams                            Email: jeffm@iglou.com
  23049. Head Network Administrator              Voice: (502) 966-3848
  23050. IgLou Internet Services                        (800) 436-4456
  23051.  
  23052. -
  23053.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23054.  with "unsubscribe usr-tc" in the body of the message.
  23055.  For information on digests or retrieving files and old messages send
  23056.  "help" to the same address.  Do not use quotes in your message.
  23057.  
  23058.  
  23059.  
  23060. -
  23061.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23062.  with "unsubscribe usr-tc" in the body of the message.
  23063.  For information on digests or retrieving files and old messages send
  23064.  "help" to the same address.  Do not use quotes in your message.
  23065.  
  23066.  
  23067. -
  23068.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23069.  with "unsubscribe usr-tc" in the body of the message.
  23070.  For information on digests or retrieving files and old messages send
  23071.  "help" to the same address.  Do not use quotes in your message.
  23072.  
  23073.  
  23074. -------------------------------------------------------------------------------
  23075.  
  23076. From: "Jason A. Nunnelley" <interests@linkfast.net>
  23077. Subject: RE: (usr-tc) 3com V90 Problems
  23078. Date: 18 Oct 1999 09:15:05 -0700
  23079.  
  23080. That sounds cool. What script do you run for that?
  23081.  
  23082. -----Original Message-----
  23083. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  23084. farber@admin.f-tech.net
  23085. Sent: Monday, October 18, 1999 6:45 AM
  23086.  
  23087.  
  23088. BINGO!  We have a winner.
  23089.  
  23090. I have had a lot of good experiences with making a "Connection Page" that
  23091. shows connection speeds lifted from the NMC card.  Most people hit that
  23092. page after they log in and see what the DSP's say they are getting.
  23093. Ususally they are happy to see that they are "in the green" even though
  23094. the band is from 37K to 53K.
  23095.  
  23096. Kinda like stroking thier ego.
  23097.  
  23098. Paul Farber
  23099. Farber Technology
  23100. farber@admin.f-tech.net
  23101. Ph  570-628-5303
  23102. Fax 570-628-5545
  23103.  
  23104. On Sun, 17 Oct 1999, Brian wrote:
  23105.  
  23106. > I wonder how much of it is pschological vs. real.  For example, ever post
  23107. > to your customers about how you made an upgrade to something like your
  23108. > mail server, and then they start calling tech support and say things like
  23109. > "ever since you all upgraded the server, I can't connect fast".  I often
  23110. > thought, if you told the customers all of them, that you were upgrading
  23111. > your modem code tonight, and wanted their feedback the following day,and
  23112. > you really didn't touch anything, I am betting 25% would say they connect
  23113. > faster, 25% would say they connect slower, and 50% would notice no
  23114. > change.........i'm telling you I believe in this :)
  23115. >
  23116. > Its like those customers who's modems report the DTE speed of 115,200, and
  23117. > when you fix them up, it only reports say 28800, yet they swear the
  23118. > connection is not as fast anymore.
  23119. >
  23120. > Well if a customer visually sees a v90 connect, and its a terrible
  23121. > connection, would they claim that connection was faster than a really
  23122. > solid v.34 connect?
  23123. >
  23124. > What I am getting at, is raw data and numbers are the best, rather than
  23125. > the more subjective data of customers opinions about their connections.
  23126. >
  23127. >
  23128. >
  23129. > On Sun, 17 Oct 1999, Greg Coffey wrote:
  23130. >
  23131. > > I've never had a customer call the v90 connection "unreliable" to the
  23132. > > competition's Ascends.  The feedback that I've got from customers is
  23133. that
  23134. > > they get better throughput and are not dissatified with the connects to
  23135. the
  23136. > > Ascends.  They are using USR modems to dial and they connect
  23137. consistently
  23138. > > with Ascends at v90 rates, usually 40something.  They never connect at
  23139. v90
  23140. > > to our TC racks from the same location, using the same PC, software,
  23141. phone
  23142. > > lines, config, etc.  I don't know the exact cause, they seem to be on
  23143. the
  23144. > > fringe of the v90 availability area.  3Com described it to me as a "bug"
  23145. in
  23146. > > the Ascend server firmware.  All I know is that it has cost me customers
  23147. in
  23148. > > the past and continues to be an issue that I have no answer for when it
  23149. > > comes up.  I have gone to great lengths to explain to them what I have
  23150. > > learned many months ago from 3Com but I don't think they believe me.
  23151. Would
  23152. > > you believe that 3Com/USR modems connect better to the competition than
  23153. > > their own racks?  Thankfully, it is a somewhat rare occurance and I only
  23154. > > have to explain once or twice a month.  I really don't know for sure to
  23155. > > what extent it really occurs.  I do know that I have lost customers over
  23156. > > this and it continues to be an issue.  I am getting tired of no news to
  23157. > > update the situation though.  I'm also afraid that it will harm our
  23158. > > reputation if this continues as is.  Word of mouth is still our best
  23159. > > marketing and this will grow in significance with time.
  23160. > >
  23161. > >
  23162. > >
  23163. > > At 11:15 AM 10/17/99 -0700, you wrote:
  23164. > > >Ed writes...
  23165. > > >> . . .
  23166. > > >>Let him know you are having the 3com V90 problems and you want it
  23167. resolved.
  23168. > > >>I think they believe it is a rare scenerio not effecting very many
  23169. people.
  23170. > > >>We told them it was more widespread than they knew... and that if 3com
  23171. > > >>client modems connect to Ascends they should darn well connect to a
  23172. 3com TC.
  23173. > > >>No ifs ands or buts.
  23174. > > >
  23175. > > >If modem X connects at an unreliable V.90 speed to an Ascend, and
  23176. > > >connects at a reliable v.34 rate to a 3com, that's a problem?
  23177. > > >
  23178. > > >
  23179. > > >--
  23180. > > >Aaron Nabil
  23181. > > >
  23182. > > >-
  23183. > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23184. > > > with "unsubscribe usr-tc" in the body of the message.
  23185. > > > For information on digests or retrieving files and old messages send
  23186. > > > "help" to the same address.  Do not use quotes in your message.
  23187. > > >
  23188. > > >
  23189. > >
  23190. > > Thanks,
  23191. > >
  23192. > > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446
  23193. > > =====================================================================
  23194. > > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM
  23195. > >
  23196. > >
  23197. > > -
  23198. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23199. > >  with "unsubscribe usr-tc" in the body of the message.
  23200. > >  For information on digests or retrieving files and old messages send
  23201. > >  "help" to the same address.  Do not use quotes in your message.
  23202. > >
  23203. >
  23204. > -----------------------------------------------------
  23205. > Brian Feeny (BF304)     signal@shreve.net
  23206. > 318-222-2638 x 109    http://www.shreve.net/~signal
  23207. > Network Administrator   ShreveNet Inc. (ASN 11881)
  23208. >
  23209. >
  23210. > -
  23211. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23212. >  with "unsubscribe usr-tc" in the body of the message.
  23213. >  For information on digests or retrieving files and old messages send
  23214. >  "help" to the same address.  Do not use quotes in your message.
  23215. >
  23216.  
  23217.  
  23218. -
  23219.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23220.  with "unsubscribe usr-tc" in the body of the message.
  23221.  For information on digests or retrieving files and old messages send
  23222.  "help" to the same address.  Do not use quotes in your message.
  23223.  
  23224.  
  23225. -
  23226.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23227.  with "unsubscribe usr-tc" in the body of the message.
  23228.  For information on digests or retrieving files and old messages send
  23229.  "help" to the same address.  Do not use quotes in your message.
  23230.  
  23231.  
  23232. -------------------------------------------------------------------------------
  23233.  
  23234. From: "Jason A. Nunnelley" <interests@linkfast.net>
  23235. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  23236. Date: 18 Oct 1999 09:17:35 -0700
  23237.  
  23238. You guys don't know big business if you think a company would consider
  23239. giving away cards cause the one's they sold went bad. Don't know about the
  23240. side-gas tanks in the small trucks (un-named car company that preferred
  23241. paying off litigations one by one than admit and fix) or the typical medical
  23242. industry reaction when they catch a bad procedure or drug. 3COM faces far
  23243. too many problems, as any big business admitting to any wrong doing or
  23244. mistake. Let the customers deal with it, solve the problem in new releases
  23245. of the product, and wait to let it go away. That's how big business handles
  23246. stuff like that. Seriously! Even if they were a nice company, they aren't
  23247. small business minded like an ISP. Screw the customers we have - they are
  23248. stuck. Get the new fish! It would cost me a fortune to switch to another
  23249. brand (although I keep saying the hardware is pretty good by my experience).
  23250. I can't really do it now. I miss my PM3, but I have to keep my 3COM and
  23251. think (maybe influenced by reality not allowing any real choice) that it is
  23252. a better choice despite support problems. I just do not call support when I
  23253. have problems. I ask you guys, or people like you. My contract was a waste
  23254. of money. I do not think I'll make that mistake again. Of course, if
  23255. revision releases rely on it - he he, I guess once again I have no choice.
  23256.  
  23257. After all, this is not a bad box to own. And, I do not have any hardware
  23258. issues with hanging modems, never seen it.
  23259.  
  23260. -----Original Message-----
  23261. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  23262. Sent: Monday, October 18, 1999 6:09 AM
  23263.  
  23264.  
  23265. Thus spake K Mitchell
  23266. >At 07:26 PM 10/17/99 -0700, Jason A. Nunnelley wrote:
  23267. >>It would seem that admitting this (on 3COM's part) would be
  23268. >>financially impossible.
  23269.  
  23270. >Far cheaper than loosing a bunch of customers, I'd bet. Actually, were
  23271. >they to announce that early DSPs were bad and ship out free
  23272. >replacements, they'd likely sell enough product to new customers to
  23273. >cover the replacement costs.  A move like that could lock in tons of
  23274. >business from companies that like 3Com equipment, but are hesitant to
  23275. >buy because of their support reputation.
  23276.  
  23277. Agreed...3Com needs to do some *serious* work on their support
  23278. reputation.  While its never been good, and *some* issues with support
  23279. have been worked on (hold times for tech support are down, for sure) but
  23280. the quality of tech support is still pitiful, and the *overall* support
  23281. issues (and this isn't just restricted to tech support...its having to
  23282. do with 3Com's overall customer service attitudes) still really sucks
  23283. swamp water.
  23284. --
  23285. Jeff McAdams                            Email: jeffm@iglou.com
  23286. Head Network Administrator              Voice: (502) 966-3848
  23287. IgLou Internet Services                        (800) 436-4456
  23288.  
  23289. -
  23290.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23291.  with "unsubscribe usr-tc" in the body of the message.
  23292.  For information on digests or retrieving files and old messages send
  23293.  "help" to the same address.  Do not use quotes in your message.
  23294.  
  23295.  
  23296. -
  23297.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23298.  with "unsubscribe usr-tc" in the body of the message.
  23299.  For information on digests or retrieving files and old messages send
  23300.  "help" to the same address.  Do not use quotes in your message.
  23301.  
  23302.  
  23303. -------------------------------------------------------------------------------
  23304.  
  23305. From: Jeff Mcadams <jeffm@iglou.com>
  23306. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  23307. Date: 18 Oct 1999 10:28:36 -0400
  23308.  
  23309. Thus spake Ed
  23310. >The ONLY reason Hold times are down is because everyone has stopped
  23311. >calling.  They get the 3rd degree about a support contract everytime
  23312. >and then even if they have a contract they ask if it's the right
  23313. >chassis for the contract and drill them if they are sure they don't
  23314. >have 20 chassis' and a contract for 5.
  23315.  
  23316. Yeah, that and they pulled in a bunch of people with virtually no
  23317. training or experience for first level tech support, I think so they
  23318. could at least have someone answer the phone.
  23319.  
  23320. If they're going to take this route...do what Livingston used to
  23321. do...have someone (more likely multiple someone's), *not* a tech support
  23322. person, answer the phone, take some information about the nature of the
  23323. problem and the urgency, and then do tech support on a callback basis.
  23324. Livingston did this for quite some time, and while non-urgent callbacks
  23325. could take up to 2 weeks to occur, urgent problems were handled
  23326. promptly, efficiently, and by an engineer that was well versed in the
  23327. equipment.  I would certainly not be averse to such a model of tech
  23328. support.  While I would *prefer* to have prompt, efficient, quality
  23329. handling of *all* tech support inquiries, I have to acknowledge that the
  23330. realities of the technical job market could preclude that possibility.
  23331.  
  23332. Regardless...I agree with you, Ed, here, in that the constant abuse that
  23333. customers receive concerning their support contracts is a significant
  23334. factor as well.
  23335. -- 
  23336. Jeff McAdams                            Email: jeffm@iglou.com
  23337. Head Network Administrator              Voice: (502) 966-3848
  23338. IgLou Internet Services                        (800) 436-4456
  23339.  
  23340. -
  23341.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23342.  with "unsubscribe usr-tc" in the body of the message.
  23343.  For information on digests or retrieving files and old messages send
  23344.  "help" to the same address.  Do not use quotes in your message.
  23345.  
  23346.  
  23347. -------------------------------------------------------------------------------
  23348.  
  23349. From: Jeff Mcadams <jeffm@iglou.com>
  23350. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  23351. Date: 18 Oct 1999 10:31:32 -0400
  23352.  
  23353. Thus spake Jason A. Nunnelley
  23354. >My contract was a waste of money. I do not think I'll make that mistake
  23355. >again. Of course, if revision releases rely on it - he he, I guess once
  23356. >again I have no choice.
  23357.  
  23358. Well...as was discussed before...there are other ways around getting the
  23359. releases...and they're becoming more and more common.
  23360. -- 
  23361. Jeff McAdams                            Email: jeffm@iglou.com
  23362. Head Network Administrator              Voice: (502) 966-3848
  23363. IgLou Internet Services                        (800) 436-4456
  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: "Jason A. Nunnelley" <interests@linkfast.net>
  23375. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  23376. Date: 18 Oct 1999 09:30:18 -0700
  23377.  
  23378. I must agree once again: I miss working with Livingston. They
  23379. undersand and have in their business plan - good tech support
  23380. and upgrades. They are most concerned with supporting and making
  23381. sure that their product works. Whereas I think the #1 goal of
  23382. 3COM is to avoid these things at all costs. Then again, how is
  23383. their stock doing? That's really all that matters.
  23384.  
  23385. -----Original Message-----
  23386. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  23387. Sent: Monday, October 18, 1999 6:07 AM
  23388.  
  23389.  
  23390. Thus spake Jason A. Nunnelley
  23391. >It would seem that admitting this (on 3COM's part) would be financially
  23392. >impossible. There would be an outcry for replacement cards, especially
  23393. those
  23394. >who are under support and guaranteed contracts.
  23395.  
  23396. In MegaZone's absence, I'll point out that Livingston did exactly
  23397. this...actually...they went one step farther.  Livingston had been
  23398. shipping modems saying they would be upgradeable to v.90 when v.90 was
  23399. designed.  They weren't.  Livingston replaced any and all of the old
  23400. modem cards free of charge with the new ones that were capable of v.90.
  23401.  
  23402. 3Com doesn't even, apparently, have the willingness (almost said "guts")
  23403. to replace cards when the *current* functionality is broken.  This is,
  23404. at least, borderline illegal.  As another example of this, harken back
  23405. to ye ol' days of NETServers and broken MPIP (many of you will remember
  23406. all of this) and 3Com, to this day, refuses to make this situation
  23407. right.
  23408.  
  23409. Again...I truly believe its beaurocracy getting in the way here.  The
  23410. people that are in the position to make the decision to "do the right
  23411. thing," are so *totally* insulated from the customers by layer upon
  23412. layer of beaurocracy, that they don't even *realize* how their decisions
  23413. for 3Com are royally screwing over their customer base...and may even be
  23414. illegal!
  23415. --
  23416. Jeff McAdams                            Email: jeffm@iglou.com
  23417. Head Network Administrator              Voice: (502) 966-3848
  23418. IgLou Internet Services                        (800) 436-4456
  23419.  
  23420. -
  23421.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23422.  with "unsubscribe usr-tc" in the body of the message.
  23423.  For information on digests or retrieving files and old messages send
  23424.  "help" to the same address.  Do not use quotes in your message.
  23425.  
  23426.  
  23427. -
  23428.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23429.  with "unsubscribe usr-tc" in the body of the message.
  23430.  For information on digests or retrieving files and old messages send
  23431.  "help" to the same address.  Do not use quotes in your message.
  23432.  
  23433.  
  23434. -------------------------------------------------------------------------------
  23435.  
  23436. From: <dciresi@defunct.ae.usr.com>
  23437. Subject: Re: (usr-tc) S/A database cleanup?
  23438. Date: 18 Oct 1999 09:49:44 -0500 (CDT)
  23439.  
  23440. There is a macro for purging the contents of the CALLS and EVENTS table in
  23441. the database.  It sends output to a CSV text file.
  23442.  
  23443. The macro is under Server Setup->Advanced->Database Maintenance.
  23444.  
  23445. Afterwords, it makes sense to compact the database.  I recommend saving a
  23446. backup copy before and after this operation.
  23447.  
  23448. Dominic
  23449.  
  23450. On Sat, 16 Oct 1999, Mike Moore wrote:
  23451.  
  23452. > I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the database? It
  23453. > is getting quite large. TIA!!!!!
  23454. > 
  23455. > Mike Moore
  23456. > BCSNet
  23457. > 
  23458. > 
  23459. > -
  23460. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23461. >  with "unsubscribe usr-tc" in the body of the message.
  23462. >  For information on digests or retrieving files and old messages send
  23463. >  "help" to the same address.  Do not use quotes in your message.
  23464. > 
  23465.  
  23466.  
  23467. -
  23468.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23469.  with "unsubscribe usr-tc" in the body of the message.
  23470.  For information on digests or retrieving files and old messages send
  23471.  "help" to the same address.  Do not use quotes in your message.
  23472.  
  23473.  
  23474. -------------------------------------------------------------------------------
  23475.  
  23476. From: <dciresi@defunct.ae.usr.com>
  23477. Subject: Re: (usr-tc) (USR-TC) S/A DATABASE CLE
  23478. Date: 18 Oct 1999 09:53:02 -0500 (CDT)
  23479.  
  23480. On the UNIX platform, both Oracle and Postgresql are supported.
  23481.  
  23482. On Sun, 17 Oct 1999, Jeff Binkley wrote:
  23483.  
  23484. > 
  23485. > 
  23486. > 
  23487. > Mike,
  23488. > 
  23489. > What I do, since S/A yet supports SQL, is I have an SQL server and two 
  23490. > linked tables for events and calls.  I have an ASP job which I run 
  23491. > periodically which copies records out of the normal calls and events 
  23492. > tables into the SQL server calls and events tables, then deletes the 
  23493. > records in the Access database.  All you need to do then is periodically 
  23494. > use the MS Access database compress option to shrink the database down 
  23495. > to something resonable.  Of course if 3Com would ever support an SQL 
  23496. > server, this would be a mute point.
  23497. > 
  23498. > Jeff Binkley
  23499. > ASA Network Computing 
  23500. > 
  23501. > 
  23502. > U>I'm using 3Com S/A 6.0.90 for now. Any tips on cleaning up the
  23503. > U>database? It is getting quite large. TIA!!!!!
  23504. > 
  23505. > U>Mike Moore
  23506. > U>BCSNet
  23507. > 
  23508. > 
  23509. > U>-
  23510. > U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23511. > U> with "unsubscribe usr-tc" in the body of the message.
  23512. > U> For information on digests or retrieving files and old messages send
  23513. > U> "help" to the same address.  Do not use quotes in your message.
  23514. > 
  23515. > CMPQwk 1.42-21 9999
  23516. > 
  23517. > 
  23518. > 
  23519. > -
  23520. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23521. >  with "unsubscribe usr-tc" in the body of the message.
  23522. >  For information on digests or retrieving files and old messages send
  23523. >  "help" to the same address.  Do not use quotes in your message.
  23524. > 
  23525.  
  23526.  
  23527. -
  23528.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23529.  with "unsubscribe usr-tc" in the body of the message.
  23530.  For information on digests or retrieving files and old messages send
  23531.  "help" to the same address.  Do not use quotes in your message.
  23532.  
  23533.  
  23534. -------------------------------------------------------------------------------
  23535.  
  23536. From: Jeff Mcadams <jeffm@iglou.com>
  23537. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  23538. Date: 18 Oct 1999 11:06:45 -0400
  23539.  
  23540. Thus spake Jason A. Nunnelley
  23541. >Then again, how is their stock doing? That's really all that matters.
  23542.  
  23543. Ooh...good question...and one I bet 3Com really doesn't want asked...
  23544.  
  23545. After a quick perusal of 3Com's stock history on yahoo (symbol: COMS).
  23546. Their current stock price is approximately 30.  Going back on their 5
  23547. year chart, COMS stock first hit the 30 mark (split adjusted) around
  23548. April or May of 1995!  Given that I had to go to the 5 year chart to be
  23549. able to see back that far, the chart was course grained enough that I'd
  23550. guesstimate the margin for error being a couple of months either way.
  23551.  
  23552. This all means...if you had purchased 3Com stock in early to mid 1995,
  23553. you would be breaking even at this point (3Com doesn't issue dividends,
  23554. so you can't even count on dividends for gains here)
  23555. -- 
  23556. Jeff McAdams                            Email: jeffm@iglou.com
  23557. Head Network Administrator              Voice: (502) 966-3848
  23558. IgLou Internet Services                        (800) 436-4456
  23559.  
  23560. -
  23561.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23562.  with "unsubscribe usr-tc" in the body of the message.
  23563.  For information on digests or retrieving files and old messages send
  23564.  "help" to the same address.  Do not use quotes in your message.
  23565.  
  23566.  
  23567. -------------------------------------------------------------------------------
  23568.  
  23569. From: "John Schmerold" <john@katy.com>
  23570. Subject: (usr-tc) Netserver 8I+ to Livingston Portmaster
  23571. Date: 18 Oct 1999 10:32:47 -0500
  23572.  
  23573. I'm trying to get my Netserver to connect to our ISP's Portmaster without
  23574. success.
  23575.  
  23576. It seems to connect & stay connected, problem is, it does not allow me to
  23577. ping the portmaster or IP addresses on Portmaster side of the connection.
  23578.  
  23579. We're running V4.0.13 ( I know about 4.0.2, but we thought we ought to get
  23580. this working first)
  23581.  
  23582. Our connection to our ISP works fine with a Netgear RT328, but I'd like to
  23583. eliminate the separate router.
  23584.  
  23585. I execute following to configure the Netserver:
  23586. add modem_group 78 INTERFACES mod:7,mod:8
  23587. add user BN password isppassword type network,dial_out enable no
  23588. set system transmit_authentication_name ME
  23589. set ppp receive_authentication pap
  23590. set network user BN send_pass isppassword
  23591. set user BN modem_group 78 phone_number 5551212
  23592. set network user BN ppp compression_algorithm ASCEND
  23593. set network user BN address_selection SPECIFIED remote_ip_address
  23594. 209.74.143.3
  23595. set dial_out user BN site type continuous
  23596. set network user BN ip_routing none header_compression tcp/ip
  23597. add framed USER BN IP_ROUTE 209.74.143.0/C GATEWAY 209.74.143.3 METRIC 5
  23598. ENABLE USER BN
  23599. ADD IP default gateway 209.74.143.3 metric 1
  23600.  
  23601. save all
  23602.  
  23603.  
  23604. Other pertainent information:
  23605.  
  23606. USRobotics Total Control MP I-modem with ISDN/V.34 ISDN Switch Settings...
  23607.  
  23608.    Switch Protocol *W   2                       US National ISDN-1
  23609.    Multipoint      *M   1                       Multi-point
  23610.    Dialing Mode    *O   1                       Overlap Sending mode
  23611.    SPID            *S1  31421535730101        <-SPID1
  23612.                    *S2  31421535740101          SPID2
  23613.    Directory No.   *P1  2153573               <-DN1
  23614.                    *P2  2153574                 DN2
  23615.    TEI             *T1  00                      Automatic TEI
  23616.                    *T2  00                      Automatic TEI
  23617.  
  23618.    Physical Interface:  Inactive
  23619.    Data Link Layer   :  Inactive
  23620.  
  23621. OK
  23622.  
  23623. USRobotics Total Control MP I-modem with ISDN/V.34 Settings...
  23624.  
  23625.    B0  C1  E1  F1  Q0  V1  X1
  23626.    BAUD=115200 PARITY=N  WORDLEN=8
  23627.    DIAL=TONE   ON HOOK   TIMER
  23628.  
  23629.    <enter> for more... Q to quit...
  23630.    &A1  &B0  &C1  &D2  &G0  &H0  &I0  &K1  &M4  &N0  &P0  &R1  &S0
  23631.    &T5  &U0  &X0  &Y1  %N6  *V=5  #CID=0
  23632.  
  23633.    S00=001  S01=000  S02=043  S03=013  S04=010  S05=008  S06=002  S07=060
  23634.    S08=002  S09=006  S10=018  S11=070  S12=050  S13=000  S14=001  S15=000
  23635.    S16=000  S17=000  S18=000  S19=000  S20=000  S21=010  S22=017  S23=019
  23636.    S24=150  S25=005  S26=001  S27=000  S28=008  S29=020  S30=000  S31=000
  23637.    S32=009  S33=000  S34=000  S35=000  S36=000  S37=000  S38=000  S39=000
  23638.    S40=000  S41=000  S42=126  S43=200  S44=015  S45=000  S46=255  S47=000
  23639.    S48=000  S49=016  S50=100  S51=064  S52=005  S53=000  S54=064  S55=000
  23640.    S56=000  S57=000  S58=000  S59=000  S60=000  S61=000  S62=000  S63=000
  23641.    S64=000  S65=000  S66=000  S67=064  S68=008  S69=000  S70=012
  23642.  
  23643.  
  23644. USRobotics Total Control MP I-modem with ISDN/V.34 Configuration Profile...
  23645.  
  23646. Product type           US/Canada External
  23647. Options                HST,V32bis,Terbo,V.FC,V34+,x2,V.90
  23648. Fax Options            Class 1/Class 2.0
  23649. Clock Freq             20.16Mhz
  23650. Eprom                  768k
  23651. Ram                    256k
  23652.  
  23653. Supervisor date        03/02/99
  23654. DSP date               04/02/98
  23655.  
  23656. Supervisor rev         2.3.7
  23657. DSP rev                2.1.0
  23658.  
  23659.  
  23660.  
  23661. -
  23662.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23663.  with "unsubscribe usr-tc" in the body of the message.
  23664.  For information on digests or retrieving files and old messages send
  23665.  "help" to the same address.  Do not use quotes in your message.
  23666.  
  23667.  
  23668. -------------------------------------------------------------------------------
  23669.  
  23670. From:  <farber@admin.f-tech.net>
  23671. Subject: Re: (usr-tc) 3com V90 Problems
  23672. Date: 18 Oct 1999 11:44:41 -0400 (EDT)
  23673.  
  23674. It's a perl script.  Not to accurate (3Com's off by one snmp errors) and
  23675. my inability to write good perl code).
  23676.  
  23677. Give me an address and I send it to you.
  23678.  
  23679. Paul Farber
  23680. Farber Technology
  23681. farber@admin.f-tech.net
  23682. Ph  570-628-5303
  23683. Fax 570-628-5545
  23684.  
  23685. On Mon, 18 Oct 1999, K Mitchell wrote:
  23686.  
  23687. > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
  23688. > >BINGO!  We have a winner.
  23689. > >
  23690. > >I have had a lot of good experiences with making a "Connection Page" that
  23691. > >shows connection speeds lifted from the NMC card.  Most people hit that
  23692. > >page after they log in and see what the DSP's say they are getting.
  23693. > >Ususally they are happy to see that they are "in the green" even though
  23694. > >the band is from 37K to 53K.
  23695. > 
  23696. > Care to share your mrtg.cfg entry for this?  :)
  23697. > 
  23698. > 
  23699. > -- 
  23700. > Kirk Mitchell-General Manager        mitch@keyconn.net
  23701. > Keystone Connect                     Unlock Your World
  23702. > Altoona, PA   814-941-5000      http://www.keyconn.net
  23703. > 
  23704. > 
  23705. > -
  23706. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23707. >  with "unsubscribe usr-tc" in the body of the message.
  23708. >  For information on digests or retrieving files and old messages send
  23709. >  "help" to the same address.  Do not use quotes in your message.
  23710. > 
  23711.  
  23712.  
  23713. -
  23714.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23715.  with "unsubscribe usr-tc" in the body of the message.
  23716.  For information on digests or retrieving files and old messages send
  23717.  "help" to the same address.  Do not use quotes in your message.
  23718.  
  23719.  
  23720. -------------------------------------------------------------------------------
  23721.  
  23722. From: Jeff Mcadams <jeffm@iglou.com>
  23723. Subject: Re: (usr-tc) 3com V90 Problems
  23724. Date: 18 Oct 1999 11:49:40 -0400
  23725.  
  23726. Thus spake farber@admin.f-tech.net
  23727. >It's a perl script.  Not to accurate (3Com's off by one snmp errors) and
  23728. >my inability to write good perl code).
  23729.  
  23730. Upgrade to the 6.x.x version of NMC code and these are all taken care
  23731. of.  :)
  23732.  
  23733. Unfortunately, I haven't had the time to do this yet, but I have checked
  23734. it out, and that version of code does indeed fix the problem.
  23735. -- 
  23736. Jeff McAdams                            Email: jeffm@iglou.com
  23737. Head Network Administrator              Voice: (502) 966-3848
  23738. IgLou Internet Services                        (800) 436-4456
  23739.  
  23740. -
  23741.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23742.  with "unsubscribe usr-tc" in the body of the message.
  23743.  For information on digests or retrieving files and old messages send
  23744.  "help" to the same address.  Do not use quotes in your message.
  23745.  
  23746.  
  23747. -------------------------------------------------------------------------------
  23748.  
  23749. From: "Mike McHenry" <mmchen@minn.net>
  23750. Subject: (usr-tc) Still having problems with default routes disappearing
  23751. Date: 18 Oct 1999 12:23:30 -0500
  23752.  
  23753.  
  23754. Last week I mentioned that I have been having problems on several of my
  23755. chassis with the default route just disappearing. To this date I have still
  23756. not found a cause for this abnormal behavior. I am almost positive it is not
  23757. a configuration issue although I am still open to any suggestions as far as
  23758. that goes.
  23759.  
  23760. This problem just started occuring about a week ago and it does not recur
  23761. with any sort of pattern.  I am running 4.2.32-1 on the ARCs. I am also
  23762. running OSPF on the chassis now but I don't think it is a direct OSPF
  23763. problem. The things ran flawlessly for several weeks with OSPF routing and
  23764. 4.2.32-1 before I started having this problem.
  23765.  
  23766. Has anyone been having any sort of odd problems with OSPF or 4.2.32-1? I
  23767. would really like to get this resolved and I am at a loss right now. Any
  23768. comments or suggestions would be appreciated...
  23769.  
  23770. Mike McHenry
  23771.  Systems Administrator
  23772.  MinnNet Communications, Inc.
  23773.  
  23774.  
  23775. -
  23776.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23777.  with "unsubscribe usr-tc" in the body of the message.
  23778.  For information on digests or retrieving files and old messages send
  23779.  "help" to the same address.  Do not use quotes in your message.
  23780.  
  23781.  
  23782. -------------------------------------------------------------------------------
  23783.  
  23784. From: K Mitchell <mitch@keyconn.net>
  23785. Subject: Re: (usr-tc) 3com V90 Problems
  23786. Date: 18 Oct 1999 13:42:19 -0400
  23787.  
  23788. At 11:44 AM 10/18/99 -0400, Paul Farber wrote:
  23789. >It's a perl script.  Not to accurate (3Com's off by one snmp errors) and
  23790. >my inability to write good perl code).
  23791. >
  23792. >Give me an address and I send it to you.
  23793.  
  23794. mitch@keyconn.net
  23795.  
  23796. Thanks,
  23797.  
  23798. -- 
  23799. Kirk Mitchell-General Manager        mitch@keyconn.net
  23800. Keystone Connect                     Unlock Your World
  23801. Altoona, PA   814-941-5000      http://www.keyconn.net
  23802.  
  23803.  
  23804. -
  23805.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23806.  with "unsubscribe usr-tc" in the body of the message.
  23807.  For information on digests or retrieving files and old messages send
  23808.  "help" to the same address.  Do not use quotes in your message.
  23809.  
  23810.  
  23811. -------------------------------------------------------------------------------
  23812.  
  23813. From: "Eric Billeter" <ebilleter@cableone.net>
  23814. Subject: RE: (usr-tc) 3com V90 Problems
  23815. Date: 18 Oct 1999 11:06:27 -0700
  23816.  
  23817. I also would appreciate a copy 
  23818.  
  23819. Thanks
  23820. Eric Billeter                   
  23821. Internet Engineer
  23822. Cable One, Inc.
  23823.  
  23824. eric.billeter@cableone.net
  23825. 602-364-6462
  23826.  
  23827. -----Original Message-----
  23828. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell
  23829. Sent: Monday, October 18, 1999 10:42 AM
  23830.  
  23831.  
  23832. At 11:44 AM 10/18/99 -0400, Paul Farber wrote:
  23833. >It's a perl script.  Not to accurate (3Com's off by one snmp errors) and
  23834. >my inability to write good perl code).
  23835. >
  23836. >Give me an address and I send it to you.
  23837.  
  23838. mitch@keyconn.net
  23839.  
  23840. Thanks,
  23841.  
  23842. -- 
  23843. Kirk Mitchell-General Manager        mitch@keyconn.net
  23844. Keystone Connect                     Unlock Your World
  23845. Altoona, PA   814-941-5000      http://www.keyconn.net
  23846.  
  23847.  
  23848. -
  23849.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23850.  with "unsubscribe usr-tc" in the body of the message.
  23851.  For information on digests or retrieving files and old messages send
  23852.  "help" to the same address.  Do not use quotes in your message.
  23853.  
  23854.  
  23855.  
  23856.  
  23857. -
  23858.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23859.  with "unsubscribe usr-tc" in the body of the message.
  23860.  For information on digests or retrieving files and old messages send
  23861.  "help" to the same address.  Do not use quotes in your message.
  23862.  
  23863.  
  23864. -------------------------------------------------------------------------------
  23865.  
  23866. From: "Jason A. Nunnelley" <interests@linkfast.net>
  23867. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  23868. Date: 18 Oct 1999 13:06:08 -0700
  23869.  
  23870. Uh Oh!
  23871.  
  23872. So, is this a company that is not concerned with growth or stock
  23873. value? What motivates the management here then? Is it squeezing the
  23874. customer for every penny they can get and keeping costs low as they
  23875. can for management paychecks? Ouhhhhhhh, that's a coctail for failure.
  23876.  
  23877. Makes you wonder doesn't it?
  23878.  
  23879. -----Original Message-----
  23880. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  23881. Sent: Monday, October 18, 1999 8:07 AM
  23882.  
  23883.  
  23884. Thus spake Jason A. Nunnelley
  23885. >Then again, how is their stock doing? That's really all that matters.
  23886.  
  23887. Ooh...good question...and one I bet 3Com really doesn't want asked...
  23888.  
  23889. After a quick perusal of 3Com's stock history on yahoo (symbol: COMS).
  23890. Their current stock price is approximately 30.  Going back on their 5
  23891. year chart, COMS stock first hit the 30 mark (split adjusted) around
  23892. April or May of 1995!  Given that I had to go to the 5 year chart to be
  23893. able to see back that far, the chart was course grained enough that I'd
  23894. guesstimate the margin for error being a couple of months either way.
  23895.  
  23896. This all means...if you had purchased 3Com stock in early to mid 1995,
  23897. you would be breaking even at this point (3Com doesn't issue dividends,
  23898. so you can't even count on dividends for gains here)
  23899. -- 
  23900. Jeff McAdams                            Email: jeffm@iglou.com
  23901. Head Network Administrator              Voice: (502) 966-3848
  23902. IgLou Internet Services                        (800) 436-4456
  23903.  
  23904. -
  23905.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23906.  with "unsubscribe usr-tc" in the body of the message.
  23907.  For information on digests or retrieving files and old messages send
  23908.  "help" to the same address.  Do not use quotes in your message.
  23909.  
  23910. -
  23911.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23912.  with "unsubscribe usr-tc" in the body of the message.
  23913.  For information on digests or retrieving files and old messages send
  23914.  "help" to the same address.  Do not use quotes in your message.
  23915.  
  23916.  
  23917. -------------------------------------------------------------------------------
  23918.  
  23919. From: "Jason A. Nunnelley" <interests@linkfast.net>
  23920. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  23921. Date: 18 Oct 1999 13:16:13 -0700
  23922.  
  23923. From a Person who actually relied on LT, due to weaker skills (I have
  23924. to say 3COM imrpoves your problems solving skills - again they have
  23925. good stuff, just tough to get support) I really appreciated LT support.
  23926. I much prefered it the way they handled things. But, again they did not
  23927. discourage people from calling in the first place. They support all the
  23928. equipment they sell - period. I am thinking about selling LT equipment,
  23929. I am sounding like a salesman already.
  23930.  
  23931. -----Original Message-----
  23932. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  23933. Sent: Monday, October 18, 1999 7:29 AM
  23934.  
  23935.  
  23936. Thus spake Ed
  23937. >The ONLY reason Hold times are down is because everyone has stopped
  23938. >calling.  They get the 3rd degree about a support contract everytime
  23939. >and then even if they have a contract they ask if it's the right
  23940. >chassis for the contract and drill them if they are sure they don't
  23941. >have 20 chassis' and a contract for 5.
  23942.  
  23943. Yeah, that and they pulled in a bunch of people with virtually no
  23944. training or experience for first level tech support, I think so they
  23945. could at least have someone answer the phone.
  23946.  
  23947. If they're going to take this route...do what Livingston used to
  23948. do...have someone (more likely multiple someone's), *not* a tech support
  23949. person, answer the phone, take some information about the nature of the
  23950. problem and the urgency, and then do tech support on a callback basis.
  23951. Livingston did this for quite some time, and while non-urgent callbacks
  23952. could take up to 2 weeks to occur, urgent problems were handled
  23953. promptly, efficiently, and by an engineer that was well versed in the
  23954. equipment.  I would certainly not be averse to such a model of tech
  23955. support.  While I would *prefer* to have prompt, efficient, quality
  23956. handling of *all* tech support inquiries, I have to acknowledge that the
  23957. realities of the technical job market could preclude that possibility.
  23958.  
  23959. Regardless...I agree with you, Ed, here, in that the constant abuse that
  23960. customers receive concerning their support contracts is a significant
  23961. factor as well.
  23962. -- 
  23963. Jeff McAdams                            Email: jeffm@iglou.com
  23964. Head Network Administrator              Voice: (502) 966-3848
  23965. IgLou Internet Services                        (800) 436-4456
  23966.  
  23967. -
  23968.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23969.  with "unsubscribe usr-tc" in the body of the message.
  23970.  For information on digests or retrieving files and old messages send
  23971.  "help" to the same address.  Do not use quotes in your message.
  23972.  
  23973. -
  23974.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23975.  with "unsubscribe usr-tc" in the body of the message.
  23976.  For information on digests or retrieving files and old messages send
  23977.  "help" to the same address.  Do not use quotes in your message.
  23978.  
  23979.  
  23980. -------------------------------------------------------------------------------
  23981.  
  23982. From: CyberPort Montana <netboss@cyberport.net>
  23983. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  23984. Date: 18 Oct 1999 12:26:26 -0600
  23985.  
  23986. Actually you would be losing money.  Not only have you lost the use of the
  23987. money for 4+ years (time value), the actual value of the money has gone
  23988. down (inflation).
  23989.  
  23990.  
  23991. At 01:06 PM 10/18/1999 -0700, you wrote:
  23992. >
  23993. >This all means...if you had purchased 3Com stock in early to mid 1995,
  23994. >you would be breaking even at this point (3Com doesn't issue dividends,
  23995. >so you can't even count on dividends for gains here)
  23996.  
  23997.  
  23998. -
  23999.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24000.  with "unsubscribe usr-tc" in the body of the message.
  24001.  For information on digests or retrieving files and old messages send
  24002.  "help" to the same address.  Do not use quotes in your message.
  24003.  
  24004.  
  24005. -------------------------------------------------------------------------------
  24006.  
  24007. From: Dataheart <lists@dataheart.net>
  24008. Subject: (usr-tc) HiPer Config Guide
  24009. Date: 19 Oct 1999 04:27:32 +1000
  24010.  
  24011. Just a quicky.
  24012.  
  24013. does anyone know of any online config guides for the DSP cards.
  24014. they are E1 NIC's.
  24015.  
  24016. Thanks,
  24017. Aaron
  24018.  
  24019.  
  24020. -
  24021.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24022.  with "unsubscribe usr-tc" in the body of the message.
  24023.  For information on digests or retrieving files and old messages send
  24024.  "help" to the same address.  Do not use quotes in your message.
  24025.  
  24026.  
  24027. -------------------------------------------------------------------------------
  24028.  
  24029. From: Jeff Mcadams <jeffm@iglou.com>
  24030. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  24031. Date: 18 Oct 1999 14:36:31 -0400
  24032.  
  24033. Thus spake CyberPort Montana
  24034. >Actually you would be losing money.  Not only have you lost the use of the
  24035. >money for 4+ years (time value), the actual value of the money has gone
  24036. >down (inflation).
  24037.  
  24038. Well, yeah...true...I really didn't feel like digging out my Econ 101
  24039. and 102 though.  :)
  24040.  
  24041. >At 01:06 PM 10/18/1999 -0700, you wrote:
  24042. >>This all means...if you had purchased 3Com stock in early to mid 1995,
  24043. >>you would be breaking even at this point (3Com doesn't issue dividends,
  24044. >>so you can't even count on dividends for gains here)
  24045. -- 
  24046. Jeff McAdams                            Email: jeffm@iglou.com
  24047. Head Network Administrator              Voice: (502) 966-3848
  24048. IgLou Internet Services                        (800) 436-4456
  24049.  
  24050. -
  24051.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24052.  with "unsubscribe usr-tc" in the body of the message.
  24053.  For information on digests or retrieving files and old messages send
  24054.  "help" to the same address.  Do not use quotes in your message.
  24055.  
  24056.  
  24057. -------------------------------------------------------------------------------
  24058.  
  24059. From: "Mike McHenry" <mmchen@minn.net>
  24060. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  24061. Date: 18 Oct 1999 14:13:56 -0500
  24062.  
  24063. Out comes the calculator... :)
  24064.  
  24065. $5000 invested into 3com at it's lowest price point in 1995 (before the 2:1
  24066. split) would have bought you about 113 shares (44.375/share). You would be
  24067. holding 226 shares today because there was one 2:1 split at the end of 1995.
  24068. At today's market price of 27-11/16 your shares would be worth $6328.
  24069. Assuming you bought the shares in January of 1995 that would leave you with
  24070. a 5.07% return per year. That should be enough to cover inflation over that
  24071. time period but only by a few percentage points.
  24072.  
  24073. $5000 invested into Cisco at it's lowest price point in 1995 (before the 2:1
  24074. and 3:2 splits) would have bought you about 154 shares (32.50/share). You
  24075. would be holding 1386 shares today because there have been two 2:1 splits
  24076. and 2 3:2 splits since then. At today's market price of 65-7/8 your shares
  24077. would be worth about $92,000. Assuming you bought the shares in January of
  24078. 1995 that would leave you with a 84.38% return per year.
  24079.  
  24080. I think my math is correct, but you get the picture in any case :)
  24081.  
  24082. Mike McHenry
  24083.  Systems Administrator
  24084.  MinnNet Communications, Inc.
  24085.  
  24086. -----Original Message-----
  24087. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  24088. Sent: Monday, October 18, 1999 1:37 PM
  24089.  
  24090.  
  24091. Thus spake CyberPort Montana
  24092. >Actually you would be losing money.  Not only have you lost the use of the
  24093. >money for 4+ years (time value), the actual value of the money has gone
  24094. >down (inflation).
  24095.  
  24096. Well, yeah...true...I really didn't feel like digging out my Econ 101
  24097. and 102 though.  :)
  24098.  
  24099. >At 01:06 PM 10/18/1999 -0700, you wrote:
  24100. >>This all means...if you had purchased 3Com stock in early to mid 1995,
  24101. >>you would be breaking even at this point (3Com doesn't issue dividends,
  24102. >>so you can't even count on dividends for gains here)
  24103. --
  24104. Jeff McAdams                            Email: jeffm@iglou.com
  24105. Head Network Administrator              Voice: (502) 966-3848
  24106. IgLou Internet Services                        (800) 436-4456
  24107.  
  24108. -
  24109.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24110.  with "unsubscribe usr-tc" in the body of the message.
  24111.  For information on digests or retrieving files and old messages send
  24112.  "help" to the same address.  Do not use quotes in your message.
  24113.  
  24114.  
  24115. -
  24116.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24117.  with "unsubscribe usr-tc" in the body of the message.
  24118.  For information on digests or retrieving files and old messages send
  24119.  "help" to the same address.  Do not use quotes in your message.
  24120.  
  24121.  
  24122. -------------------------------------------------------------------------------
  24123.  
  24124. From: Brian <signal@shreve.net>
  24125. Subject: Re: (usr-tc) Ascend vs. 3Com
  24126. Date: 18 Oct 1999 16:07:22 -0500 (CDT)
  24127.  
  24128. On Mon, 18 Oct 1999, Ed wrote:
  24129.  
  24130. > Yes have seen it ourselves over and over.
  24131. > 
  24132. > BTW, reason he is having the problem with Quake probably has to do with MTU
  24133. > settings on the Ascend... or he has incorrect error control and thus his
  24134. > packets are resending. (correct me someone if I am incorrect)
  24135.  
  24136. I would expect the default MTU on the ascend to be the same as the
  24137. 3com.........I would also expect error control to be autonegotiated
  24138. correctly by either NAS.
  24139.  
  24140.  
  24141. > 
  24142. > Ed
  24143. > 
  24144. > ----- Original Message -----
  24145. > From: Ken Kirchner <kenk@shreve.net>
  24146. > To: <usr-tc@lists.xmission.com>
  24147. > Sent: Monday, October 18, 1999 1:34 AM
  24148. > Subject: (usr-tc) Ascend vs. 3Com
  24149. > 
  24150. > 
  24151. > 
  24152. > Well here is an illustration from a users e-mail to me:
  24153. > 
  24154. > "Ken, been connecting very nicely lately with that new number.  I've been
  24155. > connecting at 38.8 and 40.0!  :-)  Problem is when I play Quake I get the
  24156. > "phone jack" quite often, much more often than when I use the other
  24157. > number. I can browse the net and download files much better, but it is
  24158. > pretty useless with Quake.  What do you reckon the problem could be?"
  24159. > 
  24160. > Now for some of the pertinant details:
  24161. > 
  24162. > This customer has a USR 3Com modem.
  24163. > He used to dial into our TC gear ("other number").
  24164. > He is now dialing into our Max TNT ("new number").
  24165. > The best he ever got with TC was 28.8K.
  24166. > 
  24167. > Infer from this what you will.  I have details such as our HDM/ARC
  24168. > revisons as well as his FLASH/DSP dates/revisions if anyone cares.
  24169. > I am working with other cases (The v.90 X-files) who have similar
  24170. > experiences and will let you know if there's a pattern.  Tedious work, no
  24171. > wonder no one else has done it. :-P
  24172. > 
  24173. > -----
  24174. >                         .~.
  24175. >   Ken Kirchner          /V\       L   I   N   U   X
  24176. >   Asst SysAdmin        // \  > Don't fear the penguin <
  24177. >   ShreveNet, Inc.     /(   )\
  24178. >                        ^^-^^
  24179. > 
  24180. > 
  24181. > -
  24182. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24183. >  with "unsubscribe usr-tc" in the body of the message.
  24184. >  For information on digests or retrieving files and old messages send
  24185. >  "help" to the same address.  Do not use quotes in your message.
  24186. > 
  24187. > 
  24188. > 
  24189. > -
  24190. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24191. >  with "unsubscribe usr-tc" in the body of the message.
  24192. >  For information on digests or retrieving files and old messages send
  24193. >  "help" to the same address.  Do not use quotes in your message.
  24194. > 
  24195.  
  24196. Brian Feeny (BF304)     signal@shreve.net   
  24197. 318-222-2638 x 109    http://www.shreve.net/~signal      
  24198. Network Administrator   ShreveNet Inc. (ASN 11881)           
  24199.  
  24200.  
  24201. -
  24202.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24203.  with "unsubscribe usr-tc" in the body of the message.
  24204.  For information on digests or retrieving files and old messages send
  24205.  "help" to the same address.  Do not use quotes in your message.
  24206.  
  24207.  
  24208. -------------------------------------------------------------------------------
  24209.  
  24210. From: Jeff Mcadams <jeffm@iglou.com>
  24211. Subject: Re: (usr-tc) Ascend vs. 3Com
  24212. Date: 18 Oct 1999 17:15:47 -0400
  24213.  
  24214. Thus spake Brian
  24215. >On Mon, 18 Oct 1999, Ed wrote:
  24216. >> Yes have seen it ourselves over and over.
  24217.  
  24218. >> BTW, reason he is having the problem with Quake probably has to do
  24219. >> with MTU settings on the Ascend... or he has incorrect error control
  24220. >> and thus his packets are resending. (correct me someone if I am
  24221. >> incorrect)
  24222.  
  24223. >I would expect the default MTU on the ascend to be the same as the
  24224. >3com.........I would also expect error control to be autonegotiated
  24225. >correctly by either NAS.
  24226.  
  24227. And the MTU shouldn't matter for Quake and the like.  Quake and the like
  24228. tends to use very small packets, packets where the MTU on the link isn't
  24229. relevant.
  24230. -- 
  24231. Jeff McAdams                            Email: jeffm@iglou.com
  24232. Head Network Administrator              Voice: (502) 966-3848
  24233. IgLou Internet Services                        (800) 436-4456
  24234.  
  24235. -
  24236.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24237.  with "unsubscribe usr-tc" in the body of the message.
  24238.  For information on digests or retrieving files and old messages send
  24239.  "help" to the same address.  Do not use quotes in your message.
  24240.  
  24241.  
  24242. -------------------------------------------------------------------------------
  24243.  
  24244. From: das <das@gol.com>
  24245. Subject: Re: (usr-tc) 3com V90 Problems
  24246. Date: 19 Oct 1999 09:02:36 +0900
  24247.  
  24248. I would like a copy as well, please.
  24249. das@gol.com
  24250.  
  24251. das
  24252.  
  24253. farber@admin.f-tech.net (farber@admin.f-tech.net) spake:
  24254.  
  24255. > It's a perl script.  Not to accurate (3Com's off by one snmp errors) and
  24256. > my inability to write good perl code).
  24257. > 
  24258. > Give me an address and I send it to you.
  24259. > 
  24260. > Paul Farber
  24261. > Farber Technology
  24262. > farber@admin.f-tech.net
  24263. > Ph  570-628-5303
  24264. > Fax 570-628-5545
  24265. > 
  24266. > On Mon, 18 Oct 1999, K Mitchell wrote:
  24267. > 
  24268. > > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
  24269. > > >BINGO!  We have a winner.
  24270. > > >
  24271. > > >I have had a lot of good experiences with making a "Connection Page" that
  24272. > > >shows connection speeds lifted from the NMC card.  Most people hit that
  24273. > > >page after they log in and see what the DSP's say they are getting.
  24274. > > >Ususally they are happy to see that they are "in the green" even though
  24275. > > >the band is from 37K to 53K.
  24276. > > 
  24277. > > Care to share your mrtg.cfg entry for this?  :)
  24278. > > 
  24279. > > 
  24280. > > -- 
  24281. > > Kirk Mitchell-General Manager        mitch@keyconn.net
  24282. > > Keystone Connect                     Unlock Your World
  24283. > > Altoona, PA   814-941-5000      http://www.keyconn.net
  24284. > > 
  24285. > > 
  24286. > > -
  24287. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24288. > >  with "unsubscribe usr-tc" in the body of the message.
  24289. > >  For information on digests or retrieving files and old messages send
  24290. > >  "help" to the same address.  Do not use quotes in your message.
  24291. > > 
  24292. > 
  24293. > 
  24294. > -
  24295. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24296. >  with "unsubscribe usr-tc" in the body of the message.
  24297. >  For information on digests or retrieving files and old messages send
  24298. >  "help" to the same address.  Do not use quotes in your message.
  24299.  
  24300. -- 
  24301. ____________________________________________
  24302. Alex Substanley       Global OnLine Japan
  24303.                 Engineering Department
  24304. Das Man               TEL: 81-3-5334-1700
  24305. Systems Engineer      FAX: 81-3-5334-1711
  24306.   The Highest Quality Service, Bar None
  24307. ____________________________________________
  24308.  
  24309. -
  24310.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24311.  with "unsubscribe usr-tc" in the body of the message.
  24312.  For information on digests or retrieving files and old messages send
  24313.  "help" to the same address.  Do not use quotes in your message.
  24314.  
  24315.  
  24316. -------------------------------------------------------------------------------
  24317.  
  24318. From: "Ed" <ed@taylors.com>
  24319. Subject: Re: (usr-tc) Ascend vs. 3Com
  24320. Date: 18 Oct 1999 21:30:49 -0400
  24321.  
  24322. Jeff McAdams wrote:
  24323. "And the MTU shouldn't matter for Quake and the like.  Quake and the like
  24324. tends to use very small packets, packets where the MTU on the link isn't
  24325. relevant."
  24326.  
  24327. Not necessarily... if the packets are always larger then Quake would lag and
  24328. time out. Have the client manually set their MTU down to 576 and see what
  24329. the result is. I may be wrong but I have seen stranger things cause problems
  24330. on games such as Quake.
  24331.  
  24332. I know when USR had an issue with Quake that was one solution... we were
  24333. deeply involved in it. However until a code revision it wasn't completely
  24334. resolved. Think about it though... USR even cared about Quake and made an
  24335. issue of it and resolved it. 3com would laugh about an issue with gaming.
  24336. That shows how even the little things were important to USR.
  24337.  
  24338. We were PROUD to be a USR ISP! Used to rip all the other ISP's that used
  24339. other access servers... now we feel like they are ripping on us ;-(
  24340.  
  24341. Ed
  24342.  
  24343. ----- Original Message -----
  24344. Sent: Monday, October 18, 1999 5:15 PM
  24345.  
  24346.  
  24347. Thus spake Brian
  24348. >On Mon, 18 Oct 1999, Ed wrote:
  24349. >> Yes have seen it ourselves over and over.
  24350.  
  24351. >> BTW, reason he is having the problem with Quake probably has to do
  24352. >> with MTU settings on the Ascend... or he has incorrect error control
  24353. >> and thus his packets are resending. (correct me someone if I am
  24354. >> incorrect)
  24355.  
  24356. >I would expect the default MTU on the ascend to be the same as the
  24357. >3com.........I would also expect error control to be autonegotiated
  24358. >correctly by either NAS.
  24359.  
  24360. And the MTU shouldn't matter for Quake and the like.  Quake and the like
  24361. tends to use very small packets, packets where the MTU on the link isn't
  24362. relevant.
  24363. --
  24364. Jeff McAdams                            Email: jeffm@iglou.com
  24365. Head Network Administrator              Voice: (502) 966-3848
  24366. IgLou Internet Services                        (800) 436-4456
  24367.  
  24368. -
  24369.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24370.  with "unsubscribe usr-tc" in the body of the message.
  24371.  For information on digests or retrieving files and old messages send
  24372.  "help" to the same address.  Do not use quotes in your message.
  24373.  
  24374.  
  24375.  
  24376. -
  24377.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24378.  with "unsubscribe usr-tc" in the body of the message.
  24379.  For information on digests or retrieving files and old messages send
  24380.  "help" to the same address.  Do not use quotes in your message.
  24381.  
  24382.  
  24383. -------------------------------------------------------------------------------
  24384.  
  24385. From: "Marshall Morgan" <marshall@netdoor.com>
  24386. Subject: (usr-tc) Hung Modems/What to do?
  24387. Date: 18 Oct 1999 22:35:01 -0500
  24388.  
  24389. Much of the discussion over the past few days has been quite interesting, but
  24390. what are people doing with the modem+neighbor modem hung problem in the field?
  24391. We have many of our new DSPs doing this (2-4 DSPs running CT1 and PRI).  Also,
  24392. we have had DSPs on PRI's hang the d-channel or T1 carrier as well (maybe telco
  24393. here).
  24394.  
  24395. Running 2.0.81 HDM and 4.1.59-6 ARC code.
  24396.  
  24397. BTW: Anyone at 3Com going to take us up on that offer for a meeting? Gordon
  24398. Biersch (http://www.gordonbiersch.com/) was fun, but what about a serious
  24399. discussion first!
  24400.  
  24401. Thank you,
  24402.  
  24403. Marshall Morgan
  24404. President
  24405.  
  24406. Internet Doorway, Inc (aka NETDOOR)
  24407. http://www.netdoor.com
  24408.  
  24409. 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  24410.  
  24411.  
  24412. -
  24413.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24414.  with "unsubscribe usr-tc" in the body of the message.
  24415.  For information on digests or retrieving files and old messages send
  24416.  "help" to the same address.  Do not use quotes in your message.
  24417.  
  24418.  
  24419. -------------------------------------------------------------------------------
  24420.  
  24421. From: Greg Coffey <greg@coffey.com>
  24422. Subject: Re: (usr-tc) Hung Modems/What to do?
  24423. Date: 18 Oct 1999 21:42:06 -0600
  24424.  
  24425. I just wanted to chip in that we have not seen the hung twins as described
  24426. here.  We only started buying the DSP's this summer so maybe we got some of
  24427. the newer ones.  We are running CT1's exclusively.  
  24428.  
  24429.  
  24430.  
  24431. At 10:35 PM 10/18/99 -0500, you wrote:
  24432. >Much of the discussion over the past few days has been quite interesting, but
  24433. >what are people doing with the modem+neighbor modem hung problem in the
  24434. field?
  24435. >We have many of our new DSPs doing this (2-4 DSPs running CT1 and PRI).
  24436. Also,
  24437. >we have had DSPs on PRI's hang the d-channel or T1 carrier as well (maybe
  24438. telco
  24439. >here).
  24440. >
  24441. >Running 2.0.81 HDM and 4.1.59-6 ARC code.
  24442. >
  24443. >BTW: Anyone at 3Com going to take us up on that offer for a meeting? Gordon
  24444. >Biersch (http://www.gordonbiersch.com/) was fun, but what about a serious
  24445. >discussion first!
  24446. >
  24447. >Thank you,
  24448. >
  24449. >Marshall Morgan
  24450. >President
  24451. >
  24452. >Internet Doorway, Inc (aka NETDOOR)
  24453. >http://www.netdoor.com
  24454. >
  24455. >601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  24456. >
  24457. >
  24458. >-
  24459. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24460. > with "unsubscribe usr-tc" in the body of the message.
  24461. > For information on digests or retrieving files and old messages send
  24462. > "help" to the same address.  Do not use quotes in your message.
  24463. >
  24464. >
  24465.  
  24466. Thanks,
  24467.  
  24468. Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  24469. =====================================================================
  24470. 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  24471.  
  24472.  
  24473. -
  24474.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24475.  with "unsubscribe usr-tc" in the body of the message.
  24476.  For information on digests or retrieving files and old messages send
  24477.  "help" to the same address.  Do not use quotes in your message.
  24478.  
  24479.  
  24480. -------------------------------------------------------------------------------
  24481.  
  24482. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  24483. Subject: Re: (usr-tc) Ascend vs. 3Com
  24484. Date: 19 Oct 1999 00:29:15 -0400 (EDT)
  24485.  
  24486.  
  24487. On Mon, 18 Oct 1999, Ed wrote:
  24488.  
  24489. > Not necessarily... if the packets are always larger then Quake would lag and
  24490. > time out. Have the client manually set their MTU down to 576 and see what
  24491. > the result is. I may be wrong but I have seen stranger things cause problems
  24492. > on games such as Quake.
  24493.  
  24494. Tell the quake (I'm assuming actually quake2 here) player to type
  24495. 'netgraph 1' at his console when he's on his favorite gameserver and
  24496. compare it between the two chassis. Specifically, compare the sizes of
  24497. the green bars (latency), and the number of red bars (dropped packets).
  24498.  
  24499.  
  24500.  
  24501. -
  24502.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24503.  with "unsubscribe usr-tc" in the body of the message.
  24504.  For information on digests or retrieving files and old messages send
  24505.  "help" to the same address.  Do not use quotes in your message.
  24506.  
  24507.  
  24508. -------------------------------------------------------------------------------
  24509.  
  24510. From: Brian <signal@shreve.net>
  24511. Subject: Re: (usr-tc) Hung Modems/What to do?
  24512. Date: 18 Oct 1999 23:40:00 -0500 (CDT)
  24513.  
  24514.  
  24515.  
  24516. If you are talking about the situation where a modem goes out and so does
  24517. the one next to it, that is supposedly addressed in a service release.
  24518.  
  24519.  
  24520. On Mon, 18 Oct 1999, Marshall Morgan wrote:
  24521.  
  24522. > Much of the discussion over the past few days has been quite interesting, but
  24523. > what are people doing with the modem+neighbor modem hung problem in the field?
  24524. > We have many of our new DSPs doing this (2-4 DSPs running CT1 and PRI).  Also,
  24525. > we have had DSPs on PRI's hang the d-channel or T1 carrier as well (maybe telco
  24526. > here).
  24527. > 
  24528. > Running 2.0.81 HDM and 4.1.59-6 ARC code.
  24529. > 
  24530. > BTW: Anyone at 3Com going to take us up on that offer for a meeting? Gordon
  24531. > Biersch (http://www.gordonbiersch.com/) was fun, but what about a serious
  24532. > discussion first!
  24533. > 
  24534. > Thank you,
  24535. > 
  24536. > Marshall Morgan
  24537. > President
  24538. > 
  24539. > Internet Doorway, Inc (aka NETDOOR)
  24540. > http://www.netdoor.com
  24541. > 
  24542. > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
  24543. > 
  24544. > 
  24545. > -
  24546. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24547. >  with "unsubscribe usr-tc" in the body of the message.
  24548. >  For information on digests or retrieving files and old messages send
  24549. >  "help" to the same address.  Do not use quotes in your message.
  24550. > 
  24551.  
  24552. Brian Feeny (BF304)     signal@shreve.net   
  24553. 318-222-2638 x 109    http://www.shreve.net/~signal      
  24554. Network Administrator   ShreveNet Inc. (ASN 11881)           
  24555.  
  24556.  
  24557. -
  24558.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24559.  with "unsubscribe usr-tc" in the body of the message.
  24560.  For information on digests or retrieving files and old messages send
  24561.  "help" to the same address.  Do not use quotes in your message.
  24562.  
  24563.  
  24564. -------------------------------------------------------------------------------
  24565.  
  24566. From: Jeff Mcadams <jeffm@iglou.com>
  24567. Subject: Re: (usr-tc) Ascend vs. 3Com
  24568. Date: 19 Oct 1999 09:23:47 -0400
  24569.  
  24570. Thus spake Ed
  24571. >Jeff McAdams wrote:
  24572. >"And the MTU shouldn't matter for Quake and the like.  Quake and the
  24573. >like tends to use very small packets, packets where the MTU on the link
  24574. >isn't relevant."
  24575.  
  24576. >Not necessarily... if the packets are always larger then Quake would
  24577. >lag and time out. Have the client manually set their MTU down to 576
  24578. >and see what the result is. I may be wrong but I have seen stranger
  24579. >things cause problems on games such as Quake.
  24580.  
  24581. Well...if there's other stuff on the link (someone doing an ftp
  24582. transfer) sure, cranking down the MTU will help (I suspect this falls
  24583. into the too little, too late department though).  But if you're only
  24584. running Quake on the link, I doubt dropping the MTU to 576 is going to
  24585. help any...I've never seen Quake send any packets of that size or
  24586. larger, so the MTU is totally irrelevant in that situation.
  24587.  
  24588. >I know when USR had an issue with Quake that was one solution... we
  24589. >were deeply involved in it. 
  24590.  
  24591. I never saw any change in performance in Quake by changing the MTU...we
  24592. tried it when people were suggesting it, but didn't do anything here.
  24593. Like I said, if it was Quake traffic mixed in with other stuff, dropping
  24594. the MTU helped, but the performance would generally be so sucky in that
  24595. situation that nothing would make game play satisfactory...dropping the
  24596. MTU only made it to be not quite so terribly painful.  :)
  24597.  
  24598. >However until a code revision it wasn't completely resolved. Think
  24599. >about it though... USR even cared about Quake and made an issue of it
  24600. >and resolved it. 3com would laugh about an issue with gaming.  That
  24601. >shows how even the little things were important to USR.
  24602.  
  24603. Actually, on the NETServers, "Quake Lag" was *never* resolved fully.  It
  24604. got better, but it was never to the point that I would consider
  24605. acceptable.
  24606.  
  24607. >We were PROUD to be a USR ISP! Used to rip all the other ISP's that
  24608. >used other access servers... now we feel like they are ripping on us
  24609. >;-(
  24610.  
  24611. Agreed there.
  24612. -- 
  24613. Jeff McAdams                            Email: jeffm@iglou.com
  24614. Head Network Administrator              Voice: (502) 966-3848
  24615. IgLou Internet Services                        (800) 436-4456
  24616.  
  24617. -
  24618.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24619.  with "unsubscribe usr-tc" in the body of the message.
  24620.  For information on digests or retrieving files and old messages send
  24621.  "help" to the same address.  Do not use quotes in your message.
  24622.  
  24623.  
  24624. -------------------------------------------------------------------------------
  24625.  
  24626. From: Scott Trautman <scottt@corp.gdinet.com>
  24627. Subject: (usr-tc) Performance monitoring/ANI information from Dual T1 card running 
  24628. Date: 19 Oct 1999 08:32:13 -0500
  24629.  
  24630. This is a multi-part message in MIME format.
  24631.  
  24632. ------=_NextPart_000_0096_01BF1A0C.54480900
  24633. Content-Type: multipart/alternative;
  24634.     boundary="----=_NextPart_000_0092_01BF1A0C.542F9F00"
  24635.  
  24636.  
  24637. ------=_NextPart_000_0092_01BF1A0C.542F9F00
  24638. Content-Type: text/plain;
  24639.     charset="iso-8859-1"
  24640. Content-Transfer-Encoding: 7bit
  24641.  
  24642. I'm guessing the answer is "can't get there from here" unless it's modem
  24643. calls.
  24644. I'm interested in the calling number info that is coming in on the PRI.
  24645.  
  24646. I can view a modem call and get the calling number info, but not on ISDN,
  24647. which
  24648. is all I'm running. Trying performance monitor on the T1, nothing there
  24649. like it.
  24650.  
  24651. Using a Netserver with das Munich daughterboard und dual T1, works really
  24652. quite well. Might be a mighty cheap way for some of you to do ISDN only
  24653. traffic for dedicated customers. You can do the Dual PRI& Netserver in
  24654. same chassis as with a HiperARC & DSP's. Neat.
  24655.  
  24656. I'm also wondering whether I can get via radius accounting that "calling
  24657. number" from a Netserver/or is it NMC???
  24658.  
  24659. Anybody be able to shed some light?
  24660.  
  24661. SMT
  24662.  
  24663. Scott M. Trautman               800-482-4638
  24664. Global Dialog Internet          608-240-4638,4637fax
  24665. 2810 Crossroads, STE LL2         scott@gdinet.com
  24666. Madison WI 53718                    http://www.gdinet.com
  24667.  
  24668. ------=_NextPart_000_0092_01BF1A0C.542F9F00
  24669. Content-Type: text/html;
  24670.     charset="iso-8859-1"
  24671. Content-Transfer-Encoding: quoted-printable
  24672.  
  24673. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
  24674. <HTML>
  24675. <HEAD>
  24676. <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
  24677. charset=3Diso-8859-1">
  24678. <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
  24679. 5.5.2163.0">
  24680. <TITLE></TITLE>
  24681. </HEAD>
  24682. <BODY>
  24683.  
  24684. <P><FONT SIZE=3D2>I'm guessing the answer is "can't get there from =
  24685. here" unless it's modem calls.</FONT>
  24686. <BR><FONT SIZE=3D2>I'm interested in the calling number info that is =
  24687. coming in on the PRI.</FONT>
  24688. </P>
  24689.  
  24690. <P><FONT SIZE=3D2>I can view a modem call and get the calling number =
  24691. info, but not on ISDN, which</FONT>
  24692. <BR><FONT SIZE=3D2>is all I'm running. Trying performance monitor on the =
  24693. T1, nothing there like it.</FONT>
  24694. </P>
  24695.  
  24696. <P><FONT SIZE=3D2>Using a Netserver with das Munich daughterboard und =
  24697. dual T1, works really quite well. Might be a mighty cheap way for some =
  24698. of you to do ISDN only traffic for dedicated customers. You can do the =
  24699. Dual PRI& Netserver in same chassis as with a HiperARC & DSP's. =
  24700. Neat.</FONT></P>
  24701.  
  24702. <P><FONT SIZE=3D2>I'm also wondering whether I can get via radius =
  24703. accounting that "calling number" from a Netserver/or is it =
  24704. NMC???</FONT>
  24705. </P>
  24706.  
  24707. <P><FONT SIZE=3D2>Anybody be able to shed some light?</FONT>
  24708. </P>
  24709.  
  24710. <P><FONT SIZE=3D2>SMT</FONT>
  24711. </P>
  24712.  
  24713. <P><FONT SIZE=3D2>Scott M. =
  24714. Trautman           =
  24715. ;    800-482-4638</FONT>
  24716. <BR><FONT SIZE=3D2>Global Dialog =
  24717. Internet          =
  24718. 608-240-4638,4637fax</FONT>
  24719. <BR><FONT SIZE=3D2>2810 Crossroads, STE =
  24720. LL2         =
  24721. scott@gdinet.com</FONT>
  24722. <BR><FONT SIZE=3D2>Madison WI =
  24723. 53718           &n=
  24724. bsp;        <A =
  24725. HREF=3D"http://www.gdinet.com" =
  24726. TARGET=3D"_blank">http://www.gdinet.com</A></FONT>
  24727. </P>
  24728.  
  24729. </BODY>
  24730. </HTML>
  24731. ------=_NextPart_000_0092_01BF1A0C.542F9F00--
  24732.  
  24733. ------=_NextPart_000_0096_01BF1A0C.54480900
  24734. Content-Type: application/x-pkcs7-signature;
  24735.     name="smime.p7s"
  24736. Content-Transfer-Encoding: base64
  24737. Content-Disposition: attachment;
  24738.     filename="smime.p7s"
  24739.  
  24740. MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH9DCCAy4w
  24741. ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
  24742. MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
  24743. eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla
  24744. MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
  24745. d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
  24746. IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
  24747. dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN
  24748. ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H
  24749. COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q
  24750. JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g
  24751. BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z
  24752. aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB
  24753. AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe
  24754. wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS
  24755. xVhqwY0DPOvDzQWikK5uMIIEvjCCBCegAwIBAgIQVrF/4WLazvWal7NsEYMnmjANBgkqhkiG9w0B
  24756. AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
  24757. IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
  24758. LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
  24759. aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTAyMDgwMDAwMDBa
  24760. Fw0wMDAyMDgyMzU5NTlaMIIBGjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
  24761. cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
  24762. eS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90
  24763. IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwg
  24764. U2VydmljZTEZMBcGA1UEAxQQU2NvdHQgTSBUcmF1dG1hbjElMCMGCSqGSIb3DQEJARYWc2NvdHR0
  24765. QGNvcnAuZ2RpbmV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDqNu5NtXl7PPIAQBb8Tu6P
  24766. zp3jxD69hR+0k+dIFqMUkvdsko/dlJT1sgHYAPoumkdUI3Jp9TAHx9AqpHMkvZcXAgMBAAGjggGS
  24767. MIIBjjAJBgNVHRMEAjAAMIGvBgNVHSAEgacwgDCABgtghkgBhvhFAQcBATCAMCgGCCsGAQUFBwIB
  24768. FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24s
  24769. IEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRk
  24770. LiAoYyk5NyBWZXJpU2lnbgAAAAAAADARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgME
  24771. eBZ2ZDQ2NTJiZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0
  24772. YmM5NzAxNzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxM2FlNmVmNGQ2MTE0OTlhYTNiYzQ0Zjlm
  24773. M2VhNDUwZDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
  24774. Y3JsMA0GCSqGSIb3DQEBBAUAA4GBAJ2Ht+ZlyKQaudGmCV67bq4QT1JQ8QyQruxMDwQOuLpCP9jS
  24775. KKfEWXzKlPtfTUUN+LJ/Ua2nE3GU9a0ckTF0Qg8nQy0JMsVqr0T0qRlMZUw1kHziHoFim6Kj0Ms1
  24776. 9N6R93uTMbU6KSGS+pwwu1R9JPRVJwHBDT8G6Cx/blkQsfgTMYIC9zCCAvMCAQEwgeEwgcwxFzAV
  24777. BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYw
  24778. RAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixM
  24779. SUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
  24780. c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFaxf+Fi2s71mpezbBGDJ5owCQYFKw4DAhoF
  24781. AKCCAawwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMDE5MTMz
  24782. MTI0WjAjBgkqhkiG9w0BCQQxFgQUO2+0ACrpd7Lt8OzFvsa7WAql7GswWAYJKoZIhvcNAQkPMUsw
  24783. STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
  24784. Kw4DAhowCgYIKoZIhvcNAgUwgfIGCSsGAQQBgjcQBDGB5DCB4TCBzDEXMBUGA1UEChMOVmVyaVNp
  24785. Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52
  24786. ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
  24787. SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv
  24788. bmEgTm90IFZhbGlkYXRlZAIQVrF/4WLazvWal7NsEYMnmjANBgkqhkiG9w0BAQEFAARAz7/LLHqQ
  24789. mpqVFOOov8pEkdW8U4djZwJjal2AtZKl5jpPGh/lPMyrk1Q3Ednspf7oihwCKWWMMf00aDBUrmvq
  24790. FgAAAAAAAA==
  24791.  
  24792. ------=_NextPart_000_0096_01BF1A0C.54480900--
  24793.  
  24794.  
  24795. -
  24796.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24797.  with "unsubscribe usr-tc" in the body of the message.
  24798.  For information on digests or retrieving files and old messages send
  24799.  "help" to the same address.  Do not use quotes in your message.
  24800.  
  24801.  
  24802. -------------------------------------------------------------------------------
  24803.  
  24804. From: Kevin Benton <s1kevin@tims.net>
  24805. Subject: Re: (usr-tc) 3com V90 Problems
  24806. Date: 19 Oct 1999 11:45:21 -0400 (EDT)
  24807.  
  24808. On Sun, 17 Oct 1999, Brian wrote:
  24809.  
  24810. > I wonder how much of it is pschological vs. real.  For example, ever post
  24811. > to your customers about how you made an upgrade to something like your
  24812. > mail server, and then they start calling tech support and say things like
  24813. > "ever since you all upgraded the server, I can't connect fast".  I often
  24814. > thought, if you told the customers all of them, that you were upgrading
  24815. > your modem code tonight, and wanted their feedback the following day,and
  24816. > you really didn't touch anything, I am betting 25% would say they connect
  24817. > faster, 25% would say they connect slower, and 50% would notice no
  24818. > change.........i'm telling you I believe in this :)
  24819.  
  24820. Duh!  That's why telco's don't tell you when they're doing major local
  24821. switch changes like they did to us at one of our pops and that in the
  24822. process, they wound up changing options at the same time which were not
  24823. certified with our system on initial installation.  It took us more than a
  24824. month to get them to admit they lied to us and changed options without
  24825. telling us which impacted our ability to handle calls properly.  If they
  24826. tell people things are going to be changed, you can bet that anyone who
  24827. suspects the telco will be reminded to call them and gripe about something
  24828. even if it's not related to the change.
  24829.  
  24830. Kevin
  24831.  
  24832. > Its like those customers who's modems report the DTE speed of 115,200, and
  24833. > when you fix them up, it only reports say 28800, yet they swear the
  24834. > connection is not as fast anymore.
  24835. > 
  24836. > Well if a customer visually sees a v90 connect, and its a terrible
  24837. > connection, would they claim that connection was faster than a really
  24838. > solid v.34 connect?
  24839. > 
  24840. > What I am getting at, is raw data and numbers are the best, rather than
  24841. > the more subjective data of customers opinions about their connections.
  24842. > 
  24843. > 
  24844. > 
  24845. > On Sun, 17 Oct 1999, Greg Coffey wrote:
  24846. > 
  24847. > > I've never had a customer call the v90 connection "unreliable" to the
  24848. > > competition's Ascends.  The feedback that I've got from customers is that
  24849. > > they get better throughput and are not dissatified with the connects to the
  24850. > > Ascends.  They are using USR modems to dial and they connect consistently
  24851. > > with Ascends at v90 rates, usually 40something.  They never connect at v90
  24852. > > to our TC racks from the same location, using the same PC, software, phone
  24853. > > lines, config, etc.  I don't know the exact cause, they seem to be on the
  24854. > > fringe of the v90 availability area.  3Com described it to me as a "bug" in
  24855. > > the Ascend server firmware.  All I know is that it has cost me customers in
  24856. > > the past and continues to be an issue that I have no answer for when it
  24857. > > comes up.  I have gone to great lengths to explain to them what I have
  24858. > > learned many months ago from 3Com but I don't think they believe me.  Would
  24859. > > you believe that 3Com/USR modems connect better to the competition than
  24860. > > their own racks?  Thankfully, it is a somewhat rare occurance and I only
  24861. > > have to explain once or twice a month.  I really don't know for sure to
  24862. > > what extent it really occurs.  I do know that I have lost customers over
  24863. > > this and it continues to be an issue.  I am getting tired of no news to
  24864. > > update the situation though.  I'm also afraid that it will harm our
  24865. > > reputation if this continues as is.  Word of mouth is still our best
  24866. > > marketing and this will grow in significance with time.  
  24867. > > 
  24868. > > 
  24869. > > 
  24870. > > At 11:15 AM 10/17/99 -0700, you wrote:
  24871. > > >Ed writes...
  24872. > > >> . . .
  24873. > > >>Let him know you are having the 3com V90 problems and you want it resolved.
  24874. > > >>I think they believe it is a rare scenerio not effecting very many people.
  24875. > > >>We told them it was more widespread than they knew... and that if 3com
  24876. > > >>client modems connect to Ascends they should darn well connect to a 3com TC.
  24877. > > >>No ifs ands or buts.
  24878. > > >
  24879. > > >If modem X connects at an unreliable V.90 speed to an Ascend, and 
  24880. > > >connects at a reliable v.34 rate to a 3com, that's a problem?
  24881. > > >
  24882. > > >
  24883. > > >-- 
  24884. > > >Aaron Nabil
  24885. > > >
  24886. > > >-
  24887. > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24888. > > > with "unsubscribe usr-tc" in the body of the message.
  24889. > > > For information on digests or retrieving files and old messages send
  24890. > > > "help" to the same address.  Do not use quotes in your message.
  24891. > > >
  24892. > > >
  24893. > > 
  24894. > > Thanks,
  24895. > > 
  24896. > > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  24897. > > =====================================================================
  24898. > > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  24899. > > 
  24900. > > 
  24901. > > -
  24902. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24903. > >  with "unsubscribe usr-tc" in the body of the message.
  24904. > >  For information on digests or retrieving files and old messages send
  24905. > >  "help" to the same address.  Do not use quotes in your message.
  24906. > > 
  24907. > 
  24908. > -----------------------------------------------------
  24909. > Brian Feeny (BF304)     signal@shreve.net   
  24910. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  24911. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  24912. > 
  24913. > 
  24914. > -
  24915. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24916. >  with "unsubscribe usr-tc" in the body of the message.
  24917. >  For information on digests or retrieving files and old messages send
  24918. >  "help" to the same address.  Do not use quotes in your message.
  24919. > 
  24920.  
  24921. E-Mail:  s1kevin@tims.net
  24922. Web:     http://users.sota-oh.com/~s1kevin/
  24923. Unsolicited advertisements processing fee: $50 subject to change without notice
  24924.  
  24925.  
  24926. -
  24927.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24928.  with "unsubscribe usr-tc" in the body of the message.
  24929.  For information on digests or retrieving files and old messages send
  24930.  "help" to the same address.  Do not use quotes in your message.
  24931.  
  24932.  
  24933. -------------------------------------------------------------------------------
  24934.  
  24935. From: <dciresi@defunct.ae.usr.com>
  24936. Subject: Re: (usr-tc) Performance monitoring/ANI information from Dual T1
  24937. Date: 19 Oct 1999 12:17:48 -0500 (CDT)
  24938.  
  24939. Scott,
  24940.  
  24941. If you are terminating ISDN on the Munich daughterboard, you will not be
  24942. able to view the Called/Calling-Number-info.  This is specifically located
  24943. on the modem.  This information should be in the Netserver RADIUS
  24944. requests, however.
  24945.  
  24946. Dominic
  24947.  
  24948. On Tue, 19 Oct 1999, Scott Trautman wrote:
  24949.  
  24950. > I'm guessing the answer is "can't get there from here" unless it's modem
  24951. > calls.
  24952. > I'm interested in the calling number info that is coming in on the PRI.
  24953. > 
  24954. > I can view a modem call and get the calling number info, but not on ISDN,
  24955. > which
  24956. > is all I'm running. Trying performance monitor on the T1, nothing there
  24957. > like it.
  24958. > 
  24959. > Using a Netserver with das Munich daughterboard und dual T1, works really
  24960. > quite well. Might be a mighty cheap way for some of you to do ISDN only
  24961. > traffic for dedicated customers. You can do the Dual PRI& Netserver in
  24962. > same chassis as with a HiperARC & DSP's. Neat.
  24963. > 
  24964. > I'm also wondering whether I can get via radius accounting that "calling
  24965. > number" from a Netserver/or is it NMC???
  24966. > 
  24967. > Anybody be able to shed some light?
  24968. > 
  24969. > SMT
  24970. > 
  24971. > Scott M. Trautman               800-482-4638
  24972. > Global Dialog Internet          608-240-4638,4637fax
  24973. > 2810 Crossroads, STE LL2         scott@gdinet.com
  24974. > Madison WI 53718                    http://www.gdinet.com
  24975. > 
  24976.  
  24977.  
  24978. -
  24979.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24980.  with "unsubscribe usr-tc" in the body of the message.
  24981.  For information on digests or retrieving files and old messages send
  24982.  "help" to the same address.  Do not use quotes in your message.
  24983.  
  24984.  
  24985. -------------------------------------------------------------------------------
  24986.  
  24987. From: andrew smith <smitha@rciol.com>
  24988. Subject: (usr-tc) CT1 and Remote Pop
  24989. Date: 19 Oct 1999 12:30:05 -0500 (CDT)
  24990.  
  24991.  
  24992. This is slightly off-topic:
  24993.  
  24994. I am looking to provide dial-up service to few rural towns outside
  24995. of our local dialing area. These are *small* rural communities, 20, 30,
  24996. and 60 miles away from our main office. I seriously doubt any of these
  24997. communities will ever need more than 96 dial-up lines, and many will start
  24998. out with just 24-48 lines.
  24999.  
  25000. Because of their size, I don't particularly want to put a Total Control 
  25001. Chassis in a closet somewhere. I envision doing the following:
  25002.  
  25003. 1. Having CT1s longhauled back to our main office so everything can be in
  25004. a centralized location. Each of these towns are in US Worst's area except
  25005. for one, so I don't see any type of foreign exchange fee between telcos.
  25006. The one independent telco was going to charge us a small foreign exchange
  25007. fee to link with US Worst. I know I will have to pay mileage fees on all
  25008. the lines.
  25009.  
  25010. My question is, how distance sensitive is a CT1? Has anyone else done
  25011. this? Would a CT1 running 60 miles between telcos offer quality 56k access? 
  25012. What other technical issues, problems, or financial issues am I overlooking?
  25013.  
  25014. -
  25015.     andrew
  25016.  
  25017.  
  25018. -
  25019.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25020.  with "unsubscribe usr-tc" in the body of the message.
  25021.  For information on digests or retrieving files and old messages send
  25022.  "help" to the same address.  Do not use quotes in your message.
  25023.  
  25024.  
  25025. -------------------------------------------------------------------------------
  25026.  
  25027. From: Scott Trautman <scottt@corp.gdinet.com>
  25028. Subject: RE: (usr-tc) Performance monitoring/ANI information from Dual T1 
  25029. Date: 19 Oct 1999 12:43:19 -0500
  25030.  
  25031. Beauty. That's what I thought. Now to confirm I have the right radius
  25032. attributes in there.
  25033.  
  25034. -----Original Message-----
  25035. Sent: Tuesday, October 19, 1999 12:18 PM
  25036. Cc: 'usr-tc@lists.xmission.com'
  25037. T1 card running PRI
  25038.  
  25039.  
  25040. Scott,
  25041.  
  25042. If you are terminating ISDN on the Munich daughterboard, you will not be
  25043. able to view the Called/Calling-Number-info.  This is specifically located
  25044. on the modem.  This information should be in the Netserver RADIUS
  25045. requests, however.
  25046.  
  25047. Dominic
  25048.  
  25049. On Tue, 19 Oct 1999, Scott Trautman wrote:
  25050.  
  25051. > I'm guessing the answer is "can't get there from here" unless it's modem
  25052. > calls.
  25053. > I'm interested in the calling number info that is coming in on the PRI.
  25054. > 
  25055. > I can view a modem call and get the calling number info, but not on ISDN,
  25056. > which
  25057. > is all I'm running. Trying performance monitor on the T1, nothing there
  25058. > like it.
  25059. > 
  25060. > Using a Netserver with das Munich daughterboard und dual T1, works really
  25061. > quite well. Might be a mighty cheap way for some of you to do ISDN only
  25062. > traffic for dedicated customers. You can do the Dual PRI& Netserver in
  25063. > same chassis as with a HiperARC & DSP's. Neat.
  25064. > 
  25065. > I'm also wondering whether I can get via radius accounting that "calling
  25066. > number" from a Netserver/or is it NMC???
  25067. > 
  25068. > Anybody be able to shed some light?
  25069. > 
  25070. > SMT
  25071. > 
  25072. > Scott M. Trautman               800-482-4638
  25073. > Global Dialog Internet          608-240-4638,4637fax
  25074. > 2810 Crossroads, STE LL2         scott@gdinet.com
  25075. > Madison WI 53718                    http://www.gdinet.com
  25076. > 
  25077.  
  25078.  
  25079. -
  25080.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25081.  with "unsubscribe usr-tc" in the body of the message.
  25082.  For information on digests or retrieving files and old messages send
  25083.  "help" to the same address.  Do not use quotes in your message.
  25084.  
  25085. -
  25086.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25087.  with "unsubscribe usr-tc" in the body of the message.
  25088.  For information on digests or retrieving files and old messages send
  25089.  "help" to the same address.  Do not use quotes in your message.
  25090.  
  25091.  
  25092. -------------------------------------------------------------------------------
  25093.  
  25094. From: "Mike Wilker" <mikew@LL.NET>
  25095. Subject: Re: (usr-tc) CT1 and Remote Pop
  25096. Date: 19 Oct 1999 12:48:51 -0500
  25097.  
  25098. Generally if you can go to one of those towns and dial into your POP long
  25099. distance with a decent 56k connection, you should get the same results with
  25100. a backhauled CT1.  They are for the most part going over the same circuites
  25101. between the towns.
  25102.  
  25103.  
  25104. ----- Original Message -----
  25105. Sent: Tuesday, October 19, 1999 12:30 PM
  25106.  
  25107.  
  25108. >
  25109. > This is slightly off-topic:
  25110. >
  25111. > I am looking to provide dial-up service to few rural towns outside
  25112. > of our local dialing area. These are *small* rural communities, 20, 30,
  25113. > and 60 miles away from our main office. I seriously doubt any of these
  25114. > communities will ever need more than 96 dial-up lines, and many will start
  25115. > out with just 24-48 lines.
  25116. >
  25117. > Because of their size, I don't particularly want to put a Total Control
  25118. > Chassis in a closet somewhere. I envision doing the following:
  25119. >
  25120. > 1. Having CT1s longhauled back to our main office so everything can be in
  25121. > a centralized location. Each of these towns are in US Worst's area except
  25122. > for one, so I don't see any type of foreign exchange fee between telcos.
  25123. > The one independent telco was going to charge us a small foreign exchange
  25124. > fee to link with US Worst. I know I will have to pay mileage fees on all
  25125. > the lines.
  25126. >
  25127. > My question is, how distance sensitive is a CT1? Has anyone else done
  25128. > this? Would a CT1 running 60 miles between telcos offer quality 56k
  25129. access?
  25130. > What other technical issues, problems, or financial issues am I
  25131. overlooking?
  25132. >
  25133. > -
  25134. > andrew
  25135. >
  25136. >
  25137. > -
  25138. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25139. >  with "unsubscribe usr-tc" in the body of the message.
  25140. >  For information on digests or retrieving files and old messages send
  25141. >  "help" to the same address.  Do not use quotes in your message.
  25142.  
  25143.  
  25144. -
  25145.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25146.  with "unsubscribe usr-tc" in the body of the message.
  25147.  For information on digests or retrieving files and old messages send
  25148.  "help" to the same address.  Do not use quotes in your message.
  25149.  
  25150.  
  25151. -------------------------------------------------------------------------------
  25152.  
  25153. From: Kevin Benton <s1kevin@tims.net>
  25154. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  25155. Date: 19 Oct 1999 14:27:51 -0400 (EDT)
  25156.  
  25157. On Sun, 17 Oct 1999, Scot Desort wrote:
  25158.  
  25159. > I was thinking -- while the DSP and Hiper code controls almost all of the
  25160. > cards' functions, is it possible that the physical hardware on the DSP cards
  25161. > is playing a role in these problems? My cards are all less than 3 months
  25162. > old, and I've NEVER experienced the modem-pair hanging problem that plagues
  25163. > many here. I also have very, very few connect issues. Could it be the
  25164. > HARDWARE revisions on the DSP cards are also effecting performance and
  25165. > stability?
  25166. > 
  25167. > Just a thought...
  25168.  
  25169. Who ever said secretaries don't ask good technical questions once in a
  25170. while?!?  Oh, come on, even a blind pig finds an acorn once in a
  25171. while...  :) j/k :) Good idea, Scot.
  25172.  
  25173. Kevin
  25174.  
  25175.  
  25176. -
  25177.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25178.  with "unsubscribe usr-tc" in the body of the message.
  25179.  For information on digests or retrieving files and old messages send
  25180.  "help" to the same address.  Do not use quotes in your message.
  25181.  
  25182.  
  25183. -------------------------------------------------------------------------------
  25184.  
  25185. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  25186. Subject: RE: (usr-tc) Performance monitoring/ANI information from Dual T1 
  25187. Date: 19 Oct 1999 15:41:16 -0300
  25188.  
  25189.  
  25190. The attribute name I use is Calling-Station-ID.  I can't remember if I had
  25191. to add that to the dictionary or if it was in there already (I think it was
  25192. in there but...).  If you don't have it, let me know and I'll look it up.
  25193.  
  25194. Matthew
  25195.  
  25196. > -----Original Message-----
  25197. > From: Scott Trautman [mailto:scottt@corp.gdinet.com]
  25198. > Sent: Tuesday, October 19, 1999 2:43 PM
  25199. > To: 'usr-tc@lists.xmission.com'
  25200. > Subject: RE: (usr-tc) Performance monitoring/ANI information from Dual
  25201. > T1 card running PRI
  25202. > 
  25203. > 
  25204. > Beauty. That's what I thought. Now to confirm I have the right radius
  25205. > attributes in there.
  25206. > 
  25207. > -----Original Message-----
  25208. > From: dciresi@defunct.ae.usr.com [mailto:dciresi@defunct.ae.usr.com]
  25209. > Sent: Tuesday, October 19, 1999 12:18 PM
  25210. > To: Scott Trautman
  25211. > Cc: 'usr-tc@lists.xmission.com'
  25212. > Subject: Re: (usr-tc) Performance monitoring/ANI information from Dual
  25213. > T1 card running PRI
  25214. > 
  25215. > 
  25216. > Scott,
  25217. > 
  25218. > If you are terminating ISDN on the Munich daughterboard, you 
  25219. > will not be
  25220. > able to view the Called/Calling-Number-info.  This is 
  25221. > specifically located
  25222. > on the modem.  This information should be in the Netserver RADIUS
  25223. > requests, however.
  25224. > 
  25225. > Dominic
  25226. > 
  25227. > On Tue, 19 Oct 1999, Scott Trautman wrote:
  25228. > 
  25229. > > I'm guessing the answer is "can't get there from here" 
  25230. > unless it's modem
  25231. > > calls.
  25232. > > I'm interested in the calling number info that is coming in 
  25233. > on the PRI.
  25234. > > 
  25235. > > I can view a modem call and get the calling number info, 
  25236. > but not on ISDN,
  25237. > > which
  25238. > > is all I'm running. Trying performance monitor on the T1, 
  25239. > nothing there
  25240. > > like it.
  25241. > > 
  25242. > > Using a Netserver with das Munich daughterboard und dual 
  25243. > T1, works really
  25244. > > quite well. Might be a mighty cheap way for some of you to 
  25245. > do ISDN only
  25246. > > traffic for dedicated customers. You can do the Dual PRI& 
  25247. > Netserver in
  25248. > > same chassis as with a HiperARC & DSP's. Neat.
  25249. > > 
  25250. > > I'm also wondering whether I can get via radius accounting 
  25251. > that "calling
  25252. > > number" from a Netserver/or is it NMC???
  25253. > > 
  25254. > > Anybody be able to shed some light?
  25255. > > 
  25256. > > SMT
  25257. > > 
  25258. > > Scott M. Trautman               800-482-4638
  25259. > > Global Dialog Internet          608-240-4638,4637fax
  25260. > > 2810 Crossroads, STE LL2         scott@gdinet.com
  25261. > > Madison WI 53718                    http://www.gdinet.com
  25262. > > 
  25263. > 
  25264. > 
  25265. > -
  25266. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25267. >  with "unsubscribe usr-tc" in the body of the message.
  25268. >  For information on digests or retrieving files and old messages send
  25269. >  "help" to the same address.  Do not use quotes in your message.
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25280.  with "unsubscribe usr-tc" in the body of the message.
  25281.  For information on digests or retrieving files and old messages send
  25282.  "help" to the same address.  Do not use quotes in your message.
  25283.  
  25284.  
  25285. -------------------------------------------------------------------------------
  25286.  
  25287. From: Kevin Benton <s1kevin@tims.net>
  25288. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  25289. Date: 19 Oct 1999 14:50:21 -0400 (EDT)
  25290.  
  25291. On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
  25292.  
  25293. > I too have had the same experience with the 3COM. I am disatisfied with the
  25294. > company's attitude toward customers. It seems to have an "avoid them or bill
  25295. > them" philosophy. I did not buy the 3COM for the support, although it is
  25296. > important. LT has the best support because they have their goals set right.
  25297. > They want everyone using a LT Product to get good support. They are not
  25298. > concerned about contracts, etc. You would think the price we pay for support
  25299. > would give us incredible support. I have yet to even get the latest codes
  25300. > directly from 3COM for the hassle I have to go through. I had an LT Support
  25301. > guy help me with mine. But, the 3COM seems to be a better box than the PM3.
  25302. > And, I have not personally tried the ASCEND products for Access Servers,
  25303. > only routers. I know that pre-LT involvement, ASCEND was harder to get
  25304. > support from than 3COM. So, I was never excited about looking that way.
  25305. > Maybe I should try them out for a month.
  25306.  
  25307. Okay, time for someone to come up to bat for 3Com.  There's one thing I
  25308. can say that I'm very happy about with 3Com - even though the NetServer
  25309. has been disco'd, they still support it (albeit minimally), and getting to
  25310. talk to a good support person is sometimes difficult, I have never had a
  25311. problem getting support for product which we've had problems with from
  25312. 3Com.  I've also never seen 3Com completely discontinue a platform without
  25313. already having something existing in place to replace it.  Granted, the
  25314. HARC was not a 100% feature replacement for the NetServer card, but at
  25315. least it still worked with *all* the old equipment.  Some of the software
  25316. issues were not quite complete when the NetServer manufacturing was
  25317. discontinued, but the OS was fairly stable and worked enough that we are
  25318. still using them in some of our smallest digital locations.  Let's face
  25319. it, USR (now 3Com) did a good job getting themselves into the chassis
  25320. market by borrowing the wheel from someone else while they invented their
  25321. own better version.  Lucent has all but shot themselves in the foot by
  25322. killing PM2's and PM3's completely.  Based on that fact, we have made a
  25323. firm decision that we will *not* be buying any Lucent equipment so we
  25324. don't get shot in the foot by Lucent's knee jerk decisions.
  25325.  
  25326. In business, growth or death is inevitable.  If you're not doing one,
  25327. you're doing the other.  There is no such thing as stagnant business.
  25328. 3Com has chosen to grow.  The problem with growing is that sometimes it
  25329. means getting rid of excess weight.  The NetServer was never intended to
  25330. be a long-term solution for TC platforms.
  25331.  
  25332. I don't know much about Lucent PM's except that due to their own handling
  25333. of their own product, we have made a decision not to buy Lucent because
  25334. they are building product which is not forward compatible.
  25335.  
  25336. Kevin Benton
  25337. SOTA Technologies
  25338.  
  25339. E-Mail:  s1kevin@tims.net
  25340. Web:     http://users.sota-oh.com/~s1kevin/
  25341. Unsolicited advertisements processing fee: $50 subject to change without notice
  25342.  
  25343.  
  25344. -
  25345.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25346.  with "unsubscribe usr-tc" in the body of the message.
  25347.  For information on digests or retrieving files and old messages send
  25348.  "help" to the same address.  Do not use quotes in your message.
  25349.  
  25350.  
  25351. -------------------------------------------------------------------------------
  25352.  
  25353. From: "Jason A. Nunnelley" <interests@linkfast.net>
  25354. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  25355. Date: 19 Oct 1999 14:22:35 -0700
  25356.  
  25357. Kevin,
  25358.     I don't think we disagree on anything here. This is why I still have 3COM.
  25359. It would be nice if they would borrow a little Livingston mentality toward
  25360. support.
  25361. Hmmm, maybe support isn't valuable when the product works. The problem is,
  25362. the 3COM
  25363. stuff is MORE complicated than Livingston stuff - not simpler. I just like
  25364. the idea
  25365. that a company wants to give upgrades and support information to anyone
  25366. using the
  25367. product. That makes sense. Raise the proce an extra grand or 2, and make it
  25368. simpler
  25369. to use for my understanding of the systems. And, don't give me the third
  25370. degree each
  25371. and every time I call for help. I have received much more help from Solunet
  25372. than
  25373. 3COM - yet I paid 3COM for support. Does that make sense?
  25374.     Other than that - I like my 3COM box fine.
  25375.  
  25376. Jason
  25377.  
  25378. -----Original Message-----
  25379. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Kevin Benton
  25380. Sent: Tuesday, October 19, 1999 11:50 AM
  25381.  
  25382.  
  25383. On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
  25384.  
  25385. > I too have had the same experience with the 3COM. I am disatisfied with
  25386. the
  25387. > company's attitude toward customers. It seems to have an "avoid them or
  25388. bill
  25389. > them" philosophy. I did not buy the 3COM for the support, although it is
  25390. > important. LT has the best support because they have their goals set
  25391. right.
  25392. > They want everyone using a LT Product to get good support. They are not
  25393. > concerned about contracts, etc. You would think the price we pay for
  25394. support
  25395. > would give us incredible support. I have yet to even get the latest codes
  25396. > directly from 3COM for the hassle I have to go through. I had an LT
  25397. Support
  25398. > guy help me with mine. But, the 3COM seems to be a better box than the
  25399. PM3.
  25400. > And, I have not personally tried the ASCEND products for Access Servers,
  25401. > only routers. I know that pre-LT involvement, ASCEND was harder to get
  25402. > support from than 3COM. So, I was never excited about looking that way.
  25403. > Maybe I should try them out for a month.
  25404.  
  25405. Okay, time for someone to come up to bat for 3Com.  There's one thing I
  25406. can say that I'm very happy about with 3Com - even though the NetServer
  25407. has been disco'd, they still support it (albeit minimally), and getting to
  25408. talk to a good support person is sometimes difficult, I have never had a
  25409. problem getting support for product which we've had problems with from
  25410. 3Com.  I've also never seen 3Com completely discontinue a platform without
  25411. already having something existing in place to replace it.  Granted, the
  25412. HARC was not a 100% feature replacement for the NetServer card, but at
  25413. least it still worked with *all* the old equipment.  Some of the software
  25414. issues were not quite complete when the NetServer manufacturing was
  25415. discontinued, but the OS was fairly stable and worked enough that we are
  25416. still using them in some of our smallest digital locations.  Let's face
  25417. it, USR (now 3Com) did a good job getting themselves into the chassis
  25418. market by borrowing the wheel from someone else while they invented their
  25419. own better version.  Lucent has all but shot themselves in the foot by
  25420. killing PM2's and PM3's completely.  Based on that fact, we have made a
  25421. firm decision that we will *not* be buying any Lucent equipment so we
  25422. don't get shot in the foot by Lucent's knee jerk decisions.
  25423.  
  25424. In business, growth or death is inevitable.  If you're not doing one,
  25425. you're doing the other.  There is no such thing as stagnant business.
  25426. 3Com has chosen to grow.  The problem with growing is that sometimes it
  25427. means getting rid of excess weight.  The NetServer was never intended to
  25428. be a long-term solution for TC platforms.
  25429.  
  25430. I don't know much about Lucent PM's except that due to their own handling
  25431. of their own product, we have made a decision not to buy Lucent because
  25432. they are building product which is not forward compatible.
  25433.  
  25434. Kevin Benton
  25435. SOTA Technologies
  25436.  
  25437. E-Mail:  s1kevin@tims.net
  25438. Web:     http://users.sota-oh.com/~s1kevin/
  25439. Unsolicited advertisements processing fee: $50 subject to change without
  25440. notice
  25441.  
  25442.  
  25443. -
  25444.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25445.  with "unsubscribe usr-tc" in the body of the message.
  25446.  For information on digests or retrieving files and old messages send
  25447.  "help" to the same address.  Do not use quotes in your message.
  25448.  
  25449.  
  25450. -
  25451.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25452.  with "unsubscribe usr-tc" in the body of the message.
  25453.  For information on digests or retrieving files and old messages send
  25454.  "help" to the same address.  Do not use quotes in your message.
  25455.  
  25456.  
  25457. -------------------------------------------------------------------------------
  25458.  
  25459. From: Tim Wolfe <tim@clipper.net>
  25460. Subject: (usr-tc) Radius attribute
  25461. Date: 19 Oct 1999 16:07:05 -0700 (PDT)
  25462.  
  25463. Is there a radius attribute that can be passed to the TC that will limit a
  25464. users session time?  Similar to Livingston's Session-Timeout (which doesn't
  25465. seem to do anything on the TC...)
  25466.  
  25467. Thanks,
  25468.  
  25469. -- Tim
  25470.  
  25471. * Timothy M. Wolfe, Chief Network Engineer       *
  25472. * ClipperNet Corporation / It's a wireless world *
  25473. * tim@clipper.net 800.338.2629 x 402             *
  25474. * Sufficient for today = Inadequate for tomorrow *
  25475.  
  25476.  
  25477. -
  25478.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25479.  with "unsubscribe usr-tc" in the body of the message.
  25480.  For information on digests or retrieving files and old messages send
  25481.  "help" to the same address.  Do not use quotes in your message.
  25482.  
  25483.  
  25484. -------------------------------------------------------------------------------
  25485.  
  25486. From: Jeff Mcadams <jeffm@iglou.com>
  25487. Subject: Re: (usr-tc) Radius attribute
  25488. Date: 19 Oct 1999 19:20:27 -0400
  25489.  
  25490. Thus spake Tim Wolfe
  25491. >Is there a radius attribute that can be passed to the TC that will limit a
  25492. >users session time?  Similar to Livingston's Session-Timeout (which doesn't
  25493. >seem to do anything on the TC...)
  25494.  
  25495. s/Livingston's/IETF's/
  25496.  
  25497. Session-Timeout is a RADIUS standard attribute.  Works like a champ for
  25498. us on our HiPer Arcs (and did as well on NETServers).
  25499. -- 
  25500. Jeff McAdams                            Email: jeffm@iglou.com
  25501. Head Network Administrator              Voice: (502) 966-3848
  25502. IgLou Internet Services                        (800) 436-4456
  25503.  
  25504. -
  25505.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25506.  with "unsubscribe usr-tc" in the body of the message.
  25507.  For information on digests or retrieving files and old messages send
  25508.  "help" to the same address.  Do not use quotes in your message.
  25509.  
  25510.  
  25511. -------------------------------------------------------------------------------
  25512.  
  25513. From:  <farber@admin.f-tech.net>
  25514. Subject: (usr-tc) Cistron checkrad.pl script
  25515. Date: 19 Oct 1999 21:14:08 -0400 (EDT)
  25516.  
  25517. Hello fellow Total Control victems.
  25518.  
  25519. My name is Paul... and I own an ARC chassis
  25520.  
  25521. <group>
  25522.  
  25523. Hi Paul
  25524.  
  25525. Anyways...  for everone out there using the most exellent Cistron Radius
  25526. 1.5.4.3 daemon there is a bit of a problem with the checkrad.pl script
  25527. that checks the simeltaneous-use on the ARC vi SNMP.
  25528.  
  25529. When the radius acct packet comes in it has the port number prefixed with
  25530. an S (S10, S1010) and the code did not strip out that letter before it
  25531. built the OID to snmpget from the ARC.
  25532.  
  25533. So basically is was never checking the arc to see if they were already
  25534. logged in.
  25535.  
  25536. So.. in all its glory... I give my fix... cut,paste,enjoy.
  25537.  
  25538. sub usrhiper_snmp {
  25539.  
  25540.         # Somebody please verify????
  25541.  
  25542.         # remove leading S from port #
  25543.         $_=$ARGV[2];
  25544.         s/S//;
  25545.         my($slot) = $_;
  25546.         my($oidext) = $slot + 1256;
  25547.  
  25548.         my ($login);
  25549.  
  25550.         $login = snmpget($ARGV[1], "public", "$usrm.4.10.1.1.18.$oidext");
  25551.         print LOG " snmpget info: $login\n" if ($debug);
  25552.  
  25553.         #($login) = /^.*\"([^"]+)".*$/;
  25554.  
  25555.         print LOG "  user at port [S]$slot: $login\n" if ($debug);
  25556.  
  25557.         ($login eq $ARGV[3]) ? 1 : 0;
  25558. }
  25559.  
  25560. Wait... no warranties, not refunds, send free beer and pizza to the
  25561. address below (anything other than Coors light will be proptly returned to
  25562. sender).
  25563.  
  25564. Paul Farber
  25565. Farber Technology
  25566. farber@admin.f-tech.net
  25567. Ph  570-628-5303
  25568. Fax 570-628-5545
  25569.  
  25570.  
  25571. -
  25572.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25573.  with "unsubscribe usr-tc" in the body of the message.
  25574.  For information on digests or retrieving files and old messages send
  25575.  "help" to the same address.  Do not use quotes in your message.
  25576.  
  25577.  
  25578. -------------------------------------------------------------------------------
  25579.  
  25580. From: "Ed" <ed@taylors.com>
  25581. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  25582. Date: 19 Oct 1999 21:18:22 -0400
  25583.  
  25584. I don't think 3com needs anyone to "BAT" for them... (from what I've seen
  25585. they all get enough batting practice on all the trade in equipment)
  25586.  
  25587. Sorry but 3com has MANY issues and they need resolved, not complimented on
  25588. what they do OK on. I don't know about you but we purchased our equipment
  25589. and therefore have the right to b**** when things are not working properly
  25590. or they have issues. Also if we don't talk about these issues why would 3com
  25591. go above and beyond to fix them?... not to mention vent our frustrations to
  25592. others that are experiencing the same and possibly run across a resolution.
  25593.  
  25594.  
  25595. Ed
  25596.  
  25597. ----- Original Message -----
  25598. Sent: Tuesday, October 19, 1999 2:50 PM
  25599.  
  25600.  
  25601. On Sun, 17 Oct 1999, Jason A. Nunnelley wrote:
  25602.  
  25603. > I too have had the same experience with the 3COM. I am disatisfied with
  25604. the
  25605. > company's attitude toward customers. It seems to have an "avoid them or
  25606. bill
  25607. > them" philosophy. I did not buy the 3COM for the support, although it is
  25608. > important. LT has the best support because they have their goals set
  25609. right.
  25610. > They want everyone using a LT Product to get good support. They are not
  25611. > concerned about contracts, etc. You would think the price we pay for
  25612. support
  25613. > would give us incredible support. I have yet to even get the latest codes
  25614. > directly from 3COM for the hassle I have to go through. I had an LT
  25615. Support
  25616. > guy help me with mine. But, the 3COM seems to be a better box than the
  25617. PM3.
  25618. > And, I have not personally tried the ASCEND products for Access Servers,
  25619. > only routers. I know that pre-LT involvement, ASCEND was harder to get
  25620. > support from than 3COM. So, I was never excited about looking that way.
  25621. > Maybe I should try them out for a month.
  25622.  
  25623. Okay, time for someone to come up to bat for 3Com.  There's one thing I
  25624. can say that I'm very happy about with 3Com - even though the NetServer
  25625. has been disco'd, they still support it (albeit minimally), and getting to
  25626. talk to a good support person is sometimes difficult, I have never had a
  25627. problem getting support for product which we've had problems with from
  25628. 3Com.  I've also never seen 3Com completely discontinue a platform without
  25629. already having something existing in place to replace it.  Granted, the
  25630. HARC was not a 100% feature replacement for the NetServer card, but at
  25631. least it still worked with *all* the old equipment.  Some of the software
  25632. issues were not quite complete when the NetServer manufacturing was
  25633. discontinued, but the OS was fairly stable and worked enough that we are
  25634. still using them in some of our smallest digital locations.  Let's face
  25635. it, USR (now 3Com) did a good job getting themselves into the chassis
  25636. market by borrowing the wheel from someone else while they invented their
  25637. own better version.  Lucent has all but shot themselves in the foot by
  25638. killing PM2's and PM3's completely.  Based on that fact, we have made a
  25639. firm decision that we will *not* be buying any Lucent equipment so we
  25640. don't get shot in the foot by Lucent's knee jerk decisions.
  25641.  
  25642. In business, growth or death is inevitable.  If you're not doing one,
  25643. you're doing the other.  There is no such thing as stagnant business.
  25644. 3Com has chosen to grow.  The problem with growing is that sometimes it
  25645. means getting rid of excess weight.  The NetServer was never intended to
  25646. be a long-term solution for TC platforms.
  25647.  
  25648. I don't know much about Lucent PM's except that due to their own handling
  25649. of their own product, we have made a decision not to buy Lucent because
  25650. they are building product which is not forward compatible.
  25651.  
  25652. Kevin Benton
  25653. SOTA Technologies
  25654.  
  25655. E-Mail:  s1kevin@tims.net
  25656. Web:     http://users.sota-oh.com/~s1kevin/
  25657. Unsolicited advertisements processing fee: $50 subject to change without
  25658. notice
  25659.  
  25660.  
  25661. -
  25662.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25663.  with "unsubscribe usr-tc" in the body of the message.
  25664.  For information on digests or retrieving files and old messages send
  25665.  "help" to the same address.  Do not use quotes in your message.
  25666.  
  25667.  
  25668.  
  25669. -
  25670.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25671.  with "unsubscribe usr-tc" in the body of the message.
  25672.  For information on digests or retrieving files and old messages send
  25673.  "help" to the same address.  Do not use quotes in your message.
  25674.  
  25675.  
  25676. -------------------------------------------------------------------------------
  25677.  
  25678. From: "Ed" <ed@taylors.com>
  25679. Subject: (usr-tc) 3com Radius Session Limiting
  25680. Date: 19 Oct 1999 21:25:00 -0400
  25681.  
  25682. We have had a problem with limiting multiple logins since upgrading to 6.0.9
  25683. Radius... recently upgraded to 6.0.83 and it still seems to be broken.
  25684.  
  25685. If we enable accounting our logs are over 100MB a day (we have 15,000+
  25686. users) Anyone have a solution to this? We need session limiting without the
  25687. HUGE logs. Only need to log for specific DNIS or a Certain Chassis for
  25688. measured rate service.
  25689.  
  25690. Ed
  25691.  
  25692.  
  25693. -
  25694.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25695.  with "unsubscribe usr-tc" in the body of the message.
  25696.  For information on digests or retrieving files and old messages send
  25697.  "help" to the same address.  Do not use quotes in your message.
  25698.  
  25699.  
  25700. -------------------------------------------------------------------------------
  25701.  
  25702. From: Blake Fithen <fithen@NetworksPlus.com>
  25703. Subject: RE: (usr-tc) Hung Modems/What to do?
  25704. Date: 19 Oct 1999 21:22:31 -0500
  25705.  
  25706. is that 1.2.37?
  25707.  
  25708. blake
  25709.  
  25710. > -----Original Message-----
  25711. > From: Brian [mailto:signal@shreve.net]
  25712. > Sent: Monday, October 18, 1999 11:40 PM
  25713. > To: usr-tc@lists.xmission.com
  25714. > Subject: Re: (usr-tc) Hung Modems/What to do?
  25715. > 
  25716. > 
  25717. > 
  25718. > 
  25719. > If you are talking about the situation where a modem goes out 
  25720. > and so does
  25721. > the one next to it, that is supposedly addressed in a service release.
  25722. > 
  25723. > 
  25724. > On Mon, 18 Oct 1999, Marshall Morgan wrote:
  25725. > 
  25726. > > Much of the discussion over the past few days has been 
  25727. > quite interesting, but
  25728. > > what are people doing with the modem+neighbor modem hung 
  25729. > problem in the field?
  25730. > > We have many of our new DSPs doing this (2-4 DSPs running 
  25731. > CT1 and PRI).  Also,
  25732. > > we have had DSPs on PRI's hang the d-channel or T1 carrier 
  25733. > as well (maybe telco
  25734. > > here).
  25735. > > 
  25736. > > Running 2.0.81 HDM and 4.1.59-6 ARC code.
  25737. > > 
  25738. > > BTW: Anyone at 3Com going to take us up on that offer for a 
  25739. > meeting? Gordon
  25740. > > Biersch (http://www.gordonbiersch.com/) was fun, but what 
  25741. > about a serious
  25742. > > discussion first!
  25743. > > 
  25744. > > Thank you,
  25745. > > 
  25746. > > Marshall Morgan
  25747. > > President
  25748. > > 
  25749. > > Internet Doorway, Inc (aka NETDOOR)
  25750. > > http://www.netdoor.com
  25751. > > 
  25752. > > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | 
  25753. > Fax 601.969.3838
  25754. > > 
  25755. > > 
  25756. > > -
  25757. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25758. > >  with "unsubscribe usr-tc" in the body of the message.
  25759. > >  For information on digests or retrieving files and old 
  25760. > messages send
  25761. > >  "help" to the same address.  Do not use quotes in your message.
  25762. > > 
  25763. > 
  25764. > -----------------------------------------------------
  25765. > Brian Feeny (BF304)     signal@shreve.net   
  25766. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  25767. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  25768. > 
  25769. > 
  25770. > -
  25771. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25772. >  with "unsubscribe usr-tc" in the body of the message.
  25773. >  For information on digests or retrieving files and old messages send
  25774. >  "help" to the same address.  Do not use quotes in your message.
  25775. > 
  25776.  
  25777. -
  25778.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25779.  with "unsubscribe usr-tc" in the body of the message.
  25780.  For information on digests or retrieving files and old messages send
  25781.  "help" to the same address.  Do not use quotes in your message.
  25782.  
  25783.  
  25784. -------------------------------------------------------------------------------
  25785.  
  25786. From: Dataheart <lists@dataheart.net>
  25787. Subject: (usr-tc) NMC NAC troubles + Passwords
  25788. Date: 20 Oct 1999 21:12:25 +1000
  25789.  
  25790. Howdy,
  25791.  
  25792. 1. For my NMC I have a High Speed WAN/ Ethernet NIC, which has the
  25793. console at the top then 2 v.35 then the 10BaseT at the bottom the seller
  25794. told me that they were pulled from a working system, they mush have been
  25795. used for Netservers because thats where the jumper was set to when they
  25796. arrived.
  25797. So I changed the jumper from NAC to NMC then inserted the NMC and it
  25798. powers up with the Hub Status light red, the rn/fl light flashing
  25799. between red and green and USR written on the 4 character display.
  25800.  
  25801. I know the NMC works I have had it working in another rack.
  25802.  
  25803. is there anything special I have to do when changing the High Speed
  25804. WAN/Ethernet NIC from a netserver to a NMC. New code or something.
  25805. Also when this is happening I get nothing on the console
  25806.  
  25807. 2. I have a NMC with a password on the console. is there any way to
  25808. erase this password.
  25809.  
  25810. Thank you all,
  25811. Aaron
  25812.  
  25813.  
  25814. -
  25815.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25816.  with "unsubscribe usr-tc" in the body of the message.
  25817.  For information on digests or retrieving files and old messages send
  25818.  "help" to the same address.  Do not use quotes in your message.
  25819.  
  25820.  
  25821. -------------------------------------------------------------------------------
  25822.  
  25823. From: Jeff Mcadams <jeffm@iglou.com>
  25824. Subject: Re: (usr-tc) NMC NAC troubles + Passwords
  25825. Date: 20 Oct 1999 07:57:56 -0400
  25826.  
  25827. Thus spake Dataheart
  25828. >2. I have a NMC with a password on the console. is there any way to
  25829. >erase this password.
  25830.  
  25831. The console password is (I believe) your community string(s).  If you
  25832. know the read-write community string for that NMC, put that in for the
  25833. password and that should get you access if I remember correctly.
  25834. -- 
  25835. Jeff McAdams                            Email: jeffm@iglou.com
  25836. Head Network Administrator              Voice: (502) 966-3848
  25837. IgLou Internet Services                        (800) 436-4456
  25838.  
  25839. -
  25840.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25841.  with "unsubscribe usr-tc" in the body of the message.
  25842.  For information on digests or retrieving files and old messages send
  25843.  "help" to the same address.  Do not use quotes in your message.
  25844.  
  25845.  
  25846. -------------------------------------------------------------------------------
  25847.  
  25848. From: "Steve Valiunas" <Steve_Valiunas@mw.3com.com>
  25849. Subject: Re: (usr-tc) NMC NAC troubles + Passwords
  25850. Date: 20 Oct 1999 07:50:42 -0500
  25851.  
  25852.  
  25853.  
  25854. You won't be able to use the dual v.35 nics behind an NMC-  You might get the
  25855. console up but I doubt if you'll ever get it to talk on the ethernet port.
  25856. The Passwords are the community strings.  They can be disabled after you get in
  25857. with a menu option.  If you can't get past the password then try flipping
  25858. dipSwitch #6 up, that should bypass them.
  25859.   The red/green LED means that the NMC didn't see a network connection when it
  25860. booted up.
  25861.  
  25862. Steve
  25863.  
  25864.  
  25865.  
  25866.  
  25867. Dataheart <lists@dataheart.net> on 10/20/99 06:12:25 AM
  25868.  
  25869. Please respond to usr-tc@lists.xmission.com
  25870.  
  25871. Sent by:  Dataheart <lists@dataheart.net>
  25872.  
  25873.  
  25874. cc:    (Steve Valiunas/MW/US/3Com)
  25875.  
  25876.  
  25877.  
  25878.  
  25879. Howdy,
  25880.  
  25881. 1. For my NMC I have a High Speed WAN/ Ethernet NIC, which has the
  25882. console at the top then 2 v.35 then the 10BaseT at the bottom the seller
  25883. told me that they were pulled from a working system, they mush have been
  25884. used for Netservers because thats where the jumper was set to when they
  25885. arrived.
  25886. So I changed the jumper from NAC to NMC then inserted the NMC and it
  25887. powers up with the Hub Status light red, the rn/fl light flashing
  25888. between red and green and USR written on the 4 character display.
  25889.  
  25890. I know the NMC works I have had it working in another rack.
  25891.  
  25892. is there anything special I have to do when changing the High Speed
  25893. WAN/Ethernet NIC from a netserver to a NMC. New code or something.
  25894. Also when this is happening I get nothing on the console
  25895.  
  25896. 2. I have a NMC with a password on the console. is there any way to
  25897. erase this password.
  25898.  
  25899. Thank you all,
  25900. Aaron
  25901.  
  25902.  
  25903. -
  25904.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25905.  with "unsubscribe usr-tc" in the body of the message.
  25906.  For information on digests or retrieving files and old messages send
  25907.  "help" to the same address.  Do not use quotes in your message.
  25908.  
  25909.  
  25910.  
  25911.  
  25912.  
  25913. -
  25914.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25915.  with "unsubscribe usr-tc" in the body of the message.
  25916.  For information on digests or retrieving files and old messages send
  25917.  "help" to the same address.  Do not use quotes in your message.
  25918.  
  25919.  
  25920. -------------------------------------------------------------------------------
  25921.  
  25922. From: Robert von Bismarck <rvb@petrel.ch>
  25923. Subject: RE: (usr-tc) NMC NAC troubles + Passwords
  25924. Date: 20 Oct 1999 16:39:10 +0200
  25925.  
  25926.     Password = read-write SNMP community string, if you enter the
  25927. read-only string, you will be able to get into your NMC but you won't be
  25928. able to modify anything ;-)
  25929.  
  25930.     To erase it go in the NMC console, select 1. Configuration and 14.
  25931. PASSWORD Screen Enable/Disable then select 2. Disable.
  25932.     Then save the config to NVRAM.
  25933.  
  25934.     Robert
  25935.  
  25936.  
  25937. > 2. I have a NMC with a password on the console. is there any way to
  25938. > erase this password.
  25939. > 
  25940. > Thank you all,
  25941. > Aaron
  25942. > 
  25943. > 
  25944. > -
  25945. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25946. >  with "unsubscribe usr-tc" in the body of the message.
  25947. >  For information on digests or retrieving files and old messages send
  25948. >  "help" to the same address.  Do not use quotes in your message.
  25949.  
  25950. -
  25951.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25952.  with "unsubscribe usr-tc" in the body of the message.
  25953.  For information on digests or retrieving files and old messages send
  25954.  "help" to the same address.  Do not use quotes in your message.
  25955.  
  25956.  
  25957. -------------------------------------------------------------------------------
  25958.  
  25959. From: Greg Coffey <greg@coffey.com>
  25960. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?) 
  25961. Date: 20 Oct 1999 08:30:21 -0600
  25962.  
  25963. Do you have a conclusion on this yet?  Does changing these settings have 
  25964. any impact?
  25965.  
  25966.  
  25967. At 04:46 AM 10/7/99 -0700, you wrote:
  25968.  
  25969.  
  25970. >I call into our Max's and measured the level they were sending.  Only
  25971. >-14dbm, much lower power, more what I was expecting.  Telnet in
  25972. >and check to see what they are set to, -13dbm, another off by one, but
  25973. >this time in the opposite direction!
  25974. >
  25975. >Here's a summary:
  25976. >                         Configured for          Actually sends
  25977. >USR HiperDSP            -11dbm                  -10dbm
  25978. >Ascend Max              -13dbm                  -14dbm
  25979. >
  25980. >I don't have any scripts in place that monitor failure ratios, but
  25981. >if someone does I'd be interested if they could set half their modems
  25982. >to -15dbm (for an output of -14dbm) and see what effect that has.
  25983. >
  25984. >
  25985. >--
  25986. >Aaron Nabil
  25987.  
  25988.  
  25989. Thanks, Greg Coffey                     <gcoffey@vcn.com>
  25990. Visionary Communications V 307-234-5443 F 307-234-5446
  25991. 100 N. Center, Casper, WY  82601         www.vcn.com
  25992.  
  25993. -
  25994.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25995.  with "unsubscribe usr-tc" in the body of the message.
  25996.  For information on digests or retrieving files and old messages send
  25997.  "help" to the same address.  Do not use quotes in your message.
  25998.  
  25999.  
  26000. -------------------------------------------------------------------------------
  26001.  
  26002. From: Brian <signal@shreve.net>
  26003. Subject: (usr-tc) Telco cluster fsck
  26004. Date: 20 Oct 1999 10:38:12 -0500 (CDT)
  26005.  
  26006.  
  26007. Battling with telco still over problematic CT1's in a remote pop.  I
  26008. found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
  26009. pull trigger) instead of TRUNK SIDE.  Below is the email I sent them on
  26010. how to provision the lines.........is their anything in it that would
  26011. indicate I was asking for trunk side instead of line side service, because
  26012. I know they are going to throw in my face "you didn't ask for TRUNK side
  26013. specifically", so I am hoping that the provisioning info below would only
  26014. be valid for trunk side service.  
  26015.  
  26016. I sent them:
  26017.  
  26018. 1. Line Coding:
  26019.     B8ZS        *
  26020.     AMI
  26021.  
  26022. 2. Framing:
  26023.     ESF        *
  26024.     SF
  26025.  
  26026. 3. Trunk type:
  26027.     E&M II
  26028.     loop start
  26029.     ground start     *
  26030.  
  26031. 4. Trunk Start:
  26032.     wink
  26033.     immediate
  26034.     dial tone    *
  26035.  
  26036. 5. Dial-In address Acknowledgment Wink
  26037.     enabled
  26038.     disabled    *
  26039.  
  26040. 6. T1 Tone type (signalling)
  26041.     mf
  26042.     dtmf        *
  26043.  
  26044. 7. # of DTMF Tones: 4
  26045.  
  26046. 8. DNIS sent: yes
  26047.    ANI sent: yes
  26048.    number of digits sent: 4
  26049.  
  26050.  
  26051.  
  26052.  
  26053. Brian
  26054.  
  26055. Brian Feeny (BF304)     signal@shreve.net   
  26056. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26057. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26058.  
  26059.  
  26060.  
  26061. -
  26062.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26063.  with "unsubscribe usr-tc" in the body of the message.
  26064.  For information on digests or retrieving files and old messages send
  26065.  "help" to the same address.  Do not use quotes in your message.
  26066.  
  26067.  
  26068. -------------------------------------------------------------------------------
  26069.  
  26070. From: Dataheart <lists@dataheart.net>
  26071. Subject: (usr-tc) Netserver
  26072. Date: 21 Oct 1999 02:44:51 +1000
  26073.  
  26074. thanks the passwords for the NMC worked.
  26075.  
  26076. Now how do I reset the passwordss on a Netserver PRI.
  26077. its not Dip Switch 6?
  26078.  
  26079. Thanks again,
  26080. Aaron
  26081.  
  26082.  
  26083. -
  26084.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26085.  with "unsubscribe usr-tc" in the body of the message.
  26086.  For information on digests or retrieving files and old messages send
  26087.  "help" to the same address.  Do not use quotes in your message.
  26088.  
  26089.  
  26090. -------------------------------------------------------------------------------
  26091.  
  26092. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  26093. Subject: Re: (usr-tc) Netserver
  26094. Date: 19 Oct 1999 23:55:22 -0500 (CDT)
  26095.  
  26096. Its dip switch 5
  26097. put dip switch 5 in the on position and then boot the card. the !root 
  26098. password would cleared set to no password
  26099.  
  26100. do you config 
  26101. do a save all
  26102.  
  26103. pull out the card, put the dip switch 5 in off position and 
  26104. put the card back
  26105.  
  26106. krish
  26107.  
  26108.         \    T.S.V. Krishnan  \
  26109.          \      Network System Engineer \ ( : - : )
  26110.           \     3Com ............   \
  26111.         ----------------------------------------------/
  26112. tkrishna@bubba.ae.usr.com  
  26113. ----------------------------/ http://interproc.ae.usr.com ----/
  26114.     Any Sufficiently advanced bug is indistinguishable for a feature.
  26115.                         - Rick Kulawiec
  26116.  
  26117. On Thu, 21 Oct 1999, Dataheart wrote:
  26118.  
  26119. > thanks the passwords for the NMC worked.
  26120. > 
  26121. > Now how do I reset the passwordss on a Netserver PRI.
  26122. > its not Dip Switch 6?
  26123. > 
  26124. > Thanks again,
  26125. > Aaron
  26126. > 
  26127. > 
  26128. > -
  26129. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26130. >  with "unsubscribe usr-tc" in the body of the message.
  26131. >  For information on digests or retrieving files and old messages send
  26132. >  "help" to the same address.  Do not use quotes in your message.
  26133. > 
  26134.  
  26135. -
  26136.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26137.  with "unsubscribe usr-tc" in the body of the message.
  26138.  For information on digests or retrieving files and old messages send
  26139.  "help" to the same address.  Do not use quotes in your message.
  26140.  
  26141.  
  26142. -------------------------------------------------------------------------------
  26143.  
  26144. From: Ronald Kushner <ron@glis.net>
  26145. Subject: Re: (usr-tc) Telco cluster fsck
  26146. Date: 20 Oct 1999 13:32:58 -0400
  26147.  
  26148. Brian wrote:
  26149. > 
  26150. > Battling with telco still over problematic CT1's in a remote pop.  I
  26151. > found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
  26152. > pull trigger) instead of TRUNK SIDE.  Below is the email I sent them on
  26153. > how to provision the lines.........is their anything in it that would
  26154. > indicate I was asking for trunk side instead of line side service, because
  26155. > I know they are going to throw in my face "you didn't ask for TRUNK side
  26156. > specifically", so I am hoping that the provisioning info below would only
  26157. > be valid for trunk side service.
  26158. > 
  26159. > I sent them:      B8ZS,  ESF, ground start, dial tone, wink ack disabled, dtmf, DTMF Tones: 4, DNIS sent: yes, ANI sent: yes, number of digits sent: 4
  26160.  
  26161. Looks like you ordered a line side CH DS-1. If you would have ordered it
  26162. with E&M Type II, Wink Start, and a wink ack you most likely (but not
  26163. always) ended up with a trunk side CH DS-1. Ground start trunks are allmost
  26164. always line side trunks.
  26165.  
  26166. -Ron
  26167. GLISnet, Inc.
  26168. +1 810/939.9885
  26169.  
  26170. -
  26171.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26172.  with "unsubscribe usr-tc" in the body of the message.
  26173.  For information on digests or retrieving files and old messages send
  26174.  "help" to the same address.  Do not use quotes in your message.
  26175.  
  26176.  
  26177. -------------------------------------------------------------------------------
  26178.  
  26179. From: Aaron Nabil <nabil@spiritone.com>
  26180. Subject: Re: (usr-tc) Telco cluster fsck
  26181. Date: 20 Oct 1999 12:44:08 -0700 (PDT)
  26182.  
  26183. Brian writes...
  26184. >Battling with telco still over problematic CT1's in a remote pop.  I
  26185. >found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
  26186. >pull trigger) instead of TRUNK SIDE.  Below is the email I sent them on
  26187. >how to provision the lines.........is their anything in it that would
  26188. >indicate I was asking for trunk side instead of line side service, because
  26189. >I know they are going to throw in my face "you didn't ask for TRUNK side
  26190. >specifically", so I am hoping that the provisioning info below would only
  26191. >be valid for trunk side service.  
  26192. > . . .
  26193. >3. Trunk type:
  26194. >    E&M II
  26195. >    loop start
  26196. >    ground start     *
  26197. >
  26198. >4. Trunk Start:
  26199. >    wink
  26200. >    immediate
  26201. >    dial tone    *
  26202.  
  26203. This is almost a blueprint for getting line-side service.
  26204.  
  26205. Reorder as E&M/wink.
  26206.  
  26207.  
  26208. -- 
  26209. Aaron Nabil
  26210.  
  26211. -
  26212.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26213.  with "unsubscribe usr-tc" in the body of the message.
  26214.  For information on digests or retrieving files and old messages send
  26215.  "help" to the same address.  Do not use quotes in your message.
  26216.  
  26217.  
  26218. -------------------------------------------------------------------------------
  26219.  
  26220. From: Aaron Nabil <nabil@spiritone.com>
  26221. Subject: Re: (usr-tc) Telco cluster fsck
  26222. Date: 20 Oct 1999 12:44:08 -0700 (PDT)
  26223.  
  26224. Brian writes...
  26225. >Battling with telco still over problematic CT1's in a remote pop.  I
  26226. >found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
  26227. >pull trigger) instead of TRUNK SIDE.  Below is the email I sent them on
  26228. >how to provision the lines.........is their anything in it that would
  26229. >indicate I was asking for trunk side instead of line side service, because
  26230. >I know they are going to throw in my face "you didn't ask for TRUNK side
  26231. >specifically", so I am hoping that the provisioning info below would only
  26232. >be valid for trunk side service.  
  26233. > . . .
  26234. >3. Trunk type:
  26235. >    E&M II
  26236. >    loop start
  26237. >    ground start     *
  26238. >
  26239. >4. Trunk Start:
  26240. >    wink
  26241. >    immediate
  26242. >    dial tone    *
  26243.  
  26244. This is almost a blueprint for getting line-side service.
  26245.  
  26246. Reorder as E&M/wink.
  26247.  
  26248.  
  26249. -- 
  26250. Aaron Nabil
  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: Aaron Nabil <nabil@spiritone.com>
  26262. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  26263. Date: 20 Oct 1999 14:01:57 -0700 (PDT)
  26264.  
  26265. Greg Coffey writes...
  26266. >Do you have a conclusion on this yet?  Does changing these settings have 
  26267. >any impact?
  26268.  
  26269. I haven't tried it yet, haven't been around the office much.  
  26270.  
  26271. -a
  26272.  
  26273. >
  26274. >
  26275. >At 04:46 AM 10/7/99 -0700, you wrote:
  26276. >
  26277. >
  26278. >>I call into our Max's and measured the level they were sending.  Only
  26279. >>-14dbm, much lower power, more what I was expecting.  Telnet in
  26280. >>and check to see what they are set to, -13dbm, another off by one, but
  26281. >>this time in the opposite direction!
  26282. >>
  26283. >>Here's a summary:
  26284. >>                         Configured for          Actually sends
  26285. >>USR HiperDSP            -11dbm                  -10dbm
  26286. >>Ascend Max              -13dbm                  -14dbm
  26287. >>
  26288. >>I don't have any scripts in place that monitor failure ratios, but
  26289. >>if someone does I'd be interested if they could set half their modems
  26290. >>to -15dbm (for an output of -14dbm) and see what effect that has.
  26291. >>
  26292. >>
  26293. >>--
  26294. >>Aaron Nabil
  26295.  
  26296.  
  26297. -- 
  26298. Aaron Nabil
  26299.  
  26300. -
  26301.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26302.  with "unsubscribe usr-tc" in the body of the message.
  26303.  For information on digests or retrieving files and old messages send
  26304.  "help" to the same address.  Do not use quotes in your message.
  26305.  
  26306.  
  26307. -------------------------------------------------------------------------------
  26308.  
  26309. From: Brian <signal@shreve.net>
  26310. Subject: Re: (usr-tc) Telco cluster fsck
  26311. Date: 20 Oct 1999 16:25:04 -0500 (CDT)
  26312.  
  26313. Ok, we bought a company that had 2 CT1's already.  So I just placed the
  26314. order to "mirror" the two there already.  I "assumed" they had trunk
  26315. side......I don't deal with CT1's much because most of our stuff is
  26316. PRI......thanks for the input.
  26317.  
  26318. Brian
  26319.  
  26320.  
  26321. On Wed, 20 Oct 1999, Aaron Nabil wrote:
  26322.  
  26323. > Brian writes...
  26324. > >Battling with telco still over problematic CT1's in a remote pop.  I
  26325. > >found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
  26326. > >pull trigger) instead of TRUNK SIDE.  Below is the email I sent them on
  26327. > >how to provision the lines.........is their anything in it that would
  26328. > >indicate I was asking for trunk side instead of line side service, because
  26329. > >I know they are going to throw in my face "you didn't ask for TRUNK side
  26330. > >specifically", so I am hoping that the provisioning info below would only
  26331. > >be valid for trunk side service.  
  26332. > > . . .
  26333. > >3. Trunk type:
  26334. > >    E&M II
  26335. > >    loop start
  26336. > >    ground start     *
  26337. > >
  26338. > >4. Trunk Start:
  26339. > >    wink
  26340. > >    immediate
  26341. > >    dial tone    *
  26342. > 
  26343. > This is almost a blueprint for getting line-side service.
  26344. > 
  26345. > Reorder as E&M/wink.
  26346. > 
  26347. > 
  26348. > -- 
  26349. > Aaron Nabil
  26350. > 
  26351. > -
  26352. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26353. >  with "unsubscribe usr-tc" in the body of the message.
  26354. >  For information on digests or retrieving files and old messages send
  26355. >  "help" to the same address.  Do not use quotes in your message.
  26356. > 
  26357.  
  26358. Brian Feeny (BF304)     signal@shreve.net   
  26359. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26360. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26361.  
  26362.  
  26363. -
  26364.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26365.  with "unsubscribe usr-tc" in the body of the message.
  26366.  For information on digests or retrieving files and old messages send
  26367.  "help" to the same address.  Do not use quotes in your message.
  26368.  
  26369.  
  26370. -------------------------------------------------------------------------------
  26371.  
  26372. From: Brian <signal@shreve.net>
  26373. Subject: Re: (usr-tc) Telco cluster fsck
  26374. Date: 20 Oct 1999 16:25:04 -0500 (CDT)
  26375.  
  26376. Ok, we bought a company that had 2 CT1's already.  So I just placed the
  26377. order to "mirror" the two there already.  I "assumed" they had trunk
  26378. side......I don't deal with CT1's much because most of our stuff is
  26379. PRI......thanks for the input.
  26380.  
  26381. Brian
  26382.  
  26383.  
  26384. On Wed, 20 Oct 1999, Aaron Nabil wrote:
  26385.  
  26386. > Brian writes...
  26387. > >Battling with telco still over problematic CT1's in a remote pop.  I
  26388. > >found out they provisioned the lines as LINE SIDE (open mouth, insert gun,
  26389. > >pull trigger) instead of TRUNK SIDE.  Below is the email I sent them on
  26390. > >how to provision the lines.........is their anything in it that would
  26391. > >indicate I was asking for trunk side instead of line side service, because
  26392. > >I know they are going to throw in my face "you didn't ask for TRUNK side
  26393. > >specifically", so I am hoping that the provisioning info below would only
  26394. > >be valid for trunk side service.  
  26395. > > . . .
  26396. > >3. Trunk type:
  26397. > >    E&M II
  26398. > >    loop start
  26399. > >    ground start     *
  26400. > >
  26401. > >4. Trunk Start:
  26402. > >    wink
  26403. > >    immediate
  26404. > >    dial tone    *
  26405. > 
  26406. > This is almost a blueprint for getting line-side service.
  26407. > 
  26408. > Reorder as E&M/wink.
  26409. > 
  26410. > 
  26411. > -- 
  26412. > Aaron Nabil
  26413. > 
  26414. > -
  26415. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26416. >  with "unsubscribe usr-tc" in the body of the message.
  26417. >  For information on digests or retrieving files and old messages send
  26418. >  "help" to the same address.  Do not use quotes in your message.
  26419. > 
  26420.  
  26421. Brian Feeny (BF304)     signal@shreve.net   
  26422. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26423. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26424.  
  26425.  
  26426. -
  26427.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26428.  with "unsubscribe usr-tc" in the body of the message.
  26429.  For information on digests or retrieving files and old messages send
  26430.  "help" to the same address.  Do not use quotes in your message.
  26431.  
  26432.  
  26433. -------------------------------------------------------------------------------
  26434.  
  26435. From: <pferraro@wna-linknet.com>
  26436. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?)
  26437. Date: 20 Oct 1999 17:38:15 -0400 (EDT)
  26438.  
  26439.  
  26440.     We set a couple of HUBS to -13db and did not notice much of a
  26441. difference  our call fail rate is between 3% and 4%  For example out of
  26442. 235 calls taken 7 would fail....
  26443.  
  26444.  This was about the same whether it was -11db/-12db/or -13db
  26445.  
  26446. ==============================================================================
  26447. Phillip Ferraro                WorldNet Access, Inc
  26448. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  26449. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  26450. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  26451. ==============================================================================
  26452.  
  26453. On Wed, 20 Oct 1999, Aaron Nabil wrote:
  26454.  
  26455. > Greg Coffey writes...
  26456. > >Do you have a conclusion on this yet?  Does changing these settings have 
  26457. > >any impact?
  26458. > 
  26459. > I haven't tried it yet, haven't been around the office much.  
  26460. > 
  26461. > -a
  26462. > 
  26463. > >
  26464. > >
  26465. > >At 04:46 AM 10/7/99 -0700, you wrote:
  26466. > >
  26467. > >
  26468. > >>I call into our Max's and measured the level they were sending.  Only
  26469. > >>-14dbm, much lower power, more what I was expecting.  Telnet in
  26470. > >>and check to see what they are set to, -13dbm, another off by one, but
  26471. > >>this time in the opposite direction!
  26472. > >>
  26473. > >>Here's a summary:
  26474. > >>                         Configured for          Actually sends
  26475. > >>USR HiperDSP            -11dbm                  -10dbm
  26476. > >>Ascend Max              -13dbm                  -14dbm
  26477. > >>
  26478. > >>I don't have any scripts in place that monitor failure ratios, but
  26479. > >>if someone does I'd be interested if they could set half their modems
  26480. > >>to -15dbm (for an output of -14dbm) and see what effect that has.
  26481. > >>
  26482. > >>
  26483. > >>--
  26484. > >>Aaron Nabil
  26485. > 
  26486. > 
  26487. > -- 
  26488. > Aaron Nabil
  26489. > 
  26490. > -
  26491. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26492. >  with "unsubscribe usr-tc" in the body of the message.
  26493. >  For information on digests or retrieving files and old messages send
  26494. >  "help" to the same address.  Do not use quotes in your message.
  26495. > 
  26496.  
  26497.  
  26498. -
  26499.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26500.  with "unsubscribe usr-tc" in the body of the message.
  26501.  For information on digests or retrieving files and old messages send
  26502.  "help" to the same address.  Do not use quotes in your message.
  26503.  
  26504.  
  26505. -------------------------------------------------------------------------------
  26506.  
  26507. From: "Campbell Simpson" <Campbell.Simpson@telecom.co.nz>
  26508. Subject: Re: (usr-tc) USR vs Ascend (3com vs Lucent?) -Reply
  26509. Date: 21 Oct 1999 10:47:50 +1300
  26510.  
  26511. Phillip
  26512.  
  26513. When you talk about call failure rate, what do you actually mean? Is this =
  26514. based on the modem disconnection result or disconnection reasons from =
  26515. radius?
  26516.  
  26517. Campbell Simpson
  26518.  
  26519.  
  26520. -
  26521.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26522.  with "unsubscribe usr-tc" in the body of the message.
  26523.  For information on digests or retrieving files and old messages send
  26524.  "help" to the same address.  Do not use quotes in your message.
  26525.  
  26526.  
  26527. -------------------------------------------------------------------------------
  26528.  
  26529. From: Rick <rallan@monmouth.com>
  26530. Subject: Re: (usr-tc) ISPCon/3Com Open Meeting
  26531. Date: 20 Oct 1999 22:18:26 -0400
  26532.  
  26533. I would have to agree with Allen when it comes to the quality of support
  26534. between 3com and ANYONE. We currently maintain maintenance agreements with many
  26535. vendors (including cisco and lucent..aka ascend) and it is always refreshing to
  26536. have to deal with both cisco and lucent of 3com engineers. Both cisco and
  26537. lucent are very willing to upgrade any firmware revision that has KNOWN bugs.
  26538. If 3com would start to comprehend this subject I think it would help with their
  26539. stock....., I mean image...
  26540.  
  26541. :>
  26542.  
  26543. Allen Marsalis wrote:
  26544.  
  26545. > At 09:15 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
  26546. > >On Fri, 15 Oct 1999, Allen Marsalis wrote:
  26547. > >
  26548. > >> I have no regrets..  x2 was a big deal in our area (we certainly helped)
  26549. > >> and being the first 56k provider in our area was a big win for us.
  26550. > >> USR made that happen..  I liked USR..  It's 3com that I feel ill about.
  26551. > >
  26552. > >Agreed here too. Getting my TC rack was a big win for us, and having it
  26553. > >still is. We were first with x2, first with v.90, and our v.90 *still*
  26554. > >walks all over my competitions' PM-based dialup pools. And we're still
  26555. > >the only provider in town doing ISDN, which is the best thing you can
  26556. > >get here aside from a dedicated line. (and we're served by Sprint, who
  26557. > >has some really good ISDN BRI pricing...only about $5 more than two
  26558. > >regular phone lines and flat-rate to boot...not to mention that inbound
  26559. > >PRIs are about 1/2 the cost of CT1's).
  26560. >
  26561. > Same here.  That's pretty much exactly how we feel about it.  However
  26562. > we occationally find a user with a good sportster/3com modem who can't
  26563. > get v.90 on our TCS but can on our TNT (eval) and more importantly,
  26564. > can with our competitors.  Users won't stay with 28.8 when they can
  26565. > get 48k elsewhere..  If there were no modem code issues, I'd be more
  26566. > than happy to send the eval back.  Instead, I'll probably get an invoice...
  26567. >
  26568. > >
  26569. > >> Do we use 3com switches or routers?  no we use cisco, foundry, etc..
  26570. > >
  26571. > >I'm actually a fan of their switches. But one doesn't have the same
  26572. > >problems...either a ethernet switch works or it doesn't. If it's
  26573. >
  26574. > Well back when we started, we bought a superstack and it worked of course
  26575. > but when I found out it was half-duplex on all 10T ports, we sent it back
  26576. > and opted for a catalyst..  But nowadays I'm sure things are different.
  26577. > We outgrew the catalyst and now have a fastiron and we love it..
  26578. >
  26579. > I realize that switches don't call for much support, but we did have
  26580. > some issues with the catalyst.  Ciscos support as amazing and they
  26581. > even called back again just to make sure we were happy.  3com on the
  26582. > otherhand wanted to charge us for support on a 1 day old switch!
  26583. > I just wanted to double check to see that their was no fdx on
  26584. > the ports before sending it back.  They could have cared less whether
  26585. > I returned it or not..  So I did!
  26586. >
  26587. > Allen
  26588. >
  26589. > -
  26590. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26591. >  with "unsubscribe usr-tc" in the body of the message.
  26592. >  For information on digests or retrieving files and old messages send
  26593. >  "help" to the same address.  Do not use quotes in your message.
  26594.  
  26595. --
  26596. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  26597. Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
  26598. Head of Network Engineering    |    Monmouth Internet Corporation
  26599. 732-842-5366=====extension 102 |      http://www.monmouth.com
  26600. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  26601.  
  26602.  
  26603.  
  26604. -
  26605.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26606.  with "unsubscribe usr-tc" in the body of the message.
  26607.  For information on digests or retrieving files and old messages send
  26608.  "help" to the same address.  Do not use quotes in your message.
  26609.  
  26610.  
  26611. -------------------------------------------------------------------------------
  26612.  
  26613. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  26614. Subject: RE: (usr-tc) ISPCon/3Com Open Meeting
  26615. Date: 20 Oct 1999 23:28:49 -0300
  26616.  
  26617.  
  26618. When a security problem became publicized about a particular version of IOS
  26619. I called the Cisco TAC to request a new version of the firmware.  I didn't
  26620. have a contract and they had never heard from me before.  Not only did I get
  26621. the code emailed to me, a support engineer phoned me back to see if I needed
  26622. any help getting the code into the routers.  He spent an hour on the phone
  26623. with me suggesting memory upgrades, where to buy said upgrades, and
  26624. explaining every little thing I could think to ask about Cisco routers.
  26625.  
  26626. Now THAT is service.
  26627.  
  26628. Matthew
  26629.  
  26630. > -----Original Message-----
  26631. > From:    Rick [SMTP:rallan@monmouth.com]
  26632. > Sent:    Wednesday, October 20, 1999 11:18 PM
  26633. > To:    usr-tc@lists.xmission.com
  26634. > Subject:    Re: (usr-tc) ISPCon/3Com Open Meeting
  26635. > 
  26636. > I would have to agree with Allen when it comes to the quality of support
  26637. > between 3com and ANYONE. We currently maintain maintenance agreements with
  26638. > many
  26639. > vendors (including cisco and lucent..aka ascend) and it is always
  26640. > refreshing to
  26641. > have to deal with both cisco and lucent of 3com engineers. Both cisco and
  26642. > lucent are very willing to upgrade any firmware revision that has KNOWN
  26643. > bugs.
  26644. > If 3com would start to comprehend this subject I think it would help with
  26645. > their
  26646. > stock....., I mean image...
  26647. > 
  26648. > :>
  26649. > 
  26650. > Allen Marsalis wrote:
  26651. > 
  26652. > > At 09:15 PM 10/15/99 -0400, Lon R. Stockton, Jr. wrote:
  26653. > > >On Fri, 15 Oct 1999, Allen Marsalis wrote:
  26654. > > >
  26655. > > >> I have no regrets..  x2 was a big deal in our area (we certainly
  26656. > helped)
  26657. > > >> and being the first 56k provider in our area was a big win for us.
  26658. > > >> USR made that happen..  I liked USR..  It's 3com that I feel ill
  26659. > about.
  26660. > > >
  26661. > > >Agreed here too. Getting my TC rack was a big win for us, and having it
  26662. > > >still is. We were first with x2, first with v.90, and our v.90 *still*
  26663. > > >walks all over my competitions' PM-based dialup pools. And we're still
  26664. > > >the only provider in town doing ISDN, which is the best thing you can
  26665. > > >get here aside from a dedicated line. (and we're served by Sprint, who
  26666. > > >has some really good ISDN BRI pricing...only about $5 more than two
  26667. > > >regular phone lines and flat-rate to boot...not to mention that inbound
  26668. > > >PRIs are about 1/2 the cost of CT1's).
  26669. > >
  26670. > > Same here.  That's pretty much exactly how we feel about it.  However
  26671. > > we occationally find a user with a good sportster/3com modem who can't
  26672. > > get v.90 on our TCS but can on our TNT (eval) and more importantly,
  26673. > > can with our competitors.  Users won't stay with 28.8 when they can
  26674. > > get 48k elsewhere..  If there were no modem code issues, I'd be more
  26675. > > than happy to send the eval back.  Instead, I'll probably get an
  26676. > invoice...
  26677. > >
  26678. > > >
  26679. > > >> Do we use 3com switches or routers?  no we use cisco, foundry, etc..
  26680. > > >
  26681. > > >I'm actually a fan of their switches. But one doesn't have the same
  26682. > > >problems...either a ethernet switch works or it doesn't. If it's
  26683. > >
  26684. > > Well back when we started, we bought a superstack and it worked of
  26685. > course
  26686. > > but when I found out it was half-duplex on all 10T ports, we sent it
  26687. > back
  26688. > > and opted for a catalyst..  But nowadays I'm sure things are different.
  26689. > > We outgrew the catalyst and now have a fastiron and we love it..
  26690. > >
  26691. > > I realize that switches don't call for much support, but we did have
  26692. > > some issues with the catalyst.  Ciscos support as amazing and they
  26693. > > even called back again just to make sure we were happy.  3com on the
  26694. > > otherhand wanted to charge us for support on a 1 day old switch!
  26695. > > I just wanted to double check to see that their was no fdx on
  26696. > > the ports before sending it back.  They could have cared less whether
  26697. > > I returned it or not..  So I did!
  26698. > >
  26699. > > Allen
  26700. > >
  26701. > > -
  26702. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26703. > >  with "unsubscribe usr-tc" in the body of the message.
  26704. > >  For information on digests or retrieving files and old messages send
  26705. > >  "help" to the same address.  Do not use quotes in your message.
  26706. > 
  26707. > --
  26708. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  26709. > Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone
  26710. > Head of Network Engineering    |    Monmouth Internet Corporation
  26711. > 732-842-5366=====extension 102 |      http://www.monmouth.com
  26712. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  26713. > 
  26714. > 
  26715. > 
  26716. > -
  26717. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26718. >  with "unsubscribe usr-tc" in the body of the message.
  26719. >  For information on digests or retrieving files and old messages send
  26720. >  "help" to the same address.  Do not use quotes in your message.
  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 send
  26726.  "help" to the same address.  Do not use quotes in your message.
  26727.  
  26728.  
  26729. -------------------------------------------------------------------------------
  26730.  
  26731. From: Malcolm Dobson <malcolm@beano.sol.co.uk>
  26732. Subject: (usr-tc) Licences for SAServer/RADIUS with Oracle
  26733. Date: 21 Oct 1999 14:10:08 +0100 (BST)
  26734.  
  26735. We use version 6.0 of saserver with an Oracle backend. Recently Oracle
  26736. (UK) have told us that we must pay an annual "Limited User Programs"
  26737. Licence for each user in the users table. For our operation this would
  26738. amount to some $40K (US) a year. We think this is totally outrageous.
  26739.  
  26740. Has anyone else been asked to pay per-user licences by Oracle for
  26741. this?
  26742.  
  26743. Regards
  26744.  
  26745. Malcolm
  26746.  
  26747. Malcolm Dobson, Scotland On Line
  26748. www.scotland.net
  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. From: Brian <signal@shreve.net>
  26761. Subject: Re: (usr-tc) Licences for SAServer/RADIUS with Oracle
  26762. Date: 21 Oct 1999 09:13:09 -0500 (CDT)
  26763.  
  26764.  
  26765.  
  26766. That's crazy.  That's like Oracle telling a store owner they want a
  26767. license fee for each product they sell listed in the
  26768. database............"datums" should not have license fees :)
  26769.  
  26770.  
  26771. On Thu, 21 Oct 1999, Malcolm Dobson wrote:
  26772.  
  26773. > We use version 6.0 of saserver with an Oracle backend. Recently Oracle
  26774. > (UK) have told us that we must pay an annual "Limited User Programs"
  26775. > Licence for each user in the users table. For our operation this would
  26776. > amount to some $40K (US) a year. We think this is totally outrageous.
  26777. > 
  26778. > Has anyone else been asked to pay per-user licences by Oracle for
  26779. > this?
  26780. > 
  26781. > Regards
  26782. > 
  26783. > Malcolm
  26784. > 
  26785. > Malcolm Dobson, Scotland On Line
  26786. > www.scotland.net
  26787. > 
  26788. > 
  26789. > -
  26790. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26791. >  with "unsubscribe usr-tc" in the body of the message.
  26792. >  For information on digests or retrieving files and old messages send
  26793. >  "help" to the same address.  Do not use quotes in your message.
  26794. > 
  26795.  
  26796. Brian Feeny (BF304)     signal@shreve.net   
  26797. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26798. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26799.  
  26800.  
  26801. -
  26802.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26803.  with "unsubscribe usr-tc" in the body of the message.
  26804.  For information on digests or retrieving files and old messages send
  26805.  "help" to the same address.  Do not use quotes in your message.
  26806.  
  26807.  
  26808. -------------------------------------------------------------------------------
  26809.  
  26810. From: Clayton Zekelman <clayton@MNSi.Net>
  26811. Subject: Re: (usr-tc) Licences for SAServer/RADIUS with Oracle
  26812. Date: 21 Oct 1999 10:36:07 -0400
  26813.  
  26814. They may have been referring to a "per seat" fee - for each user of THEIR
  26815. software. IE each desktop in your company that will be using the database.
  26816.  
  26817. At 09:13 AM 10/21/99 -0500, you wrote:
  26818. >
  26819. >
  26820. >That's crazy.  That's like Oracle telling a store owner they want a
  26821. >license fee for each product they sell listed in the
  26822. >database............"datums" should not have license fees :)
  26823. >
  26824. >
  26825. >On Thu, 21 Oct 1999, Malcolm Dobson wrote:
  26826. >
  26827. >> We use version 6.0 of saserver with an Oracle backend. Recently Oracle
  26828. >> (UK) have told us that we must pay an annual "Limited User Programs"
  26829. >> Licence for each user in the users table. For our operation this would
  26830. >> amount to some $40K (US) a year. We think this is totally outrageous.
  26831. >> 
  26832. >> Has anyone else been asked to pay per-user licences by Oracle for
  26833. >> this?
  26834. >> 
  26835. >> Regards
  26836. >> 
  26837. >> Malcolm
  26838. >> 
  26839. >> Malcolm Dobson, Scotland On Line
  26840. >> www.scotland.net
  26841. >> 
  26842. >> 
  26843. >> -
  26844. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26845. >>  with "unsubscribe usr-tc" in the body of the message.
  26846. >>  For information on digests or retrieving files and old messages send
  26847. >>  "help" to the same address.  Do not use quotes in your message.
  26848. >> 
  26849. >
  26850. >-----------------------------------------------------
  26851. >Brian Feeny (BF304)     signal@shreve.net   
  26852. >318-222-2638 x 109    http://www.shreve.net/~signal      
  26853. >Network Administrator   ShreveNet Inc. (ASN 11881)           
  26854. >
  26855. >
  26856. >-
  26857. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26858. > with "unsubscribe usr-tc" in the body of the message.
  26859. > For information on digests or retrieving files and old messages send
  26860. > "help" to the same address.  Do not use quotes in your message.
  26861. > 
  26862. ---
  26863. Clayton Zekelman
  26864. Managed Network Systems Inc. (MNSi)
  26865. 875 Ouellette Avenue
  26866. Windsor, Ontario
  26867. N9A 4J6
  26868.  
  26869. tel. 519-985-8410
  26870. fax. 519-258-3009
  26871.  
  26872. -
  26873.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26874.  with "unsubscribe usr-tc" in the body of the message.
  26875.  For information on digests or retrieving files and old messages send
  26876.  "help" to the same address.  Do not use quotes in your message.
  26877.  
  26878.  
  26879. -------------------------------------------------------------------------------
  26880.  
  26881. From: Malcolm Dobson <malcolm@beano.sol.co.uk>
  26882. Subject: Re: (usr-tc) Licences for SAServer/RADIUS with Oracle
  26883. Date: 21 Oct 1999 15:46:11 +0100 (BST)
  26884.  
  26885.  
  26886.  
  26887. On Thu, 21 Oct 1999, Clayton Zekelman wrote:
  26888.  
  26889. > They may have been referring to a "per seat" fee - for each user of THEIR
  26890. > software. IE each desktop in your company that will be using the database.
  26891. > 
  26892.  
  26893. Absolutely not - they figure a user being authenticated by the RADIUS
  26894. system is a user of the database. I kid you not! We already pay for our
  26895. staff to use Oracle.
  26896.  
  26897. > At 09:13 AM 10/21/99 -0500, you wrote:
  26898. > >
  26899. > >
  26900. > >That's crazy.  That's like Oracle telling a store owner they want a
  26901. > >license fee for each product they sell listed in the
  26902. > >database............"datums" should not have license fees :)
  26903. > >
  26904. > >
  26905. > >On Thu, 21 Oct 1999, Malcolm Dobson wrote:
  26906. > >
  26907. > >> We use version 6.0 of saserver with an Oracle backend. Recently Oracle
  26908. > >> (UK) have told us that we must pay an annual "Limited User Programs"
  26909. > >> Licence for each user in the users table. For our operation this would
  26910. > >> amount to some $40K (US) a year. We think this is totally outrageous.
  26911. > >> 
  26912. > >> Has anyone else been asked to pay per-user licences by Oracle for
  26913. > >> this?
  26914. > >> 
  26915. > >> Regards
  26916. > >> 
  26917. > >> Malcolm
  26918. > >> 
  26919. > >> Malcolm Dobson, Scotland On Line
  26920. > >> www.scotland.net
  26921. > >> 
  26922. > >> 
  26923. > >> -
  26924. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26925. > >>  with "unsubscribe usr-tc" in the body of the message.
  26926. > >>  For information on digests or retrieving files and old messages send
  26927. > >>  "help" to the same address.  Do not use quotes in your message.
  26928. > >> 
  26929. > >
  26930. > >-----------------------------------------------------
  26931. > >Brian Feeny (BF304)     signal@shreve.net   
  26932. > >318-222-2638 x 109    http://www.shreve.net/~signal      
  26933. > >Network Administrator   ShreveNet Inc. (ASN 11881)           
  26934. > >
  26935. > >
  26936. > >-
  26937. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26938. > > with "unsubscribe usr-tc" in the body of the message.
  26939. > > For information on digests or retrieving files and old messages send
  26940. > > "help" to the same address.  Do not use quotes in your message.
  26941. > > 
  26942. > ---
  26943. > Clayton Zekelman
  26944. > Managed Network Systems Inc. (MNSi)
  26945. > 875 Ouellette Avenue
  26946. > Windsor, Ontario
  26947. > N9A 4J6
  26948. > 
  26949. > tel. 519-985-8410
  26950. > fax. 519-258-3009
  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. Regards
  26960.  
  26961. Malcolm
  26962.  
  26963. Malcolm Dobson, Scotland On Line
  26964. www.scotland.net
  26965.  
  26966.  
  26967. -
  26968.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26969.  with "unsubscribe usr-tc" in the body of the message.
  26970.  For information on digests or retrieving files and old messages send
  26971.  "help" to the same address.  Do not use quotes in your message.
  26972.  
  26973.  
  26974. -------------------------------------------------------------------------------
  26975.  
  26976. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  26977. Subject: RE: (usr-tc) Licences for SAServer/RADIUS with Oracle
  26978. Date: 21 Oct 1999 11:50:11 -0300
  26979.  
  26980.  
  26981. Then they obviously don't understand the nature of what you're doing.  It
  26982. might be more accurate to say that each chassis is a "client" of the
  26983. database - but even that is stretching it.
  26984.  
  26985. Matthew
  26986.  
  26987. > -----Original Message-----
  26988. > From: Malcolm Dobson [mailto:malcolm@beano.sol.co.uk]
  26989. > Sent: Thursday, October 21, 1999 11:46 AM
  26990. > To: usr-tc@lists.xmission.com
  26991. > Subject: Re: (usr-tc) Licences for SAServer/RADIUS with Oracle
  26992. > 
  26993. > 
  26994. > 
  26995. > 
  26996. > On Thu, 21 Oct 1999, Clayton Zekelman wrote:
  26997. > 
  26998. > > They may have been referring to a "per seat" fee - for each 
  26999. > user of THEIR
  27000. > > software. IE each desktop in your company that will be 
  27001. > using the database.
  27002. > > 
  27003. > 
  27004. > Absolutely not - they figure a user being authenticated by the RADIUS
  27005. > system is a user of the database. I kid you not! We already 
  27006. > pay for our
  27007. > staff to use Oracle.
  27008. > 
  27009. > > At 09:13 AM 10/21/99 -0500, you wrote:
  27010. > > >
  27011. > > >
  27012. > > >That's crazy.  That's like Oracle telling a store owner they want a
  27013. > > >license fee for each product they sell listed in the
  27014. > > >database............"datums" should not have license fees :)
  27015. > > >
  27016. > > >
  27017. > > >On Thu, 21 Oct 1999, Malcolm Dobson wrote:
  27018. > > >
  27019. > > >> We use version 6.0 of saserver with an Oracle backend. 
  27020. > Recently Oracle
  27021. > > >> (UK) have told us that we must pay an annual "Limited 
  27022. > User Programs"
  27023. > > >> Licence for each user in the users table. For our 
  27024. > operation this would
  27025. > > >> amount to some $40K (US) a year. We think this is 
  27026. > totally outrageous.
  27027. > > >> 
  27028. > > >> Has anyone else been asked to pay per-user licences by Oracle for
  27029. > > >> this?
  27030. > > >> 
  27031. > > >> Regards
  27032. > > >> 
  27033. > > >> Malcolm
  27034. > > >> 
  27035. > > >> Malcolm Dobson, Scotland On Line
  27036. > > >> www.scotland.net
  27037. > > >> 
  27038. > > >> 
  27039. > > >> -
  27040. > > >>  To unsubscribe to usr-tc, send an email to 
  27041. > "majordomo@xmission.com"
  27042. > > >>  with "unsubscribe usr-tc" in the body of the message.
  27043. > > >>  For information on digests or retrieving files and old 
  27044. > messages send
  27045. > > >>  "help" to the same address.  Do not use quotes in your message.
  27046. > > >> 
  27047. > > >
  27048. > > >-----------------------------------------------------
  27049. > > >Brian Feeny (BF304)     signal@shreve.net   
  27050. > > >318-222-2638 x 109    http://www.shreve.net/~signal      
  27051. > > >Network Administrator   ShreveNet Inc. (ASN 11881)           
  27052. > > >
  27053. > > >
  27054. > > >-
  27055. > > > To unsubscribe to usr-tc, send an email to 
  27056. > "majordomo@xmission.com"
  27057. > > > with "unsubscribe usr-tc" in the body of the message.
  27058. > > > For information on digests or retrieving files and old 
  27059. > messages send
  27060. > > > "help" to the same address.  Do not use quotes in your message.
  27061. > > > 
  27062. > > ---
  27063. > > Clayton Zekelman
  27064. > > Managed Network Systems Inc. (MNSi)
  27065. > > 875 Ouellette Avenue
  27066. > > Windsor, Ontario
  27067. > > N9A 4J6
  27068. > > 
  27069. > > tel. 519-985-8410
  27070. > > fax. 519-258-3009
  27071. > > 
  27072. > > -
  27073. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27074. > >  with "unsubscribe usr-tc" in the body of the message.
  27075. > >  For information on digests or retrieving files and old 
  27076. > messages send
  27077. > >  "help" to the same address.  Do not use quotes in your message.
  27078. > > 
  27079. > 
  27080. > Regards
  27081. > 
  27082. > Malcolm
  27083. > 
  27084. > Malcolm Dobson, Scotland On Line
  27085. > www.scotland.net
  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.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27097.  with "unsubscribe usr-tc" in the body of the message.
  27098.  For information on digests or retrieving files and old messages send
  27099.  "help" to the same address.  Do not use quotes in your message.
  27100.  
  27101.  
  27102. -------------------------------------------------------------------------------
  27103.  
  27104. From: Clayton Zekelman <clayton@MNSi.Net>
  27105. Subject: Re: (usr-tc) Licences for SAServer/RADIUS with Oracle
  27106. Date: 21 Oct 1999 13:51:03 -0400
  27107.  
  27108.  
  27109. >
  27110. >Absolutely not - they figure a user being authenticated by the RADIUS
  27111. >system is a user of the database. I kid you not! We already pay for our
  27112. >staff to use Oracle.
  27113. >
  27114.  
  27115. They're on hallucinogens.  Really bad ones.
  27116. ---
  27117. Clayton Zekelman
  27118. Managed Network Systems Inc. (MNSi)
  27119. 875 Ouellette Avenue
  27120. Windsor, Ontario
  27121. N9A 4J6
  27122.  
  27123. tel. 519-985-8410
  27124. fax. 519-258-3009
  27125.  
  27126. -
  27127.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27128.  with "unsubscribe usr-tc" in the body of the message.
  27129.  For information on digests or retrieving files and old messages send
  27130.  "help" to the same address.  Do not use quotes in your message.
  27131.  
  27132.  
  27133. -------------------------------------------------------------------------------
  27134.  
  27135. From: "Chuck Stace" <Chuck_Stace@mw.3com.com>
  27136. Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  27137. Date: 20 Oct 1999 08:06:30 -0500
  27138.  
  27139.  
  27140.  
  27141. 3Com Customers,
  27142.  
  27143. Due to various issues with prior versions of HiPer ARC and HiPer DSP code, 3Com
  27144. is advising that all customers upgrade their HiPer ARC and HiPer DSP cards to
  27145. one of the following versions of code:
  27146.  
  27147. HiPerARC v4.1.59-6
  27148. Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7. Version 4.1.59-6 is
  27149. an effort to combine many previous Engineering Releases into a generally
  27150. available code release. It addresses a series of P1 and P2 issues identified
  27151. with the previous HiPer ARC code release.
  27152.  
  27153. HiPerARC v4.2.32-1
  27154. The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29.  This
  27155. version fixes the upgrade issues from v4.1.59-6, HiPerBomb DoS (Denial of
  27156. Service) attack, and SNMP security issues.
  27157.  
  27158. If customers are using HiPerARC v4.2.29 on their Total Control chassis at this
  27159. time, they are advised to upgrade to v4.2.32-1 as soon as possible.
  27160.  
  27161. HiPerDSP v2.0.19
  27162. This is the released version of HiPer DSP T1 and T1/PRI, TCS 3.5. Please see the
  27163. release notes accompanying the code prior to deployment. NS1500 PRI switch type
  27164. is not supported in this release. EdgeServer/ESPro gateway cards have not been
  27165. included or tested for compatibility with TCS 3.5 System release. Once
  27166. compatibility has been verified and approved, this disclaimer will be removed
  27167. and status will be updated on the Software Compatibility Matrix.
  27168.  
  27169. HiPerDSP v2.0.81
  27170. This Service Release has the same functionality and limitations of v2.0.19, but
  27171. also includes a number of P1 and P2 bug fixes.  Please see the release notes
  27172. accompanying the code for details on bug fixes and outstanding issues.
  27173.  
  27174.  
  27175. Access the code and release notes in either of the following locations:
  27176.  
  27177.         http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
  27178.                    ( posted under Total Control Hubs )
  27179.                   or
  27180.         http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
  27181.                    ( search by Total Control Hubs : Hiper DSP or Hiper ARC )
  27182.  
  27183.  
  27184. If there are any questions or concerns regarding these changes, please contact
  27185. 3Com Technical Support toll-free at 1-800-231-8770.  If you are calling from an
  27186. area not handled by this number, the TotalService website has contact
  27187. information for other countries and regions.  Please go to the TotalService
  27188. website and click on 'Contacting Tech Support' for more information.
  27189.  
  27190. Chuck Stace
  27191. Customer Service Product Planning
  27192. Chuck_Stace@3com.com
  27193.  
  27194. -
  27195.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27196.  with "unsubscribe usr-tc" in the body of the message.
  27197.  For information on digests or retrieving files and old messages send
  27198.  "help" to the same address.  Do not use quotes in your message.
  27199.  
  27200.  
  27201. -------------------------------------------------------------------------------
  27202.  
  27203. From: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com>
  27204. Subject: (usr-tc) HiPer DSP & Quads in one chassis, plus MRTG question
  27205. Date: 18 Oct 1999 09:53:02 -0700
  27206.  
  27207. I have a few questions that I'm hoping someone can quickly answer.
  27208.  
  27209. The first group is, I have a TC chassis with 4 HiPer DSP's and one 70 AMP
  27210. PS.  I would like to put an additional 2 DSP's in this chassis.  Will the
  27211. one PS do the trick, or do I have to install another PS?
  27212.  
  27213. How many DSP's can I run off of two 70 AMP PS?
  27214.  
  27215. At what point do I have to switch the PS's to 130's?
  27216.  
  27217. The second group of questions is, I have a TC chassis, NSC card with 8 MB
  27218. DRAM and 2 MB Flash, NMC 4 MB DRAM and 2MB Flash,  12 A/D Quad's running in
  27219. Analog mode, no V.90 license and two 45 AMP PS's.  I want to add one HiPer
  27220. DSP.
  27221.  
  27222. Will the DSP be able to answer V.90 calls without the V.90 license
  27223. installed?
  27224.  
  27225. Do I have enough memory in the NMC and NSC to be able to handle the Quad's
  27226. and DSP?
  27227.  
  27228. Can someone tell me where the list archive is?
  27229.  
  27230. I'm also looking for MRTG scripts that will work with the TC's, can someone
  27231. point me in the right direction?
  27232.  
  27233. Thank you.
  27234.  
  27235. -
  27236.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27237.  with "unsubscribe usr-tc" in the body of the message.
  27238.  For information on digests or retrieving files and old messages send
  27239.  "help" to the same address.  Do not use quotes in your message.
  27240.  
  27241.  
  27242. -------------------------------------------------------------------------------
  27243.  
  27244. From: Richard Bosire <rbosire@africaonline.co.ke>
  27245. Subject: (usr-tc) netserver cards and Y2K
  27246. Date: 18 Oct 1999 22:01:02 +0300
  27247.  
  27248. Hi,s
  27249.  
  27250. I've been upgrading my Total Control firmware to make it Y2K compliant. A
  27251. look through 3Com's website reveals that I have to upgrade my Netserver Card
  27252. Software to version 3.8. When I go to the download site it implies that this
  27253. version is for 16MB cards. Is there a version for the 4MB cards or will I
  27254. have to upgrade the memory in order to upgrade the firmware?
  27255.  
  27256. thanx
  27257. bosire
  27258.  
  27259. --
  27260.  
  27261. richard bosire        bosire@africaonline.co.ke
  27262. AfricaOnline (k) Ltd    http://www.africaonline.co.ke
  27263. tel: 254.2.243775    fax: 254.2.243762
  27264. 2nd floor        Nairobi
  27265. Union Towers,Moi Ave.    Kenya
  27266.  
  27267. -
  27268.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27269.  with "unsubscribe usr-tc" in the body of the message.
  27270.  For information on digests or retrieving files and old messages send
  27271.  "help" to the same address.  Do not use quotes in your message.
  27272.  
  27273.  
  27274. -------------------------------------------------------------------------------
  27275.  
  27276. From: Dick <dick@dw.net>
  27277. Subject: Re: (usr-tc) 3com V90 Problems
  27278. Date: 17 Oct 1999 16:44:14 -0500 (CDT)
  27279.  
  27280. I hate to say this but perception is reality.
  27281.  
  27282. Telling a customer that the competition's equipment is lying to them
  27283. doesn't sound all that sincere, even if it is.  The customer, a 60 year
  27284. old grandfather of 6, isn't interested in you rhetoric (as they see it).
  27285.  
  27286. They are mad that your connections are 33.6 when the competition is 40+.
  27287.  
  27288. We do loose customers over this and that sucks because not only do we have
  27289. better (more reliable connects and no busy signals, ever) we have more
  27290. bandwidth and a faster overall network than the competition.  However as
  27291. the connect rate is lower we suck, as they see it.
  27292.  
  27293. Please read the above to mean that if the competition uses what I would
  27294. call 'an aggressive V90 connect' then that is what I need.  Hell I have
  27295. tossed around the joke of fixing the windows dialer to report 2 rates
  27296. higher than the actual rate.  Boy would my customers be happy!  They would
  27297. all believe it was FAST and 'perception is reality'
  27298.  
  27299. On Sun, 17 Oct 1999, Brian wrote:
  27300.  
  27301. > 
  27302. > I think (and perhaps someone can refresh my memory) that 3com actually
  27303. > responded to this ascend phenomenon, and said that its actually more or
  27304. > less a bug in the ascend code, and not a problem in the 3com code, in that
  27305. > the ascend picks piss poor connections to negotiate v90 with.  But I would
  27306. > be interested in knowing the stability of the connection, the number of
  27307. > retrains, and the ongoing average xmit/rcv rates of such a connection, raw
  27308. > thruput tests would be cool too.  I don't know if anyone has done this.
  27309. > 
  27310. > I would imagine, actually hope, that 3com's tests labs, have done many
  27311. > tests against their own stuff and against competitors.  I would think they
  27312. > would not make a policy of releasing such data, unless of course 3com was
  27313. > best in every case, which I doubt it was, but certainly coudln't have done
  27314. > too poor.
  27315. > 
  27316. > Brian
  27317. > 
  27318. > 
  27319. > On Sun, 17 Oct 1999, Greg Coffey wrote:
  27320. > 
  27321. > > If it comes down to significantly degrading other connections to our system
  27322. > > in order to enhance some on the fringe to get them v90, no, I don't want
  27323. > > that.  I would like to hear it from someone at 3Com that this is the
  27324. > > current thinking on the matter.  
  27325. > > 
  27326. > > >
  27327. > > >If you are going to pursue this rather dubious argument, why not just
  27328. > > >say what you really want?  You want 3com chassis to _connect_ at some
  27329. > > >outrageously high rate, say, 53k, and then silently fall back to a slower
  27330. > > >speed since it's unlikely the customer will notice the fallback.
  27331. > > >
  27332. > > >Hey 3com, how about that?   Make all v.90 connections, regardless of quality,
  27333. > > >always "CONNECT 53000" and then fall back to 40k or V.34 later?  Please
  27334. > > >make sure it's an option that can be disabled, I'd don't need any more
  27335. > > >"mysterious disconnects" or "neglible throughput" trouble calls than I
  27336. > > >already get.
  27337. > > 
  27338. > > 
  27339. > > Thanks,
  27340. > > 
  27341. > > Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  27342. > > =====================================================================
  27343. > > 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  27344. > > 
  27345. > > 
  27346. > > -
  27347. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27348. > >  with "unsubscribe usr-tc" in the body of the message.
  27349. > >  For information on digests or retrieving files and old messages send
  27350. > >  "help" to the same address.  Do not use quotes in your message.
  27351. > > 
  27352. > 
  27353. > -----------------------------------------------------
  27354. > Brian Feeny (BF304)     signal@shreve.net   
  27355. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  27356. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  27357. > 
  27358. > 
  27359. > -
  27360. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27361. >  with "unsubscribe usr-tc" in the body of the message.
  27362. >  For information on digests or retrieving files and old messages send
  27363. >  "help" to the same address.  Do not use quotes in your message.
  27364. > 
  27365.  
  27366. Richard B. Stuplich                                Nobody will be free until
  27367. CTO, DataWave Technologies                           nerd persecution ends.
  27368. DataWave, Wausau's first local ISP to have a direct connection to the
  27369. Midwest NAP, 2 full T1s, high-speed terminal servers, wireless connections,
  27370. Frame Relay, ISDN, x2, k56Flex, v.90/PCM and all digital modem connections. 
  27371.  
  27372. Experience the integrity, innovation and dedication of DataWave 715-843-7823
  27373.  
  27374. -
  27375.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27376.  with "unsubscribe usr-tc" in the body of the message.
  27377.  For information on digests or retrieving files and old messages send
  27378.  "help" to the same address.  Do not use quotes in your message.
  27379.  
  27380.  
  27381. -------------------------------------------------------------------------------
  27382.  
  27383. From: "Jolliffe, Anu" <anu@saltspring.com>
  27384. Subject: RE: (usr-tc) badmodems.pl
  27385. Date: 16 Oct 1999 15:42:11 -0700
  27386.  
  27387. Another quick question about this script.
  27388.  
  27389. How exactly do I set the failure rate percentage, which triggers the
  27390. notification?
  27391.  
  27392. -
  27393.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27394.  with "unsubscribe usr-tc" in the body of the message.
  27395.  For information on digests or retrieving files and old messages send
  27396.  "help" to the same address.  Do not use quotes in your message.
  27397.  
  27398.  
  27399. -------------------------------------------------------------------------------
  27400.  
  27401. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  27402. Subject: RE: (usr-tc) 3com Support Woes
  27403. Date: 15 Oct 1999 08:38:14 -0300
  27404.  
  27405.  
  27406. Well let me add my vote in for the "disgruntled masses".  I, for one, can
  27407. tell you I will NEVER buy another service contract after the harassment I
  27408. was put through last time by logistics.  In the past two years, the I have
  27409. only had to make one call to tech support, for which I paid 'per incident'.
  27410. After two hours of 3Com yelling "TELCO ISSUE" and the telco yelling "YOUR
  27411. EQUIPMENT", I ended up hanging up and finding the problem myself.
  27412.  
  27413. Matthew
  27414.  
  27415. > -----Original Message-----
  27416. > From: Ed [mailto:ed@taylors.com]
  27417. > Sent: Friday, October 15, 1999 12:03 AM
  27418. > To: usr-tc@lists.xmission.com
  27419. > Subject: (usr-tc) 3com Support Woes
  27420. > 
  27421. > 
  27422. > I cannot believe how many people keep coming out of the 
  27423. > woodwork that feel
  27424. > the same way about 3com's support issues. Seems like everyone 
  27425. > is disgruntled
  27426. > about it. When you speak to 3com they tell you people are 
  27427. > happy and like the
  27428. > changes being made and you are the only one complaining. What a smoke
  27429. > screen.
  27430. > 
  27431. > I believe 3com Executives and Stockholders should actually 
  27432. > read this list
  27433. > sometime...
  27434. > 
  27435. > 
  27436. > Ed
  27437. > 
  27438. > ----- Original Message -----
  27439. > From: Richard Lorbieski <richard@alpha1.net>
  27440. > To: <usr-tc@lists.xmission.com>
  27441. > Sent: Thursday, October 14, 1999 10:40 PM
  27442. > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  27443. > 
  27444. > 
  27445. > Sorry, but only people with service contracts can visit the 
  27446. > 3Com booth.
  27447. > 
  27448. > Sheldon Koehler wrote:
  27449. > >
  27450. > > Maybe we should all gang up at ISPCon and do a mass 
  27451. > movement from the 3Com
  27452. > > booth over to the Cisco booth and see if 3Com notices then...
  27453. > >
  27454. > > ----- Original Message -----
  27455. > > From: Brian <signal@shreve.net>
  27456. > > To: <usr-tc@lists.xmission.com>
  27457. > > Sent: Wednesday, October 13, 1999 8:50 PM
  27458. > > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  27459. > >
  27460. > > >
  27461. > > > I had the same shit happen.  She couldn't get it thru her 
  27462. > head that we
  27463. > had
  27464. > > > SOLD half the stuff they had us listed down for.  We SOLD 
  27465. > it because it
  27466. > > > was quad modem technology and its a good thing too, 
  27467. > because we would be
  27468. > > > screwed had we not sold, and 3com doesn't make a support 
  27469. > contract to fix
  27470. > > > you if you got a quad chassis.......not good enough 
  27471. > anyways, its all
  27472. > > > EOL'ed.
  27473. > > >
  27474. > > > It took I want to say 18+ months of negotiations between 
  27475. > our 3com rep,
  27476. > us,
  27477. > > > and 3com support contract people.  To this day we have 
  27478. > not been able to
  27479. > > > get contracts because we can't come to an agreement on 
  27480. > how the stuff
  27481. > > > should be priced.
  27482. > > >
  27483. > > >
  27484. > > > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  27485. > > >
  27486. > > > >
  27487. > > > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  27488. > > > >
  27489. > > > > > Unless I am mistaken they do offer software only 
  27490. > contracts.  I've
  27491. > seen
  27492. > > > > > them on Tech Data's price listing.  They are 
  27493. > generally less than
  27494. > half
  27495. > > of
  27496. > > > > > the full service contracts.
  27497. > > > >
  27498. > > > > They are still pricey.  And on top of the price, we 
  27499. > started getting
  27500. > > > > harrassing phone calls from some lackey in the 'service 
  27501. > contract'
  27502. > > > > department saying:
  27503. > > > >
  27504. > > > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  27505. > > > >
  27506. > > > > -me: "Yes.  That's why I bought X contracts."
  27507. > > > >
  27508. > > > > -rude 3Com lady: "Well you HAVE to buy a contract for 
  27509. > each chassis"
  27510. > > > >
  27511. > > > > -me: "Yes."
  27512. > > > >
  27513. > > > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  27514. > > > >
  27515. > > > > -me: "Tell you what.  Put me down for one, I'm selling 
  27516. > the rest of
  27517. > this
  27518. > > > > crap off."
  27519. > > > >
  27520. > > > > I didn't even buy direct from 3Com, but via a reseller.  They
  27521. > apparently
  27522. > > > > have the time and money to put losers like this on the 
  27523. > phone to harass
  27524. > > > > customers about the number of contracts they have 
  27525. > versus the number of
  27526. > > > > chassis they've purchased in the last 3 years.  What a 
  27527. > waste.  What
  27528. > > > > arrogance.
  27529. > > > >
  27530. > > > > I'll mention also that I have contracts (24x7x4) on our 
  27531. > high-end Cisco
  27532. > > > > routers that cost LESS than putting full support with no
  27533. > > > > "spare-in-the-air" support on all our TCH stuff.  And 
  27534. > I've been told
  27535. > by
  27536. > > > > numerous Cisco employees; support, sales, engineering 
  27537. > that they let
  27538. > > people
  27539. > > > > slide on most support/software issues.  They frown on 'version
  27540. > jumping'
  27541. > > > > where you go and thieve say IOS w/Firewall support when 
  27542. > you bought
  27543. > basic
  27544. > > > > IP, but I've had so many instances where I've received
  27545. > support/software
  27546. > > on
  27547. > > > > equipment with no contract.  I've even told the guy on 
  27548. > the phone "I
  27549. > have
  27550. > > > > no contract" and the basic response is "We want you to 
  27551. > be happy.  Your
  27552. > > > > hardware fried?  We'll send you new...  You need IOS 
  27553. > 12.x to fix this
  27554. > > bug?
  27555. > > > > Here it is."
  27556. > > > >
  27557. > > > > Why can't 3Com adopt at least some of this attitude?  
  27558. > It's not like
  27559. > > > > Pilgrim is feature-packed like IOS, we're all just 
  27560. > looking for solid
  27561. > > > > connects and standard routing features...
  27562. > > > >
  27563. > > > > Charles
  27564. > > > >
  27565. > > > > > Jeff Binkley
  27566. > > > > > ASA Network Computing
  27567. > > > > >
  27568. > > > > >
  27569. > > > > > U>I think Brian is on the right track here. Perhaps 
  27570. > 3COM can split
  27571. > > their
  27572. > > > > > U>service contracts into 2 categories - firmware 
  27573. > download only, and
  27574. > > full
  27575. > > > > > U>support with download and telephone support.
  27576. > > > > >
  27577. > > > > > U>Those of us new to the platform (myself included) 
  27578. > might benefit
  27579. > from
  27580. > > > > > U>the convenience of knowing that phone support is 
  27581. > available 24x7
  27582. > when
  27583. > > > > > U>you're staring at a box not taking calls at 2AM. 
  27584. > But once you get
  27585. > > the
  27586. > > > > > U>hang of TC and know how to troubleshoot these 
  27587. > things on your own
  27588. > (or
  27589. > > > > > U>at least with the added help of those on this 
  27590. > list), you can drop
  27591. > > the
  27592. > > > > > U>tel support, and just pay for code updates.
  27593. > > > > >
  27594. > > > > > U>Does any of this matter to those on this list that 
  27595. > are complaining
  27596. > > > > > U>about 3COM's lack of timely response to code 
  27597. > issues? Probably not.
  27598. > > > > > U>Should 3COM redirect it's efforts to resolving 
  27599. > these issues? Yep.
  27600. > > > > > U>Should they perhaps head-up a small team (1 person) 
  27601. > to field code
  27602. > > > > > U>enhancement and bug fix requests, both from an 
  27603. > email/web input
  27604. > area
  27605. > > on
  27606. > > > > > U>the 3COM ISP pages, but also through monitoring of 
  27607. > this list and
  27608. > the
  27609. > > > > > U>totalcontol newsgroups? Absolutely. 3COM may 
  27610. > already be doing this
  27611. > > > > > U>"behind the scenes", quietly tracking and logging 
  27612. > this stuff, but
  27613. > > it's
  27614. > > > > > U>apparent that the people who need to know the most 
  27615. > that it's being
  27616. > > > > > U>done and being worked on, the ISP customers, don't know that
  27617. > someone
  27618. > > > > > U>has acknowledged the problem and it has been placed into an
  27619. > > > > > U>engineering queue.
  27620. > > > > >
  27621. > > > > > U>I think that things like this would greatly improve 
  27622. > 3COM's image
  27623. > > among
  27624. > > > > > U>it's ISP customers, and even more so if they acted 
  27625. > expediently on
  27626. > > > > > U>these issues that trouble so many on this list. 
  27627. > Give the telephone
  27628. > > > > > U>support staff access to the database created as a 
  27629. > result of these
  27630. > > > > > U>pages (hell, give us access to these pages as well, 
  27631. > even WITHOUT a
  27632. > > > > > U>contract). Tie the ER/SR releases to the database, 
  27633. > so it's easier
  27634. > to
  27635. > > > > > U>identify which bug is fixed with which release. And most
  27636. > > importantly,
  27637. > > > > > U>of allowing us to view this database to obtain the status a
  27638. > > confirmed
  27639. > > > > > U>of bug and it's up-to-date progress in getting 
  27640. > resolved would be
  27641. > > > > > U>tremendous benefit. To know that someone is 
  27642. > actually WORKING on
  27643. > > Jeff's
  27644. > > > > > U>SNMP issue by simply searching the database is 
  27645. > comforting (knowing
  27646. > > > > > that
  27647. > > > > > U>it will be fixed QUICKLY is even better). Some of 
  27648. > this status
  27649. > > > > > U>information may already be in the 3KB, but a 
  27650. > dedicated database
  27651. > for
  27652. > > TC
  27653. > > > > > U>code issues and status reports would be really great.
  27654. > > > > >
  27655. > > > > > U>Scot
  27656. > > > > > U>NJAccess
  27657. > > > > >
  27658. > > > > > CMPQwk 1.42 9999
  27659. > > > > >
  27660. > > > > > -
  27661. > > > > >  To unsubscribe to usr-tc, send an email to 
  27662. > "majordomo@xmission.com"
  27663. > > > > >  with "unsubscribe usr-tc" in the body of the message.
  27664. > > > > >  For information on digests or retrieving files and 
  27665. > old messages
  27666. > send
  27667. > > > > >  "help" to the same address.  Do not use quotes in 
  27668. > your message.
  27669. > > > > >
  27670. > > > >
  27671. > > > >
  27672. > > > > -
  27673. > > > >  To unsubscribe to usr-tc, send an email to 
  27674. > "majordomo@xmission.com"
  27675. > > > >  with "unsubscribe usr-tc" in the body of the message.
  27676. > > > >  For information on digests or retrieving files and old 
  27677. > messages send
  27678. > > > >  "help" to the same address.  Do not use quotes in your message.
  27679. > > > >
  27680. > > >
  27681. > > > -----------------------------------------------------
  27682. > > > Brian Feeny (BF304)     signal@shreve.net
  27683. > > > 318-222-2638 x 109 http://www.shreve.net/~signal
  27684. > > > Network Administrator   ShreveNet Inc. (ASN 11881)
  27685. > > >
  27686. > > >
  27687. > > > -
  27688. > > >  To unsubscribe to usr-tc, send an email to 
  27689. > "majordomo@xmission.com"
  27690. > > >  with "unsubscribe usr-tc" in the body of the message.
  27691. > > >  For information on digests or retrieving files and old 
  27692. > messages send
  27693. > > >  "help" to the same address.  Do not use quotes in your message.
  27694. > > >
  27695. > >
  27696. > > -
  27697. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27698. > >  with "unsubscribe usr-tc" in the body of the message.
  27699. > >  For information on digests or retrieving files and old 
  27700. > messages send
  27701. > >  "help" to the same address.  Do not use quotes in your message.
  27702. > 
  27703. > --
  27704. > 
  27705. > Richard Lorbieski - richard@alpha1.net
  27706. > Chief Technical Officer - Senior System Administrator
  27707. > Alpha1 Internet  http://www.alpha1.net
  27708. > 409.731.8236  - 877.4.alpha1 (877.425.7421)
  27709. > 
  27710. > -
  27711. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27712. >  with "unsubscribe usr-tc" in the body of the message.
  27713. >  For information on digests or retrieving files and old messages send
  27714. >  "help" to the same address.  Do not use quotes in your message.
  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.  
  27725. -
  27726.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27727.  with "unsubscribe usr-tc" in the body of the message.
  27728.  For information on digests or retrieving files and old messages send
  27729.  "help" to the same address.  Do not use quotes in your message.
  27730.  
  27731.  
  27732. -------------------------------------------------------------------------------
  27733.  
  27734. From: "Sheldon Koehler" <sheldon@tenforward.com>
  27735. Subject: Re: (usr-tc) 3com Support Woes
  27736. Date: 14 Oct 1999 20:26:38 -0700
  27737.  
  27738. I have never been happy with the service contracts and I plan on voicing it
  27739. at ISPCon in two weeks. I am also going to talk with Cisco again. As a USR
  27740. user for over 13 years, I wanted to remain loyal as in the past I felt I was
  27741. treated very well. But not since the 3Com takeover.
  27742.  
  27743. My current contract expires in February 2000 and at this time, I will not
  27744. renew if I have to purchase contracts on all of my quad chassis as well as
  27745. my DSP ones. I do not like being forced to buy a contract on anything, let
  27746. alone a product that is acknowledged EOL by the company.
  27747.  
  27748. I am going to talk to my stock broker tomorrow about how to let stock
  27749. holders know how we feel...
  27750.  
  27751.  
  27752. ----- Original Message -----
  27753. Sent: Thursday, October 14, 1999 8:03 PM
  27754.  
  27755.  
  27756. > I cannot believe how many people keep coming out of the woodwork that feel
  27757. > the same way about 3com's support issues. Seems like everyone is
  27758. disgruntled
  27759. > about it. When you speak to 3com they tell you people are happy and like
  27760. the
  27761. > changes being made and you are the only one complaining. What a smoke
  27762. > screen.
  27763. >
  27764. > I believe 3com Executives and Stockholders should actually read this list
  27765. > sometime...
  27766. >
  27767. >
  27768. > Ed
  27769. >
  27770. > ----- Original Message -----
  27771. > From: Richard Lorbieski <richard@alpha1.net>
  27772. > To: <usr-tc@lists.xmission.com>
  27773. > Sent: Thursday, October 14, 1999 10:40 PM
  27774. > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  27775. >
  27776. >
  27777. > Sorry, but only people with service contracts can visit the 3Com booth.
  27778. >
  27779. > Sheldon Koehler wrote:
  27780. > >
  27781. > > Maybe we should all gang up at ISPCon and do a mass movement from the
  27782. 3Com
  27783. > > booth over to the Cisco booth and see if 3Com notices then...
  27784. > >
  27785. > > ----- Original Message -----
  27786. > > From: Brian <signal@shreve.net>
  27787. > > To: <usr-tc@lists.xmission.com>
  27788. > > Sent: Wednesday, October 13, 1999 8:50 PM
  27789. > > Subject: Re: (usr-tc) RE: (USR-TC) 2.0.60 HDM C
  27790. > >
  27791. > > >
  27792. > > > I had the same shit happen.  She couldn't get it thru her head that we
  27793. > had
  27794. > > > SOLD half the stuff they had us listed down for.  We SOLD it because
  27795. it
  27796. > > > was quad modem technology and its a good thing too, because we would
  27797. be
  27798. > > > screwed had we not sold, and 3com doesn't make a support contract to
  27799. fix
  27800. > > > you if you got a quad chassis.......not good enough anyways, its all
  27801. > > > EOL'ed.
  27802. > > >
  27803. > > > It took I want to say 18+ months of negotiations between our 3com rep,
  27804. > us,
  27805. > > > and 3com support contract people.  To this day we have not been able
  27806. to
  27807. > > > get contracts because we can't come to an agreement on how the stuff
  27808. > > > should be priced.
  27809. > > >
  27810. > > >
  27811. > > > On Wed, 13 Oct 1999, Charles Sprickman wrote:
  27812. > > >
  27813. > > > >
  27814. > > > > On Wed, 13 Oct 1999, Jeff Binkley wrote:
  27815. > > > >
  27816. > > > > > Unless I am mistaken they do offer software only contracts.  I've
  27817. > seen
  27818. > > > > > them on Tech Data's price listing.  They are generally less than
  27819. > half
  27820. > > of
  27821. > > > > > the full service contracts.
  27822. > > > >
  27823. > > > > They are still pricey.  And on top of the price, we started getting
  27824. > > > > harrassing phone calls from some lackey in the 'service contract'
  27825. > > > > department saying:
  27826. > > > >
  27827. > > > > -rude 3Com lady: "Are you SUUUURE that you only have X chassis?"
  27828. > > > >
  27829. > > > > -me: "Yes.  That's why I bought X contracts."
  27830. > > > >
  27831. > > > > -rude 3Com lady: "Well you HAVE to buy a contract for each chassis"
  27832. > > > >
  27833. > > > > -me: "Yes."
  27834. > > > >
  27835. > > > > -rude 3Com lady: "You're SUUURE you only have X chassis?"
  27836. > > > >
  27837. > > > > -me: "Tell you what.  Put me down for one, I'm selling the rest of
  27838. > this
  27839. > > > > crap off."
  27840. > > > >
  27841. > > > > I didn't even buy direct from 3Com, but via a reseller.  They
  27842. > apparently
  27843. > > > > have the time and money to put losers like this on the phone to
  27844. harass
  27845. > > > > customers about the number of contracts they have versus the number
  27846. of
  27847. > > > > chassis they've purchased in the last 3 years.  What a waste.  What
  27848. > > > > arrogance.
  27849. > > > >
  27850. > > > > I'll mention also that I have contracts (24x7x4) on our high-end
  27851. Cisco
  27852. > > > > routers that cost LESS than putting full support with no
  27853. > > > > "spare-in-the-air" support on all our TCH stuff.  And I've been told
  27854. > by
  27855. > > > > numerous Cisco employees; support, sales, engineering that they let
  27856. > > people
  27857. > > > > slide on most support/software issues.  They frown on 'version
  27858. > jumping'
  27859. > > > > where you go and thieve say IOS w/Firewall support when you bought
  27860. > basic
  27861. > > > > IP, but I've had so many instances where I've received
  27862. > support/software
  27863. > > on
  27864. > > > > equipment with no contract.  I've even told the guy on the phone "I
  27865. > have
  27866. > > > > no contract" and the basic response is "We want you to be happy.
  27867. Your
  27868. > > > > hardware fried?  We'll send you new...  You need IOS 12.x to fix
  27869. this
  27870. > > bug?
  27871. > > > > Here it is."
  27872. > > > >
  27873. > > > > Why can't 3Com adopt at least some of this attitude?  It's not like
  27874. > > > > Pilgrim is feature-packed like IOS, we're all just looking for solid
  27875. > > > > connects and standard routing features...
  27876. > > > >
  27877. > > > > Charles
  27878. > > > >
  27879. > > > > > Jeff Binkley
  27880. > > > > > ASA Network Computing
  27881. > > > > >
  27882. > > > > >
  27883. > > > > > U>I think Brian is on the right track here. Perhaps 3COM can split
  27884. > > their
  27885. > > > > > U>service contracts into 2 categories - firmware download only,
  27886. and
  27887. > > full
  27888. > > > > > U>support with download and telephone support.
  27889. > > > > >
  27890. > > > > > U>Those of us new to the platform (myself included) might benefit
  27891. > from
  27892. > > > > > U>the convenience of knowing that phone support is available 24x7
  27893. > when
  27894. > > > > > U>you're staring at a box not taking calls at 2AM. But once you
  27895. get
  27896. > > the
  27897. > > > > > U>hang of TC and know how to troubleshoot these things on your own
  27898. > (or
  27899. > > > > > U>at least with the added help of those on this list), you can
  27900. drop
  27901. > > the
  27902. > > > > > U>tel support, and just pay for code updates.
  27903. > > > > >
  27904. > > > > > U>Does any of this matter to those on this list that are
  27905. complaining
  27906. > > > > > U>about 3COM's lack of timely response to code issues? Probably
  27907. not.
  27908. > > > > > U>Should 3COM redirect it's efforts to resolving these issues?
  27909. Yep.
  27910. > > > > > U>Should they perhaps head-up a small team (1 person) to field
  27911. code
  27912. > > > > > U>enhancement and bug fix requests, both from an email/web input
  27913. > area
  27914. > > on
  27915. > > > > > U>the 3COM ISP pages, but also through monitoring of this list and
  27916. > the
  27917. > > > > > U>totalcontol newsgroups? Absolutely. 3COM may already be doing
  27918. this
  27919. > > > > > U>"behind the scenes", quietly tracking and logging this stuff,
  27920. but
  27921. > > it's
  27922. > > > > > U>apparent that the people who need to know the most that it's
  27923. being
  27924. > > > > > U>done and being worked on, the ISP customers, don't know that
  27925. > someone
  27926. > > > > > U>has acknowledged the problem and it has been placed into an
  27927. > > > > > U>engineering queue.
  27928. > > > > >
  27929. > > > > > U>I think that things like this would greatly improve 3COM's image
  27930. > > among
  27931. > > > > > U>it's ISP customers, and even more so if they acted expediently
  27932. on
  27933. > > > > > U>these issues that trouble so many on this list. Give the
  27934. telephone
  27935. > > > > > U>support staff access to the database created as a result of
  27936. these
  27937. > > > > > U>pages (hell, give us access to these pages as well, even WITHOUT
  27938. a
  27939. > > > > > U>contract). Tie the ER/SR releases to the database, so it's
  27940. easier
  27941. > to
  27942. > > > > > U>identify which bug is fixed with which release. And most
  27943. > > importantly,
  27944. > > > > > U>of allowing us to view this database to obtain the status a
  27945. > > confirmed
  27946. > > > > > U>of bug and it's up-to-date progress in getting resolved would be
  27947. > > > > > U>tremendous benefit. To know that someone is actually WORKING on
  27948. > > Jeff's
  27949. > > > > > U>SNMP issue by simply searching the database is comforting
  27950. (knowing
  27951. > > > > > that
  27952. > > > > > U>it will be fixed QUICKLY is even better). Some of this status
  27953. > > > > > U>information may already be in the 3KB, but a dedicated database
  27954. > for
  27955. > > TC
  27956. > > > > > U>code issues and status reports would be really great.
  27957. > > > > >
  27958. > > > > > U>Scot
  27959. > > > > > U>NJAccess
  27960. > > > > >
  27961. > > > > > CMPQwk 1.42 9999
  27962. > > > > >
  27963. > > > > > -
  27964. > > > > >  To unsubscribe to usr-tc, send an email to
  27965. "majordomo@xmission.com"
  27966. > > > > >  with "unsubscribe usr-tc" in the body of the message.
  27967. > > > > >  For information on digests or retrieving files and old messages
  27968. > send
  27969. > > > > >  "help" to the same address.  Do not use quotes in your message.
  27970. > > > > >
  27971. > > > >
  27972. > > > >
  27973. > > > > -
  27974. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27975. > > > >  with "unsubscribe usr-tc" in the body of the message.
  27976. > > > >  For information on digests or retrieving files and old messages
  27977. send
  27978. > > > >  "help" to the same address.  Do not use quotes in your message.
  27979. > > > >
  27980. > > >
  27981. > > > -----------------------------------------------------
  27982. > > > Brian Feeny (BF304)     signal@shreve.net
  27983. > > > 318-222-2638 x 109 http://www.shreve.net/~signal
  27984. > > > Network Administrator   ShreveNet Inc. (ASN 11881)
  27985. > > >
  27986. > > >
  27987. > > > -
  27988. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27989. > > >  with "unsubscribe usr-tc" in the body of the message.
  27990. > > >  For information on digests or retrieving files and old messages send
  27991. > > >  "help" to the same address.  Do not use quotes in your message.
  27992. > > >
  27993. > >
  27994. > > -
  27995. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27996. > >  with "unsubscribe usr-tc" in the body of the message.
  27997. > >  For information on digests or retrieving files and old messages send
  27998. > >  "help" to the same address.  Do not use quotes in your message.
  27999. >
  28000. > --
  28001. >
  28002. > Richard Lorbieski - richard@alpha1.net
  28003. > Chief Technical Officer - Senior System Administrator
  28004. > Alpha1 Internet  http://www.alpha1.net
  28005. > 409.731.8236  - 877.4.alpha1 (877.425.7421)
  28006. >
  28007. > -
  28008. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28009. >  with "unsubscribe usr-tc" in the body of the message.
  28010. >  For information on digests or retrieving files and old messages send
  28011. >  "help" to the same address.  Do not use quotes in your message.
  28012. >
  28013. >
  28014. >
  28015. > -
  28016. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28017. >  with "unsubscribe usr-tc" in the body of the message.
  28018. >  For information on digests or retrieving files and old messages send
  28019. >  "help" to the same address.  Do not use quotes in your message.
  28020. >
  28021.  
  28022. -
  28023.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28024.  with "unsubscribe usr-tc" in the body of the message.
  28025.  For information on digests or retrieving files and old messages send
  28026.  "help" to the same address.  Do not use quotes in your message.
  28027.  
  28028.  
  28029. -------------------------------------------------------------------------------
  28030.  
  28031. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  28032. Subject: RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28033. Date: 21 Oct 1999 16:11:48 -0300
  28034.  
  28035.  
  28036. How's about releasing HiPerARC 4.1.x that fixes the bugs for those of us who
  28037. don't want or aren't entitled to 4.2.x?
  28038.  
  28039. > -----Original Message-----
  28040. > From: Chuck Stace [mailto:Chuck_Stace@mw.3com.com]
  28041. > Sent: Wednesday, October 20, 1999 10:07 AM
  28042. > To: usr-tc@lists.xmission.com
  28043. > Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28044. > 
  28045. > 
  28046. > 
  28047. > 
  28048. > 3Com Customers,
  28049. > 
  28050. > Due to various issues with prior versions of HiPer ARC and 
  28051. > HiPer DSP code, 3Com
  28052. > is advising that all customers upgrade their HiPer ARC and 
  28053. > HiPer DSP cards to
  28054. > one of the following versions of code:
  28055. > 
  28056. > HiPerARC v4.1.59-6
  28057. > Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7. 
  28058. > Version 4.1.59-6 is
  28059. > an effort to combine many previous Engineering Releases into 
  28060. > a generally
  28061. > available code release. It addresses a series of P1 and P2 
  28062. > issues identified
  28063. > with the previous HiPer ARC code release.
  28064. > 
  28065. > HiPerARC v4.2.32-1
  28066. > The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC 
  28067. > v4.2.29.  This
  28068. > version fixes the upgrade issues from v4.1.59-6, HiPerBomb 
  28069. > DoS (Denial of
  28070. > Service) attack, and SNMP security issues.
  28071. > 
  28072. > If customers are using HiPerARC v4.2.29 on their Total 
  28073. > Control chassis at this
  28074. > time, they are advised to upgrade to v4.2.32-1 as soon as possible.
  28075. > 
  28076. > HiPerDSP v2.0.19
  28077. > This is the released version of HiPer DSP T1 and T1/PRI, TCS 
  28078. > 3.5. Please see the
  28079. > release notes accompanying the code prior to deployment. 
  28080. > NS1500 PRI switch type
  28081. > is not supported in this release. EdgeServer/ESPro gateway 
  28082. > cards have not been
  28083. > included or tested for compatibility with TCS 3.5 System release. Once
  28084. > compatibility has been verified and approved, this disclaimer 
  28085. > will be removed
  28086. > and status will be updated on the Software Compatibility Matrix.
  28087. > 
  28088. > HiPerDSP v2.0.81
  28089. > This Service Release has the same functionality and 
  28090. > limitations of v2.0.19, but
  28091. > also includes a number of P1 and P2 bug fixes.  Please see 
  28092. > the release notes
  28093. > accompanying the code for details on bug fixes and outstanding issues.
  28094. > 
  28095. > 
  28096. > Access the code and release notes in either of the following 
  28097. > locations:
  28098. > 
  28099.         http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
  28100.                    ( posted under Total Control Hubs )
  28101.                   or
  28102.  
  28103. http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
  28104.                    ( search by Total Control Hubs : Hiper DSP or Hiper ARC )
  28105.  
  28106.  
  28107. If there are any questions or concerns regarding these changes, please
  28108. contact
  28109. 3Com Technical Support toll-free at 1-800-231-8770.  If you are calling from
  28110. an
  28111. area not handled by this number, the TotalService website has contact
  28112. information for other countries and regions.  Please go to the TotalService
  28113. website and click on 'Contacting Tech Support' for more information.
  28114.  
  28115. Chuck Stace
  28116. Customer Service Product Planning
  28117. Chuck_Stace@3com.com
  28118.  
  28119. -
  28120.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28121.  with "unsubscribe usr-tc" in the body of the message.
  28122.  For information on digests or retrieving files and old messages send
  28123.  "help" to the same address.  Do not use quotes in your message.
  28124.  
  28125. -
  28126.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28127.  with "unsubscribe usr-tc" in the body of the message.
  28128.  For information on digests or retrieving files and old messages send
  28129.  "help" to the same address.  Do not use quotes in your message.
  28130.  
  28131.  
  28132. -------------------------------------------------------------------------------
  28133.  
  28134. From: <pferraro@wna-linknet.com>
  28135. Subject: RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28136. Date: 21 Oct 1999 15:35:11 -0400 (EDT)
  28137.  
  28138.  
  28139.     I just visited the Total Services web site and all of those
  28140. upgrades are unlocked!!!  You better get them now while you have a chance!
  28141. You can not, however download the HARC manager software for the new
  28142. HiperArc code, so if you are using the windows or unix based HiperArc
  28143. manager 1.18 now, you can not us it with the newer code.
  28144.  
  28145. ==============================================================================
  28146. Phillip Ferraro                WorldNet Access, Inc
  28147. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  28148. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  28149. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  28150. ==============================================================================
  28151.  
  28152. On Thu, 21 Oct 1999, Stainforth, Matthew wrote:
  28153.  
  28154. > 
  28155. > How's about releasing HiPerARC 4.1.x that fixes the bugs for those of us who
  28156. > don't want or aren't entitled to 4.2.x?
  28157. > 
  28158. > > -----Original Message-----
  28159. > > From: Chuck Stace [mailto:Chuck_Stace@mw.3com.com]
  28160. > > Sent: Wednesday, October 20, 1999 10:07 AM
  28161. > > To: usr-tc@lists.xmission.com
  28162. > > Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28163. > > 
  28164. > > 
  28165. > > 
  28166. > > 
  28167. > > 3Com Customers,
  28168. > > 
  28169. > > Due to various issues with prior versions of HiPer ARC and 
  28170. > > HiPer DSP code, 3Com
  28171. > > is advising that all customers upgrade their HiPer ARC and 
  28172. > > HiPer DSP cards to
  28173. > > one of the following versions of code:
  28174. > > 
  28175. > > HiPerARC v4.1.59-6
  28176. > > Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7. 
  28177. > > Version 4.1.59-6 is
  28178. > > an effort to combine many previous Engineering Releases into 
  28179. > > a generally
  28180. > > available code release. It addresses a series of P1 and P2 
  28181. > > issues identified
  28182. > > with the previous HiPer ARC code release.
  28183. > > 
  28184. > > HiPerARC v4.2.32-1
  28185. > > The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC 
  28186. > > v4.2.29.  This
  28187. > > version fixes the upgrade issues from v4.1.59-6, HiPerBomb 
  28188. > > DoS (Denial of
  28189. > > Service) attack, and SNMP security issues.
  28190. > > 
  28191. > > If customers are using HiPerARC v4.2.29 on their Total 
  28192. > > Control chassis at this
  28193. > > time, they are advised to upgrade to v4.2.32-1 as soon as possible.
  28194. > > 
  28195. > > HiPerDSP v2.0.19
  28196. > > This is the released version of HiPer DSP T1 and T1/PRI, TCS 
  28197. > > 3.5. Please see the
  28198. > > release notes accompanying the code prior to deployment. 
  28199. > > NS1500 PRI switch type
  28200. > > is not supported in this release. EdgeServer/ESPro gateway 
  28201. > > cards have not been
  28202. > > included or tested for compatibility with TCS 3.5 System release. Once
  28203. > > compatibility has been verified and approved, this disclaimer 
  28204. > > will be removed
  28205. > > and status will be updated on the Software Compatibility Matrix.
  28206. > > 
  28207. > > HiPerDSP v2.0.81
  28208. > > This Service Release has the same functionality and 
  28209. > > limitations of v2.0.19, but
  28210. > > also includes a number of P1 and P2 bug fixes.  Please see 
  28211. > > the release notes
  28212. > > accompanying the code for details on bug fixes and outstanding issues.
  28213. > > 
  28214. > > 
  28215. > > Access the code and release notes in either of the following 
  28216. > > locations:
  28217. > > 
  28218. >         http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
  28219. >                    ( posted under Total Control Hubs )
  28220. >                   or
  28221. >  
  28222. > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
  28223. >                    ( search by Total Control Hubs : Hiper DSP or Hiper ARC )
  28224. > 
  28225. > 
  28226. > If there are any questions or concerns regarding these changes, please
  28227. > contact
  28228. > 3Com Technical Support toll-free at 1-800-231-8770.  If you are calling from
  28229. > an
  28230. > area not handled by this number, the TotalService website has contact
  28231. > information for other countries and regions.  Please go to the TotalService
  28232. > website and click on 'Contacting Tech Support' for more information.
  28233. > 
  28234. > Chuck Stace
  28235. > Customer Service Product Planning
  28236. > Chuck_Stace@3com.com
  28237. > 
  28238. > -
  28239. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28240. >  with "unsubscribe usr-tc" in the body of the message.
  28241. >  For information on digests or retrieving files and old messages send
  28242. >  "help" to the same address.  Do not use quotes in your message.
  28243. > 
  28244. > -
  28245. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28246. >  with "unsubscribe usr-tc" in the body of the message.
  28247. >  For information on digests or retrieving files and old messages send
  28248. >  "help" to the same address.  Do not use quotes in your message.
  28249. > 
  28250.  
  28251.  
  28252. -
  28253.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28254.  with "unsubscribe usr-tc" in the body of the message.
  28255.  For information on digests or retrieving files and old messages send
  28256.  "help" to the same address.  Do not use quotes in your message.
  28257.  
  28258.  
  28259. -------------------------------------------------------------------------------
  28260.  
  28261. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  28262. Subject: RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28263. Date: 21 Oct 1999 16:44:26 -0300
  28264.  
  28265.  
  28266. hmmm..interesting, someone else just reported that to me as well.
  28267. Fortunately I fall into the category of "not interested in HARC 4.2" rather
  28268. than "not entitled to" anyway.  ;-)
  28269.  
  28270.  
  28271.  
  28272. > -----Original Message-----
  28273. > From: pferraro@wna-linknet.com [mailto:pferraro@wna-linknet.com]
  28274. > Sent: Thursday, October 21, 1999 4:35 PM
  28275. > To: Stainforth, Matthew
  28276. > Cc: 'usr-tc@lists.xmission.com'
  28277. > Subject: RE: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28278. > 
  28279. > 
  28280. > 
  28281. >     I just visited the Total Services web site and all of those
  28282. > upgrades are unlocked!!!  You better get them now while you 
  28283. > have a chance!
  28284. > You can not, however download the HARC manager software for the new
  28285. > HiperArc code, so if you are using the windows or unix based HiperArc
  28286. > manager 1.18 now, you can not us it with the newer code.
  28287. > 
  28288. > ==============================================================
  28289. > ================
  28290. > Phillip Ferraro                WorldNet Access, Inc
  28291. > pferraro@wna-linknet.com    Onslow County's PREMIER 
  28292. > InterNet Service 
  28293. > Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  28294. > FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  28295. > ==============================================================
  28296. > ================
  28297. > 
  28298. > On Thu, 21 Oct 1999, Stainforth, Matthew wrote:
  28299. > 
  28300. > > 
  28301. > > How's about releasing HiPerARC 4.1.x that fixes the bugs 
  28302. > for those of us who
  28303. > > don't want or aren't entitled to 4.2.x?
  28304. > > 
  28305. > > > -----Original Message-----
  28306. > > > From: Chuck Stace [mailto:Chuck_Stace@mw.3com.com]
  28307. > > > Sent: Wednesday, October 20, 1999 10:07 AM
  28308. > > > To: usr-tc@lists.xmission.com
  28309. > > > Subject: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28310. > > > 
  28311. > > > 
  28312. > > > 
  28313. > > > 
  28314. > > > 3Com Customers,
  28315. > > > 
  28316. > > > Due to various issues with prior versions of HiPer ARC and 
  28317. > > > HiPer DSP code, 3Com
  28318. > > > is advising that all customers upgrade their HiPer ARC and 
  28319. > > > HiPer DSP cards to
  28320. > > > one of the following versions of code:
  28321. > > > 
  28322. > > > HiPerARC v4.1.59-6
  28323. > > > Service Release for HiPer ARC 4.1.59-6 built from 4.1.72-7. 
  28324. > > > Version 4.1.59-6 is
  28325. > > > an effort to combine many previous Engineering Releases into 
  28326. > > > a generally
  28327. > > > available code release. It addresses a series of P1 and P2 
  28328. > > > issues identified
  28329. > > > with the previous HiPer ARC code release.
  28330. > > > 
  28331. > > > HiPerARC v4.2.32-1
  28332. > > > The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC 
  28333. > > > v4.2.29.  This
  28334. > > > version fixes the upgrade issues from v4.1.59-6, HiPerBomb 
  28335. > > > DoS (Denial of
  28336. > > > Service) attack, and SNMP security issues.
  28337. > > > 
  28338. > > > If customers are using HiPerARC v4.2.29 on their Total 
  28339. > > > Control chassis at this
  28340. > > > time, they are advised to upgrade to v4.2.32-1 as soon as 
  28341. > possible.
  28342. > > > 
  28343. > > > HiPerDSP v2.0.19
  28344. > > > This is the released version of HiPer DSP T1 and T1/PRI, TCS 
  28345. > > > 3.5. Please see the
  28346. > > > release notes accompanying the code prior to deployment. 
  28347. > > > NS1500 PRI switch type
  28348. > > > is not supported in this release. EdgeServer/ESPro gateway 
  28349. > > > cards have not been
  28350. > > > included or tested for compatibility with TCS 3.5 System 
  28351. > release. Once
  28352. > > > compatibility has been verified and approved, this disclaimer 
  28353. > > > will be removed
  28354. > > > and status will be updated on the Software Compatibility Matrix.
  28355. > > > 
  28356. > > > HiPerDSP v2.0.81
  28357. > > > This Service Release has the same functionality and 
  28358. > > > limitations of v2.0.19, but
  28359. > > > also includes a number of P1 and P2 bug fixes.  Please see 
  28360. > > > the release notes
  28361. > > > accompanying the code for details on bug fixes and 
  28362. > outstanding issues.
  28363. > > > 
  28364. > > > 
  28365. > > > Access the code and release notes in either of the following 
  28366. > > > locations:
  28367. > > > 
  28368. > >         
  28369. http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+latest
  28370. >                    ( posted under Total Control Hubs )
  28371. >                   or
  28372. >  
  28373. > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software
  28374. >                    ( search by Total Control Hubs : Hiper DSP or Hiper ARC
  28375. )
  28376. > 
  28377. > 
  28378. > If there are any questions or concerns regarding these changes, please
  28379. > contact
  28380. > 3Com Technical Support toll-free at 1-800-231-8770.  If you are calling
  28381. from
  28382. > an
  28383. > area not handled by this number, the TotalService website has contact
  28384. > information for other countries and regions.  Please go to the
  28385. TotalService
  28386. > website and click on 'Contacting Tech Support' for more information.
  28387. > 
  28388. > Chuck Stace
  28389. > Customer Service Product Planning
  28390. > Chuck_Stace@3com.com
  28391. > 
  28392. > -
  28393. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28394. >  with "unsubscribe usr-tc" in the body of the message.
  28395. >  For information on digests or retrieving files and old messages send
  28396. >  "help" to the same address.  Do not use quotes in your message.
  28397. > 
  28398. > -
  28399. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28400. >  with "unsubscribe usr-tc" in the body of the message.
  28401. >  For information on digests or retrieving files and old messages send
  28402. >  "help" to the same address.  Do not use quotes in your message.
  28403. > 
  28404.  
  28405. -
  28406.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28407.  with "unsubscribe usr-tc" in the body of the message.
  28408.  For information on digests or retrieving files and old messages send
  28409.  "help" to the same address.  Do not use quotes in your message.
  28410.  
  28411.  
  28412. -------------------------------------------------------------------------------
  28413.  
  28414. From: Jeff Mcadams <jeffm@iglou.com>
  28415. Subject: Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28416. Date: 21 Oct 1999 15:54:53 -0400
  28417.  
  28418. Thus spake Stainforth, Matthew
  28419. >hmmm..interesting, someone else just reported that to me as well.
  28420. >Fortunately I fall into the category of "not interested in HARC 4.2" rather
  28421. >than "not entitled to" anyway.  ;-)
  28422.  
  28423. Actually...4.2.x isn't that drastic of a change...bug fixes and adds
  28424. frame-relay (for the new NICs) and OSPF...other than that, there just
  28425. really isn't that much difference.  If you're not interested in OSPF or
  28426. frame, it might be worth it to get it for the bug fixes (some of which
  28427. aren't insignificant).  I don't see too much downside on it at this
  28428. point, they already released the first version (4.2.29) and made their
  28429. mistakes  :)  4.2.32 looks to be pretty solid from what I've seen.  I
  28430. haven't upgraded throughout my network yet, but that's more an issue of
  28431. not having the hours in the day to do it yet than not wanting to.  :)
  28432. -- 
  28433. Jeff McAdams                            Email: jeffm@iglou.com
  28434. Head Network Administrator              Voice: (502) 966-3848
  28435. IgLou Internet Services                        (800) 436-4456
  28436.  
  28437. -
  28438.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28439.  with "unsubscribe usr-tc" in the body of the message.
  28440.  For information on digests or retrieving files and old messages send
  28441.  "help" to the same address.  Do not use quotes in your message.
  28442.  
  28443.  
  28444. -------------------------------------------------------------------------------
  28445.  
  28446. From: Jeff Mcadams <jeffm@iglou.com>
  28447. Subject: (usr-tc) Question re: L2TP
  28448. Date: 21 Oct 1999 15:58:53 -0400
  28449.  
  28450. Hrmm...was browsing through the 4.2 Harc product reference and noticed
  28451. something...there is the following note:
  28452.  
  28453.     A HiPer ARC may only be set as the LAC.  It can not be set as an
  28454.     LNS....
  28455.  
  28456. I'm curious...I went back into the 4.1 config guide and this language
  28457. was not in there that I found.  Has this functionality been removed in
  28458. 4.2?  I know it works in 4.1.59-6 'cause I'm using it on one of my Arcs.
  28459. It would really suck if it was gone in 4.2.  :)  I did check my system
  28460. that I have running 4.2 as a testbed, and the "enable l2tp lns" command
  28461. is still there, and it *seems* to still enable the actual lns
  28462. functionality (though I don't have an easy setup to test this out at the
  28463. moment).
  28464.  
  28465. What's up with this note in the 4.2 product reference?
  28466. -- 
  28467. Jeff McAdams                            Email: jeffm@iglou.com
  28468. Head Network Administrator              Voice: (502) 966-3848
  28469. IgLou Internet Services                        (800) 436-4456
  28470.  
  28471. -
  28472.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28473.  with "unsubscribe usr-tc" in the body of the message.
  28474.  For information on digests or retrieving files and old messages send
  28475.  "help" to the same address.  Do not use quotes in your message.
  28476.  
  28477.  
  28478. -------------------------------------------------------------------------------
  28479.  
  28480. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  28481. Subject: RE: (usr-tc) Question re: L2TP
  28482. Date: 21 Oct 1999 15:31:56 -0700
  28483.  
  28484.  
  28485.  
  28486. > -----Original Message-----
  28487. > From: owner-usr-tc@lists.xmission.com
  28488. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
  28489. > Sent: Thursday, October 21, 1999 12:59 PM
  28490. > To: usr-tc@lists.xmission.com
  28491. > Subject: (usr-tc) Question re: L2TP
  28492. >
  28493. >
  28494. > Hrmm...was browsing through the 4.2 Harc product reference and noticed
  28495. > something...there is the following note:
  28496. >
  28497. >     A HiPer ARC may only be set as the LAC.  It can not be set as an
  28498. >     LNS....
  28499. >
  28500. > I'm curious...I went back into the 4.1 config guide and this language
  28501. > was not in there that I found.  Has this functionality been removed in
  28502. > 4.2?  I know it works in 4.1.59-6 'cause I'm using it on one of my Arcs.
  28503. > It would really suck if it was gone in 4.2.  :)  I did check my system
  28504. > that I have running 4.2 as a testbed, and the "enable l2tp lns" command
  28505. > is still there, and it *seems* to still enable the actual lns
  28506. > functionality (though I don't have an easy setup to test this out at the
  28507. > moment).
  28508. >
  28509. > What's up with this note in the 4.2 product reference?
  28510.  
  28511. L2TP LNS was only functional tested and not stress/load tested. Therefore we
  28512. are not supporting scaled use of a HiperARC as LNS in the 4.2 code base.
  28513. This will not be the case in HARC 5.0.
  28514.  
  28515. -m
  28516.  
  28517.  
  28518. -
  28519.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28520.  with "unsubscribe usr-tc" in the body of the message.
  28521.  For information on digests or retrieving files and old messages send
  28522.  "help" to the same address.  Do not use quotes in your message.
  28523.  
  28524.  
  28525. -------------------------------------------------------------------------------
  28526.  
  28527. From: Jeff Mcadams <jeffm@iglou.com>
  28528. Subject: Re: (usr-tc) Question re: L2TP
  28529. Date: 21 Oct 1999 16:41:45 -0400
  28530.  
  28531. Thus spake Mike Wronski
  28532. >> Hrmm...was browsing through the 4.2 Harc product reference and noticed
  28533. >> something...there is the following note:
  28534.  
  28535. >>     A HiPer ARC may only be set as the LAC.  It can not be set as an
  28536. >>     LNS....
  28537.  
  28538. >> I'm curious...I went back into the 4.1 config guide and this language
  28539. >> was not in there that I found.  Has this functionality been removed in
  28540. >> 4.2?  I know it works in 4.1.59-6 'cause I'm using it on one of my Arcs.
  28541. >> It would really suck if it was gone in 4.2.  :)  I did check my system
  28542. >> that I have running 4.2 as a testbed, and the "enable l2tp lns" command
  28543. >> is still there, and it *seems* to still enable the actual lns
  28544. >> functionality (though I don't have an easy setup to test this out at the
  28545. >> moment).
  28546.  
  28547. >> What's up with this note in the 4.2 product reference?
  28548.  
  28549. >L2TP LNS was only functional tested and not stress/load tested. Therefore we
  28550. >are not supporting scaled use of a HiperARC as LNS in the 4.2 code base.
  28551. >This will not be the case in HARC 5.0.
  28552.  
  28553. A'ight...makes sense.  Maybe this could be explained better in manuals
  28554. in the future?  I dunno...might cause some confusion...but I guess
  28555. that's probably gonna happen now matter how you say it (witness my
  28556. confusion :/ )
  28557.  
  28558. Thanks for the answer anyway.  :)
  28559. -- 
  28560. Jeff McAdams                            Email: jeffm@iglou.com
  28561. Head Network Administrator              Voice: (502) 966-3848
  28562. IgLou Internet Services                        (800) 436-4456
  28563.  
  28564. -
  28565.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28566.  with "unsubscribe usr-tc" in the body of the message.
  28567.  For information on digests or retrieving files and old messages send
  28568.  "help" to the same address.  Do not use quotes in your message.
  28569.  
  28570.  
  28571. -------------------------------------------------------------------------------
  28572.  
  28573. From: jlf@montrose-colo.com (Jim Faulkner)
  28574. Subject: (usr-tc) Y2K and TC Radius
  28575. Date: 21 Oct 1999 15:12:43 -0600
  28576.  
  28577. Hello,
  28578.  
  28579. Does anybody know what issues TC Radius 5.5.3 has with Y2K. Do I really need
  28580. to spend $5-600.00 on the 6+ version?
  28581.  
  28582. Thanks You,
  28583. Jim Faulkner
  28584. GWE.NET
  28585. DigitalDuck.com
  28586.  
  28587.  
  28588. -
  28589.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28590.  with "unsubscribe usr-tc" in the body of the message.
  28591.  For information on digests or retrieving files and old messages send
  28592.  "help" to the same address.  Do not use quotes in your message.
  28593.  
  28594.  
  28595. -------------------------------------------------------------------------------
  28596.  
  28597. From:  <farber@admin.f-tech.net>
  28598. Subject: Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28599. Date: 21 Oct 1999 18:52:25 -0400 (EDT)
  28600.  
  28601. I've run 4.0.59-6 and 2.0.19 for 4+ months and switched to 2.0.81 and the
  28602. phone wouldn't stop ringing..... dropped connections, poor connects etc.
  28603.  
  28604. *MY* experience shows that 4.0.59-6 and 2.0.19 are very reliable (for what
  28605. that means now adays).
  28606.  
  28607. Paul Farber
  28608. Farber Technology
  28609. farber@admin.f-tech.net
  28610. Ph  570-628-5303
  28611. Fax 570-628-5545
  28612.  
  28613. On Thu, 21 Oct 1999, Jeff Mcadams wrote:
  28614.  
  28615. > Thus spake Stainforth, Matthew
  28616. > >hmmm..interesting, someone else just reported that to me as well.
  28617. > >Fortunately I fall into the category of "not interested in HARC 4.2" rather
  28618. > >than "not entitled to" anyway.  ;-)
  28619. > 
  28620. > Actually...4.2.x isn't that drastic of a change...bug fixes and adds
  28621. > frame-relay (for the new NICs) and OSPF...other than that, there just
  28622. > really isn't that much difference.  If you're not interested in OSPF or
  28623. > frame, it might be worth it to get it for the bug fixes (some of which
  28624. > aren't insignificant).  I don't see too much downside on it at this
  28625. > point, they already released the first version (4.2.29) and made their
  28626. > mistakes  :)  4.2.32 looks to be pretty solid from what I've seen.  I
  28627. > haven't upgraded throughout my network yet, but that's more an issue of
  28628. > not having the hours in the day to do it yet than not wanting to.  :)
  28629. > -- 
  28630. > Jeff McAdams                            Email: jeffm@iglou.com
  28631. > Head Network Administrator              Voice: (502) 966-3848
  28632. > IgLou Internet Services                        (800) 436-4456
  28633. > 
  28634. > -
  28635. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28636. >  with "unsubscribe usr-tc" in the body of the message.
  28637. >  For information on digests or retrieving files and old messages send
  28638. >  "help" to the same address.  Do not use quotes in your message.
  28639. > 
  28640.  
  28641.  
  28642. -
  28643.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28644.  with "unsubscribe usr-tc" in the body of the message.
  28645.  For information on digests or retrieving files and old messages send
  28646.  "help" to the same address.  Do not use quotes in your message.
  28647.  
  28648.  
  28649. -------------------------------------------------------------------------------
  28650.  
  28651. From: Brian <signal@shreve.net>
  28652. Subject: Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28653. Date: 21 Oct 1999 17:55:37 -0500 (CDT)
  28654.  
  28655. On Thu, 21 Oct 1999, Jeff Mcadams wrote:
  28656.  
  28657. > Thus spake Stainforth, Matthew
  28658. > >hmmm..interesting, someone else just reported that to me as well.
  28659. > >Fortunately I fall into the category of "not interested in HARC 4.2" rather
  28660. > >than "not entitled to" anyway.  ;-)
  28661. > 
  28662. > Actually...4.2.x isn't that drastic of a change...bug fixes and adds
  28663. > frame-relay (for the new NICs) and OSPF...other than that, there just
  28664. > really isn't that much difference.  If you're not interested in OSPF or
  28665.  
  28666. well, I like OSPF........but the few people here posting wierd routing
  28667. issues surrounding 4.2.x (like default routes disappearing)......has kept
  28668. me from running it.  
  28669.  
  28670. Also, I have heard 3com say that you need 128MB per ARC to do 4.2.x, and I
  28671. have a couple arc's still at 64MB.  I have also heard that you only need
  28672. 128MB if you do ipx............does anyone know the truth?  I wouldn't
  28673. think a few hundred or even thousand ospf routes is going to use 128MB.
  28674.  
  28675. > frame, it might be worth it to get it for the bug fixes (some of which
  28676. > aren't insignificant).  I don't see too much downside on it at this
  28677. > point, they already released the first version (4.2.29) and made their
  28678. > mistakes  :)  4.2.32 looks to be pretty solid from what I've seen.  I
  28679. > haven't upgraded throughout my network yet, but that's more an issue of
  28680. > not having the hours in the day to do it yet than not wanting to.  :)
  28681. > -- 
  28682. > Jeff McAdams                            Email: jeffm@iglou.com
  28683. > Head Network Administrator              Voice: (502) 966-3848
  28684. > IgLou Internet Services                        (800) 436-4456
  28685. > 
  28686. > -
  28687. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28688. >  with "unsubscribe usr-tc" in the body of the message.
  28689. >  For information on digests or retrieving files and old messages send
  28690. >  "help" to the same address.  Do not use quotes in your message.
  28691. > 
  28692.  
  28693. Brian Feeny (BF304)     signal@shreve.net   
  28694. 318-222-2638 x 109    http://www.shreve.net/~signal      
  28695. Network Administrator   ShreveNet Inc. (ASN 11881)           
  28696.  
  28697.  
  28698. -
  28699.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28700.  with "unsubscribe usr-tc" in the body of the message.
  28701.  For information on digests or retrieving files and old messages send
  28702.  "help" to the same address.  Do not use quotes in your message.
  28703.  
  28704.  
  28705. -------------------------------------------------------------------------------
  28706.  
  28707. From: Jeff Mcadams <jeffm@iglou.com>
  28708. Subject: Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  28709. Date: 21 Oct 1999 19:34:05 -0400
  28710.  
  28711. Thus spake Brian
  28712. >well, I like OSPF........but the few people here posting wierd routing
  28713. >issues surrounding 4.2.x (like default routes disappearing)......has kept
  28714. >me from running it.  
  28715.  
  28716. Yeah...I don't think I'm quite ready to enable OSPF on them yet...that
  28717. still has a bit of settling to do...but if you leave that turned off,
  28718. 4.2 is quite a solid release from what little I've seen so far.  Might
  28719. be worth it to pick up the bug fixes anyway.
  28720.  
  28721. >Also, I have heard 3com say that you need 128MB per ARC to do 4.2.x, and I
  28722. >have a couple arc's still at 64MB.  I have also heard that you only need
  28723. >128MB if you do ipx............does anyone know the truth?  I wouldn't
  28724. >think a few hundred or even thousand ospf routes is going to use 128MB.
  28725.  
  28726. I highly doubt you need 128MB for any release of the HiPer Arc
  28727. code...not unless 3Com is worse with memory management than I ever
  28728. imagined!
  28729. -- 
  28730. Jeff McAdams                            Email: jeffm@iglou.com
  28731. Head Network Administrator              Voice: (502) 966-3848
  28732. IgLou Internet Services                        (800) 436-4456
  28733.  
  28734. -
  28735.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28736.  with "unsubscribe usr-tc" in the body of the message.
  28737.  For information on digests or retrieving files and old messages send
  28738.  "help" to the same address.  Do not use quotes in your message.
  28739.  
  28740.  
  28741. -------------------------------------------------------------------------------
  28742.  
  28743. From: Blake Fithen <fithen@NetworksPlus.com>
  28744. Subject: RE: (usr-tc) 3com V90 Problems
  28745. Date: 21 Oct 1999 20:08:29 -0500
  28746.  
  28747. Could i trouble you for a copy of this Paul?
  28748.  
  28749. thanks, blake
  28750.  
  28751. > -----Original Message-----
  28752. > From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net]
  28753. > Sent: Monday, October 18, 1999 10:45 AM
  28754. > To: usr-tc@lists.xmission.com
  28755. > Subject: Re: (usr-tc) 3com V90 Problems
  28756. > 
  28757. > 
  28758. > It's a perl script.  Not to accurate (3Com's off by one snmp 
  28759. > errors) and
  28760. > my inability to write good perl code).
  28761. > 
  28762. > Give me an address and I send it to you.
  28763. > 
  28764. > Paul Farber
  28765. > Farber Technology
  28766. > farber@admin.f-tech.net
  28767. > Ph  570-628-5303
  28768. > Fax 570-628-5545
  28769. > 
  28770. > On Mon, 18 Oct 1999, K Mitchell wrote:
  28771. > 
  28772. > > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
  28773. > > >BINGO!  We have a winner.
  28774. > > >
  28775. > > >I have had a lot of good experiences with making a 
  28776. > "Connection Page" that
  28777. > > >shows connection speeds lifted from the NMC card.  Most 
  28778. > people hit that
  28779. > > >page after they log in and see what the DSP's say they are getting.
  28780. > > >Ususally they are happy to see that they are "in the 
  28781. > green" even though
  28782. > > >the band is from 37K to 53K.
  28783. > > 
  28784. > > Care to share your mrtg.cfg entry for this?  :)
  28785. > > 
  28786. > > 
  28787. > > -- 
  28788. > > Kirk Mitchell-General Manager        mitch@keyconn.net
  28789. > > Keystone Connect                     Unlock Your World
  28790. > > Altoona, PA   814-941-5000      http://www.keyconn.net
  28791. > > 
  28792. > > 
  28793. > > -
  28794. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28795. > >  with "unsubscribe usr-tc" in the body of the message.
  28796. > >  For information on digests or retrieving files and old 
  28797. > messages send
  28798. > >  "help" to the same address.  Do not use quotes in your message.
  28799. > > 
  28800. > 
  28801. > 
  28802. > -
  28803. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28804. >  with "unsubscribe usr-tc" in the body of the message.
  28805. >  For information on digests or retrieving files and old messages send
  28806. >  "help" to the same address.  Do not use quotes in your message.
  28807. > 
  28808.  
  28809. -
  28810.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28811.  with "unsubscribe usr-tc" in the body of the message.
  28812.  For information on digests or retrieving files and old messages send
  28813.  "help" to the same address.  Do not use quotes in your message.
  28814.  
  28815.  
  28816. -------------------------------------------------------------------------------
  28817.  
  28818. From: "Ed" <ed@taylors.com>
  28819. Subject: Re: (usr-tc) 3com V90 Problems
  28820. Date: 21 Oct 1999 21:37:20 -0400
  28821.  
  28822. Yes could I also obtain a copy?
  28823.  
  28824. Thanks!
  28825.  
  28826. Ed
  28827.  
  28828. ----- Original Message ----- 
  28829. Sent: Thursday, October 21, 1999 9:08 PM
  28830.  
  28831.  
  28832. Could i trouble you for a copy of this Paul?
  28833.  
  28834. thanks, blake
  28835.  
  28836. > -----Original Message-----
  28837. > From: farber@admin.f-tech.net [mailto:farber@admin.f-tech.net]
  28838. > Sent: Monday, October 18, 1999 10:45 AM
  28839. > To: usr-tc@lists.xmission.com
  28840. > Subject: Re: (usr-tc) 3com V90 Problems
  28841. > 
  28842. > 
  28843. > It's a perl script.  Not to accurate (3Com's off by one snmp 
  28844. > errors) and
  28845. > my inability to write good perl code).
  28846. > 
  28847. > Give me an address and I send it to you.
  28848. > 
  28849. > Paul Farber
  28850. > Farber Technology
  28851. > farber@admin.f-tech.net
  28852. > Ph  570-628-5303
  28853. > Fax 570-628-5545
  28854. > 
  28855. > On Mon, 18 Oct 1999, K Mitchell wrote:
  28856. > 
  28857. > > At 09:45 AM 10/18/99 -0400, Paul Farber wrote:
  28858. > > >BINGO!  We have a winner.
  28859. > > >
  28860. > > >I have had a lot of good experiences with making a 
  28861. > "Connection Page" that
  28862. > > >shows connection speeds lifted from the NMC card.  Most 
  28863. > people hit that
  28864. > > >page after they log in and see what the DSP's say they are getting.
  28865. > > >Ususally they are happy to see that they are "in the 
  28866. > green" even though
  28867. > > >the band is from 37K to 53K.
  28868. > > 
  28869. > > Care to share your mrtg.cfg entry for this?  :)
  28870. > > 
  28871. > > 
  28872. > > -- 
  28873. > > Kirk Mitchell-General Manager        mitch@keyconn.net
  28874. > > Keystone Connect                     Unlock Your World
  28875. > > Altoona, PA   814-941-5000      http://www.keyconn.net
  28876. > > 
  28877. > > 
  28878. > > -
  28879. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28880. > >  with "unsubscribe usr-tc" in the body of the message.
  28881. > >  For information on digests or retrieving files and old 
  28882. > messages send
  28883. > >  "help" to the same address.  Do not use quotes in your message.
  28884. > > 
  28885. > 
  28886. > 
  28887. > -
  28888. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28889. >  with "unsubscribe usr-tc" in the body of the message.
  28890. >  For information on digests or retrieving files and old messages send
  28891. >  "help" to the same address.  Do not use quotes in your message.
  28892. > 
  28893.  
  28894. -
  28895.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28896.  with "unsubscribe usr-tc" in the body of the message.
  28897.  For information on digests or retrieving files and old messages send
  28898.  "help" to the same address.  Do not use quotes in your message.
  28899.  
  28900.  
  28901.  
  28902. -
  28903.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28904.  with "unsubscribe usr-tc" in the body of the message.
  28905.  For information on digests or retrieving files and old messages send
  28906.  "help" to the same address.  Do not use quotes in your message.
  28907.  
  28908.  
  28909. -------------------------------------------------------------------------------
  28910.  
  28911. From: Vadim Tulinov <Vadim_Tulinov@rrc.ru>
  28912. Subject: (usr-tc) Edgeserver & Solaris
  28913. Date: 22 Oct 1999 13:29:34 +0300
  28914.  
  28915. Hello,
  28916.  
  28917. I have hardware without soft on my table and access on
  28918. totalservice.usr.com. I haven'd found anything about UNIX installation.
  28919. Does anybody organize the Edgeserver installation with Solaris (or any
  28920. other version)?
  28921. Where can I get information about this case and where I can download
  28922. drivers for packet bus (serial ports)?
  28923. What does type of ethernet NIC Edgeserver use?
  28924.  
  28925. Best regards,
  28926. Vadim Tulinov.
  28927.  
  28928.  
  28929.  
  28930. -
  28931.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28932.  with "unsubscribe usr-tc" in the body of the message.
  28933.  For information on digests or retrieving files and old messages send
  28934.  "help" to the same address.  Do not use quotes in your message.
  28935.  
  28936.  
  28937. -------------------------------------------------------------------------------
  28938.  
  28939. From: Dataheart <lists@dataheart.net>
  28940. Subject: (usr-tc) DSP Newbie
  28941. Date: 22 Oct 1999 21:56:54 +1000
  28942.  
  28943. Hi,
  28944. After using quad modems for about 2-3 years for POTS connections I have
  28945. recently installed some HiPer DSP's for some clients who would like
  28946. digital connections.
  28947. I downloaded the code from the Total Service web site only to find
  28948. instead of the usual .nac and .sdl file (which I am used to) I find a
  28949. .dmf file and no .sdl
  28950. When trying to update my firmware I find that TCM will not accept the
  28951. Software download without a .sdl file.
  28952.  
  28953. Where am I going wrong?
  28954.  
  28955. Thanks,
  28956. Aaron
  28957.  
  28958.  
  28959. -
  28960.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28961.  with "unsubscribe usr-tc" in the body of the message.
  28962.  For information on digests or retrieving files and old messages send
  28963.  "help" to the same address.  Do not use quotes in your message.
  28964.  
  28965.  
  28966. -------------------------------------------------------------------------------
  28967.  
  28968. From: "William Knauf" <William_Knauf@mw.3com.com>
  28969. Subject: Re: (usr-tc) Edgeserver & Solaris
  28970. Date: 22 Oct 1999 10:22:45 -0500
  28971.  
  28972.  
  28973.  
  28974.  
  28975. USR only released ethernet NIC support for the EdgeServer PRO on Unix. There is
  28976. a NIC driver for Solaris 2.6 and a NIC driver for BSDI 3.0. There were never any
  28977. packetbus drivers released for unix.
  28978.  
  28979. I still have an old (very old) link to the beta page .. note, it says beta, but
  28980. this is the version that released.
  28981.  
  28982. http://reverb.ae.usr.com/edgepro/solaris/solaris.htm
  28983.  
  28984. Bill k
  28985.  
  28986.  
  28987.  
  28988.  
  28989.  
  28990. Vadim Tulinov <Vadim_Tulinov@rrc.ru> on 10/22/99 05:29:34 AM
  28991.  
  28992. Please respond to usr-tc@lists.xmission.com
  28993.  
  28994. Sent by:  Vadim Tulinov <Vadim_Tulinov@rrc.ru>
  28995.  
  28996.  
  28997. cc:    (William Knauf/MW/US/3Com)
  28998.  
  28999.  
  29000.  
  29001.  
  29002. Hello,
  29003.  
  29004. I have hardware without soft on my table and access on
  29005. totalservice.usr.com. I haven'd found anything about UNIX installation.
  29006. Does anybody organize the Edgeserver installation with Solaris (or any
  29007. other version)?
  29008. Where can I get information about this case and where I can download
  29009. drivers for packet bus (serial ports)?
  29010. What does type of ethernet NIC Edgeserver use?
  29011.  
  29012. Best regards,
  29013. Vadim Tulinov.
  29014.  
  29015.  
  29016.  
  29017. -
  29018.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29019.  with "unsubscribe usr-tc" in the body of the message.
  29020.  For information on digests or retrieving files and old messages send
  29021.  "help" to the same address.  Do not use quotes in your message.
  29022.  
  29023.  
  29024.  
  29025.  
  29026.  
  29027. -
  29028.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29029.  with "unsubscribe usr-tc" in the body of the message.
  29030.  For information on digests or retrieving files and old messages send
  29031.  "help" to the same address.  Do not use quotes in your message.
  29032.  
  29033.  
  29034. -------------------------------------------------------------------------------
  29035.  
  29036. From: "ck" <administrator@eagnet.com>
  29037. Subject: (usr-tc) 3Com SA Server Event Logging
  29038. Date: 22 Oct 1999 13:50:26 -0400
  29039.  
  29040. This is a multi-part message in MIME format.
  29041.  
  29042. ------=_NextPart_000_0006_01BF1C94.657A88D0
  29043. Content-Type: text/plain;
  29044.     charset="iso-8859-1"
  29045. Content-Transfer-Encoding: 7bit
  29046.  
  29047. Hello:
  29048.  
  29049. We are currently testing 3Com's SA Server 6.09 on Windows NT 4, SP5.  So far
  29050. we have Authentication and Accounting working as we need it, except as noted
  29051. below; however I seem to be missing something with the Event Logging.  I
  29052. have no problem getting connection info from the NMC, but what we are in
  29053. need of is a log of Successful Logins, Failed Logins and Security Breaches.
  29054. I have those features seemingly enabled via the Database Manager, but no
  29055. info is being logged. I gather from the manual this info should be written
  29056. to the Events table.  Accounting info written to the Calls table is no
  29057. problem.  I would like to have the desired information available to our help
  29058. desk via queries from the Event table.  Any ideas?  We have TC hubs with
  29059. Netserver and Arcs, as well as old Livingston PM3's and Ascend Maxen.
  29060.  
  29061. Also, concerning the Maxen, we cannot seem to authenticate through SA, only
  29062. get accounting info.  Any help on this would also be greatly appreciated.
  29063. Thanks in advance!
  29064.  
  29065. Charles Kimes, Administrator
  29066. EagleNet DataCommunications, Inc.
  29067. 1921 Osborne Rd. Ste. 4
  29068. St. Marys, GA 31558
  29069. (912) 882-8406
  29070. FAX (912) 882-8408
  29071. administrator@eagnet.com
  29072.  
  29073.  
  29074. ------=_NextPart_000_0006_01BF1C94.657A88D0
  29075. Content-Type: text/html;
  29076.     charset="iso-8859-1"
  29077. Content-Transfer-Encoding: quoted-printable
  29078.  
  29079. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  29080. <HTML>
  29081. <HEAD>
  29082. <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
  29083. charset=3Diso-8859-1">
  29084.  
  29085.  
  29086.  
  29087. <META content=3D'"MSHTML 4.72.3612.1700"' name=3DGENERATOR>
  29088. </HEAD>
  29089. <BODY bgColor=3D#ffffff>
  29090. <DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
  29091.  
  29092. size=3D2>Hello:</FONT></SPAN></DIV>
  29093. <DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
  29094.  
  29095. size=3D2></FONT></SPAN> </DIV>
  29096. <DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
  29097. size=3D2>We are=20
  29098. currently testing 3Com's SA Server 6.09 on Windows NT 4, SP5.  So =
  29099. far we=20
  29100. have Authentication and Accounting working as we need it, except as =
  29101. noted below;=20
  29102. however I seem to be missing something with the Event Logging.  I =
  29103. have no=20
  29104. problem getting connection info from the NMC, but what we are in need of =
  29105. is a=20
  29106. log of Successful Logins, Failed Logins and Security Breaches.  I =
  29107. have=20
  29108. those features seemingly enabled via the Database Manager, but no info =
  29109. is being=20
  29110. logged. I gather from the manual this info should be written to the =
  29111. Events=20
  29112. table.  Accounting info written to the Calls table is no =
  29113. problem.  I=20
  29114. would like to have the desired information available to our help desk =
  29115. via=20
  29116. queries from the Event table.  Any ideas?  We have TC hubs =
  29117. with=20
  29118. Netserver and Arcs, as well as old Livingston PM3's and Ascend=20
  29119. Maxen.</FONT></SPAN></DIV>
  29120. <DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
  29121.  
  29122. size=3D2></FONT></SPAN> </DIV>
  29123. <DIV><SPAN class=3D996292617-22101999><FONT color=3D#000000 face=3DArial =
  29124. size=3D2>Also,=20
  29125. concerning the Maxen, we cannot seem to authenticate through SA, only =
  29126. get=20
  29127. accounting info.  Any help on this would also be greatly =
  29128. appreciated. =20
  29129. Thanks in advance!</FONT></SPAN></DIV>
  29130. <DIV> </DIV>
  29131. <DIV><FONT color=3D#000000 face=3DArial size=3D2>Charles Kimes,=20
  29132. Administrator</FONT></DIV>
  29133. <DIV><FONT color=3D#000000 face=3DArial size=3D2>EagleNet =
  29134. DataCommunications,=20
  29135. Inc.</FONT></DIV>
  29136. <DIV><FONT color=3D#000000 face=3DArial size=3D2>1921 Osborne Rd. Ste. =
  29137. 4</FONT></DIV>
  29138. <DIV><FONT color=3D#000000 face=3DArial size=3D2>St. Marys, GA =
  29139. 31558</FONT></DIV>
  29140. <DIV><FONT color=3D#000000 face=3DArial size=3D2>(912) =
  29141. 882-8406</FONT></DIV>
  29142. <DIV><FONT color=3D#000000 face=3DArial size=3D2>FAX (912) =
  29143. 882-8408</FONT></DIV>
  29144. <DIV><FONT color=3D#000000 face=3DArial size=3D2><A=20
  29145. href=3D"mailto:administrator@eagnet.com">administrator@eagnet.com</A></FO=
  29146. NT></DIV>
  29147. <DIV> </DIV></BODY></HTML>
  29148.  
  29149. ------=_NextPart_000_0006_01BF1C94.657A88D0--
  29150.  
  29151.  
  29152. -
  29153.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29154.  with "unsubscribe usr-tc" in the body of the message.
  29155.  For information on digests or retrieving files and old messages send
  29156.  "help" to the same address.  Do not use quotes in your message.
  29157.  
  29158.  
  29159. -------------------------------------------------------------------------------
  29160.  
  29161. From: Jeff Mcadams <jeffm@iglou.com>
  29162. Subject: (usr-tc) set modem_group all prompt_timeout
  29163. Date: 22 Oct 1999 14:32:19 -0400
  29164.  
  29165. What is this command (in 4.2.x) "set modem_group all prompt_timeout"?
  29166.  
  29167. Its not in the 4.2 Command Reference.  I can make a guess at it, but if
  29168. its what I'm thinking, it would be the same thing as prompt_delay.
  29169.  
  29170. How do prompt_delay and prompt_timeout differ?
  29171. -- 
  29172. Jeff McAdams                            Email: jeffm@iglou.com
  29173. Head Network Administrator              Voice: (502) 966-3848
  29174. IgLou Internet Services                        (800) 436-4456
  29175.  
  29176. -
  29177.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29178.  with "unsubscribe usr-tc" in the body of the message.
  29179.  For information on digests or retrieving files and old messages send
  29180.  "help" to the same address.  Do not use quotes in your message.
  29181.  
  29182.  
  29183. -------------------------------------------------------------------------------
  29184.  
  29185. From: Mike Andrews <mandrews@bit0.com>
  29186. Subject: Re: (usr-tc) NOTICE: HiPer ARC and HiPer DSP code
  29187. Date: 22 Oct 1999 17:23:37 -0400 (EDT)
  29188.  
  29189. On Thu, 21 Oct 1999, Brian wrote:
  29190.  
  29191. > Also, I have heard 3com say that you need 128MB per ARC to do 4.2.x, and I
  29192. > have a couple arc's still at 64MB.  I have also heard that you only need
  29193. > 128MB if you do ipx............does anyone know the truth?  I wouldn't
  29194. > think a few hundred or even thousand ospf routes is going to use 128MB.
  29195.  
  29196. 64 meg works OK here.  6 quads, 6 DSP's, OSPF w/ about 50 routes, IP only:
  29197.  
  29198. fra1-arc> _show ver
  29199. V4.2.32 - 1
  29200. fra1-arc> show mem
  29201.  
  29202. SYSTEM MEMORY RESOURCES
  29203. Total System Memory Resources:             52087 KB
  29204. Free Memory:                               26148 KB
  29205. Code Size:                                 4290 KB
  29206. Initialized Data Size:                     755 KB
  29207. Uninitialized Data Size:                   4055 KB
  29208. Stack Size:                                512 KB
  29209.  
  29210.  
  29211.  
  29212. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  29213. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  29214. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  29215. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  29216.  
  29217.  
  29218. -
  29219.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29220.  with "unsubscribe usr-tc" in the body of the message.
  29221.  For information on digests or retrieving files and old messages send
  29222.  "help" to the same address.  Do not use quotes in your message.
  29223.  
  29224.  
  29225. -------------------------------------------------------------------------------
  29226.  
  29227. From: Mike Andrews <mandrews@bit0.com>
  29228. Subject: Re: (usr-tc) Still having problems with default routes disappearing
  29229. Date: 22 Oct 1999 17:26:31 -0400 (EDT)
  29230.  
  29231. I had a problem with ALL my OSPF routes disappearing in certain cases,
  29232. usually when one of my Ciscos rebooted...  check the archives a few weeks
  29233. ago.  Up until the Ciscos rebooted (I did IOS upgrades) everything ran
  29234. perfectly, then just out of the blue, bang, no routing...
  29235.  
  29236. The apparent fix (read: it hasn't happened since) is to make sure all of
  29237. your non-3Com routers have an OSPF priority higher than 0 -- which keeps
  29238. the ARCs from becoming an OSPF designated router or backup designated
  29239. router.
  29240.  
  29241.  
  29242. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  29243. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  29244. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  29245. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  29246.  
  29247. On Mon, 18 Oct 1999, Mike McHenry wrote:
  29248.  
  29249. > 
  29250. > Last week I mentioned that I have been having problems on several of my
  29251. > chassis with the default route just disappearing. To this date I have still
  29252. > not found a cause for this abnormal behavior. I am almost positive it is not
  29253. > a configuration issue although I am still open to any suggestions as far as
  29254. > that goes.
  29255. > 
  29256. > This problem just started occuring about a week ago and it does not recur
  29257. > with any sort of pattern.  I am running 4.2.32-1 on the ARCs. I am also
  29258. > running OSPF on the chassis now but I don't think it is a direct OSPF
  29259. > problem. The things ran flawlessly for several weeks with OSPF routing and
  29260. > 4.2.32-1 before I started having this problem.
  29261. > 
  29262. > Has anyone been having any sort of odd problems with OSPF or 4.2.32-1? I
  29263. > would really like to get this resolved and I am at a loss right now. Any
  29264. > comments or suggestions would be appreciated...
  29265. > 
  29266. > Mike McHenry
  29267. >  Systems Administrator
  29268. >  MinnNet Communications, Inc.
  29269. > 
  29270. > 
  29271. > -
  29272. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29273. >  with "unsubscribe usr-tc" in the body of the message.
  29274. >  For information on digests or retrieving files and old messages send
  29275. >  "help" to the same address.  Do not use quotes in your message.
  29276. > 
  29277.  
  29278.  
  29279. -
  29280.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29281.  with "unsubscribe usr-tc" in the body of the message.
  29282.  For information on digests or retrieving files and old messages send
  29283.  "help" to the same address.  Do not use quotes in your message.
  29284.  
  29285.  
  29286. -------------------------------------------------------------------------------
  29287.  
  29288. From: Mike Andrews <mandrews@bit0.com>
  29289. Subject: Re: (usr-tc) Still having problems with default routes disappearing
  29290. Date: 22 Oct 1999 17:26:31 -0400 (EDT)
  29291.  
  29292. I had a problem with ALL my OSPF routes disappearing in certain cases,
  29293. usually when one of my Ciscos rebooted...  check the archives a few weeks
  29294. ago.  Up until the Ciscos rebooted (I did IOS upgrades) everything ran
  29295. perfectly, then just out of the blue, bang, no routing...
  29296.  
  29297. The apparent fix (read: it hasn't happened since) is to make sure all of
  29298. your non-3Com routers have an OSPF priority higher than 0 -- which keeps
  29299. the ARCs from becoming an OSPF designated router or backup designated
  29300. router.
  29301.  
  29302.  
  29303. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  29304. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  29305. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  29306. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  29307.  
  29308. On Mon, 18 Oct 1999, Mike McHenry wrote:
  29309.  
  29310. > 
  29311. > Last week I mentioned that I have been having problems on several of my
  29312. > chassis with the default route just disappearing. To this date I have still
  29313. > not found a cause for this abnormal behavior. I am almost positive it is not
  29314. > a configuration issue although I am still open to any suggestions as far as
  29315. > that goes.
  29316. > 
  29317. > This problem just started occuring about a week ago and it does not recur
  29318. > with any sort of pattern.  I am running 4.2.32-1 on the ARCs. I am also
  29319. > running OSPF on the chassis now but I don't think it is a direct OSPF
  29320. > problem. The things ran flawlessly for several weeks with OSPF routing and
  29321. > 4.2.32-1 before I started having this problem.
  29322. > 
  29323. > Has anyone been having any sort of odd problems with OSPF or 4.2.32-1? I
  29324. > would really like to get this resolved and I am at a loss right now. Any
  29325. > comments or suggestions would be appreciated...
  29326. > 
  29327. > Mike McHenry
  29328. >  Systems Administrator
  29329. >  MinnNet Communications, Inc.
  29330. > 
  29331. > 
  29332. > -
  29333. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29334. >  with "unsubscribe usr-tc" in the body of the message.
  29335. >  For information on digests or retrieving files and old messages send
  29336. >  "help" to the same address.  Do not use quotes in your message.
  29337. > 
  29338.  
  29339.  
  29340. -
  29341.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29342.  with "unsubscribe usr-tc" in the body of the message.
  29343.  For information on digests or retrieving files and old messages send
  29344.  "help" to the same address.  Do not use quotes in your message.
  29345.  
  29346.  
  29347. -------------------------------------------------------------------------------
  29348.  
  29349. From: Mike Andrews <mandrews@bit0.com>
  29350. Subject: Re: (usr-tc) HiPer DSP & Quads in one chassis, plus MRTG question
  29351. Date: 22 Oct 1999 17:37:59 -0400 (EDT)
  29352.  
  29353. On Mon, 18 Oct 1999, USRobotics TC Mailing List wrote:
  29354.  
  29355. > I have a few questions that I'm hoping someone can quickly answer.
  29356. > 
  29357. > The first group is, I have a TC chassis with 4 HiPer DSP's and one 70 AMP
  29358. > PS.  I would like to put an additional 2 DSP's in this chassis.  Will the
  29359. > one PS do the trick, or do I have to install another PS?
  29360. > 
  29361. > How many DSP's can I run off of two 70 AMP PS?
  29362.  
  29363. I have a rack running 6 DSP's, 6 Quads, one Dual PRI (for the Quads), an
  29364. ARC and an NMC (leaving two slots empty) all on a *single* 70 amp PS.
  29365. No apparent problems.
  29366.  
  29367. Source Technology is selling 70 amp PS's for $300 this month, so I put a
  29368. second one in that rack yesterday just for the hell of it. :)
  29369.  
  29370. The whole thing on one power supply was pulling less than 4 amps at 120
  29371. volts.  (The power supply rating is for DC amps, but I don't know if 
  29372. that's 12 volts or 5 volts or some of each.)
  29373.  
  29374.  
  29375. > At what point do I have to switch the PS's to 130's?
  29376.  
  29377. Don't know.
  29378.  
  29379.  
  29380. > The second group of questions is, I have a TC chassis, NSC card with 8 MB
  29381. > DRAM and 2 MB Flash, NMC 4 MB DRAM and 2MB Flash,  12 A/D Quad's running in
  29382. > Analog mode, no V.90 license and two 45 AMP PS's.  I want to add one HiPer
  29383. > DSP.
  29384. > 
  29385. > Will the DSP be able to answer V.90 calls without the V.90 license
  29386. > installed?
  29387.  
  29388. Yes, the DSP doesn't need the feature key on the NMC... it's standard
  29389. equipment.  Only the Quads look at the feature key.
  29390.  
  29391.  
  29392. > Do I have enough memory in the NMC and NSC to be able to handle the Quad's
  29393. > and DSP?
  29394.  
  29395. NMC needs to be 16 meg RAM and 8 meg flash to handle a HiPer DSP or a
  29396. HiPer ARC or a HiPer anything-at-all.
  29397.  
  29398. I don't know about the NETserver -- the flash seems like it might be
  29399. little anemic to handle the software release the DSP will need to
  29400. function.  The CPU is definitely too anemic to handle a full load of Quads
  29401. and DSP's both -- I hope you don't have any users playing Quake or they
  29402. will lynch you if you don't replace it with an ARC :)
  29403.  
  29404.  
  29405. > Can someone tell me where the list archive is?
  29406.  
  29407. ftp://ftp.xmission.com/pub/lists/usr-tc is one copy I've been mirroring
  29408. locally for myself, but there's an HTML version or two that I can't
  29409. remember offhand...
  29410.  
  29411.  
  29412. > I'm also looking for MRTG scripts that will work with the TC's, can someone
  29413. > point me in the right direction?
  29414.  
  29415. http://www.dcr.net/~mandrews/usrtoys/
  29416.  
  29417.  
  29418. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  29419. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  29420. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  29421. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  29422.  
  29423.  
  29424.  
  29425. -
  29426.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29427.  with "unsubscribe usr-tc" in the body of the message.
  29428.  For information on digests or retrieving files and old messages send
  29429.  "help" to the same address.  Do not use quotes in your message.
  29430.  
  29431.  
  29432. -------------------------------------------------------------------------------
  29433.  
  29434. From: Mike Andrews <mandrews@bit0.com>
  29435. Subject: Re: (usr-tc) DSP Newbie
  29436. Date: 22 Oct 1999 17:45:32 -0400 (EDT)
  29437.  
  29438. Sounds like you need a newer version of TCM.
  29439.  
  29440.  
  29441. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  29442. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  29443. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  29444. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  29445.  
  29446. On Fri, 22 Oct 1999, Dataheart wrote:
  29447.  
  29448. > Hi,
  29449. > After using quad modems for about 2-3 years for POTS connections I have
  29450. > recently installed some HiPer DSP's for some clients who would like
  29451. > digital connections.
  29452. > I downloaded the code from the Total Service web site only to find
  29453. > instead of the usual .nac and .sdl file (which I am used to) I find a
  29454. > .dmf file and no .sdl
  29455. > When trying to update my firmware I find that TCM will not accept the
  29456. > Software download without a .sdl file.
  29457. > 
  29458. > Where am I going wrong?
  29459.  
  29460.  
  29461. -
  29462.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29463.  with "unsubscribe usr-tc" in the body of the message.
  29464.  For information on digests or retrieving files and old messages send
  29465.  "help" to the same address.  Do not use quotes in your message.
  29466.  
  29467.  
  29468. -------------------------------------------------------------------------------
  29469.  
  29470. From: Brian Burgmeier <brianb@ntwrld.com>
  29471. Subject: Re: (usr-tc) HiPer DSP & Quads in one chassis, plus MRTG question
  29472. Date: 22 Oct 1999 14:52:22 -0700
  29473.  
  29474. > Micah,
  29475.  
  29476. here's how we can tye mrtg to the total control chassis -Brian
  29477.  
  29478.  
  29479.  
  29480. >
  29481. >
  29482. > ftp://ftp.xmission.com/pub/lists/usr-tc is one copy I've been mirroring
  29483. > locally for myself, but there's an HTML version or two that I can't
  29484. > remember offhand...
  29485. >
  29486. >
  29487. > > I'm also looking for MRTG scripts that will work with the TC's, can someone
  29488. > > point me in the right direction?
  29489. >
  29490. > http://www.dcr.net/~mandrews/usrtoys/
  29491.  
  29492.  
  29493. -
  29494.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29495.  with "unsubscribe usr-tc" in the body of the message.
  29496.  For information on digests or retrieving files and old messages send
  29497.  "help" to the same address.  Do not use quotes in your message.
  29498.  
  29499.  
  29500. -------------------------------------------------------------------------------
  29501.  
  29502. From: <dciresi@defunct.ae.usr.com>
  29503. Subject: Re: (usr-tc) Y2K and TC Radius
  29504. Date: 25 Oct 1999 10:24:20 -0500 (CDT)
  29505.  
  29506. S/A has not been tested internally for Y2K compatibility (Bellcore specs).
  29507. There are other reasons why you'd want to move away from 5.5.3, however.
  29508.  
  29509. Doesn't support: MS-CHAP, max-session-limiting, long usernames, - to name
  29510. a few.
  29511.  
  29512. Dominic
  29513.  
  29514. On Thu, 21 Oct 1999, Jim Faulkner wrote:
  29515.  
  29516. > Hello,
  29517. > 
  29518. > Does anybody know what issues TC Radius 5.5.3 has with Y2K. Do I really need
  29519. > to spend $5-600.00 on the 6+ version?
  29520. > 
  29521. > Thanks You,
  29522. > Jim Faulkner
  29523. > GWE.NET
  29524. > DigitalDuck.com
  29525. > 
  29526. > 
  29527. > -
  29528. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29529. >  with "unsubscribe usr-tc" in the body of the message.
  29530. >  For information on digests or retrieving files and old messages send
  29531. >  "help" to the same address.  Do not use quotes in your message.
  29532. > 
  29533.  
  29534.  
  29535. -
  29536.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29537.  with "unsubscribe usr-tc" in the body of the message.
  29538.  For information on digests or retrieving files and old messages send
  29539.  "help" to the same address.  Do not use quotes in your message.
  29540.  
  29541.  
  29542. -------------------------------------------------------------------------------
  29543.  
  29544. From: "Kalev Nurklik" <kalev@mail.lbi.ee>
  29545. Subject: (usr-tc) attribute
  29546. Date: 25 Oct 1999 18:18:22 +0300
  29547.  
  29548. Hi,
  29549.  
  29550. does anyone know what radius attribute id 0x988b stands for?
  29551. Seem to be HARC specific. This one appeared after 4.2.32
  29552. upgrade along with others but to the rest of them I have already
  29553. found right radius dictionary counterparts.
  29554.  
  29555. regards,
  29556.  
  29557. __________________________________
  29558. Kalev Nurklik
  29559. MicroLink Online
  29560. Sakala 19, 10141 Tallinn, Estonia
  29561. Tel: +372 6 308 909
  29562. Fax: +372 6 308 901
  29563. E-mail: k.nurklik@online.ee
  29564. http://www.online.ee
  29565.  
  29566. -
  29567.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29568.  with "unsubscribe usr-tc" in the body of the message.
  29569.  For information on digests or retrieving files and old messages send
  29570.  "help" to the same address.  Do not use quotes in your message.
  29571.  
  29572.  
  29573. -------------------------------------------------------------------------------
  29574.  
  29575. From: Ahmed Saeed <Ahmed.Saeed@widener.edu>
  29576. Subject: Re: (usr-tc) Ascend vs. 3Com
  29577. Date: 25 Oct 1999 16:34:10 -0400 (EDT)
  29578.  
  29579. During LCP, the MRRU is negotiated from both ends. Latest Code of hiper 
  29580. arc does have capability of negotiating the standard value of 1500. 
  29581.  
  29582.  
  29583. On Mon, 18 Oct 1999, Ed wrote:
  29584.  
  29585. > Jeff McAdams wrote:
  29586. > "And the MTU shouldn't matter for Quake and the like.  Quake and the like
  29587. > tends to use very small packets, packets where the MTU on the link isn't
  29588. > relevant."
  29589. > 
  29590. > Not necessarily... if the packets are always larger then Quake would lag and
  29591. > time out. Have the client manually set their MTU down to 576 and see what
  29592. > the result is. I may be wrong but I have seen stranger things cause problems
  29593. > on games such as Quake.
  29594. > 
  29595. > I know when USR had an issue with Quake that was one solution... we were
  29596. > deeply involved in it. However until a code revision it wasn't completely
  29597. > resolved. Think about it though... USR even cared about Quake and made an
  29598. > issue of it and resolved it. 3com would laugh about an issue with gaming.
  29599. > That shows how even the little things were important to USR.
  29600. > 
  29601. > We were PROUD to be a USR ISP! Used to rip all the other ISP's that used
  29602. > other access servers... now we feel like they are ripping on us ;-(
  29603. > 
  29604. > Ed
  29605. > 
  29606. > ----- Original Message -----
  29607. > From: Jeff Mcadams <jeffm@iglou.com>
  29608. > To: <usr-tc@lists.xmission.com>
  29609. > Sent: Monday, October 18, 1999 5:15 PM
  29610. > Subject: Re: (usr-tc) Ascend vs. 3Com
  29611. > 
  29612. > 
  29613. > Thus spake Brian
  29614. > >On Mon, 18 Oct 1999, Ed wrote:
  29615. > >> Yes have seen it ourselves over and over.
  29616. > 
  29617. > >> BTW, reason he is having the problem with Quake probably has to do
  29618. > >> with MTU settings on the Ascend... or he has incorrect error control
  29619. > >> and thus his packets are resending. (correct me someone if I am
  29620. > >> incorrect)
  29621. > 
  29622. > >I would expect the default MTU on the ascend to be the same as the
  29623. > >3com.........I would also expect error control to be autonegotiated
  29624. > >correctly by either NAS.
  29625. > 
  29626. > And the MTU shouldn't matter for Quake and the like.  Quake and the like
  29627. > tends to use very small packets, packets where the MTU on the link isn't
  29628. > relevant.
  29629. > --
  29630. > Jeff McAdams                            Email: jeffm@iglou.com
  29631. > Head Network Administrator              Voice: (502) 966-3848
  29632. > IgLou Internet Services                        (800) 436-4456
  29633. > 
  29634. > -
  29635. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29636. >  with "unsubscribe usr-tc" in the body of the message.
  29637. >  For information on digests or retrieving files and old messages send
  29638. >  "help" to the same address.  Do not use quotes in your message.
  29639. > 
  29640. > 
  29641. > 
  29642. > -
  29643. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29644. >  with "unsubscribe usr-tc" in the body of the message.
  29645. >  For information on digests or retrieving files and old messages send
  29646. >  "help" to the same address.  Do not use quotes in your message.
  29647. > 
  29648.  
  29649. -
  29650.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29651.  with "unsubscribe usr-tc" in the body of the message.
  29652.  For information on digests or retrieving files and old messages send
  29653.  "help" to the same address.  Do not use quotes in your message.
  29654.  
  29655.  
  29656. -------------------------------------------------------------------------------
  29657.  
  29658. From: Nicolas St-Pierre <nstpierre@iasl.com>
  29659. Subject: (usr-tc) WTB Netserver card sets!
  29660. Date: 25 Oct 1999 17:38:14 -0400
  29661.  
  29662.  
  29663.  
  29664. Hello All!
  29665.  
  29666. I'm on the lookout to buy some 2nd hand Netserver card sets (NIC +
  29667. NAC).  If you have any of those and are looking to sell them, please
  29668. contact me privately.
  29669.  
  29670. Much appreciated!
  29671.  
  29672. Thanks,
  29673.  
  29674. Nick
  29675. -- 
  29676. Nicolas St-Pierre
  29677. Systems Engineer
  29678. Internet Access Solutions Ltd.
  29679. Tel (905) 469-4953
  29680. Fax (905) 469-4954
  29681.  
  29682. -
  29683.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29684.  with "unsubscribe usr-tc" in the body of the message.
  29685.  For information on digests or retrieving files and old messages send
  29686.  "help" to the same address.  Do not use quotes in your message.
  29687.  
  29688.  
  29689. -------------------------------------------------------------------------------
  29690.  
  29691. From: Jeff Mcadams <jeffm@iglou.com>
  29692. Subject: (usr-tc) Head's up...TCS 4.0 open beta
  29693. Date: 25 Oct 1999 19:04:34 -0400
  29694.  
  29695. For those of you not on the totalservice newsgroups.  3Com just
  29696. announced an Open Beta (read: no service contract required) for TCS 4.0.
  29697. Features mentioned in the beta announcement, QoS (traffic coloring),
  29698. IPSec (static keys), offline configuration support, and others that I
  29699. can't remember off the top of my head.  :)
  29700.  
  29701. Anyway...thought it'd be a good idea to get some of the folks in here on
  29702. it...the caliber of user on usr-tc seems to be a notch above what you
  29703. find in the totalservice newsgroups typically.  :)
  29704. -- 
  29705. Jeff McAdams                            Email: jeffm@iglou.com
  29706. Head Network Administrator              Voice: (502) 966-3848
  29707. IgLou Internet Services                        (800) 436-4456
  29708.  
  29709. -
  29710.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29711.  with "unsubscribe usr-tc" in the body of the message.
  29712.  For information on digests or retrieving files and old messages send
  29713.  "help" to the same address.  Do not use quotes in your message.
  29714.  
  29715.  
  29716. -------------------------------------------------------------------------------
  29717.  
  29718. From: Jeff Mcadams <jeffm@iglou.com>
  29719. Subject: (usr-tc) Re: Head's up...TCS 4.0 open beta
  29720. Date: 25 Oct 1999 19:18:45 -0400
  29721.  
  29722. Thus spake Jeff Mcadams
  29723. >For those of you not on the totalservice newsgroups.  3Com just
  29724. >announced an Open Beta (read: no service contract required) for TCS 4.0.
  29725. >Features mentioned in the beta announcement, QoS (traffic coloring),
  29726. >IPSec (static keys), offline configuration support, and others that I
  29727. >can't remember off the top of my head.  :)
  29728.  
  29729. Ack...my bad...not sure where I got offline configuration support
  29730. from...its not in the announcement (was reading some other vendor web
  29731. sites...maybe I grabbed one of their phrases in there...not sure)
  29732. -- 
  29733. Jeff McAdams                            Email: jeffm@iglou.com
  29734. Head Network Administrator              Voice: (502) 966-3848
  29735. IgLou Internet Services                        (800) 436-4456
  29736.  
  29737. -
  29738.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29739.  with "unsubscribe usr-tc" in the body of the message.
  29740.  For information on digests or retrieving files and old messages send
  29741.  "help" to the same address.  Do not use quotes in your message.
  29742.  
  29743.  
  29744. -------------------------------------------------------------------------------
  29745.  
  29746. From: eric@dol.net
  29747. Subject: (usr-tc) routing multiple class c to tc boxes
  29748. Date: 25 Oct 1999 21:57:58 -0600
  29749.  
  29750. I know something like this has been asked before I looked but here is my situation. 
  29751. Do I have to route a /26 or multiple /27s from my cisco router at my 
  29752. total controls (or pm3s) when I have units that are not on the same 
  29753. class c as my router.  I have 10 total control units that I would like 
  29754. to put on 2 class c address.  I have 2 x 254 =508 ips with 2 class c 
  29755. I have 5x48=240 ( includes the nmc and netserver) on 5 tc so 5 can fit on one 
  29756. class c and so 5 more could fit on another class c. What is the best 
  29757. way to conserve ip space.  Do I need to have a class c to every 2 chassis 
  29758. to route a /26 to each chassis?  Can I use a route command on the cisco 
  29759. that will make each the majority of two class c addresses useable by the tc box?
  29760. thanks
  29761. eric
  29762.  
  29763. Delaware Online!.........The SMART Choice!  
  29764. With 56K V.90 & X2 & Flex Modems 
  29765. Phone : 302-762-0375                
  29766. Fax:     302-762-3462        
  29767. Failure is NOT an option...
  29768.  
  29769.  
  29770.  
  29771. -
  29772.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29773.  with "unsubscribe usr-tc" in the body of the message.
  29774.  For information on digests or retrieving files and old messages send
  29775.  "help" to the same address.  Do not use quotes in your message.
  29776.  
  29777.  
  29778. -------------------------------------------------------------------------------
  29779.  
  29780. From: Steve Monkhouse <steve.monkhouse@ethertech.com.au>
  29781. Subject: (usr-tc) OID's
  29782. Date: 26 Oct 1999 14:05:12 +1000
  29783.  
  29784. Does anyone know of an online resource that documents all the USR OID's ??
  29785.  
  29786. Ive been through EVERY manual I have and can only find a few...
  29787.  
  29788. All help is appreciated....
  29789.  
  29790. Steve Monkhouse - Network Engineer
  29791. EtherTech Computer Services
  29792.  
  29793. Ph : +61-3-9768-2665
  29794. Fx : +61-3-9768-2664
  29795. http://www.ethertech.com.au
  29796.  
  29797.  
  29798. -
  29799.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29800.  with "unsubscribe usr-tc" in the body of the message.
  29801.  For information on digests or retrieving files and old messages send
  29802.  "help" to the same address.  Do not use quotes in your message.
  29803.  
  29804.  
  29805. -------------------------------------------------------------------------------
  29806.  
  29807. From: Dale Hege <fhege@sover.net>
  29808. Subject: Re: (usr-tc) Re: Head's up...TCS 4.0 open beta
  29809. Date: 26 Oct 1999 05:51:16 -0400 (EDT)
  29810.  
  29811. If you already signed up then you got it from the BETA survey.
  29812.  
  29813. -Dale :)
  29814.  
  29815. On Mon, 25 Oct 1999, Jeff Mcadams wrote:
  29816.  
  29817. > Thus spake Jeff Mcadams
  29818. > >For those of you not on the totalservice newsgroups.  3Com just
  29819. > >announced an Open Beta (read: no service contract required) for TCS 4.0.
  29820. > >Features mentioned in the beta announcement, QoS (traffic coloring),
  29821. > >IPSec (static keys), offline configuration support, and others that I
  29822. > >can't remember off the top of my head.  :)
  29823. > 
  29824. > Ack...my bad...not sure where I got offline configuration support
  29825. > from...its not in the announcement (was reading some other vendor web
  29826. > sites...maybe I grabbed one of their phrases in there...not sure)
  29827. > -- 
  29828. > Jeff McAdams                            Email: jeffm@iglou.com
  29829. > Head Network Administrator              Voice: (502) 966-3848
  29830. > IgLou Internet Services                        (800) 436-4456
  29831. > 
  29832. > -
  29833. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29834. >  with "unsubscribe usr-tc" in the body of the message.
  29835. >  For information on digests or retrieving files and old messages send
  29836. >  "help" to the same address.  Do not use quotes in your message.
  29837. > 
  29838.  
  29839.  
  29840. -
  29841.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29842.  with "unsubscribe usr-tc" in the body of the message.
  29843.  For information on digests or retrieving files and old messages send
  29844.  "help" to the same address.  Do not use quotes in your message.
  29845.  
  29846.  
  29847. -------------------------------------------------------------------------------
  29848.  
  29849. From: Jeff Mcadams <jeffm@iglou.com>
  29850. Subject: Re: (usr-tc) Re: Head's up...TCS 4.0 open beta
  29851. Date: 26 Oct 1999 06:35:00 -0400
  29852.  
  29853. Thus spake Dale Hege
  29854. >If you already signed up then you got it from the BETA survey.
  29855.  
  29856. Yeah, I realized that later on, but figured I'd made enough of a fool of
  29857. myself following up to myself once, didn't figure I needed to do it
  29858. again.  :)
  29859.  
  29860. >> Ack...my bad...not sure where I got offline configuration support
  29861. >> from...its not in the announcement (was reading some other vendor web
  29862. >> sites...maybe I grabbed one of their phrases in there...not sure)
  29863. -- 
  29864. Jeff McAdams                            Email: jeffm@iglou.com
  29865. Head Network Administrator              Voice: (502) 966-3848
  29866. IgLou Internet Services                        (800) 436-4456
  29867.  
  29868. -
  29869.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29870.  with "unsubscribe usr-tc" in the body of the message.
  29871.  For information on digests or retrieving files and old messages send
  29872.  "help" to the same address.  Do not use quotes in your message.
  29873.  
  29874.  
  29875. -------------------------------------------------------------------------------
  29876.  
  29877. From: Jeff Mcadams <jeffm@iglou.com>
  29878. Subject: Re: (usr-tc) routing multiple class c to tc boxes
  29879. Date: 26 Oct 1999 06:36:45 -0400
  29880.  
  29881. Thus spake eric@dol.net
  29882. >I know something like this has been asked before I looked but here is
  29883. >my situation. 
  29884.  
  29885. >Do I have to route a /26 or multiple /27s from my cisco router at my
  29886. >total controls (or pm3s) when I have units that are not on the same
  29887. >class c as my router.  I have 10 total control units that I would like
  29888. >to put on 2 class c address.  I have 2 x 254 =508 ips with 2 class c I
  29889. >have 5x48=240 ( includes the nmc and netserver) on 5 tc so 5 can fit on
  29890. >one class c and so 5 more could fit on another class c. What is the
  29891. >best way to conserve ip space.  Do I need to have a class c to every 2
  29892. >chassis to route a /26 to each chassis?  Can I use a route command on
  29893. >the cisco that will make each the majority of two class c addresses
  29894. >useable by the tc box?
  29895.  
  29896. How about doing "ip address x.x.x.x y.y.y.y secondary" on your cisco
  29897. with x.x.x.x being from the second /24?  Gives the interface on the
  29898. Cisco a secondary address so it'll see the second /24 as directly
  29899. connected the same as the first.
  29900. -- 
  29901. Jeff McAdams                            Email: jeffm@iglou.com
  29902. Head Network Administrator              Voice: (502) 966-3848
  29903. IgLou Internet Services                        (800) 436-4456
  29904.  
  29905. -
  29906.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29907.  with "unsubscribe usr-tc" in the body of the message.
  29908.  For information on digests or retrieving files and old messages send
  29909.  "help" to the same address.  Do not use quotes in your message.
  29910.  
  29911.  
  29912. -------------------------------------------------------------------------------
  29913.  
  29914. From: Marty Elliott <marty@2assetrecovery.com>
  29915. Subject: Re: (usr-tc) WTB Netserver card sets!
  29916. Date: 26 Oct 1999 05:04:42 -0700
  29917.  
  29918. Nick,
  29919.  
  29920. We have some NetServer PRI card sets new/unused for $550 each.
  29921.  
  29922. Regards
  29923.  
  29924. Marty
  29925.  
  29926.  
  29927. At 05:38 PM 10/25/99 -0400, you wrote:
  29928. >
  29929. >
  29930. >Hello All!
  29931. >
  29932. >I'm on the lookout to buy some 2nd hand Netserver card sets (NIC +
  29933. >NAC).  If you have any of those and are looking to sell them, please
  29934. >contact me privately.
  29935. >
  29936. >Much appreciated!
  29937. >
  29938. >Thanks,
  29939. >
  29940. >Nick
  29941. >-- 
  29942. >Nicolas St-Pierre
  29943. >Systems Engineer
  29944. >Internet Access Solutions Ltd.
  29945. >Tel (905) 469-4953
  29946. >Fax (905) 469-4954
  29947. >
  29948. >-
  29949. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29950. > with "unsubscribe usr-tc" in the body of the message.
  29951. > For information on digests or retrieving files and old messages send
  29952. > "help" to the same address.  Do not use quotes in your message.
  29953.  
  29954. =====================================
  29955. Marty Elliott
  29956. Managed Asset Recovery Specialists, Inc. (MARS)
  29957. 2105 South 48th Street   Suite 104
  29958. Tempe, Arizona 85282  USA
  29959. (602) 426-8272      (602) 454-0770  fax
  29960. www.2assetrecovery.com
  29961. =====================================
  29962.  
  29963.  
  29964. -
  29965.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29966.  with "unsubscribe usr-tc" in the body of the message.
  29967.  For information on digests or retrieving files and old messages send
  29968.  "help" to the same address.  Do not use quotes in your message.
  29969.  
  29970.  
  29971. -------------------------------------------------------------------------------
  29972.  
  29973. From: Charles Sprickman <spork@inch.com>
  29974. Subject: Re: (usr-tc) OID's
  29975. Date: 26 Oct 1999 11:58:21 -0400 (EDT)
  29976.  
  29977. I'll second that and broaden it...
  29978.  
  29979. I like snmp, but I hate hunting around in enterprise MIBs trying to find
  29980. what I want.  What tools (if any exist) are used for just digging around
  29981. and searching for what you're looking to set/monitor?
  29982.  
  29983. David Bolen, where are you...
  29984.  
  29985. Charles
  29986.  
  29987. On Tue, 26 Oct 1999, Steve Monkhouse wrote:
  29988.  
  29989. > Does anyone know of an online resource that documents all the USR OID's ??
  29990. > 
  29991. > Ive been through EVERY manual I have and can only find a few...
  29992. > 
  29993. > All help is appreciated....
  29994. > 
  29995. > Steve Monkhouse - Network Engineer
  29996. > ---------------------------------------------------------------------
  29997. > EtherTech Computer Services
  29998. > 
  29999. > Ph : +61-3-9768-2665
  30000. > Fx : +61-3-9768-2664
  30001. > http://www.ethertech.com.au
  30002. > 
  30003. > 
  30004. > -
  30005. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30006. >  with "unsubscribe usr-tc" in the body of the message.
  30007. >  For information on digests or retrieving files and old messages send
  30008. >  "help" to the same address.  Do not use quotes in your message.
  30009. > 
  30010.  
  30011.  
  30012. -
  30013.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30014.  with "unsubscribe usr-tc" in the body of the message.
  30015.  For information on digests or retrieving files and old messages send
  30016.  "help" to the same address.  Do not use quotes in your message.
  30017.  
  30018.  
  30019. -------------------------------------------------------------------------------
  30020.  
  30021. From: Jeff Mcadams <jeffm@iglou.com>
  30022. Subject: Re: (usr-tc) OID's
  30023. Date: 26 Oct 1999 12:40:49 -0400
  30024.  
  30025. Thus spake Charles Sprickman
  30026. >I'll second that and broaden it...
  30027.  
  30028. >I like snmp, but I hate hunting around in enterprise MIBs trying to find
  30029. >what I want.  What tools (if any exist) are used for just digging around
  30030. >and searching for what you're looking to set/monitor?
  30031.  
  30032. Yeah...they have the SNMP parameter reference...but that's not much more
  30033. help than just grep'ing the mib files.
  30034.  
  30035. FWIW, that's exactly what I do...grep the mib files.  After a bit of
  30036. time doing that (bummer, I know) you start to get an idea of how the
  30037. mibs are arranged which shortens future searches since you have some
  30038. idea where to start looking.
  30039.  
  30040. >David Bolen, where are you...
  30041.  
  30042. No doubt...he un-sub'ed a while ago since he's moved onward and
  30043. upward...I'd love to get a brain-dump from him.  :)
  30044.  
  30045. >On Tue, 26 Oct 1999, Steve Monkhouse wrote:
  30046. >> Does anyone know of an online resource that documents all the USR OID's ??
  30047.  
  30048. >> Ive been through EVERY manual I have and can only find a few...
  30049.  
  30050. >> All help is appreciated....
  30051. -- 
  30052. Jeff McAdams                            Email: jeffm@iglou.com
  30053. Head Network Administrator              Voice: (502) 966-3848
  30054. IgLou Internet Services                        (800) 436-4456
  30055.  
  30056. -
  30057.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30058.  with "unsubscribe usr-tc" in the body of the message.
  30059.  For information on digests or retrieving files and old messages send
  30060.  "help" to the same address.  Do not use quotes in your message.
  30061.  
  30062.  
  30063. -------------------------------------------------------------------------------
  30064.  
  30065. From: "Cheryl Johnson" <netadmin@seidata.com>
  30066. Subject: (usr-tc) HiPerDSP Engr. code 2.0.60 & Bad modems
  30067. Date: 26 Oct 1999 15:28:40 -0500
  30068.  
  30069. This is a multi-part message in MIME format.
  30070.  
  30071. ------=_NextPart_000_003A_01BF1FC6.C784AD50
  30072. Content-Type: text/plain;
  30073.     charset="iso-8859-1"
  30074. Content-Transfer-Encoding: quoted-printable
  30075.  
  30076. Once again the problem of pairs of  DSP modems suddenly appeared again. =
  30077. I had called 3com on 10/19/99 and got the latest and greatest =
  30078. engineering code to fix the paired modem problem (version 2.0.60)..I was =
  30079. actually hopeful for a few days..but less than 5 days..it once again =
  30080. appears. I have noticed this problem on various codes throughout the =
  30081. past year if not longer. Always hopeful for a fix to this annoying =
  30082. problem. It makes upgrading code almost fearful due to one problem being =
  30083. fixed but creating a nightmare. Evidentally, I am not the only user of =
  30084. Total Control having this problem by reading this list.  Is it too much =
  30085. to ask to fix this DSP problem?=20
  30086.  
  30087.  
  30088. Cheryl
  30089. Network Administrator
  30090. Seidata Network Services, Inc.
  30091. http://www.seidata.com
  30092.  
  30093.  
  30094. ------=_NextPart_000_003A_01BF1FC6.C784AD50
  30095. Content-Type: text/html;
  30096.     charset="iso-8859-1"
  30097. Content-Transfer-Encoding: quoted-printable
  30098.  
  30099. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  30100. <HTML><HEAD>
  30101. <META content=3D"text/html; charset=3Diso-8859-1" =
  30102. http-equiv=3DContent-Type>
  30103. <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
  30104. <STYLE></STYLE>
  30105. </HEAD>
  30106. <BODY bgColor=3D#ffffff>
  30107. <DIV><FONT face=3DArial size=3D2>Once again the problem of pairs =
  30108. of  DSP modems=20
  30109. suddenly appeared again. I had called 3com on 10/19/99 and got the =
  30110. latest and=20
  30111. greatest engineering code to fix the paired modem problem (version =
  30112. 2.0.60)..I=20
  30113. was actually hopeful for a few days..but less than 5 days..it once again =
  30114.  
  30115. appears. I have noticed this problem on various codes throughout the =
  30116. past year=20
  30117. if not longer. Always hopeful for a fix to this annoying problem. It =
  30118. makes=20
  30119. upgrading code almost fearful due to one problem being fixed but =
  30120. creating a=20
  30121. nightmare. Evidentally, I am not the only user of Total =
  30122. Control having=20
  30123. this problem by reading this list.  Is it too much to ask to fix this =
  30124. DSP=20
  30125. problem? </FONT></DIV>
  30126. <DIV> </DIV>
  30127. <DIV> </DIV>
  30128. <DIV><FONT face=3DArial size=3D2>Cheryl</FONT></DIV>
  30129. <DIV><FONT face=3DArial size=3D2>Network Administrator</FONT></DIV>
  30130. <DIV><FONT face=3DArial size=3D2>Seidata Network Services, =
  30131. Inc.</FONT></DIV>
  30132. <DIV><FONT face=3DArial size=3D2><A=20
  30133. href=3D"http://www.seidata.com">http://www.seidata.com</A></FONT></DIV>
  30134. <DIV> </DIV></BODY></HTML>
  30135.  
  30136. ------=_NextPart_000_003A_01BF1FC6.C784AD50--
  30137.  
  30138.  
  30139. -
  30140.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30141.  with "unsubscribe usr-tc" in the body of the message.
  30142.  For information on digests or retrieving files and old messages send
  30143.  "help" to the same address.  Do not use quotes in your message.
  30144.  
  30145.  
  30146. -------------------------------------------------------------------------------
  30147.  
  30148. From: Clayton Zekelman <clayton@MNSi.Net>
  30149. Subject: (usr-tc) ARC Default Gateway
  30150. Date: 26 Oct 1999 17:01:39 -0400
  30151.  
  30152.  
  30153. OK, I know I'm missing something simple, but how do you change the default
  30154. gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route, but it
  30155. rejected it.  Any ideas?
  30156.  
  30157.  
  30158. ---
  30159. Clayton Zekelman
  30160. Managed Network Systems Inc. (MNSi)
  30161. 875 Ouellette Avenue
  30162. Windsor, Ontario
  30163. N9A 4J6
  30164.  
  30165. tel. 519-985-8410
  30166. fax. 519-258-3009
  30167.  
  30168. -
  30169.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30170.  with "unsubscribe usr-tc" in the body of the message.
  30171.  For information on digests or retrieving files and old messages send
  30172.  "help" to the same address.  Do not use quotes in your message.
  30173.  
  30174.  
  30175. -------------------------------------------------------------------------------
  30176.  
  30177. From: speedy@dixie-net.com
  30178. Subject: Re: (usr-tc) ARC Default Gateway
  30179. Date: 26 Oct 1999 16:46:47 -0500 (CDT)
  30180.  
  30181. set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  30182.  
  30183. If you should need multiple defaultroutes:
  30184. add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  30185.  
  30186. Gabriel
  30187.  
  30188. On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  30189.  
  30190. > OK, I know I'm missing something simple, but how do you change the default
  30191. > gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route, but it
  30192. > rejected it.  Any ideas?
  30193. > 
  30194. > 
  30195. > ---
  30196. > Clayton Zekelman
  30197. > Managed Network Systems Inc. (MNSi)
  30198. > 875 Ouellette Avenue
  30199. > Windsor, Ontario
  30200. > N9A 4J6
  30201. > 
  30202. > tel. 519-985-8410
  30203. > fax. 519-258-3009
  30204. > 
  30205. > -
  30206. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30207. >  with "unsubscribe usr-tc" in the body of the message.
  30208. >  For information on digests or retrieving files and old messages send
  30209. >  "help" to the same address.  Do not use quotes in your message.
  30210. > 
  30211. > 
  30212. > 
  30213.  
  30214. --
  30215. * speedy@dixie-net.com *
  30216. * Gabriel Grissett     *
  30217.  
  30218.  
  30219. -
  30220.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30221.  with "unsubscribe usr-tc" in the body of the message.
  30222.  For information on digests or retrieving files and old messages send
  30223.  "help" to the same address.  Do not use quotes in your message.
  30224.  
  30225.  
  30226. -------------------------------------------------------------------------------
  30227.  
  30228. From: Clayton Zekelman <clayton@MNSi.Net>
  30229. Subject: Re: (usr-tc) ARC Default Gateway
  30230. Date: 26 Oct 1999 18:11:16 -0400
  30231.  
  30232. It seems "set" won't work.  I tried add, and it worked, but replaced the
  30233. existing default (which is what I wanted, but wouldn't expect from "add").
  30234.  
  30235. I've never run into a device with such an annoying command structure.
  30236.  
  30237. At 04:46 PM 10/26/99 -0500, you wrote:
  30238. >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  30239. >
  30240. >If you should need multiple defaultroutes:
  30241. >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  30242. >
  30243. >Gabriel
  30244. >
  30245. >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  30246. >
  30247. >> OK, I know I'm missing something simple, but how do you change the default
  30248. >> gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route, but it
  30249. >> rejected it.  Any ideas?
  30250. >> 
  30251. >> 
  30252. >> ---
  30253. >> Clayton Zekelman
  30254. >> Managed Network Systems Inc. (MNSi)
  30255. >> 875 Ouellette Avenue
  30256. >> Windsor, Ontario
  30257. >> N9A 4J6
  30258. >> 
  30259. >> tel. 519-985-8410
  30260. >> fax. 519-258-3009
  30261. >> 
  30262. >> -
  30263. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30264. >>  with "unsubscribe usr-tc" in the body of the message.
  30265. >>  For information on digests or retrieving files and old messages send
  30266. >>  "help" to the same address.  Do not use quotes in your message.
  30267. >> 
  30268. >> 
  30269. >> 
  30270. >
  30271. >--
  30272. >* speedy@dixie-net.com *
  30273. >* Gabriel Grissett     *
  30274. >
  30275. >
  30276. >-
  30277. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30278. > with "unsubscribe usr-tc" in the body of the message.
  30279. > For information on digests or retrieving files and old messages send
  30280. > "help" to the same address.  Do not use quotes in your message.
  30281. > 
  30282. ---
  30283. Clayton Zekelman
  30284. Managed Network Systems Inc. (MNSi)
  30285. 875 Ouellette Avenue
  30286. Windsor, Ontario
  30287. N9A 4J6
  30288.  
  30289. tel. 519-985-8410
  30290. fax. 519-258-3009
  30291.  
  30292. -
  30293.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30294.  with "unsubscribe usr-tc" in the body of the message.
  30295.  For information on digests or retrieving files and old messages send
  30296.  "help" to the same address.  Do not use quotes in your message.
  30297.  
  30298.  
  30299. -------------------------------------------------------------------------------
  30300.  
  30301. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  30302. Subject: Re: (usr-tc) ARC Default Gateway
  30303. Date: 26 Oct 1999 05:58:49 -0500 (CDT)
  30304.  
  30305. you will have to add it as a gateway
  30306.  
  30307. the command should be
  30308.  
  30309. add ip net <netname> default gateway <address>
  30310.  
  30311. krish
  30312.  
  30313.         \    T.S.V. Krishnan  \
  30314.          \      Network System Engineer \ ( : - : )
  30315.           \     3Com ............   \
  30316.         ----------------------------------------------/
  30317. tkrishna@bubba.ae.usr.com  
  30318. ----------------------------/ http://interproc.ae.usr.com ----/
  30319.     Any Sufficiently advanced bug is indistinguishable for a feature.
  30320.                         - Rick Kulawiec
  30321.  
  30322. On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  30323.  
  30324. > 
  30325. > OK, I know I'm missing something simple, but how do you change the default
  30326. > gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route, but it
  30327. > rejected it.  Any ideas?
  30328. > 
  30329. > 
  30330. > ---
  30331. > Clayton Zekelman
  30332. > Managed Network Systems Inc. (MNSi)
  30333. > 875 Ouellette Avenue
  30334. > Windsor, Ontario
  30335. > N9A 4J6
  30336. > 
  30337. > tel. 519-985-8410
  30338. > fax. 519-258-3009
  30339. > 
  30340. > -
  30341. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30342. >  with "unsubscribe usr-tc" in the body of the message.
  30343. >  For information on digests or retrieving files and old messages send
  30344. >  "help" to the same address.  Do not use quotes in your message.
  30345. > 
  30346.  
  30347. -
  30348.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30349.  with "unsubscribe usr-tc" in the body of the message.
  30350.  For information on digests or retrieving files and old messages send
  30351.  "help" to the same address.  Do not use quotes in your message.
  30352.  
  30353.  
  30354. -------------------------------------------------------------------------------
  30355.  
  30356. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  30357. Subject: Re: (usr-tc) ARC Default Gateway
  30358. Date: 26 Oct 1999 05:58:49 -0500 (CDT)
  30359.  
  30360. you will have to add it as a gateway
  30361.  
  30362. the command should be
  30363.  
  30364. add ip net <netname> default gateway <address>
  30365.  
  30366. krish
  30367.  
  30368.         \    T.S.V. Krishnan  \
  30369.          \      Network System Engineer \ ( : - : )
  30370.           \     3Com ............   \
  30371.         ----------------------------------------------/
  30372. tkrishna@bubba.ae.usr.com  
  30373. ----------------------------/ http://interproc.ae.usr.com ----/
  30374.     Any Sufficiently advanced bug is indistinguishable for a feature.
  30375.                         - Rick Kulawiec
  30376.  
  30377. On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  30378.  
  30379. > 
  30380. > OK, I know I'm missing something simple, but how do you change the default
  30381. > gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route, but it
  30382. > rejected it.  Any ideas?
  30383. > 
  30384. > 
  30385. > ---
  30386. > Clayton Zekelman
  30387. > Managed Network Systems Inc. (MNSi)
  30388. > 875 Ouellette Avenue
  30389. > Windsor, Ontario
  30390. > N9A 4J6
  30391. > 
  30392. > tel. 519-985-8410
  30393. > fax. 519-258-3009
  30394. > 
  30395. > -
  30396. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30397. >  with "unsubscribe usr-tc" in the body of the message.
  30398. >  For information on digests or retrieving files and old messages send
  30399. >  "help" to the same address.  Do not use quotes in your message.
  30400. > 
  30401.  
  30402. -
  30403.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30404.  with "unsubscribe usr-tc" in the body of the message.
  30405.  For information on digests or retrieving files and old messages send
  30406.  "help" to the same address.  Do not use quotes in your message.
  30407.  
  30408.  
  30409. -------------------------------------------------------------------------------
  30410.  
  30411. From: jlf@montrose-colo.com (Jim Faulkner)
  30412. Subject: (usr-tc) DSP 4 Sale?
  30413. Date: 27 Oct 1999 10:48:05 -0600
  30414.  
  30415. I'm in the market for a HiPer DSP 24 Port T1 card set. Please let me know
  30416. what you might have and how much.
  30417.  
  30418. Thanks,
  30419. Jim Faulkner
  30420. GWE.NET
  30421.  
  30422.  
  30423.  
  30424. -
  30425.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30426.  with "unsubscribe usr-tc" in the body of the message.
  30427.  For information on digests or retrieving files and old messages send
  30428.  "help" to the same address.  Do not use quotes in your message.
  30429.  
  30430.  
  30431. -------------------------------------------------------------------------------
  30432.  
  30433. From: Jeff Mcadams <jeffm@iglou.com>
  30434. Subject: (usr-tc) USR VSA's - 2 that I can't find
  30435. Date: 27 Oct 1999 14:15:14 -0400
  30436.  
  30437. Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
  30438. and 93051 (0x988b) are?
  30439.  
  30440. I looked on totalservice at the dictionary file there and these weren't
  30441. in there.
  30442.  
  30443. Thanks!
  30444. -- 
  30445. Jeff McAdams                            Email: jeffm@iglou.com
  30446. Head Network Administrator              Voice: (502) 966-3848
  30447. IgLou Internet Services                        (800) 436-4456
  30448.  
  30449. -
  30450.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30451.  with "unsubscribe usr-tc" in the body of the message.
  30452.  For information on digests or retrieving files and old messages send
  30453.  "help" to the same address.  Do not use quotes in your message.
  30454.  
  30455.  
  30456. -------------------------------------------------------------------------------
  30457.  
  30458. From: jlf@montrose-colo.com (Jim Faulkner)
  30459. Subject: (usr-tc) DSP 4 Sale?
  30460. Date: 27 Oct 1999 10:48:05 -0600
  30461.  
  30462. I'm in the market for a HiPer DSP 24 Port T1 card set. Please let me know
  30463. what you might have and how much.
  30464.  
  30465. Thanks,
  30466. Jim Faulkner
  30467. GWE.NET
  30468.  
  30469.  
  30470.  
  30471. -
  30472.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30473.  with "unsubscribe usr-tc" in the body of the message.
  30474.  For information on digests or retrieving files and old messages send
  30475.  "help" to the same address.  Do not use quotes in your message.
  30476.  
  30477.  
  30478. -------------------------------------------------------------------------------
  30479.  
  30480. From: <dciresi@defunct.ae.usr.com>
  30481. Subject: Re: (usr-tc) USR VSA's - 2 that I can't find
  30482. Date: 27 Oct 1999 13:58:20 -0500 (CDT)
  30483.  
  30484.  
  30485.  
  30486. On Wed, 27 Oct 1999, Jeff Mcadams wrote:
  30487.  
  30488. > Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
  30489. > and 93051 (0x988b) are?
  30490. > 
  30491. > I looked on totalservice at the dictionary file there and these weren't
  30492. > in there.
  30493. > 
  30494. > Thanks!
  30495. > -- 
  30496. > Jeff McAdams                            Email: jeffm@iglou.com
  30497. > Head Network Administrator              Voice: (502) 966-3848
  30498. > IgLou Internet Services                        (800) 436-4456
  30499. > 
  30500. > -
  30501. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30502. >  with "unsubscribe usr-tc" in the body of the message.
  30503. >  For information on digests or retrieving files and old messages send
  30504. >  "help" to the same address.  Do not use quotes in your message.
  30505. > 
  30506. Jeff,
  30507.  
  30508. These VSAs are part of HARC 4.2.x.
  30509. The following should be added to your dictionary.
  30510.  
  30511. VSA USR HARC-Disconnect-Code     0x988b     integer
  30512.  
  30513.  
  30514. VALUE HARC-Disconnect-Code    no-error        0
  30515. VALUE HARC-Disconnect-Code    no-carrier           1
  30516. VALUE HARC-Disconnect-Code    no-dsr               2
  30517. VALUE HARC-Disconnect-Code    timeout              3
  30518. VALUE HARC-Disconnect-Code    reset                4
  30519. VALUE HARC-Disconnect-Code    call-drop-req        5
  30520. VALUE HARC-Disconnect-Code    idle-timeout         6
  30521. VALUE HARC-Disconnect-Code    session-timeout           7
  30522. VALUE HARC-Disconnect-Code    user-req-drop        8
  30523. VALUE HARC-Disconnect-Code    host-req-drop        9
  30524. VALUE HARC-Disconnect-Code    service-interruption      10
  30525. VALUE HARC-Disconnect-Code    service-unavailable  11
  30526. VALUE HARC-Disconnect-Code    user-input-error     12
  30527. VALUE HARC-Disconnect-Code    nas-drop-for-callback     13
  30528. VALUE HARC-Disconnect-Code    nas-drop-misc-non-error   14
  30529. VALUE HARC-Disconnect-Code    nas-internal-error   15
  30530. VALUE HARC-Disconnect-Code    line-busy       16
  30531. VALUE HARC-Disconnect-Code    RESERVED        17
  30532. VALUE HARC-Disconnect-Code    RESERVED        18
  30533. VALUE HARC-Disconnect-Code    tunnel-term-unreach  19
  30534. VALUE HARC-Disconnect-Code    tunnel-refused       20
  30535. VALUE HARC-Disconnect-Code    tunnel-auth-failed   21
  30536. VALUE HARC-Disconnect-Code    tunnel-session-timeout    22
  30537. VALUE HARC-Disconnect-Code    tunnel-timeout       23
  30538. VALUE HARC-Disconnect-Code    RESERVED        24
  30539. VALUE HARC-Disconnect-Code    radius-res-reclaim   25
  30540. VALUE HARC-Disconnect-Code    dnis-auth-failed     26
  30541. VALUE HARC-Disconnect-Code    pap-auth-failure     27
  30542. VALUE HARC-Disconnect-Code    chap-auth-failure    28
  30543. VALUE HARC-Disconnect-Code    ppp-lcp-failed       29
  30544. VALUE HARC-Disconnect-Code    ppp-ncp-failed       30
  30545. VALUE HARC-Disconnect-Code    radius-timeout       31
  30546.  
  30547.  
  30548.  
  30549.  
  30550. -
  30551.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30552.  with "unsubscribe usr-tc" in the body of the message.
  30553.  For information on digests or retrieving files and old messages send
  30554.  "help" to the same address.  Do not use quotes in your message.
  30555.  
  30556.  
  30557. -------------------------------------------------------------------------------
  30558.  
  30559. From: "Brian Gordon" <administrator@westelcom.com>
  30560. Subject: (usr-tc) - Looking for 3com/USR DSL Equip
  30561. Date: 27 Oct 1999 15:12:56 -0400
  30562.  
  30563. Part 3C-001769-02
  30564. Part 3C-001921-02
  30565.  
  30566. Viper/Affinity Dsl 
  30567.  
  30568. Brian Gordon
  30569. MCP, A+, Network +
  30570. Network Administrator
  30571. Westelcom Internet
  30572. 518.566.6726 Voice
  30573. 419.831.9137 Fax 
  30574. http://www.westelcom.com
  30575. administrator@westelcom.com
  30576.  
  30577.  
  30578.  
  30579. -
  30580.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30581.  with "unsubscribe usr-tc" in the body of the message.
  30582.  For information on digests or retrieving files and old messages send
  30583.  "help" to the same address.  Do not use quotes in your message.
  30584.  
  30585.  
  30586. -------------------------------------------------------------------------------
  30587.  
  30588. From: "Mike Wilker" <mikew@LL.NET>
  30589. Subject: (usr-tc) Abnormal disconnect
  30590. Date: 27 Oct 1999 10:21:52 -0500
  30591.  
  30592. I have a HiperDSP on a PRI that is showing "Abnormal Disconnect" for reason
  30593. for call failure, and also "carrier loss" for reason for call termination,
  30594. and it won't take calls until I reboot it.  It will only take one or two
  30595. calls successfully before the problem starts up again.  What could be
  30596. causing this?  Thanks.
  30597.  
  30598. Mike Wilker
  30599. Operations Manager
  30600. Local Link, Inc.
  30601.  
  30602.  
  30603. -
  30604.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30605.  with "unsubscribe usr-tc" in the body of the message.
  30606.  For information on digests or retrieving files and old messages send
  30607.  "help" to the same address.  Do not use quotes in your message.
  30608.  
  30609.  
  30610. -------------------------------------------------------------------------------
  30611.  
  30612. From: "Mike Wilker" <mikew@LL.NET>
  30613. Subject: (usr-tc) Abnormal disconnect
  30614. Date: 27 Oct 1999 10:21:52 -0500
  30615.  
  30616. I have a HiperDSP on a PRI that is showing "Abnormal Disconnect" for reason
  30617. for call failure, and also "carrier loss" for reason for call termination,
  30618. and it won't take calls until I reboot it.  It will only take one or two
  30619. calls successfully before the problem starts up again.  What could be
  30620. causing this?  Thanks.
  30621.  
  30622. Mike Wilker
  30623. Operations Manager
  30624. Local Link, Inc.
  30625.  
  30626.  
  30627. -
  30628.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30629.  with "unsubscribe usr-tc" in the body of the message.
  30630.  For information on digests or retrieving files and old messages send
  30631.  "help" to the same address.  Do not use quotes in your message.
  30632.  
  30633.  
  30634. -------------------------------------------------------------------------------
  30635.  
  30636. From: "Brian Becker" <brian@semo.net>
  30637. Subject: (usr-tc) Primary & Secondary Authentication servers
  30638. Date: 27 Oct 1999 10:06:40 -0500
  30639.  
  30640. This is a multi-part message in MIME format.
  30641.  
  30642. ------=_NextPart_000_00DC_01BF2063.A247F860
  30643. Content-Type: text/plain;
  30644.     charset="iso-8859-1"
  30645. Content-Transfer-Encoding: 8bit
  30646.  
  30647. How do I tell the Arc to use the Primary server when the active server shows
  30648. the secondary?
  30649. á
  30650. And is there something to configure to tell the arc to prefer the primary
  30651. and use the secondary only when the primary is unavailable but then switch
  30652. back to the primary again in a few minutes?
  30653.  
  30654. Brian Becker
  30655. President, Poplar Bluff Internet
  30656. áá http://www.semo.net
  30657. TotallyFabricated.com Software
  30658. áá http://www.TotallyFabricated.com
  30659. Home of JerusalemPerspective.com
  30660. áá http://www.JerusalemPerspective.com
  30661. Personal Page
  30662. áá http://Tonionio.comá / http://BenjaminBecker.com
  30663.  
  30664. á
  30665.  
  30666. ------=_NextPart_000_00DC_01BF2063.A247F860
  30667. Content-Type: text/html;
  30668.     charset="iso-8859-1"
  30669. Content-Transfer-Encoding: quoted-printable
  30670.  
  30671. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  30672. <HTML><HEAD>
  30673. <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
  30674. charset=3Diso-8859-1">
  30675.  
  30676.  
  30677. <META content=3D"MSHTML 5.00.2516.1900" name=3DGENERATOR></HEAD>
  30678. <BODY>
  30679. <DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>How do =
  30680. I tell the=20
  30681. Arc to use the Primary server when the active server shows the=20
  30682. secondary?</SPAN></FONT></DIV>
  30683. <DIV><FONT face=3DArial size=3D2><SPAN=20
  30684. class=3D825440615-27101999></SPAN></FONT> </DIV>
  30685. <DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>And is =
  30686. there=20
  30687. something to configure to tell the arc to prefer the primary and use the =
  30688.  
  30689. secondary only when the primary is unavailable but then switch back to =
  30690. the=20
  30691. primary again in a few minutes?</SPAN></FONT></DIV>
  30692. <P><FONT color=3D#000080 face=3DArial size=3D2>Brian Becker</FONT> =
  30693. <BR><FONT=20
  30694. color=3D#800000 face=3DArial size=3D2>President, Poplar Bluff =
  30695. Internet</FONT>=20
  30696. <BR><FONT color=3D#800000 face=3DArial size=3D2>   <A=20
  30697. href=3D"http://www.semo.net/" =
  30698. target=3D_blank>http://www.semo.net</A></FONT>=20
  30699. <BR><FONT color=3D#000080 face=3DArial size=3D2>TotallyFabricated.com =
  30700. Software</FONT>=20
  30701. <BR><FONT color=3D#000080 face=3DArial size=3D2>   <A=20
  30702. href=3D"http://www.totallyfabricated.com/"=20
  30703. target=3D_blank>http://www.TotallyFabricated.com</A></FONT> <BR><FONT=20
  30704. color=3D#800000 face=3DArial size=3D2>Home of =
  30705. JerusalemPerspective.com</FONT>=20
  30706. <BR><FONT color=3D#800000 face=3DArial size=3D2>   <A=20
  30707. href=3D"http://www.jerusalemperspective.com/"=20
  30708. target=3D_blank>http://www.JerusalemPerspective.com</A></FONT> <BR><FONT =
  30709.  
  30710. color=3D#000080 face=3DArial size=3D2>Personal Page</FONT> <BR><FONT =
  30711. color=3D#000080=20
  30712. face=3DArial size=3D2>   <A href=3D"http://tonionio.com/"=20
  30713. target=3D_blank>http://Tonionio.com</A>  / <A=20
  30714. href=3D"http://benjaminbecker.com/"=20
  30715. target=3D_blank>http://BenjaminBecker.com</A></FONT> </P>
  30716. <DIV> </DIV></BODY></HTML>
  30717.  
  30718. ------=_NextPart_000_00DC_01BF2063.A247F860--
  30719.  
  30720.  
  30721. -
  30722.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30723.  with "unsubscribe usr-tc" in the body of the message.
  30724.  For information on digests or retrieving files and old messages send
  30725.  "help" to the same address.  Do not use quotes in your message.
  30726.  
  30727.  
  30728. -------------------------------------------------------------------------------
  30729.  
  30730. From: "Brian Becker" <brian@semo.net>
  30731. Subject: (usr-tc) Primary & Secondary Authentication servers
  30732. Date: 27 Oct 1999 14:45:13 -0500
  30733.  
  30734. How do I tell the Arc to switch back to the Primary server when the active
  30735. server shows the secondary?
  30736.  
  30737. And is there something to configure to tell the arc to prefer the primary
  30738. and use the secondary only when the primary is unavailable but then switch
  30739. back to the primary again in a few minutes?
  30740.  
  30741. Brian Becker
  30742. President, Poplar Bluff Internet
  30743.    http://www.semo.net
  30744. TotallyFabricated.com Software
  30745.    http://www.TotallyFabricated.com
  30746. Home of JerusalemPerspective.com
  30747.    http://www.JerusalemPerspective.com
  30748. Personal Page
  30749.    http://Tonionio.com  / http://BenjaminBecker.com
  30750.  
  30751.  
  30752. -
  30753.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30754.  with "unsubscribe usr-tc" in the body of the message.
  30755.  For information on digests or retrieving files and old messages send
  30756.  "help" to the same address.  Do not use quotes in your message.
  30757.  
  30758.  
  30759. -------------------------------------------------------------------------------
  30760.  
  30761. From: "Brian Becker" <brian@semo.net>
  30762. Subject: (usr-tc) Primary & Secondary Authentication servers
  30763. Date: 27 Oct 1999 10:06:40 -0500
  30764.  
  30765. This is a multi-part message in MIME format.
  30766.  
  30767. ------=_NextPart_000_00DC_01BF2063.A247F860
  30768. Content-Type: text/plain;
  30769.     charset="iso-8859-1"
  30770. Content-Transfer-Encoding: 8bit
  30771.  
  30772. How do I tell the Arc to use the Primary server when the active server shows
  30773. the secondary?
  30774. á
  30775. And is there something to configure to tell the arc to prefer the primary
  30776. and use the secondary only when the primary is unavailable but then switch
  30777. back to the primary again in a few minutes?
  30778.  
  30779. Brian Becker
  30780. President, Poplar Bluff Internet
  30781. áá http://www.semo.net
  30782. TotallyFabricated.com Software
  30783. áá http://www.TotallyFabricated.com
  30784. Home of JerusalemPerspective.com
  30785. áá http://www.JerusalemPerspective.com
  30786. Personal Page
  30787. áá http://Tonionio.comá / http://BenjaminBecker.com
  30788.  
  30789. á
  30790.  
  30791. ------=_NextPart_000_00DC_01BF2063.A247F860
  30792. Content-Type: text/html;
  30793.     charset="iso-8859-1"
  30794. Content-Transfer-Encoding: quoted-printable
  30795.  
  30796. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  30797. <HTML><HEAD>
  30798. <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
  30799. charset=3Diso-8859-1">
  30800.  
  30801.  
  30802. <META content=3D"MSHTML 5.00.2516.1900" name=3DGENERATOR></HEAD>
  30803. <BODY>
  30804. <DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>How do =
  30805. I tell the=20
  30806. Arc to use the Primary server when the active server shows the=20
  30807. secondary?</SPAN></FONT></DIV>
  30808. <DIV><FONT face=3DArial size=3D2><SPAN=20
  30809. class=3D825440615-27101999></SPAN></FONT> </DIV>
  30810. <DIV><FONT face=3DArial size=3D2><SPAN class=3D825440615-27101999>And is =
  30811. there=20
  30812. something to configure to tell the arc to prefer the primary and use the =
  30813.  
  30814. secondary only when the primary is unavailable but then switch back to =
  30815. the=20
  30816. primary again in a few minutes?</SPAN></FONT></DIV>
  30817. <P><FONT color=3D#000080 face=3DArial size=3D2>Brian Becker</FONT> =
  30818. <BR><FONT=20
  30819. color=3D#800000 face=3DArial size=3D2>President, Poplar Bluff =
  30820. Internet</FONT>=20
  30821. <BR><FONT color=3D#800000 face=3DArial size=3D2>   <A=20
  30822. href=3D"http://www.semo.net/" =
  30823. target=3D_blank>http://www.semo.net</A></FONT>=20
  30824. <BR><FONT color=3D#000080 face=3DArial size=3D2>TotallyFabricated.com =
  30825. Software</FONT>=20
  30826. <BR><FONT color=3D#000080 face=3DArial size=3D2>   <A=20
  30827. href=3D"http://www.totallyfabricated.com/"=20
  30828. target=3D_blank>http://www.TotallyFabricated.com</A></FONT> <BR><FONT=20
  30829. color=3D#800000 face=3DArial size=3D2>Home of =
  30830. JerusalemPerspective.com</FONT>=20
  30831. <BR><FONT color=3D#800000 face=3DArial size=3D2>   <A=20
  30832. href=3D"http://www.jerusalemperspective.com/"=20
  30833. target=3D_blank>http://www.JerusalemPerspective.com</A></FONT> <BR><FONT =
  30834.  
  30835. color=3D#000080 face=3DArial size=3D2>Personal Page</FONT> <BR><FONT =
  30836. color=3D#000080=20
  30837. face=3DArial size=3D2>   <A href=3D"http://tonionio.com/"=20
  30838. target=3D_blank>http://Tonionio.com</A>  / <A=20
  30839. href=3D"http://benjaminbecker.com/"=20
  30840. target=3D_blank>http://BenjaminBecker.com</A></FONT> </P>
  30841. <DIV> </DIV></BODY></HTML>
  30842.  
  30843. ------=_NextPart_000_00DC_01BF2063.A247F860--
  30844.  
  30845.  
  30846. -
  30847.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30848.  with "unsubscribe usr-tc" in the body of the message.
  30849.  For information on digests or retrieving files and old messages send
  30850.  "help" to the same address.  Do not use quotes in your message.
  30851.  
  30852.  
  30853. -------------------------------------------------------------------------------
  30854.  
  30855. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  30856. Subject: RE: (usr-tc) Primary & Secondary Authentication servers
  30857. Date: 27 Oct 1999 17:01:26 -0300
  30858.  
  30859. set radiuS authenTICATION_ALGORITHM fall_THROUGH
  30860.  
  30861. -----Original Message-----
  30862. Sent: Wednesday, October 27, 1999 12:07 PM
  30863.  
  30864.  
  30865. How do I tell the Arc to use the Primary server when the active server =
  30866. shows
  30867. the secondary?
  30868. =A0
  30869. And is there something to configure to tell the arc to prefer the =
  30870. primary
  30871. and use the secondary only when the primary is unavailable but then =
  30872. switch
  30873. back to the primary again in a few minutes?
  30874.  
  30875. Brian Becker=20
  30876. President, Poplar Bluff Internet=20
  30877. =A0=A0 http://www.semo.net <http://www.semo.net/> =20
  30878. TotallyFabricated.com Software=20
  30879. =A0=A0 http://www.TotallyFabricated.com =
  30880. <http://www.totallyfabricated.com/> =20
  30881. Home of JerusalemPerspective.com=20
  30882. =A0=A0 http://www.JerusalemPerspective.com
  30883. <http://www.jerusalemperspective.com/> =20
  30884. Personal Page=20
  30885. =A0=A0 http://Tonionio.com <http://tonionio.com/> =A0 / =
  30886. http://BenjaminBecker.com
  30887. <http://benjaminbecker.com/> =20
  30888.  
  30889. =A0
  30890.  
  30891.  
  30892. -
  30893.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30894.  with "unsubscribe usr-tc" in the body of the message.
  30895.  For information on digests or retrieving files and old messages send
  30896.  "help" to the same address.  Do not use quotes in your message.
  30897.  
  30898.  
  30899. -------------------------------------------------------------------------------
  30900.  
  30901. From: "Christopher Arlis Hanes" <chanes@usacars.com>
  30902. Subject: (usr-tc) Modem connection problems...
  30903. Date: 27 Oct 1999 16:02:04 -0400
  30904.  
  30905. Hey all,
  30906.  
  30907. I'm having issues with a minority of customers' connections to my TCH
  30908. Quad modem and Hiper DSP boxes being dropped.  From experimenting with
  30909. customer's modems, it seems they are able to maintain a connection so
  30910. long as they connect at less than v.34 (i.e. 19.2K max connection
  30911. speed), otherwise they're getting dropped after about 10 minutes of
  30912. activity.   From the NMC, ds0Teardown is the disconnect reason and many
  30913. retrains, link block errors, etc. precede the call being dropped. A
  30914. modemlog on client machine shows the NAS dropping the call.  It looks
  30915. like the modems connect at a given speed, errors occur, the modems train
  30916. down, errors still occur, and so on until the connection is dropped.
  30917. Client modem types include  ESS ES56CVH-PI Data Fax Voice Modem and
  30918. another based on the Cirrus Logic CL_MD34XX.  What I am missing here?  I
  30919. haven't had any luck finding any initialization strings to help.
  30920.  
  30921. Thanks,
  30922. Chris Hanes
  30923.  
  30924.  
  30925. -
  30926.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30927.  with "unsubscribe usr-tc" in the body of the message.
  30928.  For information on digests or retrieving files and old messages send
  30929.  "help" to the same address.  Do not use quotes in your message.
  30930.  
  30931.  
  30932. -------------------------------------------------------------------------------
  30933.  
  30934. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  30935. Subject: RE: (usr-tc) Primary & Secondary Authentication servers
  30936. Date: 27 Oct 1999 17:16:25 -0300
  30937.  
  30938. And if you want to do this for accounting as well, it's enab
  30939. priorITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP=20
  30940. =A0
  30941. no, that's not a typo, it's really spelled 'prioritise' in the CLI.
  30942.  
  30943. -----Original Message-----
  30944. Sent: Wednesday, October 27, 1999 12:07 PM
  30945.  
  30946.  
  30947. How do I tell the Arc to use the Primary server when the active server =
  30948. shows
  30949. the secondary?
  30950. =A0
  30951. And is there something to configure to tell the arc to prefer the =
  30952. primary
  30953. and use the secondary only when the primary is unavailable but then =
  30954. switch
  30955. back to the primary again in a few minutes?
  30956.  
  30957. Brian Becker=20
  30958. President, Poplar Bluff Internet=20
  30959. =A0=A0 http://www.semo.net <http://www.semo.net/> =20
  30960. TotallyFabricated.com Software=20
  30961. =A0=A0 http://www.TotallyFabricated.com =
  30962. <http://www.totallyfabricated.com/> =20
  30963. Home of JerusalemPerspective.com=20
  30964. =A0=A0 http://www.JerusalemPerspective.com
  30965. <http://www.jerusalemperspective.com/> =20
  30966. Personal Page=20
  30967. =A0=A0 http://Tonionio.com <http://tonionio.com/> =A0 / =
  30968. http://BenjaminBecker.com
  30969. <http://benjaminbecker.com/> =20
  30970.  
  30971. =A0
  30972.  
  30973.  
  30974. -
  30975.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30976.  with "unsubscribe usr-tc" in the body of the message.
  30977.  For information on digests or retrieving files and old messages send
  30978.  "help" to the same address.  Do not use quotes in your message.
  30979.  
  30980.  
  30981. -------------------------------------------------------------------------------
  30982.  
  30983. From: "Scot Desort" <scot@njaccess.net>
  30984. Subject: RE: (usr-tc) Modem connection problems...
  30985. Date: 27 Oct 1999 16:43:52 -0400
  30986.  
  30987. Just a stab -- have you tried disabling compression on the client side?
  30988.  
  30989. -----Original Message-----
  30990. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Christopher Arlis
  30991. Hanes
  30992. Sent: Wednesday, October 27, 1999 4:02 PM
  30993.  
  30994.  
  30995. Hey all,
  30996.  
  30997. I'm having issues with a minority of customers' connections to my TCH
  30998. Quad modem and Hiper DSP boxes being dropped.  From experimenting with
  30999. customer's modems, it seems they are able to maintain a connection so
  31000. long as they connect at less than v.34 (i.e. 19.2K max connection
  31001. speed), otherwise they're getting dropped after about 10 minutes of
  31002. activity.   From the NMC, ds0Teardown is the disconnect reason and many
  31003. retrains, link block errors, etc. precede the call being dropped. A
  31004. modemlog on client machine shows the NAS dropping the call.  It looks
  31005. like the modems connect at a given speed, errors occur, the modems train
  31006. down, errors still occur, and so on until the connection is dropped.
  31007. Client modem types include  ESS ES56CVH-PI Data Fax Voice Modem and
  31008. another based on the Cirrus Logic CL_MD34XX.  What I am missing here?  I
  31009. haven't had any luck finding any initialization strings to help.
  31010.  
  31011. Thanks,
  31012. Chris Hanes
  31013.  
  31014.  
  31015. -
  31016.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31017.  with "unsubscribe usr-tc" in the body of the message.
  31018.  For information on digests or retrieving files and old messages send
  31019.  "help" to the same address.  Do not use quotes in your message.
  31020.  
  31021.  
  31022. -
  31023.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31024.  with "unsubscribe usr-tc" in the body of the message.
  31025.  For information on digests or retrieving files and old messages send
  31026.  "help" to the same address.  Do not use quotes in your message.
  31027.  
  31028.  
  31029. -------------------------------------------------------------------------------
  31030.  
  31031. From: Mark Lovell <mark@caverock.co.nz>
  31032. Subject: RE: (usr-tc) Primary & Secondary Authentication servers
  31033. Date: 28 Oct 1999 10:00:58 +1300 (NZDT)
  31034.  
  31035. G'day,
  31036.  
  31037. On Wed, 27 Oct 1999, Stainforth, Matthew wrote:
  31038.  
  31039. > And if you want to do this for accounting as well, it's enab
  31040. > priorITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP 
  31041.  
  31042. > no, that's not a typo, it's really spelled 'prioritise' in the CLI.
  31043.  
  31044. But of course, how else would you spell prioritise?  ;-)
  31045.  
  31046. Kindest regards,
  31047. Mark
  31048.  
  31049. -- 
  31050. Mark Lovell                                   
  31051. Cave Rock Software Ltd / Cave Rock Internet         0800 GETONLINE
  31052. Phone: +64 3 3664242 (0800 438665)              Fax: +64 3 3665478           
  31053. Unit 1a 492 Moorhouse Ave, PO Box 22488, Christchurch, New Zealand
  31054. "Happiness is a belt fed weapon"
  31055.  
  31056.  
  31057. -
  31058.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31059.  with "unsubscribe usr-tc" in the body of the message.
  31060.  For information on digests or retrieving files and old messages send
  31061.  "help" to the same address.  Do not use quotes in your message.
  31062.  
  31063.  
  31064. -------------------------------------------------------------------------------
  31065.  
  31066. From: Robert von Bismarck <rvb@petrel.ch>
  31067. Subject: RE: (usr-tc) ARC Default Gateway
  31068. Date: 27 Oct 1999 14:16:21 +0200
  31069.  
  31070. Umh.. In my knowledge, you can have only one "default" route. In ciscoes
  31071. it's very aptly named "gateway of last resort", as it is where the packets
  31072. will go if no route is found in the local routing table. If you have two
  31073. interfaces, you need to specify all the routes going through the second
  31074. interface (assuming the default route is on the first interface). If you add
  31075. a second default route, it will (say should) overwrite the first entry.
  31076.  
  31077.  
  31078. Robert
  31079.  
  31080.     -----Original Message-----
  31081.     From:    Clayton Zekelman [SMTP:clayton@MNSi.Net]
  31082.     Sent:    mercredi, 27. octobre 1999 00:11
  31083.     To:    usr-tc@lists.xmission.com
  31084.     Subject:    Re: (usr-tc) ARC Default Gateway
  31085.  
  31086.     It seems "set" won't work.  I tried add, and it worked, but replaced
  31087. the
  31088.     existing default (which is what I wanted, but wouldn't expect from
  31089. "add").
  31090.  
  31091.     I've never run into a device with such an annoying command
  31092. structure.
  31093.  
  31094.     At 04:46 PM 10/26/99 -0500, you wrote:
  31095.     >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31096.     >
  31097.     >If you should need multiple defaultroutes:
  31098.     >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31099.     >
  31100.     >Gabriel
  31101.     >
  31102.     >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  31103.     >
  31104.     >> OK, I know I'm missing something simple, but how do you change
  31105. the default
  31106.     >> gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route,
  31107. but it
  31108.     >> rejected it.  Any ideas?
  31109.     >> 
  31110.     >> 
  31111.     >> ---
  31112.     >> Clayton Zekelman
  31113.     >> Managed Network Systems Inc. (MNSi)
  31114.     >> 875 Ouellette Avenue
  31115.     >> Windsor, Ontario
  31116.     >> N9A 4J6
  31117.     >> 
  31118.     >> tel. 519-985-8410
  31119.     >> fax. 519-258-3009
  31120.     >> 
  31121.     >> -
  31122.     >>  To unsubscribe to usr-tc, send an email to
  31123. "majordomo@xmission.com"
  31124.     >>  with "unsubscribe usr-tc" in the body of the message.
  31125.     >>  For information on digests or retrieving files and old messages
  31126. send
  31127.     >>  "help" to the same address.  Do not use quotes in your message.
  31128.     >> 
  31129.     >> 
  31130.     >> 
  31131.     >
  31132.     >--
  31133.     >* speedy@dixie-net.com *
  31134.     >* Gabriel Grissett     *
  31135.     >
  31136.     >
  31137.     >-
  31138.     > To unsubscribe to usr-tc, send an email to
  31139. "majordomo@xmission.com"
  31140.     > with "unsubscribe usr-tc" in the body of the message.
  31141.     > For information on digests or retrieving files and old messages
  31142. send
  31143.     > "help" to the same address.  Do not use quotes in your message.
  31144.     > 
  31145.     ---
  31146.     Clayton Zekelman
  31147.     Managed Network Systems Inc. (MNSi)
  31148.     875 Ouellette Avenue
  31149.     Windsor, Ontario
  31150.     N9A 4J6
  31151.  
  31152.     tel. 519-985-8410
  31153.     fax. 519-258-3009
  31154.  
  31155.     -
  31156.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31157.      with "unsubscribe usr-tc" in the body of the message.
  31158.      For information on digests or retrieving files and old messages
  31159. send
  31160.      "help" to the same address.  Do not use quotes in your message.
  31161.  
  31162. -
  31163.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31164.  with "unsubscribe usr-tc" in the body of the message.
  31165.  For information on digests or retrieving files and old messages send
  31166.  "help" to the same address.  Do not use quotes in your message.
  31167.  
  31168.  
  31169. -------------------------------------------------------------------------------
  31170.  
  31171. From: Robert von Bismarck <rvb@petrel.ch>
  31172. Subject: RE: (usr-tc) ARC Default Gateway
  31173. Date: 27 Oct 1999 14:16:21 +0200
  31174.  
  31175. Umh.. In my knowledge, you can have only one "default" route. In ciscoes
  31176. it's very aptly named "gateway of last resort", as it is where the packets
  31177. will go if no route is found in the local routing table. If you have two
  31178. interfaces, you need to specify all the routes going through the second
  31179. interface (assuming the default route is on the first interface). If you add
  31180. a second default route, it will (say should) overwrite the first entry.
  31181.  
  31182.  
  31183. Robert
  31184.  
  31185.     -----Original Message-----
  31186.     From:    Clayton Zekelman [SMTP:clayton@MNSi.Net]
  31187.     Sent:    mercredi, 27. octobre 1999 00:11
  31188.     To:    usr-tc@lists.xmission.com
  31189.     Subject:    Re: (usr-tc) ARC Default Gateway
  31190.  
  31191.     It seems "set" won't work.  I tried add, and it worked, but replaced
  31192. the
  31193.     existing default (which is what I wanted, but wouldn't expect from
  31194. "add").
  31195.  
  31196.     I've never run into a device with such an annoying command
  31197. structure.
  31198.  
  31199.     At 04:46 PM 10/26/99 -0500, you wrote:
  31200.     >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31201.     >
  31202.     >If you should need multiple defaultroutes:
  31203.     >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31204.     >
  31205.     >Gabriel
  31206.     >
  31207.     >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  31208.     >
  31209.     >> OK, I know I'm missing something simple, but how do you change
  31210. the default
  31211.     >> gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route,
  31212. but it
  31213.     >> rejected it.  Any ideas?
  31214.     >> 
  31215.     >> 
  31216.     >> ---
  31217.     >> Clayton Zekelman
  31218.     >> Managed Network Systems Inc. (MNSi)
  31219.     >> 875 Ouellette Avenue
  31220.     >> Windsor, Ontario
  31221.     >> N9A 4J6
  31222.     >> 
  31223.     >> tel. 519-985-8410
  31224.     >> fax. 519-258-3009
  31225.     >> 
  31226.     >> -
  31227.     >>  To unsubscribe to usr-tc, send an email to
  31228. "majordomo@xmission.com"
  31229.     >>  with "unsubscribe usr-tc" in the body of the message.
  31230.     >>  For information on digests or retrieving files and old messages
  31231. send
  31232.     >>  "help" to the same address.  Do not use quotes in your message.
  31233.     >> 
  31234.     >> 
  31235.     >> 
  31236.     >
  31237.     >--
  31238.     >* speedy@dixie-net.com *
  31239.     >* Gabriel Grissett     *
  31240.     >
  31241.     >
  31242.     >-
  31243.     > To unsubscribe to usr-tc, send an email to
  31244. "majordomo@xmission.com"
  31245.     > with "unsubscribe usr-tc" in the body of the message.
  31246.     > For information on digests or retrieving files and old messages
  31247. send
  31248.     > "help" to the same address.  Do not use quotes in your message.
  31249.     > 
  31250.     ---
  31251.     Clayton Zekelman
  31252.     Managed Network Systems Inc. (MNSi)
  31253.     875 Ouellette Avenue
  31254.     Windsor, Ontario
  31255.     N9A 4J6
  31256.  
  31257.     tel. 519-985-8410
  31258.     fax. 519-258-3009
  31259.  
  31260.     -
  31261.      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31262.      with "unsubscribe usr-tc" in the body of the message.
  31263.      For information on digests or retrieving files and old messages
  31264. send
  31265.      "help" to the same address.  Do not use quotes in your message.
  31266.  
  31267. -
  31268.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31269.  with "unsubscribe usr-tc" in the body of the message.
  31270.  For information on digests or retrieving files and old messages send
  31271.  "help" to the same address.  Do not use quotes in your message.
  31272.  
  31273.  
  31274. -------------------------------------------------------------------------------
  31275.  
  31276. From: Charles Sprickman <spork@inch.com>
  31277. Subject: RE: (usr-tc) ARC Default Gateway
  31278. Date: 27 Oct 1999 18:40:56 -0400 (EDT)
  31279.  
  31280. I've got some mojo working on my Cisco then:
  31281.  
  31282. Inch-Whitehall-gw>sh ip route 0.0.0.0
  31283. Routing entry for 0.0.0.0/0, supernet
  31284.   Known via "static", distance 1, metric 0, candidate default path
  31285.   Redistributing via ospf 1
  31286.   Routing Descriptor Blocks:
  31287.   * 207.240.128.xxx
  31288.       Route metric is 0, traffic share count is 1
  31289.     207.240.128.xxx
  31290.       Route metric is 0, traffic share count is 1      
  31291.  
  31292. I'm using this to load balance on the way out over two T's.  If one goes
  31293. down the route goes away.  On the other side OSPF is balancing the
  31294. incoming traffic...
  31295.  
  31296. I don't know what you'd do with two default routes on an ARC, but I'm sure
  31297. there's someone who could use it...
  31298.  
  31299. Charles
  31300.  
  31301. On Wed, 27 Oct 1999, Robert von Bismarck wrote:
  31302.  
  31303. > Umh.. In my knowledge, you can have only one "default" route. In ciscoes
  31304. > it's very aptly named "gateway of last resort", as it is where the packets
  31305. > will go if no route is found in the local routing table. If you have two
  31306. > interfaces, you need to specify all the routes going through the second
  31307. > interface (assuming the default route is on the first interface). If you add
  31308. > a second default route, it will (say should) overwrite the first entry.
  31309. > 
  31310. > 
  31311. > Robert
  31312. > 
  31313. >     -----Original Message-----
  31314. >     From:    Clayton Zekelman [SMTP:clayton@MNSi.Net]
  31315. >     Sent:    mercredi, 27. octobre 1999 00:11
  31316. >     To:    usr-tc@lists.xmission.com
  31317. >     Subject:    Re: (usr-tc) ARC Default Gateway
  31318. > 
  31319. >     It seems "set" won't work.  I tried add, and it worked, but replaced
  31320. > the
  31321. >     existing default (which is what I wanted, but wouldn't expect from
  31322. > "add").
  31323. > 
  31324. >     I've never run into a device with such an annoying command
  31325. > structure.
  31326. > 
  31327. >     At 04:46 PM 10/26/99 -0500, you wrote:
  31328. >     >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31329. >     >
  31330. >     >If you should need multiple defaultroutes:
  31331. >     >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31332. >     >
  31333. >     >Gabriel
  31334. >     >
  31335. >     >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  31336. >     >
  31337. >     >> OK, I know I'm missing something simple, but how do you change
  31338. > the default
  31339. >     >> gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route,
  31340. > but it
  31341. >     >> rejected it.  Any ideas?
  31342. >     >> 
  31343. >     >> 
  31344. >     >> ---
  31345. >     >> Clayton Zekelman
  31346. >     >> Managed Network Systems Inc. (MNSi)
  31347. >     >> 875 Ouellette Avenue
  31348. >     >> Windsor, Ontario
  31349. >     >> N9A 4J6
  31350. >     >> 
  31351. >     >> tel. 519-985-8410
  31352. >     >> fax. 519-258-3009
  31353. >     >> 
  31354. >     >> -
  31355. >     >>  To unsubscribe to usr-tc, send an email to
  31356. > "majordomo@xmission.com"
  31357. >     >>  with "unsubscribe usr-tc" in the body of the message.
  31358. >     >>  For information on digests or retrieving files and old messages
  31359. > send
  31360. >     >>  "help" to the same address.  Do not use quotes in your message.
  31361. >     >> 
  31362. >     >> 
  31363. >     >> 
  31364. >     >
  31365. >     >--
  31366. >     >* speedy@dixie-net.com *
  31367. >     >* Gabriel Grissett     *
  31368. >     >
  31369. >     >
  31370. >     >-
  31371. >     > To unsubscribe to usr-tc, send an email to
  31372. > "majordomo@xmission.com"
  31373. >     > with "unsubscribe usr-tc" in the body of the message.
  31374. >     > For information on digests or retrieving files and old messages
  31375. > send
  31376. >     > "help" to the same address.  Do not use quotes in your message.
  31377. >     > 
  31378. >     ---
  31379. >     Clayton Zekelman
  31380. >     Managed Network Systems Inc. (MNSi)
  31381. >     875 Ouellette Avenue
  31382. >     Windsor, Ontario
  31383. >     N9A 4J6
  31384. > 
  31385. >     tel. 519-985-8410
  31386. >     fax. 519-258-3009
  31387. > 
  31388. >     -
  31389. >      To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31390. >      with "unsubscribe usr-tc" in the body of the message.
  31391. >      For information on digests or retrieving files and old messages
  31392. > send
  31393. >      "help" to the same address.  Do not use quotes in your message.
  31394. > 
  31395. > -
  31396. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31397. >  with "unsubscribe usr-tc" in the body of the message.
  31398. >  For information on digests or retrieving files and old messages send
  31399. >  "help" to the same address.  Do not use quotes in your message.
  31400. > 
  31401.  
  31402.  
  31403. -
  31404.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31405.  with "unsubscribe usr-tc" in the body of the message.
  31406.  For information on digests or retrieving files and old messages send
  31407.  "help" to the same address.  Do not use quotes in your message.
  31408.  
  31409.  
  31410. -------------------------------------------------------------------------------
  31411.  
  31412. From: K Mitchell <mitch@keyconn.net>
  31413. Subject: (usr-tc) dead console port?
  31414. Date: 27 Oct 1999 19:17:14 -0400
  31415.  
  31416.   I have a user that was apparently being flooded from another user of a
  31417. java chat room he was in. I opened a console ARC connection to mon ppp and
  31418. determine the origin of the attack. After about 10 seconds of tracing the
  31419. console connection froze and I've been unable to re-establish it. I've
  31420. tried disconnecting and reconnecting, as well as removing and replacing the
  31421. cables to no avail. Any ideas how I can re-open the console connection?
  31422.   In case it might help, here's the last few events received;
  31423. Incoming PPP Data on interface: slot:1/mod:23
  31424.     21 45 00 00 26 a2 70 00 00 80 11 29 7a cc ab 1f |!E  & p    )z   |
  31425.     b8 d1 75 b1 03 58 1b 58 1b 00 12 ab d3 0c 01 01 |  u  X X        |
  31426.     0a 00 d6 1b 02 0c 00                            |                |
  31427.  
  31428.  
  31429. Outgoing PPP Data on interface: slot:1/mod:23
  31430.     21 45 00 00 41 77 e7 40 00 ee 11 a5 e7 d1 75 b1 |!E  Aw @      u |
  31431.     03 cc ab 1f b8 58 1b 58 1b 00 2d 21 d7 0d 01 01 |     X X  -!    |
  31432.     25 00 d6 4c 39 0a 50 66 64 66 56 46 a5 7a a6 aa |%  L9 PfdfVF z  |
  31433.     ba 6a 56 64 96 56 19 65 8d a8 4d 80 41 04 1e 7d | jVd V e  M A  }|
  31434.     21 ec                                           |!               |
  31435.  
  31436.  
  31437. Outgoing PPP Data on interface: slot:1/mod:23
  31438.     21 45 00 00 26 77 e8 40 00 ee 11 a6 01 d1 75 b1 |!E  &w @      u |
  31439.     03 cc ab 1f b8 58 1b 58 1b 00 12 80 d4 0c 01 01 |     X X        |
  31440.     0a 00 d6 4c 01 06 00                            |   L            |
  31441.  
  31442.  
  31443. Outgoing PPP Data on interface: slot:1/mod:23
  31444.     21 45 00 01 a9 77 e9 40 00 ee 11 a4 7d d1 75 b1 |!E   w @    } u |
  31445.     03 cc ab 1f b8 58 1b 58 1b 01 95 69 26 0d 01 01 |     X X   i&   |
  31446.     59 01 d6 4d 39 0e 01 cc 2e dd f7 26 25 64 52 1e |Y  M9   .  &%dR |
  31447.     2e 75 b8 91 d2 c2 ac 2d 8e b1 62 11 8c 18 65 0a |.u     -  b   e |
  31448.     5b d5 55 66 70 c5 7b 4e 68 ae a7 54 e1 61 9e 6d |[ Ufp {Nh  T a m|
  31449.     6f 66 9e 09 c5 af 45 d1 c7 14 57 35 e2 5c 16 d3 |of    E   W5 \  |
  31450.     fe 54 45 85 65 59 b1 70 82 a4 61 91 94 69 8a 0d | TE eY p  a  i  |
  31451.     d1 8e 45 b1 46 0c 5b fc b8 f6 65 a2 53 a5 61 75 |  E F [   e S au|
  31452.     09 5a 86 9d a6 6d c9 7c e1 6a b2 0e 11 4e 3d a0 | Z   m | j   N= |
  31453.     c4 14 5e af 71 dc 55 b5 1d 55 e4 e5 de 96 5a 60 |  ^ q U  U    Z`|
  31454.     85 95 61 95 ac 25 a2 0d 09 d0 51 d1 87 18 4e 2f |  a  %    Q   N/|
  31455.     ac ae 5a fb 2b b2 5e 68 0a 1a 0e 07 b3 48 a9 92 |  Z + ^h     H  |
  31456.     99 54 28 2d 0d af 51 c1 05 10 a5 2b b2 39 60 7e | T(-  Q    + 9`~|
  31457.     f7 cc 6e ef 7c 95 d5 1e 88 91 98 7f 0d 8e d7 2c |  n |          ,|
  31458.     0d ef 55 d1 48 18 67 55 57 54 55 1d b8 29 54 a6 |  U H gUWTU  )T |
  31459.     5a 57 31 7d 70 02 85 e2 cf 19 13 08 91 51 45 61 |ZW1}p        QEa|
  31460.     46 18 7c d6 ac 6c 11 15 a9 16 67 0e 10 27 ce 95 |F |  l    g  '  |
  31461.     a7 9a ba dd 26 49 ec 09 19 71 61 91 84 1c 58 30 |    &I   qa   X0|
  31462.     2f e9 65 3d 19 a4 97 95 66 90 8a 36 5c 59 86 86 |/ e=    f  6\Y  |
  31463.     e8 b9 da 08 89 ed 35 b1 49 18 7e ce 96 54 51 23 |      5 I ~  TQ#|
  31464.     03 fd 69 a2 97 cb dc e7 7a 99 de 6e e8 7e 61 28 |  i     z  n ~a(|
  31465.     cd cd 3d b2 89 18 65 8d 16 40 55 d6 04 ab a2 85 |  =   e  @U     |
  31466.     13 1c 86 2a 5a 5e 66 70 72 95 6a 4d 51 8d 21 73 |   *Z^fpr jMQ !s|
  31467.     03 20 8c f3 e9 45 18 01 01 34 00 53 3d 44 61 6e |     E   4 S=Dan|
  31468.     62 6f 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |bo              |
  31469.     20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |                |
  31470.     20 20 20 20 20 20 20 20 20 00                   |                |
  31471.  
  31472. Thanks,
  31473. -- 
  31474. Kirk Mitchell-General Manager        mitch@keyconn.net
  31475. Keystone Connect                     Unlock Your World
  31476. Altoona, PA   814-941-5000      http://www.keyconn.net
  31477.  
  31478.  
  31479. -
  31480.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31481.  with "unsubscribe usr-tc" in the body of the message.
  31482.  For information on digests or retrieving files and old messages send
  31483.  "help" to the same address.  Do not use quotes in your message.
  31484.  
  31485.  
  31486. -------------------------------------------------------------------------------
  31487.  
  31488. From: Kevin Benton <s1kevin@tims.net>
  31489. Subject: RE: (usr-tc) ARC Default Gateway
  31490. Date: 27 Oct 1999 19:20:32 -0400 (EDT)
  31491.  
  31492. On Wed, 27 Oct 1999, Robert von Bismarck wrote:
  31493.  
  31494. > Umh.. In my knowledge, you can have only one "default" route. In ciscoes
  31495. > it's very aptly named "gateway of last resort", as it is where the packets
  31496. > will go if no route is found in the local routing table. If you have two
  31497. > interfaces, you need to specify all the routes going through the second
  31498. > interface (assuming the default route is on the first interface). If you add
  31499. > a second default route, it will (say should) overwrite the first entry.
  31500.  
  31501. Uhm, no.  As mentioned previously, you can load balance default gateways,
  31502. not to mention, fall back to a default gateway (hence the reason for a
  31503. metric on the default gateway).
  31504.  
  31505. Kevin
  31506.  
  31507. E-Mail:  s1kevin@tims.net
  31508. Web:     http://users.sota-oh.com/~s1kevin/
  31509. Unsolicited advertisements processing fee: $50 subject to change without notice
  31510.  
  31511.  
  31512. -
  31513.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31514.  with "unsubscribe usr-tc" in the body of the message.
  31515.  For information on digests or retrieving files and old messages send
  31516.  "help" to the same address.  Do not use quotes in your message.
  31517.  
  31518.  
  31519. -------------------------------------------------------------------------------
  31520.  
  31521. From: Jeff Mcadams <jeffm@iglou.com>
  31522. Subject: Re: (usr-tc) ARC Default Gateway
  31523. Date: 27 Oct 1999 22:55:43 -0400
  31524.  
  31525. Thus spake Charles Sprickman
  31526. >I've got some mojo working on my Cisco then:
  31527.  
  31528. >Inch-Whitehall-gw>sh ip route 0.0.0.0
  31529. >Routing entry for 0.0.0.0/0, supernet
  31530. ...
  31531.  
  31532. >I'm using this to load balance on the way out over two T's.  If one goes
  31533. >down the route goes away.  On the other side OSPF is balancing the
  31534. >incoming traffic...
  31535.  
  31536. >I don't know what you'd do with two default routes on an ARC, but I'm sure
  31537. >there's someone who could use it...
  31538.  
  31539. In Cisco-land at least, there is a difference between default routes and
  31540. routes to 0.0.0.0/0.  Routes to 0.0.0.0/0 are actual network routes, but
  31541. they're just the least specific network routes you can get.  They behave
  31542. the same as any other network routes (up to MAXPATHs load-balanced,
  31543. rules of administrative distances and all apply).  A default route is
  31544. what shows up as gateway of last resort, and I believe you can only set
  31545. one.
  31546. -- 
  31547. Jeff McAdams                            Email: jeffm@iglou.com
  31548. Head Network Administrator              Voice: (502) 966-3848
  31549. IgLou Internet Services                        (800) 436-4456
  31550.  
  31551. -
  31552.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31553.  with "unsubscribe usr-tc" in the body of the message.
  31554.  For information on digests or retrieving files and old messages send
  31555.  "help" to the same address.  Do not use quotes in your message.
  31556.  
  31557.  
  31558. -------------------------------------------------------------------------------
  31559.  
  31560. From: Mike Andrews <mandrews@bit0.com>
  31561. Subject: Re: (usr-tc) USR VSA's - 2 that I can't find
  31562. Date: 28 Oct 1999 02:52:14 -0400 (EDT)
  31563.  
  31564. How about 0x01ce, 0x01df, 0x01e0, 0x01e1, 0x01e2, and 0x01e3?
  31565.  
  31566. That HARC-Disconnect-Code one looks really useful, btw...
  31567.  
  31568.  
  31569. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  31570. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  31571. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  31572. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  31573.  
  31574. On Wed, 27 Oct 1999 dciresi@defunct.ae.usr.com wrote:
  31575.  
  31576. > 
  31577. > 
  31578. > On Wed, 27 Oct 1999, Jeff Mcadams wrote:
  31579. > 
  31580. > > Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
  31581. > > and 93051 (0x988b) are?
  31582. > > 
  31583. > > I looked on totalservice at the dictionary file there and these weren't
  31584. > > in there.
  31585. > > 
  31586. > > Thanks!
  31587. > > -- 
  31588. > > 
  31589. > > 
  31590. > Jeff,
  31591. > 
  31592. > These VSAs are part of HARC 4.2.x.
  31593. > The following should be added to your dictionary.
  31594. > 
  31595. > VSA USR HARC-Disconnect-Code     0x988b     integer
  31596. > 
  31597. > 
  31598. > VALUE HARC-Disconnect-Code    no-error        0
  31599. > VALUE HARC-Disconnect-Code    no-carrier           1
  31600. > VALUE HARC-Disconnect-Code    no-dsr               2
  31601. > VALUE HARC-Disconnect-Code    timeout              3
  31602. > VALUE HARC-Disconnect-Code    reset                4
  31603. > VALUE HARC-Disconnect-Code    call-drop-req        5
  31604. > VALUE HARC-Disconnect-Code    idle-timeout         6
  31605. > VALUE HARC-Disconnect-Code    session-timeout           7
  31606. > VALUE HARC-Disconnect-Code    user-req-drop        8
  31607. > VALUE HARC-Disconnect-Code    host-req-drop        9
  31608. > VALUE HARC-Disconnect-Code    service-interruption      10
  31609. > VALUE HARC-Disconnect-Code    service-unavailable  11
  31610. > VALUE HARC-Disconnect-Code    user-input-error     12
  31611. > VALUE HARC-Disconnect-Code    nas-drop-for-callback     13
  31612. > VALUE HARC-Disconnect-Code    nas-drop-misc-non-error   14
  31613. > VALUE HARC-Disconnect-Code    nas-internal-error   15
  31614. > VALUE HARC-Disconnect-Code    line-busy       16
  31615. > VALUE HARC-Disconnect-Code    RESERVED        17
  31616. > VALUE HARC-Disconnect-Code    RESERVED        18
  31617. > VALUE HARC-Disconnect-Code    tunnel-term-unreach  19
  31618. > VALUE HARC-Disconnect-Code    tunnel-refused       20
  31619. > VALUE HARC-Disconnect-Code    tunnel-auth-failed   21
  31620. > VALUE HARC-Disconnect-Code    tunnel-session-timeout    22
  31621. > VALUE HARC-Disconnect-Code    tunnel-timeout       23
  31622. > VALUE HARC-Disconnect-Code    RESERVED        24
  31623. > VALUE HARC-Disconnect-Code    radius-res-reclaim   25
  31624. > VALUE HARC-Disconnect-Code    dnis-auth-failed     26
  31625. > VALUE HARC-Disconnect-Code    pap-auth-failure     27
  31626. > VALUE HARC-Disconnect-Code    chap-auth-failure    28
  31627. > VALUE HARC-Disconnect-Code    ppp-lcp-failed       29
  31628. > VALUE HARC-Disconnect-Code    ppp-ncp-failed       30
  31629. > VALUE HARC-Disconnect-Code    radius-timeout       31
  31630. > 
  31631.  
  31632.  
  31633. -
  31634.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31635.  with "unsubscribe usr-tc" in the body of the message.
  31636.  For information on digests or retrieving files and old messages send
  31637.  "help" to the same address.  Do not use quotes in your message.
  31638.  
  31639.  
  31640. -------------------------------------------------------------------------------
  31641.  
  31642. From: "Startup Suppliers Ltd." <startnet@arcc.or.ke>
  31643. Subject: (usr-tc) ISP-EQUIPMENT- USR MP/16
  31644. Date: 28 Oct 1999 12:02:11 +0300 (EAT)
  31645.  
  31646. Hello People,
  31647.  
  31648. I need adapters to connect RJ45 cables from USR MP/16 to PM2E 30. I need 60
  31649. pcs. Any offer please? 
  31650.  
  31651. Okeyo.
  31652.  
  31653.  
  31654.  
  31655. -
  31656.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31657.  with "unsubscribe usr-tc" in the body of the message.
  31658.  For information on digests or retrieving files and old messages send
  31659.  "help" to the same address.  Do not use quotes in your message.
  31660.  
  31661.  
  31662. -------------------------------------------------------------------------------
  31663.  
  31664. From: Jeff Mcadams <jeffm@iglou.com>
  31665. Subject: Re: (usr-tc) USR VSA's - 2 that I can't find
  31666. Date: 28 Oct 1999 08:18:08 -0400
  31667.  
  31668. Thus spake Mike Andrews
  31669. >How about 0x01ce, 
  31670.  
  31671. RMMIE-Num-Of-Updates - integer
  31672. I haven't a clue what it signifies.
  31673.  
  31674. >0x01df, 
  31675.  
  31676. RMMIE-Manufacutere-ID (not a typo) integer
  31677.  
  31678. >0x01e0, 
  31679.  
  31680. RMMIE-Product-Code string
  31681.  
  31682. >0x01e1, 
  31683.  
  31684. RMMIE-Serial-Number string
  31685.  
  31686. >0x01e2, 
  31687.  
  31688. RMMIE-Firmware-Version string
  31689.  
  31690. >and 0x01e3?
  31691.  
  31692. RMMIE-Firmware-Build-Date string
  31693.  
  31694. I suspect all the RMMIE's are for the remote modem information
  31695. capability that is beginning to show up in the TC's...ie, where the TC
  31696. will actually be able to gather some status information about the modem
  31697. on the other side of the connection.
  31698.  
  31699. >That HARC-Disconnect-Code one looks really useful, btw...
  31700.  
  31701. Yup, could be.  We'll see if it actually gives useful information.  I
  31702. hope so.
  31703. -- 
  31704. Jeff McAdams                            Email: jeffm@iglou.com
  31705. Head Network Administrator              Voice: (502) 966-3848
  31706. IgLou Internet Services                        (800) 436-4456
  31707.  
  31708. -
  31709.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31710.  with "unsubscribe usr-tc" in the body of the message.
  31711.  For information on digests or retrieving files and old messages send
  31712.  "help" to the same address.  Do not use quotes in your message.
  31713.  
  31714.  
  31715. -------------------------------------------------------------------------------
  31716.  
  31717. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  31718. Subject: Re: (usr-tc) dead console port?
  31719. Date: 27 Oct 1999 20:20:29 -0500 (CDT)
  31720.  
  31721. If you have console login enabled then you could telnet to the hiper arc 
  31722. and disconnect the user who logged in to the console.  
  31723. Else you would have to reboot.
  31724.  
  31725. krish
  31726.  
  31727.         \    T.S.V. Krishnan  \
  31728.          \      Network System Engineer \ ( : - : )
  31729.           \     3Com ............   \
  31730.         ----------------------------------------------/
  31731. tkrishna@bubba.ae.usr.com  
  31732. ----------------------------/ http://interproc.ae.usr.com ----/
  31733.     Any Sufficiently advanced bug is indistinguishable for a feature.
  31734.                         - Rick Kulawiec
  31735.  
  31736. On Wed, 27 Oct 1999, K Mitchell wrote:
  31737.  
  31738. >   I have a user that was apparently being flooded from another user of a
  31739. > java chat room he was in. I opened a console ARC connection to mon ppp and
  31740. > determine the origin of the attack. After about 10 seconds of tracing the
  31741. > console connection froze and I've been unable to re-establish it. I've
  31742. > tried disconnecting and reconnecting, as well as removing and replacing the
  31743. > cables to no avail. Any ideas how I can re-open the console connection?
  31744. >   In case it might help, here's the last few events received;
  31745. > Incoming PPP Data on interface: slot:1/mod:23
  31746. >     21 45 00 00 26 a2 70 00 00 80 11 29 7a cc ab 1f |!E  & p    )z   |
  31747. >     b8 d1 75 b1 03 58 1b 58 1b 00 12 ab d3 0c 01 01 |  u  X X        |
  31748. >     0a 00 d6 1b 02 0c 00                            |                |
  31749. > 
  31750. > 
  31751. > Outgoing PPP Data on interface: slot:1/mod:23
  31752. >     21 45 00 00 41 77 e7 40 00 ee 11 a5 e7 d1 75 b1 |!E  Aw @      u |
  31753. >     03 cc ab 1f b8 58 1b 58 1b 00 2d 21 d7 0d 01 01 |     X X  -!    |
  31754. >     25 00 d6 4c 39 0a 50 66 64 66 56 46 a5 7a a6 aa |%  L9 PfdfVF z  |
  31755. >     ba 6a 56 64 96 56 19 65 8d a8 4d 80 41 04 1e 7d | jVd V e  M A  }|
  31756. >     21 ec                                           |!               |
  31757. > 
  31758. > 
  31759. > Outgoing PPP Data on interface: slot:1/mod:23
  31760. >     21 45 00 00 26 77 e8 40 00 ee 11 a6 01 d1 75 b1 |!E  &w @      u |
  31761. >     03 cc ab 1f b8 58 1b 58 1b 00 12 80 d4 0c 01 01 |     X X        |
  31762. >     0a 00 d6 4c 01 06 00                            |   L            |
  31763. > 
  31764. > 
  31765. > Outgoing PPP Data on interface: slot:1/mod:23
  31766. >     21 45 00 01 a9 77 e9 40 00 ee 11 a4 7d d1 75 b1 |!E   w @    } u |
  31767. >     03 cc ab 1f b8 58 1b 58 1b 01 95 69 26 0d 01 01 |     X X   i&   |
  31768. >     59 01 d6 4d 39 0e 01 cc 2e dd f7 26 25 64 52 1e |Y  M9   .  &%dR |
  31769. >     2e 75 b8 91 d2 c2 ac 2d 8e b1 62 11 8c 18 65 0a |.u     -  b   e |
  31770. >     5b d5 55 66 70 c5 7b 4e 68 ae a7 54 e1 61 9e 6d |[ Ufp {Nh  T a m|
  31771. >     6f 66 9e 09 c5 af 45 d1 c7 14 57 35 e2 5c 16 d3 |of    E   W5 \  |
  31772. >     fe 54 45 85 65 59 b1 70 82 a4 61 91 94 69 8a 0d | TE eY p  a  i  |
  31773. >     d1 8e 45 b1 46 0c 5b fc b8 f6 65 a2 53 a5 61 75 |  E F [   e S au|
  31774. >     09 5a 86 9d a6 6d c9 7c e1 6a b2 0e 11 4e 3d a0 | Z   m | j   N= |
  31775. >     c4 14 5e af 71 dc 55 b5 1d 55 e4 e5 de 96 5a 60 |  ^ q U  U    Z`|
  31776. >     85 95 61 95 ac 25 a2 0d 09 d0 51 d1 87 18 4e 2f |  a  %    Q   N/|
  31777. >     ac ae 5a fb 2b b2 5e 68 0a 1a 0e 07 b3 48 a9 92 |  Z + ^h     H  |
  31778. >     99 54 28 2d 0d af 51 c1 05 10 a5 2b b2 39 60 7e | T(-  Q    + 9`~|
  31779. >     f7 cc 6e ef 7c 95 d5 1e 88 91 98 7f 0d 8e d7 2c |  n |          ,|
  31780. >     0d ef 55 d1 48 18 67 55 57 54 55 1d b8 29 54 a6 |  U H gUWTU  )T |
  31781. >     5a 57 31 7d 70 02 85 e2 cf 19 13 08 91 51 45 61 |ZW1}p        QEa|
  31782. >     46 18 7c d6 ac 6c 11 15 a9 16 67 0e 10 27 ce 95 |F |  l    g  '  |
  31783. >     a7 9a ba dd 26 49 ec 09 19 71 61 91 84 1c 58 30 |    &I   qa   X0|
  31784. >     2f e9 65 3d 19 a4 97 95 66 90 8a 36 5c 59 86 86 |/ e=    f  6\Y  |
  31785. >     e8 b9 da 08 89 ed 35 b1 49 18 7e ce 96 54 51 23 |      5 I ~  TQ#|
  31786. >     03 fd 69 a2 97 cb dc e7 7a 99 de 6e e8 7e 61 28 |  i     z  n ~a(|
  31787. >     cd cd 3d b2 89 18 65 8d 16 40 55 d6 04 ab a2 85 |  =   e  @U     |
  31788. >     13 1c 86 2a 5a 5e 66 70 72 95 6a 4d 51 8d 21 73 |   *Z^fpr jMQ !s|
  31789. >     03 20 8c f3 e9 45 18 01 01 34 00 53 3d 44 61 6e |     E   4 S=Dan|
  31790. >     62 6f 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |bo              |
  31791. >     20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |                |
  31792. >     20 20 20 20 20 20 20 20 20 00                   |                |
  31793. > 
  31794. > Thanks,
  31795. > -- 
  31796. > Kirk Mitchell-General Manager        mitch@keyconn.net
  31797. > Keystone Connect                     Unlock Your World
  31798. > Altoona, PA   814-941-5000      http://www.keyconn.net
  31799. > 
  31800. > 
  31801. > -
  31802. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31803. >  with "unsubscribe usr-tc" in the body of the message.
  31804. >  For information on digests or retrieving files and old messages send
  31805. >  "help" to the same address.  Do not use quotes in your message.
  31806. > 
  31807.  
  31808. -
  31809.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31810.  with "unsubscribe usr-tc" in the body of the message.
  31811.  For information on digests or retrieving files and old messages send
  31812.  "help" to the same address.  Do not use quotes in your message.
  31813.  
  31814.  
  31815. -------------------------------------------------------------------------------
  31816.  
  31817. From: Clayton Zekelman <clayton@MNSi.Net>
  31818. Subject: RE: (usr-tc) ARC Default Gateway
  31819. Date: 28 Oct 1999 09:51:44 -0400
  31820.  
  31821. <rant>
  31822.  
  31823. Of course you can have multiple default gateways - with either equal
  31824. metrics or different to be used as backups.
  31825.  
  31826. Unfortunatly, the ARC command syntax is misleading - generally, "add"
  31827. commands are used to add tuples to a list - i.e. multiple IP pools,
  31828. multiple routes, multiple users.  The "set" commands are used to change
  31829. particular settings on existing tuples in a list, or unique settings, such
  31830. as primary DNS server, etc.
  31831.  
  31832. In this case, one must use the "add" form of the command to do what one
  31833. would expect a "set" to do, and furthermore, the "add" doesn't appear to
  31834. allow the addition of multiple default gateways - it just changes the
  31835. current gateway.  To top it all off, it seems that although listing the
  31836. routing table shows the default route as 0.0.0.0/0, to change it, you use a
  31837. completely different syntax with "defaultroute gateway".  
  31838.  
  31839. Its even more annying using HARM - if you click on the default route in the
  31840. routing table, and try to change it, it won't let you.  If you try to add a
  31841. new default route, it barfs with an error message about duplicate items
  31842. being in the list.
  31843.  
  31844. I have never seen a routing platform with such a convoluted and obscure
  31845. command syntax, that as far as I can tell, doesn't even stay consistent
  31846. with its own rules.  HARC just plain old bothers me sometimes.
  31847.  
  31848. </rant>
  31849.  
  31850. At 06:40 PM 10/27/99 -0400, you wrote:
  31851. >I've got some mojo working on my Cisco then:
  31852. >
  31853. >Inch-Whitehall-gw>sh ip route 0.0.0.0
  31854. >Routing entry for 0.0.0.0/0, supernet
  31855. >  Known via "static", distance 1, metric 0, candidate default path
  31856. >  Redistributing via ospf 1
  31857. >  Routing Descriptor Blocks:
  31858. >  * 207.240.128.xxx
  31859. >      Route metric is 0, traffic share count is 1
  31860. >    207.240.128.xxx
  31861. >      Route metric is 0, traffic share count is 1      
  31862. >
  31863. >I'm using this to load balance on the way out over two T's.  If one goes
  31864.  
  31865. >down the route goes away.  On the other side OSPF is balancing the
  31866. >incoming traffic...
  31867. >
  31868. >I don't know what you'd do with two default routes on an ARC, but I'm sure
  31869. >there's someone who could use it...
  31870. >
  31871. >Charles
  31872. >
  31873. >On Wed, 27 Oct 1999, Robert von Bismarck wrote:
  31874. >
  31875. >> Umh.. In my knowledge, you can have only one "default" route. In ciscoes
  31876. >> it's very aptly named "gateway of last resort", as it is where the packets
  31877. >> will go if no route is found in the local routing table. If you have two
  31878. >> interfaces, you need to specify all the routes going through the second
  31879. >> interface (assuming the default route is on the first interface). If you
  31880. add
  31881. >> a second default route, it will (say should) overwrite the first entry.
  31882. >> 
  31883. >> 
  31884. >> Robert
  31885. >> 
  31886. >>     -----Original Message-----
  31887. >>     From:    Clayton Zekelman [SMTP:clayton@MNSi.Net]
  31888. >>     Sent:    mercredi, 27. octobre 1999 00:11
  31889. >>     To:    usr-tc@lists.xmission.com
  31890. >>     Subject:    Re: (usr-tc) ARC Default Gateway
  31891. >> 
  31892. >>     It seems "set" won't work.  I tried add, and it worked, but replaced
  31893. >> the
  31894. >>     existing default (which is what I wanted, but wouldn't expect from
  31895. >> "add").
  31896. >> 
  31897. >>     I've never run into a device with such an annoying command
  31898. >> structure.
  31899. >> 
  31900. >>     At 04:46 PM 10/26/99 -0500, you wrote:
  31901. >>     >set ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31902. >>     >
  31903. >>     >If you should need multiple defaultroutes:
  31904. >>     >add ip deFAULTROUTE gaTEWAY xxx.xxx.xxx.xxx metric x
  31905. >>     >
  31906. >>     >Gabriel
  31907. >>     >
  31908. >>     >On Tue, 26 Oct 1999, Clayton Zekelman wrote:
  31909. >>     >
  31910. >>     >> OK, I know I'm missing something simple, but how do you change
  31911. >> the default
  31912. >>     >> gateway on a running ARC card?  I tried adding a 0.0.0.0/0 route,
  31913. >> but it
  31914. >>     >> rejected it.  Any ideas?
  31915. >>     >> 
  31916. >>     >> 
  31917. >>     >> ---
  31918. >>     >> Clayton Zekelman
  31919. >>     >> Managed Network Systems Inc. (MNSi)
  31920. >>     >> 875 Ouellette Avenue
  31921. >>     >> Windsor, Ontario
  31922. >>     >> N9A 4J6
  31923. >>     >> 
  31924. >>     >> tel. 519-985-8410
  31925. >>     >> fax. 519-258-3009
  31926. >>     >> 
  31927. >>     >> -
  31928. >>     >>  To unsubscribe to usr-tc, send an email to
  31929. >> "majordomo@xmission.com"
  31930. >>     >>  with "unsubscribe usr-tc" in the body of the message.
  31931. >>     >>  For information on digests or retrieving files and old messages
  31932. >> send
  31933. >>     >>  "help" to the same address.  Do not use quotes in your message.
  31934. >>     >> 
  31935. >>     >> 
  31936. >>     >> 
  31937. >>     >
  31938. >>     >--
  31939. >>     >* speedy@dixie-net.com *
  31940. >>     >* Gabriel Grissett     *
  31941. >>     >
  31942. >>     >
  31943. >>     >-
  31944. >>     > To unsubscribe to usr-tc, send an email to
  31945. >> "majordomo@xmission.com"
  31946. >>     > with "unsubscribe usr-tc" in the body of the message.
  31947. >>     > For information on digests or retrieving files and old messages
  31948. >> send
  31949. >>     > "help" to the same address.  Do not use quotes in your message.
  31950.  
  31951. >>     > 
  31952. >>     ---
  31953. >>     Clayton Zekelman
  31954. >>     Managed Network Systems Inc. (MNSi)
  31955. >>     875 Ouellette Avenue
  31956. >>     Windsor, Ontario
  31957. >>     N9A 4J6
  31958. >> 
  31959. >>     tel. 519-985-8410
  31960. >>     fax. 519-258-3009
  31961. >> 
  31962. >>     -
  31963. >>     To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31964. >>     with "unsubscribe usr-tc" in the body of the message.
  31965. >>     For information on digests or retrieving files and old messages
  31966. >> send
  31967. >>     "help" to the same address.  Do not use quotes in your message.
  31968. >> 
  31969. >> -
  31970. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31971. >>  with "unsubscribe usr-tc" in the body of the message.
  31972. >>  For information on digests or retrieving files and old messages send
  31973. >>  "help" to the same address.  Do not use quotes in your message.
  31974. >> 
  31975. >
  31976. >
  31977. >-
  31978. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31979. > with "unsubscribe usr-tc" in the body of the message.
  31980. > For information on digests or retrieving files and old messages send
  31981. > "help" to the same address.  Do not use quotes in your message.
  31982. > 
  31983. ---
  31984. Clayton Zekelman
  31985. Managed Network Systems Inc. (MNSi)
  31986. 875 Ouellette Avenue
  31987. Windsor, Ontario
  31988. N9A 4J6
  31989.  
  31990. tel. 519-985-8410
  31991. fax. 519-258-3009
  31992.  
  31993. -
  31994.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31995.  with "unsubscribe usr-tc" in the body of the message.
  31996.  For information on digests or retrieving files and old messages send
  31997.  "help" to the same address.  Do not use quotes in your message.
  31998.  
  31999.  
  32000. -------------------------------------------------------------------------------
  32001.  
  32002. From: "Startup Suppliers Ltd." <startnet@arcc.or.ke>
  32003. Subject: (usr-tc) ISP-EQUIPMENT- USR MP/16
  32004. Date: 28 Oct 1999 17:50:16 +0300 (EAT)
  32005.  
  32006. Hello People,
  32007.  
  32008. I need a V. 35  2 port DTU urgently! Please offer with best price.
  32009.  
  32010. Okeyo.
  32011.  
  32012.  
  32013.  
  32014.  
  32015. -
  32016.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32017.  with "unsubscribe usr-tc" in the body of the message.
  32018.  For information on digests or retrieving files and old messages send
  32019.  "help" to the same address.  Do not use quotes in your message.
  32020.  
  32021.  
  32022. -------------------------------------------------------------------------------
  32023.  
  32024. From: Mike Andrews <mandrews@bit0.com>
  32025. Subject: Re: (usr-tc) USR VSA's - 2 that I can't find
  32026. Date: 28 Oct 1999 13:24:08 -0400 (EDT)
  32027.  
  32028. Also, where on totalservice is the most up to date Radius dictionary?  I
  32029. couldn't find it in the archives and I can't find it easily on
  32030. totalservice.  (It won't let me download the S&A server, not that I really
  32031. want it anyway, I just want the dictionary)
  32032.  
  32033.  
  32034. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/
  32035. VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
  32036. Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
  32037. "With sufficient thrust, pigs fly just fine." -- RFC 1925
  32038.  
  32039. On Thu, 28 Oct 1999, Mike Andrews wrote:
  32040.  
  32041. > > On Wed, 27 Oct 1999, Jeff Mcadams wrote:
  32042. > > 
  32043. > > > Anyone know, or know where I can find, what USR VSA's 39049 (0x9889),
  32044. > > > and 93051 (0x988b) are?
  32045. > > > 
  32046. > > > I looked on totalservice at the dictionary file there and these weren't
  32047. > > > in there.
  32048.  
  32049.  
  32050. -
  32051.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32052.  with "unsubscribe usr-tc" in the body of the message.
  32053.  For information on digests or retrieving files and old messages send
  32054.  "help" to the same address.  Do not use quotes in your message.
  32055.  
  32056.  
  32057. -------------------------------------------------------------------------------
  32058.  
  32059. From: Jeff Mcadams <jeffm@iglou.com>
  32060. Subject: Re: (usr-tc) USR VSA's - 2 that I can't find
  32061. Date: 28 Oct 1999 13:33:29 -0400
  32062.  
  32063. Thus spake Mike Andrews
  32064. >Also, where on totalservice is the most up to date Radius dictionary?  I
  32065. >couldn't find it in the archives and I can't find it easily on
  32066. >totalservice.  (It won't let me download the S&A server, not that I really
  32067. >want it anyway, I just want the dictionary)
  32068.  
  32069. When you log into TotalService, go to the ISP home page, choose RADIUS,
  32070. and Vendor Specific Attributes....this will bring up their dictionary
  32071. file...you should be able to find just about all of them there.  :)
  32072. -- 
  32073. Jeff McAdams                            Email: jeffm@iglou.com
  32074. Head Network Administrator              Voice: (502) 966-3848
  32075. IgLou Internet Services                        (800) 436-4456
  32076.  
  32077. -
  32078.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32079.  with "unsubscribe usr-tc" in the body of the message.
  32080.  For information on digests or retrieving files and old messages send
  32081.  "help" to the same address.  Do not use quotes in your message.
  32082.  
  32083.  
  32084. -------------------------------------------------------------------------------
  32085.  
  32086. From: K Mitchell <mitch@keyconn.net>
  32087. Subject: (usr-tc) translating ppp output
  32088. Date: 28 Oct 1999 20:52:46 -0400
  32089.  
  32090. Anybody know of a utility(Win) that will decode mon ppp type output into
  32091. something that the hex/binary impaired can make sense of? :)
  32092.  
  32093. Thanks,
  32094. -- 
  32095. Kirk Mitchell-General Manager        mitch@keyconn.net
  32096. Keystone Connect                     Unlock Your World
  32097. Altoona, PA   814-941-5000      http://www.keyconn.net
  32098.  
  32099.  
  32100. -
  32101.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32102.  with "unsubscribe usr-tc" in the body of the message.
  32103.  For information on digests or retrieving files and old messages send
  32104.  "help" to the same address.  Do not use quotes in your message.
  32105.  
  32106.  
  32107. -------------------------------------------------------------------------------
  32108.  
  32109. From: Terry Carney <tcarney@selterra.com>
  32110. Subject: (usr-tc) HiPerARC Config.
  32111. Date: 29 Oct 1999 01:37:45 -0700 (PDT)
  32112.  
  32113. Hi.
  32114.  
  32115. I find myself having to reconfigure a HiPerARC with an increased IP
  32116. pool size and an earlier initial IP address in order to accommodate 24
  32117. additional ports. I did not configure this system and the only
  32118. documentation I have at the moment is the command reference.  When I
  32119. try to make changes the IP pool I get an error saying there is a
  32120. 'BAD_VALUE:  0.0.0.8'. My syntax appears correct as per the command
  32121. reference. 
  32122.  
  32123. (Ignore line continuation)
  32124.  
  32125. set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
  32126.                    size 120 route no_aggregate state public
  32127.  
  32128. I have tried using the alternate methods of entering the netmask
  32129. (/24,/255.255.255.0).
  32130.  
  32131. Are there preparatory steps that I need to do that are not in the
  32132. documentation I have? If so, a brief list would be appreciated.
  32133.  
  32134. The 3COM site is being really flakey and, at least from my
  32135. perspective, is currently unusable My experience has been primarily
  32136. with Lucent Technology PM3 and the Total Control is certainly a
  32137. different animal although I have managed to pick up a few things. This
  32138. ISP's users are probably getting edgy by now. <G>
  32139.  
  32140. Current pool configuration:
  32141. System version: V4.1.59
  32142.  
  32143. IP ADDRESS POOLS
  32144. Name        Address          Size InUse State   Route         Status
  32145. ippool      xxx.xxx.xxx.66/C  96   24   PUBLIC  NO_AGGREGATE  ACTIVE
  32146.  
  32147. Thanks in advance,
  32148.  
  32149.  
  32150. Terry.
  32151.  
  32152. Selterra Communications  *  Business Internet - Network Solutions
  32153. Email: info@selterra.com
  32154.  
  32155.  
  32156. -
  32157.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32158.  with "unsubscribe usr-tc" in the body of the message.
  32159.  For information on digests or retrieving files and old messages send
  32160.  "help" to the same address.  Do not use quotes in your message.
  32161.  
  32162.  
  32163. -------------------------------------------------------------------------------
  32164.  
  32165. From: "Startup Suppliers Ltd." <startnet@arcc.or.ke>
  32166. Subject: (usr-tc) ISP-EQUIPMENT-V. 35 DTU
  32167. Date: 29 Oct 1999 15:18:12 +0300 (EAT)
  32168.  
  32169. Hello People,
  32170.  
  32171. I need a V. 35  2 port DTU urgently! Please offer with best price.
  32172.  
  32173. Okeyo.
  32174.  
  32175.  
  32176.  
  32177.  
  32178. -
  32179.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32180.  with "unsubscribe usr-tc" in the body of the message.
  32181.  For information on digests or retrieving files and old messages send
  32182.  "help" to the same address.  Do not use quotes in your message.
  32183.  
  32184.  
  32185. -------------------------------------------------------------------------------
  32186.  
  32187. From: jeff.binkley@asacomp.com (Jeff Binkley)
  32188. Subject: (usr-tc) Transparent Proxy
  32189. Date: 29 Oct 1999 08:19:00 -0500
  32190.  
  32191.  
  32192.  
  32193.  
  32194. Does anyone have any information on setting up a HiPerArc to redirect 
  32195. port 80 traffic to a proxy server for transparent proxy/caching ?  I've 
  32196. not been able to locate anything.  Does anyone have this working ?
  32197.  
  32198.  
  32199. Thanks,
  32200.  
  32201. Jeff Binkley
  32202. ASA Network Computing
  32203.  
  32204. CMPQwk 1.42 9999
  32205.  
  32206.  
  32207. -
  32208.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32209.  with "unsubscribe usr-tc" in the body of the message.
  32210.  For information on digests or retrieving files and old messages send
  32211.  "help" to the same address.  Do not use quotes in your message.
  32212.  
  32213.  
  32214. -------------------------------------------------------------------------------
  32215.  
  32216. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  32217. Subject: RE: (usr-tc) Transparent Proxy
  32218. Date: 29 Oct 1999 09:59:49 -0300
  32219.  
  32220.  
  32221. I had been beta testing a product which used WCCP to talk to my cisco router
  32222. to get web traffic redirected transparently.  It was VERY cool but the
  32223. product I was using wasn't quite ready for production so we didn't end up
  32224. buying it.  I'm told that a few other caching solution providers support
  32225. WCCP as well.  It might be something you'd want to look into.  I can give
  32226. you more details if you want to email me privately.
  32227.  
  32228. Matthew
  32229.  
  32230. -----Original Message-----
  32231. Sent: Friday, October 29, 1999 10:19 AM
  32232.  
  32233.  
  32234.  
  32235.  
  32236.  
  32237. Does anyone have any information on setting up a HiPerArc to redirect 
  32238. port 80 traffic to a proxy server for transparent proxy/caching ?  I've 
  32239. not been able to locate anything.  Does anyone have this working ?
  32240.  
  32241.  
  32242. Thanks,
  32243.  
  32244. Jeff Binkley
  32245. ASA Network Computing
  32246.  
  32247. CMPQwk 1.42 9999
  32248.  
  32249.  
  32250. -
  32251.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32252.  with "unsubscribe usr-tc" in the body of the message.
  32253.  For information on digests or retrieving files and old messages send
  32254.  "help" to the same address.  Do not use quotes in your message.
  32255.  
  32256. -
  32257.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32258.  with "unsubscribe usr-tc" in the body of the message.
  32259.  For information on digests or retrieving files and old messages send
  32260.  "help" to the same address.  Do not use quotes in your message.
  32261.  
  32262.  
  32263. -------------------------------------------------------------------------------
  32264.  
  32265. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32266. Subject: Re: (usr-tc) HiPerARC Config.
  32267. Date: 28 Oct 1999 20:34:09 -0500 (CDT)
  32268.  
  32269. On Fri, 29 Oct 1999, Terry Carney wrote:
  32270.  
  32271. > Hi.
  32272. > 
  32273. > I find myself having to reconfigure a HiPerARC with an increased IP
  32274. > pool size and an earlier initial IP address in order to accommodate 24
  32275. > additional ports. I did not configure this system and the only
  32276. > documentation I have at the moment is the command reference.  When I
  32277. > try to make changes the IP pool I get an error saying there is a
  32278. > 'BAD_VALUE:  0.0.0.8'. My syntax appears correct as per the command
  32279. > reference. 
  32280. > 
  32281. > (Ignore line continuation)
  32282. > 
  32283. > set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
  32284. >                    size 120 route no_aggregate state public
  32285.  
  32286. All you need is set ip pool <poolname> initi <start of initial address> 
  32287. size <number>
  32288.  
  32289. Now if you are using the same initial address then all you need to do is
  32290.  
  32291. set ip pool <poolname> size <#>
  32292.  
  32293. krish
  32294.  
  32295. > 
  32296. > I have tried using the alternate methods of entering the netmask
  32297. > (/24,/255.255.255.0).
  32298. > 
  32299. > Are there preparatory steps that I need to do that are not in the
  32300. > documentation I have? If so, a brief list would be appreciated.
  32301. > 
  32302. > The 3COM site is being really flakey and, at least from my
  32303. > perspective, is currently unusable My experience has been primarily
  32304. > with Lucent Technology PM3 and the Total Control is certainly a
  32305. > different animal although I have managed to pick up a few things. This
  32306. > ISP's users are probably getting edgy by now. <G>
  32307. > 
  32308. > Current pool configuration:
  32309. > ------------------------------------------------------------------
  32310. > System version: V4.1.59
  32311. > 
  32312. > IP ADDRESS POOLS
  32313. > Name        Address          Size InUse State   Route         Status
  32314. > ippool      xxx.xxx.xxx.66/C  96   24   PUBLIC  NO_AGGREGATE  ACTIVE
  32315. > ------------------------------------------------------------------
  32316. > 
  32317. > Thanks in advance,
  32318. > 
  32319. > 
  32320. > Terry.
  32321. > 
  32322. > Selterra Communications  *  Business Internet - Network Solutions
  32323. > -----------------------------------------------------------------
  32324. > Email: info@selterra.com
  32325. > 
  32326. > 
  32327. > -
  32328. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32329. >  with "unsubscribe usr-tc" in the body of the message.
  32330. >  For information on digests or retrieving files and old messages send
  32331. >  "help" to the same address.  Do not use quotes in your message.
  32332. > 
  32333.  
  32334. -
  32335.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32336.  with "unsubscribe usr-tc" in the body of the message.
  32337.  For information on digests or retrieving files and old messages send
  32338.  "help" to the same address.  Do not use quotes in your message.
  32339.  
  32340.  
  32341. -------------------------------------------------------------------------------
  32342.  
  32343. From:  <farber@admin.f-tech.net>
  32344. Subject: Re: (usr-tc) HiPerARC Config.
  32345. Date: 29 Oct 1999 09:54:11 -0400 (EDT)
  32346.  
  32347. There is no need to netmask the IP's.  Use the SIZE attribute to tell how
  32348. many ip's in the pool.
  32349.  
  32350. HiPer>> help set ip po
  32351. The possible SET IP POOL  commands are:
  32352.     SET IP POOL <name>
  32353.                 INITIAL_POOL_ADDRESS <ip_net_addr>
  32354.                 ROUTE  [ AGGREGATE NO_AGGREGATE  ]
  32355.                 SIZE  < 1-4096 >
  32356.                 STATE  [ PRIVATE PUBLIC  ]
  32357. or any unique abbreviation of the keywords
  32358.  
  32359. anytime you have a question do a help cmd.
  32360.  
  32361. Paul Farber
  32362. Farber Technology
  32363. farber@admin.f-tech.net
  32364. Ph  570-628-5303
  32365. Fax 570-628-5545
  32366.  
  32367. On Fri, 29 Oct 1999, Terry Carney wrote:
  32368.  
  32369. > Hi.
  32370. > 
  32371. > I find myself having to reconfigure a HiPerARC with an increased IP
  32372. > pool size and an earlier initial IP address in order to accommodate 24
  32373. > additional ports. I did not configure this system and the only
  32374. > documentation I have at the moment is the command reference.  When I
  32375. > try to make changes the IP pool I get an error saying there is a
  32376. > 'BAD_VALUE:  0.0.0.8'. My syntax appears correct as per the command
  32377. > reference. 
  32378. > 
  32379. > (Ignore line continuation)
  32380. > 
  32381. > set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
  32382. >                    size 120 route no_aggregate state public
  32383. > 
  32384. > I have tried using the alternate methods of entering the netmask
  32385. > (/24,/255.255.255.0).
  32386. > 
  32387. > Are there preparatory steps that I need to do that are not in the
  32388. > documentation I have? If so, a brief list would be appreciated.
  32389. > 
  32390. > The 3COM site is being really flakey and, at least from my
  32391. > perspective, is currently unusable My experience has been primarily
  32392. > with Lucent Technology PM3 and the Total Control is certainly a
  32393. > different animal although I have managed to pick up a few things. This
  32394. > ISP's users are probably getting edgy by now. <G>
  32395. > 
  32396. > Current pool configuration:
  32397. > ------------------------------------------------------------------
  32398. > System version: V4.1.59
  32399. > 
  32400. > IP ADDRESS POOLS
  32401. > Name        Address          Size InUse State   Route         Status
  32402. > ippool      xxx.xxx.xxx.66/C  96   24   PUBLIC  NO_AGGREGATE  ACTIVE
  32403. > ------------------------------------------------------------------
  32404. > 
  32405. > Thanks in advance,
  32406. > 
  32407. > 
  32408. > Terry.
  32409. > 
  32410. > Selterra Communications  *  Business Internet - Network Solutions
  32411. > -----------------------------------------------------------------
  32412. > Email: info@selterra.com
  32413. > 
  32414. > 
  32415. > -
  32416. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32417. >  with "unsubscribe usr-tc" in the body of the message.
  32418. >  For information on digests or retrieving files and old messages send
  32419. >  "help" to the same address.  Do not use quotes in your message.
  32420. > 
  32421.  
  32422.  
  32423. -
  32424.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32425.  with "unsubscribe usr-tc" in the body of the message.
  32426.  For information on digests or retrieving files and old messages send
  32427.  "help" to the same address.  Do not use quotes in your message.
  32428.  
  32429.  
  32430. -------------------------------------------------------------------------------
  32431.  
  32432. From:  <farber@admin.f-tech.net>
  32433. Subject: Re: (usr-tc) HiPerARC Config.
  32434. Date: 29 Oct 1999 09:54:11 -0400 (EDT)
  32435.  
  32436. There is no need to netmask the IP's.  Use the SIZE attribute to tell how
  32437. many ip's in the pool.
  32438.  
  32439. HiPer>> help set ip po
  32440. The possible SET IP POOL  commands are:
  32441.     SET IP POOL <name>
  32442.                 INITIAL_POOL_ADDRESS <ip_net_addr>
  32443.                 ROUTE  [ AGGREGATE NO_AGGREGATE  ]
  32444.                 SIZE  < 1-4096 >
  32445.                 STATE  [ PRIVATE PUBLIC  ]
  32446. or any unique abbreviation of the keywords
  32447.  
  32448. anytime you have a question do a help cmd.
  32449.  
  32450. Paul Farber
  32451. Farber Technology
  32452. farber@admin.f-tech.net
  32453. Ph  570-628-5303
  32454. Fax 570-628-5545
  32455.  
  32456. On Fri, 29 Oct 1999, Terry Carney wrote:
  32457.  
  32458. > Hi.
  32459. > 
  32460. > I find myself having to reconfigure a HiPerARC with an increased IP
  32461. > pool size and an earlier initial IP address in order to accommodate 24
  32462. > additional ports. I did not configure this system and the only
  32463. > documentation I have at the moment is the command reference.  When I
  32464. > try to make changes the IP pool I get an error saying there is a
  32465. > 'BAD_VALUE:  0.0.0.8'. My syntax appears correct as per the command
  32466. > reference. 
  32467. > 
  32468. > (Ignore line continuation)
  32469. > 
  32470. > set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
  32471. >                    size 120 route no_aggregate state public
  32472. > 
  32473. > I have tried using the alternate methods of entering the netmask
  32474. > (/24,/255.255.255.0).
  32475. > 
  32476. > Are there preparatory steps that I need to do that are not in the
  32477. > documentation I have? If so, a brief list would be appreciated.
  32478. > 
  32479. > The 3COM site is being really flakey and, at least from my
  32480. > perspective, is currently unusable My experience has been primarily
  32481. > with Lucent Technology PM3 and the Total Control is certainly a
  32482. > different animal although I have managed to pick up a few things. This
  32483. > ISP's users are probably getting edgy by now. <G>
  32484. > 
  32485. > Current pool configuration:
  32486. > ------------------------------------------------------------------
  32487. > System version: V4.1.59
  32488. > 
  32489. > IP ADDRESS POOLS
  32490. > Name        Address          Size InUse State   Route         Status
  32491. > ippool      xxx.xxx.xxx.66/C  96   24   PUBLIC  NO_AGGREGATE  ACTIVE
  32492. > ------------------------------------------------------------------
  32493. > 
  32494. > Thanks in advance,
  32495. > 
  32496. > 
  32497. > Terry.
  32498. > 
  32499. > Selterra Communications  *  Business Internet - Network Solutions
  32500. > -----------------------------------------------------------------
  32501. > Email: info@selterra.com
  32502. > 
  32503. > 
  32504. > -
  32505. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32506. >  with "unsubscribe usr-tc" in the body of the message.
  32507. >  For information on digests or retrieving files and old messages send
  32508. >  "help" to the same address.  Do not use quotes in your message.
  32509. > 
  32510.  
  32511.  
  32512. -
  32513.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32514.  with "unsubscribe usr-tc" in the body of the message.
  32515.  For information on digests or retrieving files and old messages send
  32516.  "help" to the same address.  Do not use quotes in your message.
  32517.  
  32518.  
  32519. -------------------------------------------------------------------------------
  32520.  
  32521. From: Nicolas St-Pierre <nstpierre@iasl.com>
  32522. Subject: Re: (usr-tc) WTB Netserver card sets!
  32523. Date: 05 Feb 1999 09:25:23 -0500
  32524.  
  32525.  
  32526. Hello Marty,
  32527.  
  32528. I would be looking at buying 12 NetServer PRI card sets.  I would prefer
  32529. them to be FC2 revision boards.  
  32530.  
  32531. Let me know how many you have and how we can go about with the
  32532. transaction.
  32533.  
  32534.  
  32535. Thank you,
  32536.  
  32537. Nicolas
  32538.  
  32539. Marty Elliott wrote:
  32540. > 
  32541. > Nick,
  32542. > 
  32543. > We have some NetServer PRI card sets new/unused for $550 each.
  32544. > 
  32545. > Regards
  32546. > 
  32547. > Marty
  32548. > 
  32549. > At 05:38 PM 10/25/99 -0400, you wrote:
  32550. > >
  32551. > >
  32552. > >Hello All!
  32553. > >
  32554. > >I'm on the lookout to buy some 2nd hand Netserver card sets (NIC +
  32555. > >NAC).  If you have any of those and are looking to sell them, please
  32556. > >contact me privately.
  32557. > >
  32558. > >Much appreciated!
  32559. > >
  32560. > >Thanks,
  32561. > >
  32562. > >Nick
  32563. > >--
  32564. > >Nicolas St-Pierre
  32565. > >Systems Engineer
  32566. > >Internet Access Solutions Ltd.
  32567. > >Tel (905) 469-4953
  32568. > >Fax (905) 469-4954
  32569. > >
  32570. > >-
  32571. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32572. > > with "unsubscribe usr-tc" in the body of the message.
  32573. > > For information on digests or retrieving files and old messages send
  32574. > > "help" to the same address.  Do not use quotes in your message.
  32575. > 
  32576. > =====================================
  32577. > Marty Elliott
  32578. > Managed Asset Recovery Specialists, Inc. (MARS)
  32579. > 2105 South 48th Street   Suite 104
  32580. > Tempe, Arizona 85282  USA
  32581. > (602) 426-8272      (602) 454-0770  fax
  32582. > www.2assetrecovery.com
  32583. > =====================================
  32584. > 
  32585. > -
  32586. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32587. >  with "unsubscribe usr-tc" in the body of the message.
  32588. >  For information on digests or retrieving files and old messages send
  32589. >  "help" to the same address.  Do not use quotes in your message.
  32590.  
  32591. --
  32592. Nicolas St-Pierre
  32593. Systems Engineer
  32594. Internet Access Solutions Ltd.
  32595. Tel (905) 469-4953
  32596. Fax (905) 469-4954
  32597.  
  32598. -
  32599.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32600.  with "unsubscribe usr-tc" in the body of the message.
  32601.  For information on digests or retrieving files and old messages send
  32602.  "help" to the same address.  Do not use quotes in your message.
  32603.  
  32604.  
  32605. -------------------------------------------------------------------------------
  32606.  
  32607. From: Allen Marsalis <am@shreve.net>
  32608. Subject: Re: (usr-tc) Transparent Proxy
  32609. Date: 29 Oct 1999 10:08:55 -0500
  32610.  
  32611. At 08:19 AM 10/29/99 -0500, Jeff Binkley wrote:
  32612. >
  32613. >
  32614. >Does anyone have any information on setting up a HiPerArc to redirect 
  32615. >port 80 traffic to a proxy server for transparent proxy/caching ?  I've 
  32616. >not been able to locate anything.  Does anyone have this working ?
  32617. >
  32618.  
  32619. Without using WCCP, a layer 3/4 switch, or browser proxy configuration,
  32620. I believe you have two choices..  You can default route from the
  32621. harc to your cache box which intercepts port 80 and passes everything
  32622. else on.  Or you can default route to your router and have it redirect
  32623. port 80 traffic to your cache.  The latter doubles the load on the router
  32624. so I don't recommend that.  As long as the webcache has 100T NIC(s) and
  32625. you are not humongous (under 1000 ports), just default routing everything
  32626. though the webcache works very well..  I'm unaware of any way to get the
  32627. harc to redirect port 80 traffic all by itself..
  32628.  
  32629. Allen
  32630.  
  32631.  
  32632. -
  32633.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32634.  with "unsubscribe usr-tc" in the body of the message.
  32635.  For information on digests or retrieving files and old messages send
  32636.  "help" to the same address.  Do not use quotes in your message.
  32637.  
  32638.  
  32639. -------------------------------------------------------------------------------
  32640.  
  32641. From: Brian <signal@shreve.net>
  32642. Subject: RE: (usr-tc) Transparent Proxy
  32643. Date: 29 Oct 1999 10:40:18 -0500 (CDT)
  32644.  
  32645.  
  32646.  
  32647. Squid supports WCCP v1.0
  32648.  
  32649. We use Foundry Serveriron l4 switches to do the job, and they work very
  32650. well.
  32651.  
  32652.  
  32653. On Fri, 29 Oct 1999, Stainforth, Matthew wrote:
  32654.  
  32655. > 
  32656. > I had been beta testing a product which used WCCP to talk to my cisco router
  32657. > to get web traffic redirected transparently.  It was VERY cool but the
  32658. > product I was using wasn't quite ready for production so we didn't end up
  32659. > buying it.  I'm told that a few other caching solution providers support
  32660. > WCCP as well.  It might be something you'd want to look into.  I can give
  32661. > you more details if you want to email me privately.
  32662. > 
  32663. > Matthew
  32664. > 
  32665. > -----Original Message-----
  32666. > From: jeff.binkley@asacomp.com [mailto:jeff.binkley@asacomp.com]
  32667. > Sent: Friday, October 29, 1999 10:19 AM
  32668. > To: usr-tc@lists.xmission.com
  32669. > Subject: (usr-tc) Transparent Proxy
  32670. > 
  32671. > 
  32672. > 
  32673. > 
  32674. > 
  32675. > Does anyone have any information on setting up a HiPerArc to redirect 
  32676. > port 80 traffic to a proxy server for transparent proxy/caching ?  I've 
  32677. > not been able to locate anything.  Does anyone have this working ?
  32678. > 
  32679. > 
  32680. > Thanks,
  32681. > 
  32682. > Jeff Binkley
  32683. > ASA Network Computing
  32684. > 
  32685. > CMPQwk 1.42 9999
  32686. > 
  32687. > 
  32688. > -
  32689. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32690. >  with "unsubscribe usr-tc" in the body of the message.
  32691. >  For information on digests or retrieving files and old messages send
  32692. >  "help" to the same address.  Do not use quotes in your message.
  32693. > 
  32694. > -
  32695. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32696. >  with "unsubscribe usr-tc" in the body of the message.
  32697. >  For information on digests or retrieving files and old messages send
  32698. >  "help" to the same address.  Do not use quotes in your message.
  32699. > 
  32700.  
  32701. Brian Feeny (BF304)     signal@shreve.net   
  32702. 318-222-2638 x 109    http://www.shreve.net/~signal      
  32703. Network Administrator   ShreveNet Inc. (ASN 11881)           
  32704.  
  32705.  
  32706. -
  32707.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32708.  with "unsubscribe usr-tc" in the body of the message.
  32709.  For information on digests or retrieving files and old messages send
  32710.  "help" to the same address.  Do not use quotes in your message.
  32711.  
  32712.  
  32713. -------------------------------------------------------------------------------
  32714.  
  32715. From: Brian <signal@shreve.net>
  32716. Subject: Re: (usr-tc) Transparent Proxy
  32717. Date: 29 Oct 1999 10:39:27 -0500 (CDT)
  32718.  
  32719.  
  32720. Hmm...........I was unaware that the HiperARC was capible of policy
  32721. routing
  32722.  
  32723. On Fri, 29 Oct 1999, Jeff Binkley wrote:
  32724.  
  32725. > 
  32726. > 
  32727. > 
  32728. > Does anyone have any information on setting up a HiPerArc to redirect 
  32729. > port 80 traffic to a proxy server for transparent proxy/caching ?  I've 
  32730. > not been able to locate anything.  Does anyone have this working ?
  32731. > 
  32732. > 
  32733. > Thanks,
  32734. > 
  32735. > Jeff Binkley
  32736. > ASA Network Computing
  32737. > 
  32738. > CMPQwk 1.42 9999
  32739. > 
  32740. > 
  32741. > -
  32742. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32743. >  with "unsubscribe usr-tc" in the body of the message.
  32744. >  For information on digests or retrieving files and old messages send
  32745. >  "help" to the same address.  Do not use quotes in your message.
  32746. > 
  32747.  
  32748. Brian Feeny (BF304)     signal@shreve.net   
  32749. 318-222-2638 x 109    http://www.shreve.net/~signal      
  32750. Network Administrator   ShreveNet Inc. (ASN 11881)           
  32751.  
  32752.  
  32753. -
  32754.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32755.  with "unsubscribe usr-tc" in the body of the message.
  32756.  For information on digests or retrieving files and old messages send
  32757.  "help" to the same address.  Do not use quotes in your message.
  32758.  
  32759.  
  32760. -------------------------------------------------------------------------------
  32761.  
  32762. From: Terry Carney <tcarney@selterra.com>
  32763. Subject: Re: (usr-tc) HiPerARC Config.
  32764. Date: 29 Oct 1999 19:11:00 -0700 (PDT)
  32765.  
  32766.  
  32767. > > 
  32768. > > set ip pool ippool initial_pool_address xxx.xxx.xxx.2/C \
  32769. > >                    size 120 route no_aggregate state public
  32770. > 
  32771. > All you need is set ip pool <poolname> initi <start of initial address> 
  32772. > size <number>
  32773.  
  32774. Thanks to everyone for their responses. Even 3com tech couldn't get
  32775. it to change. Had to delete the pool, disconnect the users, then
  32776. re-add the pool with the new settings. Seems fine now.
  32777.  
  32778. Again thanks,
  32779.  
  32780.  
  32781. Terry.
  32782.  
  32783. Selterra Communications  *  Business Internet - Network Solutions
  32784. Email: info@selterra.com
  32785.  
  32786.  
  32787. -
  32788.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32789.  with "unsubscribe usr-tc" in the body of the message.
  32790.  For information on digests or retrieving files and old messages send
  32791.  "help" to the same address.  Do not use quotes in your message.
  32792.  
  32793.  
  32794. -------------------------------------------------------------------------------
  32795.  
  32796. From: "Steve Sherwick" <hostmaster@minnmicro.com>
  32797. Subject: (usr-tc) Major Blunder
  32798. Date: 31 Oct 1999 08:40:31 -0600
  32799.  
  32800.     Hi There,
  32801.  
  32802.     Well at four this morning I made a major blunder, I downloaded the wrong
  32803. version of code into a USR HIPER's NMC card. Now I can't login to it with
  32804. Total Control Manager to correct it as it can't find the NMC card. I can get
  32805. at it with the HARC Manager but it won't bridge to NMC that I can see.
  32806.  
  32807.     The SDL-2 instructions aren't making any sense, When I login to the NMC
  32808. it places me in a menu not anywhere I can enter a trigger code.
  32809.  
  32810.     My service contact is business hours only and this thing is limping
  32811. pretty badly.
  32812.  
  32813.     Does anyone know how to bootstap code into the NMC if it's possible at
  32814. all???
  32815.  
  32816.     Regards,
  32817.  
  32818.     Steve
  32819.  
  32820.  
  32821. Minnetonka Micro  - Superior Communications Services Since 1984
  32822.  
  32823.  
  32824.  
  32825. -
  32826.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32827.  with "unsubscribe usr-tc" in the body of the message.
  32828.  For information on digests or retrieving files and old messages send
  32829.  "help" to the same address.  Do not use quotes in your message.
  32830.  
  32831.  
  32832. -------------------------------------------------------------------------------
  32833.  
  32834. From: "Stainforth, Matthew" <MatthewS@staff.brunnet.net>
  32835. Subject: RE: (usr-tc) Major Blunder
  32836. Date: 31 Oct 1999 11:55:28 -0400
  32837.  
  32838.  
  32839. hook up your console cable and stumble through the command line syntax for
  32840. pcsdl.exe.
  32841.  
  32842. Once you figure out the syntax you need, start pcsdl and reseat the NMC
  32843. simultaneously.  During the NMC boot process it sees that the console is
  32844. trying to upload code to it and should allow the upload.
  32845.  
  32846. It will be quicker if you set your console to 57,600 and set your NMC dip
  32847. switches to match.  I can't remember which ones need to be flipped but 3KB
  32848. should be able to tell you.
  32849.  
  32850. Matthew
  32851.  
  32852. > -----Original Message-----
  32853. > From:    Steve Sherwick [SMTP:hostmaster@minnmicro.com]
  32854. > Sent:    Sunday, October 31, 1999 10:41 AM
  32855. > To:    usr-tc@lists.xmission.com
  32856. > Subject:    (usr-tc) Major Blunder
  32857. > 
  32858. >     Hi There,
  32859. > 
  32860. >     Well at four this morning I made a major blunder, I downloaded the
  32861. > wrong
  32862. > version of code into a USR HIPER's NMC card. Now I can't login to it with
  32863. > Total Control Manager to correct it as it can't find the NMC card. I can
  32864. > get
  32865. > at it with the HARC Manager but it won't bridge to NMC that I can see.
  32866. > 
  32867. >     The SDL-2 instructions aren't making any sense, When I login to the
  32868. > NMC
  32869. > it places me in a menu not anywhere I can enter a trigger code.
  32870. > 
  32871. >     My service contact is business hours only and this thing is limping
  32872. > pretty badly.
  32873. > 
  32874. >     Does anyone know how to bootstap code into the NMC if it's possible at
  32875. > all???
  32876. > 
  32877. >     Regards,
  32878. > 
  32879. >     Steve
  32880. > 
  32881. > 
  32882. > Minnetonka Micro  - Superior Communications Services Since 1984
  32883. > 
  32884. > 
  32885. > 
  32886. > -
  32887. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32888. >  with "unsubscribe usr-tc" in the body of the message.
  32889. >  For information on digests or retrieving files and old messages send
  32890. >  "help" to the same address.  Do not use quotes in your message.
  32891.  
  32892. -
  32893.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32894.  with "unsubscribe usr-tc" in the body of the message.
  32895.  For information on digests or retrieving files and old messages send
  32896.  "help" to the same address.  Do not use quotes in your message.
  32897.  
  32898.  
  32899. -------------------------------------------------------------------------------
  32900.  
  32901. From: Allen Marsalis <am@shreve.net>
  32902. Subject: (usr-tc) New 3Com Gaming Modem?
  32903. Date: 31 Oct 1999 10:24:26 -0500
  32904.  
  32905. Anyone got the inside scoop on what this really is/does?
  32906.  
  32907. http://www.3com.com/news/releases/pr99/oct2799b.html
  32908.  
  32909.  
  32910. am
  32911.  
  32912.  
  32913. -
  32914.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32915.  with "unsubscribe usr-tc" in the body of the message.
  32916.  For information on digests or retrieving files and old messages send
  32917.  "help" to the same address.  Do not use quotes in your message.
  32918.  
  32919.  
  32920. -------------------------------------------------------------------------------
  32921.  
  32922. From: Greg Coffey <greg@coffey.com>
  32923. Subject: Re: (usr-tc) New 3Com Gaming Modem?
  32924. Date: 31 Oct 1999 09:32:07 -0700
  32925.  
  32926. From the description, it sounds interesting.  Wonder why they can't build
  32927. the Sportster with the new functionality or what is so special to target
  32928. gamers?  Perhaps there is a flash for the v.everything so we could try it
  32929. out.  My best guess is that it is a way to extract $120 from modem users
  32930. this Xmas.
  32931.  
  32932.  
  32933.  
  32934.  
  32935. At 10:24 AM 10/31/99 -0500, you wrote:
  32936. >Anyone got the inside scoop on what this really is/does?
  32937. >
  32938. >http://www.3com.com/news/releases/pr99/oct2799b.html
  32939. >
  32940. >
  32941. >am
  32942. >
  32943. >
  32944. >-
  32945. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32946. > with "unsubscribe usr-tc" in the body of the message.
  32947. > For information on digests or retrieving files and old messages send
  32948. > "help" to the same address.  Do not use quotes in your message.
  32949. >
  32950. >
  32951.  
  32952. Thanks,
  32953.  
  32954. Greg Coffey, Visionary Communications  V 307-234-5443  F 307-234-5446 
  32955. =====================================================================
  32956. 100 N. Center St., Casper, WY  82601     WWW.VCN.COM         
  32957.  
  32958.  
  32959. -
  32960.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32961.  with "unsubscribe usr-tc" in the body of the message.
  32962.  For information on digests or retrieving files and old messages send
  32963.  "help" to the same address.  Do not use quotes in your message.
  32964.  
  32965.  
  32966. -------------------------------------------------------------------------------
  32967.  
  32968. From: Allen Marsalis <am@shreve.net>
  32969. Subject: Re: (usr-tc) New 3Com Gaming Modem?
  32970. Date: 31 Oct 1999 11:32:54 -0500
  32971.  
  32972. At 09:32 AM 10/31/99 -0700, Greg Coffey wrote:
  32973. >>From the description, it sounds interesting.  Wonder why they can't build
  32974. >the Sportster with the new functionality or what is so special to target
  32975. >gamers?  Perhaps there is a flash for the v.everything so we could try it
  32976. >out.  My best guess is that it is a way to extract $120 from modem users
  32977. >this Xmas.
  32978. >
  32979.  
  32980. I would think they would make as much or more profit on a flash upgrade,
  32981. at $60 so I'm assuming it does something in hardware.. That is, if it's
  32982. the same hardware, why not add a S-register or something to turn on
  32983. the "gaming mode"?  Maybe not as much profit per unit, but surely there
  32984. are more folks willing to upgrade than replace their entire modem..
  32985. and it's a direct sale with no middleman..  I mean they should offer
  32986. both an upgrade for existing customers and a hardware version for the
  32987. non-3com owners or new modem buyers IMO.
  32988.  
  32989. With 3com it's all about CPE..  They made zillions on NIC's and they
  32990. bought USR for their *client* modems, palm pilot, etc., surely not
  32991. for TC..  They are mass marketers and this is the best gimic immaginable
  32992. for getting a portion of the market to replace their working modems..
  32993. Actually, I've got to hand it to them marketing wise.. this is
  32994. brillant..  :>
  32995.  
  32996. Enough speculation..  Any real facts regarding this new product?
  32997.  
  32998. am
  32999.  
  33000.  
  33001. -
  33002.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33003.  with "unsubscribe usr-tc" in the body of the message.
  33004.  For information on digests or retrieving files and old messages send
  33005.  "help" to the same address.  Do not use quotes in your message.
  33006.  
  33007.  
  33008. -------------------------------------------------------------------------------
  33009.  
  33010. From: "Steve Sherwick" <hostmaster@minnmicro.com>
  33011. Subject: Re: (usr-tc) Major Blunder
  33012. Date: 31 Oct 1999 13:16:05 -0600
  33013.  
  33014. >
  33015. > hook up your console cable and stumble through the command line syntax for
  33016. > pcsdl.exe.
  33017.  
  33018.     Thanks!!!
  33019.  
  33020.     I've got it now. Your suggestion was invaluable.
  33021.  
  33022.     Your use of the term stumble is very apt, it was a pain. Somewhere they
  33023. could document how the part number is used to create the SDL  and Device
  33024. code for the PCSDL parameters. Or maybe they could just put the information
  33025. in the info file in the friggng ZIP???
  33026.  
  33027. >
  33028. > Once you figure out the syntax you need, start pcsdl and reseat the NMC
  33029. > simultaneously.  During the NMC boot process it sees that the console is
  33030. > trying to upload code to it and should allow the upload.
  33031.  
  33032.     Oddly enough once I got the syntax correct it just hooked and loaded all
  33033. by itself without reseating the NMC.
  33034.  
  33035. >
  33036. > It will be quicker if you set your console to 57,600 and set your NMC dip
  33037. > switches to match.  I can't remember which ones need to be flipped but 3KB
  33038. > should be able to tell you.
  33039.  
  33040.     I had the hardware manuals and kicked the BPS up long before my first
  33041. message. Again though, the docs on this thing suck. I don't think SDL-2 will
  33042. work on the NMC even though it's stated as the preferred option in the
  33043. manual. No matter what I tried I couldn't get a response that allowed the
  33044. supposed "trigger code" to be sent. As a matter of fact the manual intimates
  33045. that PCSDL won't work at all in some areas.
  33046.  
  33047.     Once I downloaded the 16 meg version of the code into the NMC it still
  33048. was lost in space until I reloaded the NMC's IP addresses and netmask.
  33049. Apparently when you accidentally download the 4 meg version in a 16 meg card
  33050. it loses it's settings.
  33051.  
  33052.     All and all a sleepless night <grin>....
  33053.  
  33054.     I thank you so much for rescueing me on a Sunday morning. I'm gonna get
  33055. some sleep now.
  33056.  
  33057.     Regards,
  33058.  
  33059.     -= Steve =-
  33060.  
  33061. >
  33062. > Matthew
  33063. >
  33064. > > -----Original Message-----
  33065. > > From: Steve Sherwick [SMTP:hostmaster@minnmicro.com]
  33066. > > Sent: Sunday, October 31, 1999 10:41 AM
  33067. > > To: usr-tc@lists.xmission.com
  33068. > > Subject: (usr-tc) Major Blunder
  33069. > >
  33070. > >     Hi There,
  33071. > >
  33072. > >     Well at four this morning I made a major blunder, I downloaded the
  33073. > > wrong
  33074. > > version of code into a USR HIPER's NMC card. Now I can't login to it
  33075. with
  33076. > > Total Control Manager to correct it as it can't find the NMC card. I can
  33077. > > get
  33078. > > at it with the HARC Manager but it won't bridge to NMC that I can see.
  33079. > >
  33080. > >     The SDL-2 instructions aren't making any sense, When I login to the
  33081. > > NMC
  33082. > > it places me in a menu not anywhere I can enter a trigger code.
  33083. > >
  33084. > >     My service contact is business hours only and this thing is limping
  33085. > > pretty badly.
  33086. > >
  33087. > >     Does anyone know how to bootstap code into the NMC if it's possible
  33088. at
  33089. > > all???
  33090. > >
  33091. > >     Regards,
  33092. > >
  33093. > >     Steve
  33094. > >
  33095. > >
  33096. > > Minnetonka Micro  - Superior Communications Services Since 1984
  33097. > >
  33098. > >
  33099. > >
  33100. > > -
  33101. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33102. > >  with "unsubscribe usr-tc" in the body of the message.
  33103. > >  For information on digests or retrieving files and old messages send
  33104. > >  "help" to the same address.  Do not use quotes in your message.
  33105. >
  33106. > -
  33107. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33108. >  with "unsubscribe usr-tc" in the body of the message.
  33109. >  For information on digests or retrieving files and old messages send
  33110. >  "help" to the same address.  Do not use quotes in your message.
  33111.  
  33112.  
  33113. -
  33114.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33115.  with "unsubscribe usr-tc" in the body of the message.
  33116.  For information on digests or retrieving files and old messages send
  33117.  "help" to the same address.  Do not use quotes in your message.
  33118.  
  33119.  
  33120. -------------------------------------------------------------------------------
  33121.  
  33122. From: Jeff Mcadams <jeffm@iglou.com>
  33123. Subject: Re: (usr-tc) Major Blunder
  33124. Date: 31 Oct 1999 14:48:34 -0500
  33125.  
  33126. Thus spake Steve Sherwick
  33127. >> It will be quicker if you set your console to 57,600 and set your NMC dip
  33128. >> switches to match.  I can't remember which ones need to be flipped but 3KB
  33129. >> should be able to tell you.
  33130.  
  33131. >    I had the hardware manuals and kicked the BPS up long before my first
  33132. >message. Again though, the docs on this thing suck. I don't think SDL-2 will
  33133. >work on the NMC even though it's stated as the preferred option in the
  33134. >manual. 
  33135.  
  33136. SDL-2 is *only* for HiPer cards (HiPer NMC, HiPer Arc, and HiPer DSP),
  33137. if you've got a 486 based (or 386 based!) NMC, you have to use the
  33138. original SDL setup, which uses pcsdl.
  33139.  
  33140. >No matter what I tried I couldn't get a response that allowed the
  33141. >supposed "trigger code" to be sent. As a matter of fact the manual intimates
  33142. >that PCSDL won't work at all in some areas.
  33143.  
  33144. PCSDL won't work on the HiPer cards, you have to use the SDL-2 for that.
  33145. On the flip side, SDL-2 doesn't work on non-HiPer cards.  I suspect
  33146. you're reading the wrong manual.  :)
  33147. -- 
  33148. Jeff McAdams                            Email: jeffm@iglou.com
  33149. Head Network Administrator              Voice: (502) 966-3848
  33150. IgLou Internet Services                        (800) 436-4456
  33151.  
  33152. -
  33153.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33154.  with "unsubscribe usr-tc" in the body of the message.
  33155.  For information on digests or retrieving files and old messages send
  33156.  "help" to the same address.  Do not use quotes in your message.
  33157.  
  33158.  
  33159. -------------------------------------------------------------------------------
  33160.  
  33161. From: jeff.binkley@asacomp.com (Jeff Binkley)
  33162. Subject: (usr-tc) New DSP code
  33163. Date: 31 Oct 1999 21:54:00 -0500
  33164.  
  33165.  
  33166. Has anyone loaded the new HiPerDSP code version 2.0.60 yet?  It is
  33167. an upgrade to 2.0.81 .
  33168.  
  33169. Jeff Binkley
  33170. ASA Network Computing
  33171.  
  33172. -
  33173.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33174.  with "unsubscribe usr-tc" in the body of the message.
  33175.  For information on digests or retrieving files and old messages send
  33176.  "help" to the same address.  Do not use quotes in your message.
  33177.  
  33178.