April 1999

480 messages

« March 1999May 1999 »

Messages

Subject: (usr-tc) SLIP start message
From: Roy, Richard <richard.roy@nbtel.nb.ca>
Date: 1999-03-31 16:42:07
Hi, I'm trying to find a way to customize a SLIP start message string with the command "set slip session_start_message ..." What I have before: SL/IP session from (1.2.3.4) to 1.2.3.4 beginning.... Now with HA version 4.1.59-6, I have SL/IP session from ( 1.2.3.4 ) to 1.2.3.4 beginning.... I'm trying to get rid of the spaces in "( 1.2.3.4 )". Is anyone have a recipe for this. Thanks. Richard Roy NBTel Internet.
Subject: (usr-tc) performance on quad modems
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-04-01 08:29:45
This is a multi-part message in MIME format. ------=_NextPart_000_009E_01BE7C19.CC02E140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have a old style chassis running 6 quad modems and a Hiper Arc card = that we use for backup analog access in one of our POPs. For some = reason, users cannot access this chassis above 33.6, and it is usually = much lower connection. The quads are running 5.10.9, the hiper arc 4.1.59. It is fed by a channelized T-1 via a dual t-1 board. We have both a = hunt group and DS0 dial numbers, and testing from here indicates that it = does not matter which DS0 you dial in on. Any ideas??? Samuel S. Lowe Director, Data Network Services UniversalCom, Inc. slowe@universalcom.net ------=_NextPart_000_009E_01BE7C19.CC02E140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML><HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <STYLE></STYLE> <META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2> <DIV><FONT size=3D2>We have a old style chassis running 6 quad modems = and a Hiper=20 Arc card that we use for backup analog access in one of our POPs.&nbsp; = For some=20 reason, users cannot access this chassis above 33.6, and it is usually = much=20 lower connection.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>The quads are running 5.10.9, the hiper arc=20 4.1.59.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>It is fed by a channelized T-1 via a dual t-1 = board.&nbsp; We=20 have both a hunt group and DS0 dial numbers, and testing from here = indicates=20 that it does not matter which DS0 you dial in on.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Any ideas???</FONT></DIV> <DIV></FONT><FONT size=3D2><BR>Samuel S. Lowe<BR>Director, Data Network=20 Services<BR>UniversalCom, Inc.<BR><A=20 href=3D"mailto:slowe@universalcom.net">slowe@universalcom.net</A><BR></FO= NT></DIV></DIV></BODY></HTML> ------=_NextPart_000_009E_01BE7C19.CC02E140--
Subject: Re: (usr-tc) How do you setup Multilink PPP on a HiperARC?
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 1999-04-01 10:19:40
MLPPP It set up by defaulf. set net user default ppp max_CHANNELS 2 set net user default ppp max_CHANNELS 1 disable MLPPP Regards Ray W "Matthew Pearson" <mpearson@tiac.net> on 01/04/99 02:57:22 Please respond to usr-tc@lists.xmission.com cc: (Ray Whelan/IE/3Com) Anyone have a quick doc on this? I've scoured 3com's site with no luck! Help! Thanks - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) performance on quad modems
From: Alessandro Alves <aalves@mpcnet.com.br>
Date: 1999-04-01 12:00:26
--=====================_263311451==_.ALT Content-Type: text/plain; charset="us-ascii" Hi, To connect 56 K, you need to put the latest version in NMC and T1 boards too. And you need to put the ability key for X2 in the NMC board. At 08:29 AM 4/1/99 -0600, you wrote: > > We have a old style chassis running 6 quad modems and a Hiper Arc card that > we use for backup analog access in one of our POPs. For some reason, users > cannot access this chassis above 33.6, and it is usually much lower > connection. > > The quads are running 5.10.9, the hiper arc 4.1.59. > > It is fed by a channelized T-1 via a dual t-1 board. We have both a hunt > group and DS0 dial numbers, and testing from here indicates that it does not > matter which DS0 you dial in on. > > Any ideas??? > > Samuel S. Lowe > Director, Data Network Services > UniversalCom, Inc. > <mailto:slowe@universalcom.net>slowe@universalcom.net --=====================_263311451==_.ALT Content-Type: text/html; charset="us-ascii" <html> Hi,<br> <br> To connect 56 K, you need to put the latest version in NMC and T1 boards too. And you need to put the ability key for X2 in the NMC board.<br> At 08:29 AM 4/1/99 -0600, you wrote: <br> <font size=2><blockquote type=cite cite>We have a old style chassis running 6 quad modems and a Hiper Arc card that we use for backup analog access in one of our POPs.&nbsp; For some reason, users cannot access this chassis above 33.6, and it is usually much lower connection.<br> <br> The quads are running 5.10.9, the hiper arc 4.1.59.<br> <br> It is fed by a channelized T-1 via a dual t-1 board.&nbsp; We have both a hunt group and DS0 dial numbers, and testing from here indicates that it does not matter which DS0 you dial in on.<br> <br> Any ideas???<br> <br> Samuel S. Lowe<br> Director, Data Network Services<br> UniversalCom, Inc.<br> <font size=2><a href="mailto:slowe@universalcom.net">slowe@universalcom.net</a><br> </blockquote><br> </font></html> --=====================_263311451==_.ALT--
Subject: (usr-tc) FYI: Webramp DOS
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-01 12:14:44
Just saw this on BUGTRAQ. Thought it would be of interest to some of you. Quote from ISS Vulnerability Notice: "WebRamp is vulnerable to two denial of service attacks that allow an attacker to either crash the WebRamp device or change its IP address. When the device crashes, it will have to be manually reset before it will dial up. If an attacker changes the IP address of the WebRamp, none of the machines on your network will be able to find it, so no machines will be able to access the Internet via the WebRamp. The device will still function as a network hub, so your intra-LAN connectivity will not be disrupted." Fix Information: Go to http://www.rampnet.com/upgrades to get the latest firmware for your model of WebRamp. Mike Wronski (mike@coredump.ae.usr.com) Rogue 3Com Network Systems Engineer / BETA Engineer PGP:http://coredump.ae.usr.com/pgp iCQ:15796141 "If at first you do succeed, try not to look astonished."
Subject: Re: (usr-tc) performance on quad modems
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-04-01 14:18:50
This is a multi-part message in MIME format. ------=_NextPart_000_016F_01BE7C4A.90633F00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All done already. Everything is running latest sw and x2 key applied. Any other ideas? ----- Original Message -----=20 From: Alessandro Alves=20 To: usr-tc@lists.xmission.com=20 Sent: Thursday, April 01, 1999 9:00 AM Subject: Re: (usr-tc) performance on quad modems Hi, To connect 56 K, you need to put the latest version in NMC and T1 = boards too. And you need to put the ability key for X2 in the NMC board. At 08:29 AM 4/1/99 -0600, you wrote:=20 We have a old style chassis running 6 quad modems and a Hiper Arc = card that we use for backup analog access in one of our POPs. For some = reason, users cannot access this chassis above 33.6, and it is usually = much lower connection. The quads are running 5.10.9, the hiper arc 4.1.59. It is fed by a channelized T-1 via a dual t-1 board. We have both a = hunt group and DS0 dial numbers, and testing from here indicates that it = does not matter which DS0 you dial in on. Any ideas??? Samuel S. Lowe Director, Data Network Services UniversalCom, Inc. slowe@universalcom.net ------=_NextPart_000_016F_01BE7C4A.90633F00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML><HEAD> <META content=3Dtext/html;charset=3DWindows-1252 = http-equiv=3DContent-Type> <STYLE></STYLE> <META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>All done already.&nbsp; Everything is running latest = sw and x2=20 key applied.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Any other ideas?</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message -----=20 <DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20 href=3D"mailto:aalves@mpcnet.com.br" = title=3Daalves@mpcnet.com.br>Alessandro=20 Alves</A> </DIV> <DIV><B>To:</B> <A href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV><B>Sent:</B> Thursday, April 01, 1999 9:00 AM</DIV> <DIV><B>Subject:</B> Re: (usr-tc) performance on quad = modems</DIV></DIV> <DIV><BR></DIV>Hi,<BR><BR>To connect 56 K, you need to put the latest = version=20 in NMC and T1 boards too. And you need to put the ability key for X2 = in the=20 NMC board.<BR>At 08:29 AM 4/1/99 -0600, you wrote: <BR><FONT size=3D2> <BLOCKQUOTE cite type =3D cite>We have a old style chassis running 6 = quad=20 modems and a Hiper Arc card that we use for backup analog access in = one of=20 our POPs.&nbsp; For some reason, users cannot access this chassis = above=20 33.6, and it is usually much lower connection.<BR><BR>The quads are = running=20 5.10.9, the hiper arc 4.1.59.<BR><BR>It is fed by a channelized T-1 = via a=20 dual t-1 board.&nbsp; We have both a hunt group and DS0 dial = numbers, and=20 testing from here indicates that it does not matter which DS0 you = dial in=20 on.<BR><BR>Any ideas???<BR><BR>Samuel S. Lowe<BR>Director, Data = Network=20 Services<BR>UniversalCom, Inc.<BR><FONT size=3D2><A=20 = href=3D"mailto:slowe@universalcom.net">slowe@universalcom.net</A><BR></BL= OCKQUOTE><BR></FONT></FONT></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_016F_01BE7C4A.90633F00--
Subject: (usr-tc) Primary first backup vs. secondary accounting
From: Randy Cosby <dcosby@infowest.com>
Date: 1999-04-01 14:37:26
How do I set the server IP for the primary first backup server, and primary third backup server? What's the difference between the primary first backup and the secondary server? The Primary Server Status is: ENABLED Primary Server is: x.x.x.x Primary First Backup Server is: 0.0.0.0 Primary Second Backup Server is: 0.0.0.0 Primary Destination Port is: 1646 Primary First Backup Destination Port: 1646 Primary Second Backup Destination Port: 1646 Max Primary Retranmissions: 20 The Secondary Server Status is: ENABLED Secondary Server is: 0.0.0.0 Secondary First Backup Server is: 0.0.0.0 Secondary Second Backup Server is: 0.0.0.0 Secondary Destination Port is: 1646 Secondary First Backup Destination Port: 1646 Secondary Second Backup Destination Port: 1646 Max Secondary Retranmissions: 0 Source Port is: 1646 Retransmission Timeout: 60 seconds Accounting Start Time: CONNECTION Log Unauthenticated Calls: FALSE Vendor Specific Attribute: ENABLED Active Accounting Server (Primary): x.x.x.x Active Accounting Server (Secondary): 0.0.0.0 Attribute Style: STANDARD Prioritize First Server in a Server Group: DISABLED --- set accounting CLI - Missing Required Argument(s): This field is a KEYWORD. The possible values are: ATTRIBUTE_STYLE PRIMARY_SERVER SOURCE_PORT LOG_UNAUTHENTICATED_CALLS SECONDARY_DESTINATION_PORT START_TIME PRIMARY_DESTINATION_PORT SECONDARY_RETRANSMISSIONS TIMEOUT PRIMARY_RETRANSMISSIONS SECONDARY_SECRET VSA PRIMARY_SECRET SECONDARY_SERVER Required Arguments are: End of Command _sho ver V4.1.59 - 6 --- I see how to set the secondary server, but not the primary first or second backup. thanks, Randy
Subject: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
From: John Verreault <verreaul@aei.ca>
Date: 1999-04-01 14:48:49
I have set up a Primary Accounting Server and a Primary Backup Accounting Server. I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH This works fine, except when the backup server takes over authentication it doesn't switch back to the primary automatically. What is the correct config ???? Thanks JOhn AEI Internet
Subject: RE: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-01 15:15:22
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Verreault |Sent: Thursday, April 01, 1999 1:49 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6 | | |I have set up a Primary Accounting Server and a Primary Backup Accounting |Server. | |I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH | |This works fine, except when the backup server takes over authentication it |doesn't switch back to the primary automatically. | |What is the correct config ???? That config only applies to "AUTHENTICATION" like the name implies. To set this up for "ACCOUNTING" set the following "ENABLE PRIORITIZE". -M
Subject: Re: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-01 15:25:59
On Thu, 1 Apr 1999, John Verreault wrote: > I have set up a Primary Accounting Server and a Primary Backup Accounting > Server. > > I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH If the primary is down it will go to the primary_backup and if the primary back up is down then it will go to the primary - that is how fall_through works with primary back and primary server. There should be an option set radius authentication_algo active_server that is what you need. krish > > This works fine, except when the backup server takes over authentication it > doesn't switch back to the primary automatically. > > What is the correct config ???? > > Thanks > JOhn > AEI Internet > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Failure to negociate V90
From: Fred Williams <fwilliams@gtnet.gov.uk>
Date: 1999-04-01 15:29:38
We have a user with a Compaq 420 Microcom K56/V90 PCMCIA modem. He is failing to get a connection better than 31.2K when dialiing into our TC Racks (mix of Quads and Netserver plus Hiper DSP and ARC). He regularly gets a 41 to 44K connection into other ISPs. He claims to have the latest V90 code on his modem. Can anyone offer a solution please? **************************************************************** * Fred Williams email fwilliams@gtnet.gov.uk * * CCTA voice 01603 704706 * * Rosebery Court GTN 3040 4706 * * St Andrews Business Park fax 01603 704817 * * NORWICH GTN fax 3040 4817 * * NR7 0HS UK * ****************************************************************
Subject: RE: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6
From: John Verreault <verreaul@aei.ca>
Date: 1999-04-01 16:25:56
Works like a charm, Thanks John > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski > Sent: Thursday, April 01, 1999 4:15 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Problem - Primary Backup radius server w/ARC > 4.1.59-6 > > > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Verreault > |Sent: Thursday, April 01, 1999 1:49 PM > |To: usr-tc@lists.xmission.com > |Subject: (usr-tc) Problem - Primary Backup radius server w/ARC 4.1.59-6 > | > | > |I have set up a Primary Accounting Server and a Primary Backup Accounting > |Server. > | > |I have set radIUS autHENTICATION_ALGORITHM to fall_THROUGH > | > |This works fine, except when the backup server takes over > authentication it > |doesn't switch back to the primary automatically. > | > |What is the correct config ???? > > That config only applies to "AUTHENTICATION" like the name > implies. To set this > up for "ACCOUNTING" > set the following "ENABLE PRIORITIZE". > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) modem configs
From: Randy McMillan <randy@pacinfo.com>
Date: 1999-04-01 16:39:16
I can disable the v.90 on the quad modems, but then the fastest speed I can get on the line is 28800 or less. It seems to be disabling v.34+ speeds. Does anyone know why or a way to work around it? Actually, it works the same if I disable v.90 on my sportster and dial in to a v.90 enabled line. Thanks. Randy McMillan PacInfo ----- Original Message ----- Sent: Friday, March 26, 1999 2:00 PM > On Mon, 22 Mar 1999, Mike Andrews wrote: > > > I'm also having a problem that maybe someone else can help with here. The > > above init string doesn't disable v.90/x2 correctly on the Quads. (Works > > great on DSP's.) If I call in with a Courier, it chokes during the > > handshake -- it sounds as if one side is attempting x2 (not v.90) and the > > other side is trying v.34. (It dies during the line frequency probe > > sequence, in other words.) If I call in with an LT Winmodem it seems to > > be more or less OK. > > > > So... What's the *correct* AT sequence to completely kill all 56K > > modulations on a Quad modem and leave v.34 intact? > > If anyone cares, I fixed this by disabling all 3 x2 modes -- client, > server, and symmetric. Apparently disabling just server wasn't good > enough for the Quads. Go figure... > > > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a > Microsoft operating system is like a dog without a brick tied to its head." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) Primary first backup vs. secondary accounting
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-01 17:17:45
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Cosby |Sent: Thursday, April 01, 1999 3:37 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Primary first backup vs. secondary accounting | | |How do I set the server IP for the primary first backup server, and primary |third backup server? What's the difference between the primary first backup |and the secondary server? | | |I see how to set the secondary server, but not the primary first or second |backup. If a Secondary is configured then accounting packets are send to both primary and secondary "EVERY" time. This is for database duplication,etc. For a fallback server (ie main server goes down, use fallback) you configure a PRIMARY_BACKUP with the command "set accounting_backup primary first_server X.X.X.X" "set accounting_backup primary first_secret secret" You get the idea.. -M
Subject: Re: (usr-tc) Failure to negociate V90
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 1999-04-01 17:24:55
Hi Fred, I have a document which I will send you offline which will enable you to further trouble shoot this problem Ray W "Fred Williams" <fwilliams@gtnet.gov.uk> on 01/04/99 14:29:38 Please respond to usr-tc@lists.xmission.com cc: (Ray Whelan/IE/3Com) We have a user with a Compaq 420 Microcom K56/V90 PCMCIA modem. He is failing to get a connection better than 31.2K when dialiing into our TC Racks (mix of Quads and Netserver plus Hiper DSP and ARC). He regularly gets a 41 to 44K connection into other ISPs. He claims to have the latest V90 code on his modem. Can anyone offer a solution please? **************************************************************** * Fred Williams email fwilliams@gtnet.gov.uk * * CCTA voice 01603 704706 * * Rosebery Court GTN 3040 4706 * * St Andrews Business Park fax 01603 704817 * * NORWICH GTN fax 3040 4817 * * NR7 0HS UK * **************************************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Rockwell HCF 56k PCI
From: Richard Gamberg <bbhi@shaka.com>
Date: 1999-04-02 09:30:12
Also see http://808hi.com/56k/rockhcf.htm for the HCF page at 56k=v.Unreliable; has a table of vendors w/ links to their firmware updates, and other useful info. Aloha, Richard http://808hi.com/56k/ 56k=v.Unreliable -> -----Original Message----- -> From: owner-usr-tc@lists.xmission.com -> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian -> Sent: Friday, April 02, 1999 5:52 AM -> To: USRobotics TC Mailing List -> Subject: (usr-tc) Rockwell HCF 56k PCI -> -> -> -> does anyone know of any issues with these modems? We are -> running 4.1.59-1 -> and 1.2.6. I got the below message from our Tech Support Mgr. -> -> Brian -> -> -> ----------------------------------------------------- -> Brian Feeny (BF304) signal@shreve.net -> 318-222-2638 x 109 http://www.shreve.net/~signal -> Network Administrator ShreveNet Inc. (ASN 11881) -> -> ---------- Forwarded message ---------- -> Date: Fri, 2 Apr 1999 09:47:43 -0600 (EST) -> From: Scarlett <scarlett@shreve.net> -> To: Brian <signal@shreve.net> -> Subject: Modem ISSUE -> -> Rockwell HCF 56k PCI modems are giving all of us hell more than the LT -> Winmodems I saw one yesterday but we have 2 right now that can connect -> but they get dropped w/in 2-15 minutes of being online. Can you find out -> if there is an issue out there with these modems. -> -> The one I had yesterday was a Hayes todays ones are Rockwell but they all -> use the same chip. Even putting an init string in it doesnt help -> -> THanks, -> -> Scarlett -> -> -> -> -> - -> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" -> with "unsubscribe usr-tc" in the body of the message. -> For information on digests or retrieving files and old messages send -> "help" to the same address. Do not use quotes in your message. ->
Subject: (usr-tc) [isp-services] FS:USR Total Control Units (fwd)
From: Brian <signal@shreve.net>
Date: 1999-04-02 09:41:16
This is damn cheap in case anyone is looking for some older hardware. Thats $47 a port. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) ---------- Forwarded message ---------- Have (2) Total Control Units, in Stock of Analog: USR Total Control Units 1 Netserver PRI 1 Net Mgt card 15 Quad V.34 modem cards. 2 Power supplies (45amp) 1 Fantray Set up token ring $2,300 each Also, Have (2) Digital Total Control Units -with PRI T-1 cards $3,500 each Have a great day! Andrew Shlensky **************************** PC Global, Incorporated (305) 667-2111 TEL (305) 667-3636 FAX URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org For additional commands, e-mail: isp-services-help@ispc.org ========================================================================= ISPF - The Forum for ISPs by ISPs(tm) || Nov 15-17, 1999, New Orleans 3 days of clues, news, and views from the industry's best and brightest. Visit <http://www.ispf.com/> for information and registration. =========================================================================
Subject: (usr-tc) Rockwell HCF 56k PCI
From: Brian <signal@shreve.net>
Date: 1999-04-02 09:51:57
does anyone know of any issues with these modems? We are running 4.1.59-1 and 1.2.6. I got the below message from our Tech Support Mgr. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) ---------- Forwarded message ---------- Rockwell HCF 56k PCI modems are giving all of us hell more than the LT Winmodems I saw one yesterday but we have 2 right now that can connect but they get dropped w/in 2-15 minutes of being online. Can you find out if there is an issue out there with these modems. The one I had yesterday was a Hayes todays ones are Rockwell but they all use the same chip. Even putting an init string in it doesnt help THanks, Scarlett
Subject: Re: (usr-tc) Rockwell HCF 56k PCI
From: Brian <signal@shreve.net>
Date: 1999-04-02 10:21:30
Thanks Jeff, I have sent them to check it out. On Fri, 2 Apr 1999, Jeff Mcadams wrote: > Thus spake Brian > >does anyone know of any issues with these modems? We are running 4.1.59-1 > >and 1.2.6. I got the below message from our Tech Support Mgr. > > There's a huge amount of discussion about these at www.56k.com in the > message boards...a flash upgrade helps tremendously typically (2.1.2.135 > I believe is known to work pretty well). > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) USR Total Control Units for sale
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-02 11:08:37
All sold with 30 day warranty! 10-USR Total Control Units configured as:) 1 Chassis 1 Net Mgt card 15 Quad dig/analog 2 Power supplies (45amp) set up for ethernet $2500 1-USR Total Control Units 1 Chassis 1 Netserver PRI 1 Net Mgt card 15 Quad digital/analog 2 Power supplies (70amp) set up for ethernet Fan Tray $4500 Steve Rivera sales@wrca.net Check out product information and inventory. http://www.wrca.net(All New 3/22/99) 732-833-2111 ''''''''''''''''''''''''''''''''''''''''''''''' De-installed ISP,CLEC,LEC Net-Hardware Wanted ' '''''''''''''''''''''''''''''''''''''''''''''''
Subject: Re: (usr-tc) Rockwell HCF 56k PCI
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-02 11:13:06
Thus spake Brian >does anyone know of any issues with these modems? We are running 4.1.59-1 >and 1.2.6. I got the below message from our Tech Support Mgr. There's a huge amount of discussion about these at www.56k.com in the message boards...a flash upgrade helps tremendously typically (2.1.2.135 I believe is known to work pretty well). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Rockwell HCF 56k PCI
From: Jamie Orzechowski <mhz@recorder.ca>
Date: 1999-04-02 11:38:10
I can;t seem to find the new Rockwell HCF flash anywhere?? anyone know where I can snag it? -----Original Message----- >Thus spake Brian >>does anyone know of any issues with these modems? We are running 4.1.59-1 >>and 1.2.6. I got the below message from our Tech Support Mgr. > >There's a huge amount of discussion about these at www.56k.com in the >message boards...a flash upgrade helps tremendously typically (2.1.2.135 >I believe is known to work pretty well). >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) Rockwell HCF 56k PCI
From: Greg Owens <gowens@magnolia-net.com>
Date: 1999-04-02 12:13:17
We are experiencing the same issues with the Rockwell HCF/PCI modems with the 4.1.59-1 code also. What I am curious about has anyone had success with the code listed on this page http://www.radi.com/software.htm Reason for asking..In the last two days I have hooked up 2 Compaq computers with these type modems and neither would connect unitl I disabled V-90. These computers were bought in Dec98 and Jan99. I notice the file date for the HCF modems are Dec 2nd. Is this the newest code? Before I send my users to download this file wanted to make sure..As for the brand new Compaqs with the HCF's they apperar to connect very well. -----Original Message----- >http://www.radi.com/software.htm > > >I can;t seem to find the new Rockwell HCF flash anywhere?? anyone know where >I can snag it? > > > >>Thus spake Brian >>>does anyone know of any issues with these modems? We are running 4.1.59-1 >>>and 1.2.6. I got the below message from our Tech Support Mgr. >> >>There's a huge amount of discussion about these at www.56k.com in the >>message boards...a flash upgrade helps tremendously typically (2.1.2.135 >>I believe is known to work pretty well). >> >> > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) Rockwell HCF 56k PCI
From: Hofmann <jay@iglou.com>
Date: 1999-04-02 12:14:46
http://www.radi.com/software.htm I can;t seem to find the new Rockwell HCF flash anywhere?? anyone know where I can snag it? >Thus spake Brian >>does anyone know of any issues with these modems? We are running 4.1.59-1 >>and 1.2.6. I got the below message from our Tech Support Mgr. > >There's a huge amount of discussion about these at www.56k.com in the >message boards...a flash upgrade helps tremendously typically (2.1.2.135 >I believe is known to work pretty well). > >
Subject: RE: (usr-tc) Rockwell HCF 56k PCI
From: John C Hill II <carroll@netexas.net>
Date: 1999-04-02 12:29:04
We had one Rockwell PCI in our shop recently. I don't know if it was made or sold by Powercom-usa. Anyway, I went to Powercom's webpage (www.powercom-usa.com) webpage and downloaded the latest driver. We haven't had any problems. We are running DSP code .69 John C Hill II North East Texas Internet
Subject: (usr-tc) ATS48 and "optimum" settings
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-02 16:13:29
I'm just installing the DNIS stuff that Lon came up with, and I ran over register S48 and noticed that it had disabled 300,1200,2400 and "high speed". What does this entail? With the first three disabled, I presume I can not take 300-2400 bps calls? What does "high speed" cover? Aside from the fact that anyone using a 300 bps modem must be a goof, I prefer to support everything rather than cut someone out. Is there any harm in enabling all four of the above? If not, why does it default with them off?
Subject: (usr-tc) Hiper DSP T1/PRI 1.2.43 Service Release
From: David Bachta <david_bachta@mw.3com.com>
Date: 1999-04-02 16:40:17
3Com Carrier Customer Support has posted HiPer DSP T1/PRI Service Release version 1.2.43 on the Totalservice technical support web site. This release will be available for download, free-of-charge, through the end of May, 1999. Version 1.2.43 is an effort to combine many previous Engineering Releases into a generally available code release. It addresses a series of P1 and P2 issues identified with previous HiPer DSP code release. It can be accessed in either of the following locations: http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+latest ( posted under Total Control Hubs ) or http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+software ( search by Total Control Hubs : Hiper DSP ) For a list of the issues addressed in this Service Release please review the Service Release Note, 24209600.pdf. The release note is posted along side the code on the Totalservice website. The release note is also available bundled with the code in the file hd010243.zip. Regards, David Bachta Network Engineer 3Com
Subject: Re: (usr-tc) ATS48 and "optimum" settings
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1999-04-02 18:31:52
On Fri, 2 Apr 1999, Pete Ashdown wrote: > I'm just installing the DNIS stuff that Lon came up with, and I ran over > register S48 and noticed that it had disabled 300,1200,2400 and "high > speed". What does this entail? With the first three disabled, I presume I > can not take 300-2400 bps calls? What does "high speed" cover? That's my understanding (that it prevents those speeds). High Speed is the old USR 'HST' protocol, I believe. > Aside from the fact that anyone using a 300 bps modem must be a goof, I > prefer to support everything rather than cut someone out. Is there any > harm in enabling all four of the above? If not, why does it default with > them off? I have 'em enabled here; havent' noted any troubles...I have a handful of 1200 and 2400 people still so need 'em (I still run my old text-based bbs and some of the callers there still have ancient equipment; my 'bbs' username does a rlogin to the bbs).
Subject: Re: (usr-tc) Rockwell HCF 56k PCI
From: Kirk Mitchell <mitch@keyconn.net>
Date: 1999-04-02 18:36:04
At 12:13 PM 4/2/99 -0600, you wrote: > We are experiencing the same issues with the Rockwell HCF/PCI modems with >the 4.1.59-1 code also. What I am curious about has anyone had success with >the code listed on this page http://www.radi.com/software.htm Reason for >asking..In the last two days I have hooked up 2 Compaq computers with these >type modems and neither would connect unitl I disabled V-90. These >computers were bought in Dec98 and Jan99. I notice the file date for the HCF >modems are Dec 2nd. Is this the newest code? Before I send my users to >download this file wanted to make sure..As for the brand new Compaqs with >the HCF's they apperar to connect very well. Try the driver at http://www.wellmodem.com.tw/hcf56drv.htm dated Dec 22, we've had a fair amount of success with it. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: (usr-tc) compaq Rockwell HCF modems (fwd)
From: Brian <signal@shreve.net>
Date: 1999-04-02 20:56:01
some people here I thought may want this Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) ---------- Forwarded message ---------- the main file area for the Rockwell HCF modem at compaq http://www.compaq.com/athome/support/softpaq/pages/sp8897.html VERSION: 4.1 LANGUAGE: Multi-lingual CATEGORY: Driver DIVISIONS: Consumer PRODUCTS AFFECTED: Compaq Presario 2262, 2264, 2266, 2275, 2278; 5010, 5015, 5020, 5027, 5030, 5032, 5035; 5037, 5038, 5050, 5062, 5150, 5151, 5152, 5155, 5170, 5177, 5190, 5192, 5110, 5140, 5147, 5600 (Rockwell Modem only), 5610, 5612, 5630, 5635, 5660, 5665 OPERATING SYSTEM: Microsoft Windows 95, Microsoft Windows 98 SYSTEM CONFIGURATION: Integrated 56K PCI modem (U.S., Canada, Latin America, and Brazil) PREREQUISITES: N/A EFFECTIVE DATE: January 8, 1999 ELECTRONIC DISTRIBUTION ALLOWED: Yes SOFTPAQ UTILITY VERSION: 3.x SUPERSEDES: SP7953 DESCRIPTION: Unpacks files that are used with the Presario models mentioned above to upgrade the drivers in the integrated modem. The new driver version is 2.1.2.134. Enhancements/Fixes In this version: - Improves V.90 performance - Improves V.90 connections to US Robotics Total Control Modem Banks - Improves performance when playing Quake and Quake 2 over the Internet In previous version (2.1.2.120.1): - Corrects errors in connect rate messages when connected to a V.90 modem at the Internet Service Provider (ISP) - Fixes Windows 98 issue that causes computer to lock up when an incoming call is received when no communications applications are running ........................................................................ joseph kamm http://www.biohazard.net jkamm@shreve.net tech support, shrevenet inc., http://www.shreve.net
Subject: (usr-tc) PRI on AMI encoding
From: Chris <hender@rconnect.com>
Date: 1999-04-02 21:11:22
I am setting up a chassis with an ARC and 2 HiperDSP's. Latest versions = of the code on both. Setting this up for PRI, phone company has a DMS100 = and the are running D4 and AMI on the line at 56k. Has anyone had any = luck setting a PRI up on D4 and AMI or is this just not gonna work? I've = spent hours on the phone with the telco and have talked to 3com and have = had mixed answers from them as to whether it will work, they start off = telling me it will work and then whittle it down to it won't work. Seems = like every question I ask they say, "Yeah it'll do that just fine" and = then I call back when I'm having trouble and they try some things and = then after a while decide that its not gonna work. Any one out there = have any input on whether or not this will work. The telco is leasing = the fiber from another telco so it is going to be a pain to get it = switched over to ESF and B8ZS.
Subject: Re: (usr-tc) compaq Rockwell HCF modems (fwd)
From: Bryan Wann <bwann@cwis.net>
Date: 1999-04-03 00:41:16
On Fri, 2 Apr 1999, Brian wrote: > some people here I thought may want this > > ---------- Forwarded message ---------- > Date: Fri, 2 Apr 1999 20:27:03 -0600 (EST) > From: Joe <jkamm@shreve.net> > To: tech@shreve.net > Subject: compaq Rockwell HCF modems > > > the main file area for the Rockwell HCF modem at compaq > http://www.compaq.com/athome/support/softpaq/pages/sp8897.html > > SUPERSEDES: SP7953 > > DESCRIPTION: Unpacks files that are used with the Presario models > mentioned above to upgrade the drivers in the integrated modem. > The new driver version is 2.1.2.134. FWIW, we just had two customers over the past 2 days try to upgrade their Compaq modems running 2.1.2.120.1 with SoftPaq 8897, and the modem died and became unresponsive after the upgrade. Trying to re-upgrade the modem or trying to uninstall/reinstall failed. As of yet have not heard if Compaq has been able to help them, as there really wasn't much more we could do. HCFs running 2.1.2.120.1 and 2.1.2.134.* are total hell trying to get to work on our PM3s too, usually wind up forcing to V.34 with +MS=V34. So far we haven't had any reports of problems with HCF's dialing into our POP with a USR TC (DSP 1.2.60), that could be because we don't have that many dialing with HCFs there, or customers not reporting problems even after we solicited for problem reports for two weeks. --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net 918-967-2858 Give a man a fish, he eats for a day; Teach a man to fish, he eats for a lifetime; Enlighten him further, and he opens a chain of seafood restaurants
Subject: Re: (usr-tc) Hiper DSP T1/PRI 1.2.43 Service Release
From: Charles Sprickman <spork@inch.com>
Date: 1999-04-03 12:20:34
Just a quick positive comment to the folks doing the doc work there: Everything (including the release notes) has gotten much, much better than the old Netserver days. I was shocked to see instructions on how to download code using a MIB browser and tftp. Very nice, very complete. Throw them boys in the docs department a party, they've been doing great work! Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Fri, 2 Apr 1999, David Bachta wrote: > > > > 3Com Carrier Customer Support has posted HiPer DSP T1/PRI Service Release > version 1.2.43 on the Totalservice technical support web site. > > This release will be available for download, free-of-charge, through the end > of May, 1999. > > Version 1.2.43 is an effort to combine many previous Engineering Releases > into a generally available code > release. It addresses a series of P1 and P2 issues identified with previous > HiPer DSP code release. > > It can be accessed in either of the following locations: > > http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+latest > ( posted under Total Control Hubs ) > or > http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+software > ( search by Total Control Hubs : Hiper DSP ) > > > For a list of the issues addressed in this Service Release please review the > Service Release Note, 24209600.pdf. The release note is posted along side > the code on the Totalservice website. The release note is also available > bundled with the code in the file hd010243.zip. > > Regards, > > David Bachta > Network Engineer > 3Com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Hiper code 4.1.59-6 and Quads
From: pferraro@wna-linknet.com
Date: 1999-04-03 14:26:17
Has anyone noticed any improvements or problems while running the HiperArc code 4.1.59-6 in a quad modem configuration? We currently have version 4.1.72-4 on the HiperArc and want to push it up to 4.1.59-6, but not sure if it will create more problems than it would fix! Any comments appreciated! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
Subject: (usr-tc) USR/3com OFFICIAL dictionary
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-04-04 00:35:24
Can someone mail me a CURRENT dictionary. I would prefer no personal modifications or fixes for that matter but the one they actually ship to customers today. I checked for max_channels in a Cistron Radius dict today and did not find it so I would like to start from scratch with something more up to date. Thank you in advance, Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com
Subject: (usr-tc) Disconnect problem on first call only
From: Brian Elfert <brian@citilink.com>
Date: 1999-04-04 10:59:18
I'm running quad modems with the V.90 code from last spring. I have two or three customers who claim they get disconnected on the first call after a few minutes, but when they call back right away, they can connect as long as they want. I'm running CT1s. The hunt group chooses the channel that is idle the longest to use. The likelyhood of someone hitting the same chassis on a second call is about 25%, and the likelyhood of hitting the same modem is basically 0%. Any ideas why this might happen? Brian
Subject: (usr-tc) V.90 code for Managed MP/16 V.34+
From: Jose Roberto Bulcao <bulcao@rio.com.br>
Date: 1999-04-04 12:28:41
Does anybody know if 3Com is planning to release V.90 firmware to the Managed MP/16 V.34+ modems? If not, is there any firmware newer then v.2.0.8? I think there was a US only V.90 Beta program to analog MP/16 v.90 code but don't know if it was for the Managed boxes or not. Anyway, it seems to be withdrawn (at least I can't see this entry anymore in totalservice). Tks, Jose Roberto Bulcao - RioLink Internet Tel : (021) 577-8899 e-mail : bulcao@rio.com.br
Subject: Re: (usr-tc) V.90 code for Managed MP/16 V.34+
From: Michael R. Gile <gilem@wsg.net>
Date: 1999-04-05 00:45:01
My guess is not. The US v.90 code was/is very buggy. So much so, that when a call hung up on one port, it reset the modem causing the other BRI channel to disconnect as well. When I spoke last with 3com tech support (last week), they indicated that these boxen will be discontinued soon, and continued support was questionable at best. *step up on i-modem^H^H^H^H^H^Hsoapbox* After this experience, we are planning on avoiding ALL 3com/USR products in the future. It has been almost a year since our purchase of these units, and despite the promises of v.90 compatibility, it has still not been delivered in a useful form. Companies which pull this bait-and-switch should not be tolerated. *step down* -Mike At 12:28 PM 4/4/1999 -0200, you wrote: >Does anybody know if 3Com is planning to release V.90 firmware to the >Managed MP/16 V.34+ modems? If not, is there any firmware newer then >v.2.0.8? >I think there was a US only V.90 Beta program to analog MP/16 v.90 code >but don't know if it was for the Managed boxes or not. Anyway, it seems to >be withdrawn (at least I can't see this entry anymore in totalservice). > >Tks, > >-------------------------------------- >Jose Roberto Bulcao - RioLink Internet >Tel : (021) 577-8899 >e-mail : bulcao@rio.com.br > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. ====================================================== Michael Gile gilem@wsg.net President (518)435-0682 Web Services Group http://www.wsg.net/
Subject: (usr-tc)Syslog info
From: Mark Starr <squid@greenapple.com>
Date: 1999-04-05 09:06:36
Hello, I have set up the primary syslog server on all my hiper hubs. When a user loga in, it sends over 3 lines, call coming in, id verified, call complete. But it does NOT send over the IP assigned to the call. Thus is can not go back and track a call from IP to user. I have set the level to verbose even and get tons of stuff, but no IP. Any ideas on how to get the IP over to the syslog machine? Thanks, Mark Green Apple Inc
Subject: Re: (usr-tc) Surplus HiPerARC?
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-05 09:57:33
Currently I am out of stock on these cards but I do come across them. I will be in touch when I come across more:) Do have total control units (No hyper chassis), mp, netservers, total switches. At 06:11 PM 4/5/99 +1000, you wrote: > >Hi All, > >Anyone got any surplus HiPerARC cards? > >I'm kicking tyres at the moment to see what's about and at what price. I >seem to remember some of you have surplus cards from various trade-up >deals... > >Regards, > >Bob Purdon, >Technical Manager (Tas/Vic), >Southern Internet Services. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Steve Rivera sales@wrca.net Check out product information and inventory. http://www.wrca.net(All New 3/22/99) 732-833-2111 ''''''''''''''''''''''''''''''''''''''''''''''' De-installed ISP,CLEC,LEC Net-Hardware Wanted ' '''''''''''''''''''''''''''''''''''''''''''''''
Subject: RE: (usr-tc) Surplus HiPerARC?
From: John Verreault <verreaul@aei.ca>
Date: 1999-04-05 11:10:37
How much are you asking for the TC units (and which chassis' are they)??? Reply direct Thanks John@aei.ca > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera > Sent: Monday, April 05, 1999 9:58 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Surplus HiPerARC? > > > Currently I am out of stock on these cards but I do come across them. I > will be in touch when I come across more:) > > Do have total control units (No hyper chassis), mp, netservers, total > switches. > > > At 06:11 PM 4/5/99 +1000, you wrote: > > > >Hi All, > > > >Anyone got any surplus HiPerARC cards? > > > >I'm kicking tyres at the moment to see what's about and at what price. I > >seem to remember some of you have surplus cards from various trade-up > >deals... > > > >Regards, > > > >Bob Purdon, > >Technical Manager (Tas/Vic), > >Southern Internet Services. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > Steve Rivera sales@wrca.net > Check out product information and inventory. > http://www.wrca.net(All New 3/22/99) > 732-833-2111 > ''''''''''''''''''''''''''''''''''''''''''''''' > De-installed ISP,CLEC,LEC Net-Hardware Wanted ' > ''''''''''''''''''''''''''''''''''''''''''''''' > > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Surplus HiPerARC?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-05 11:11:09
Bob Purdon said once upon a time: >Anyone got any surplus HiPerARC cards? > >I'm kicking tyres at the moment to see what's about and at what price. I >seem to remember some of you have surplus cards from various trade-up >deals... I've got one, maybe two. No idea on what I'd ask for them.
Subject: (usr-tc) FS:USR TC / Hiper ARC combo
From: C Thompson <cthompson@wingnet.net>
Date: 1999-04-05 12:09:27
We are looking at the possiblity of selling one of our USR/3com Total Control racks. Specs are as follows: Rackmount chassis Integrated fan tray 1 70 amp PS 1 NMC with memory upgrade 1 Dual PRI/T1 card 12 digital/analog quad modem cards 1 Hiper ARC card (relatively new) Asking price = $7500 Contact me if interested, or if you wish to register a bid. Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Suicide is the most sincere form of self-criticism.
Subject: (usr-tc) RIP updates on assigned pool
From: Brian Elfert <brian@citilink.com>
Date: 1999-04-05 13:02:21
For some reason, some of my Netservers (All running 3.7.24) won't broadcast any IPs in their assigned pool via RIP (v1). They will broadcast static IPs not in the assigned pool. Any ideas? On the Cisco, I can see updates coming in, but none from any of the IP pools on some of the Netservers. Brian
Subject: Re: (usr-tc) Disconnect problem on first call only
From: Carl Jagerski <carll@forcomm.net>
Date: 1999-04-05 13:15:06
See if they are Rockwell HCF modems. If they are, that would explain it all. If your customers are trying to load IE or Mail during the initial load, it puts too much usage on the processor and slows the modem down . Why are they making modems cheaper when most people use them? It's the weakest link in the chain now. At 10:59 AM 4/4/99 -0500, you wrote: >I'm running quad modems with the V.90 code from last spring. > >I have two or three customers who claim they get disconnected on the first >call after a few minutes, but when they call back right away, they can >connect as long as they want. > >I'm running CT1s. The hunt group chooses the channel that is idle the >longest to use. The likelyhood of someone hitting the same chassis on a >second call is about 25%, and the likelyhood of hitting the same modem is >basically 0%. > >Any ideas why this might happen? > >Brian > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Carl Jagerski Network Administrator, Forward Communications carll@forcomm.net 412-378-4490 Fax: 412-375-0156
Subject: RE: (usr-tc) PRI on AMI encoding
From: matthews <matthews@brunnet.net>
Date: 1999-04-05 14:29:25
I was told by a tech at USR that for a PRI you MUST use B8ZS and ESF. That's the only thing I use so I don't know from personal experience whether that's correct or not. On Friday, April 02, 1999 11:11 PM, Chris [SMTP:hender@rconnect.com] wrote: > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest versions of the code on both. Setting this up for PRI, phone company has a DMS100 and the are running D4 and AMI on the line at 56k. Has anyone had any luck setting a PRI up on D4 and AMI or is this just not gonna work? I've spent hours on the phone with the telco and have talked to 3com and have had mixed answers from them as to whether it will work, they start off telling me it will work and then whittle it down to it won't work. Seems like every question I ask they say, "Yeah it'll do that just fine" and then I call back when I'm having trouble and they try some things and then after a while decide that its not gonna work. Any one out there have any input on whether or not this will work. The telco is leasing the fiber from another telco so it is going to be a pain to get it switched over to ESF and B8ZS. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) HiPer gone wacko!
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-05 16:37:10
HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems connecting with varied error messages, messages coming through my console ARC connection are misspelled or missing letters. Reboot hasn't helped. Here's an example of console messages coming through during the reboot: HiPer enabling networks on rfaces.... Configuring Networrvices..... Starting the CLI...... Please Waor Prompt... Running; ARC 4.1.72 NMC 5.5.5 DSP 1.2.5 Has my ARC gone bad, or is there something else I can try that may correct this? Thanks, A frustrated Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) HiPer gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-05 17:01:02
You will probably want to upgrade to latest code. Current code is now 4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90 connectivity. This combination seems to be very stable. As for this exact issue that you are experiencing, if the reboot does not fix it, it is usually time to re-flash the code. Since you are in need of an upgrade this is a good time to do this. If you don't have this code, please send me a email, I will forward it to you. Todd ;-} K Mitchell <mitch@keyconn.net> on 04/05/99 03:37:10 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems connecting with varied error messages, messages coming through my console ARC connection are misspelled or missing letters. Reboot hasn't helped. Here's an example of console messages coming through during the reboot: HiPer enabling networks on rfaces.... Configuring Networrvices..... Starting the CLI...... Please Waor Prompt... Running; ARC 4.1.72 NMC 5.5.5 DSP 1.2.5 Has my ARC gone bad, or is there something else I can try that may correct this? Thanks, A frustrated Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) HiPer gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-05 17:10:52
Resetting a card by using Dip switch number 5 is usually a good idea, but unfortunately the Hyper ARC does not have a Dip # 5. Re-flashing with current code via either the Total Control Manager, or Z-modem transfer from the Console are the preferred methods. TFTP will also work, bu then you must expand the file (rename the file to netserve.dmf and then reboot). If all else fails, you can always call us in tech support (800) 231-8770. Todd ;-} Paul Farber <farber@admin.f-tech.net> on 04/05/99 04:48:31 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) Try restoring the firmware from the factory default? I think it's sw 5 to on, then reboot. Maybe replace the SIMM module? Or send it back for warranty repair? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 5 Apr 1999, K Mitchell wrote: > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems > connecting with varied error messages, messages coming through my console > ARC connection are misspelled or missing letters. Reboot hasn't helped. > Here's an example of console messages coming through during the reboot: > HiPer enabling networks on rfaces.... > > Configuring Networrvices..... > > Starting the CLI...... > Please Waor Prompt... > > Running; > ARC 4.1.72 > NMC 5.5.5 > DSP 1.2.5 > Has my ARC gone bad, or is there something else I can try that may correct > this? > > Thanks, > A frustrated Kirk > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) HiPer gone wacko!
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-05 17:28:08
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister |Sent: Monday, April 05, 1999 5:11 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) HiPer gone wacko! | | | | | Resetting a card by using Dip switch number 5 is usually a good idea, but |unfortunately the Hyper ARC does not have a Dip # 5. It has one. It just doesnt have anything to do with clearing the flash. You do get a boot menu on console before the code image loads. An option exists there to clear the configs. If your going to do that, and you are not running the latest code. You might as well do the zmodem transfer and format the flash in the process. From the console. After the Boot ROM version prompt there is a delay. During that delay you can type "AT{ZF}" this is case sensative. Then begin the zmodem transfer of the code. -M
Subject: RE: (usr-tc) HiPer gone wacko!
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-05 17:28:08
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Todd Keister |Sent: Monday, April 05, 1999 5:11 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) HiPer gone wacko! | | | | | Resetting a card by using Dip switch number 5 is usually a good idea, but |unfortunately the Hyper ARC does not have a Dip # 5. It has one. It just doesnt have anything to do with clearing the flash. You do get a boot menu on console before the code image loads. An option exists there to clear the configs. If your going to do that, and you are not running the latest code. You might as well do the zmodem transfer and format the flash in the process. From the console. After the Boot ROM version prompt there is a delay. During that delay you can type "AT{ZF}" this is case sensative. Then begin the zmodem transfer of the code. -M
Subject: Re: (usr-tc) HiPer gone wacko!
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-05 17:35:13
On Mon, 5 Apr 1999, K Mitchell wrote: >HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems >connecting with varied error messages, messages coming through my console >ARC connection are misspelled or missing letters. Reboot hasn't helped. >Here's an example of console messages coming through during the reboot: >HiPer enabling networks on rfaces.... > >Configuring Networrvices..... > >Starting the CLI...... >Please Waor Prompt... ... Umm, reseat the card (front and back) and if that does nothing, try reflashing the card from the console port with the AT{ZF}??? command to reformat the flash. The test ARC did that once, but that was because the NIC wasn't screwed down. --Ricky
Subject: Re: (usr-tc) HiPer gone wacko!
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-05 17:48:31
Try restoring the firmware from the factory default? I think it's sw 5 to on, then reboot. Maybe replace the SIMM module? Or send it back for warranty repair? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 5 Apr 1999, K Mitchell wrote: > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems > connecting with varied error messages, messages coming through my console > ARC connection are misspelled or missing letters. Reboot hasn't helped. > Here's an example of console messages coming through during the reboot: > HiPer enabling networks on rfaces.... > > Configuring Networrvices..... > > Starting the CLI...... > Please Waor Prompt... > > Running; > ARC 4.1.72 > NMC 5.5.5 > DSP 1.2.5 > Has my ARC gone bad, or is there something else I can try that may correct > this? > > Thanks, > A frustrated Kirk > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Surplus HiPerARC?
From: Bob Purdon <bobp@southcom.com.au>
Date: 1999-04-05 18:11:54
Hi All, Anyone got any surplus HiPerARC cards? I'm kicking tyres at the moment to see what's about and at what price. I seem to remember some of you have surplus cards from various trade-up deals... Regards, Bob Purdon, Technical Manager (Tas/Vic), Southern Internet Services.
Subject: Re: (usr-tc) PRI on AMI encoding
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-05 18:21:14
It's just not gonna work. PRI requires ESF/B8ZS, period. I'm kinda surprised the telco didn't know that... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Fri, 2 Apr 1999, Chris wrote: > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest > versions of the code on both. Setting this up for PRI, phone company > has a DMS100 and the are running D4 and AMI on the line at 56k. Has > anyone had any luck setting a PRI up on D4 and AMI or is this just not > gonna work? I've spent hours on the phone with the telco and have > talked to 3com and have had mixed answers from them as to whether it > will work, they start off telling me it will work and then whittle it > down to it won't work. Seems like every question I ask they say, "Yeah > it'll do that just fine" and then I call back when I'm having trouble > and they try some things and then after a while decide that its not > gonna work. Any one out there have any input on whether or not this > will work. The telco is leasing the fiber from another telco so it is > going to be a pain to get it switched over to ESF and B8ZS.
Subject: Re: (usr-tc) PRI on AMI encoding
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-05 18:21:14
It's just not gonna work. PRI requires ESF/B8ZS, period. I'm kinda surprised the telco didn't know that... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Fri, 2 Apr 1999, Chris wrote: > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest > versions of the code on both. Setting this up for PRI, phone company > has a DMS100 and the are running D4 and AMI on the line at 56k. Has > anyone had any luck setting a PRI up on D4 and AMI or is this just not > gonna work? I've spent hours on the phone with the telco and have > talked to 3com and have had mixed answers from them as to whether it > will work, they start off telling me it will work and then whittle it > down to it won't work. Seems like every question I ask they say, "Yeah > it'll do that just fine" and then I call back when I'm having trouble > and they try some things and then after a while decide that its not > gonna work. Any one out there have any input on whether or not this > will work. The telco is leasing the fiber from another telco so it is > going to be a pain to get it switched over to ESF and B8ZS.
Subject: Re: (usr-tc) HiPer gone wacko!
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-05 18:36:07
That was a cure for the NMC card I had go bad once.... since it has been about 8 months since any hardware went bad, I may be FUBAR. I never really liked that console flash idea. Every new NMC seems to go out empty, and if you run a Linix shop.. finding a windows machine to flash a card is a minor pain in the rear. If you'all (3Com) released the code I'm sure an enterprising individual would port it for you. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 5 Apr 1999, Todd Keister wrote: > > > Resetting a card by using Dip switch number 5 is usually a good idea, but > unfortunately the Hyper ARC does not have a Dip # 5. > > Re-flashing with current code via either the Total Control Manager, or > Z-modem transfer from the Console are the preferred methods. TFTP will also > work, bu then you must expand the file (rename the file to netserve.dmf and then > reboot). > > If all else fails, you can always call us in tech support (800) 231-8770. > > Todd ;-} > > > > > > Paul Farber <farber@admin.f-tech.net> on 04/05/99 04:48:31 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Todd Keister/MW/US/3Com) > Subject: Re: (usr-tc) HiPer gone wacko! > > > > > Try restoring the firmware from the factory default? I think it's sw 5 to > on, then reboot. Maybe replace the SIMM module? Or send it back for > warranty repair? > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Mon, 5 Apr 1999, K Mitchell wrote: > > > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems > > connecting with varied error messages, messages coming through my console > > ARC connection are misspelled or missing letters. Reboot hasn't helped. > > Here's an example of console messages coming through during the reboot: > > HiPer enabling networks on rfaces.... > > > > Configuring Networrvices..... > > > > Starting the CLI...... > > Please Waor Prompt... > > > > Running; > > ARC 4.1.72 > > NMC 5.5.5 > > DSP 1.2.5 > > Has my ARC gone bad, or is there something else I can try that may correct > > this? > > > > Thanks, > > A frustrated Kirk > > > > > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > > Keystone Connect http://www.keyconn.net > > Altoona, PA 814-941-5000 We Unlock the World > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) HiPer gone wacko!
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-05 18:36:07
That was a cure for the NMC card I had go bad once.... since it has been about 8 months since any hardware went bad, I may be FUBAR. I never really liked that console flash idea. Every new NMC seems to go out empty, and if you run a Linix shop.. finding a windows machine to flash a card is a minor pain in the rear. If you'all (3Com) released the code I'm sure an enterprising individual would port it for you. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 5 Apr 1999, Todd Keister wrote: > > > Resetting a card by using Dip switch number 5 is usually a good idea, but > unfortunately the Hyper ARC does not have a Dip # 5. > > Re-flashing with current code via either the Total Control Manager, or > Z-modem transfer from the Console are the preferred methods. TFTP will also > work, bu then you must expand the file (rename the file to netserve.dmf and then > reboot). > > If all else fails, you can always call us in tech support (800) 231-8770. > > Todd ;-} > > > > > > Paul Farber <farber@admin.f-tech.net> on 04/05/99 04:48:31 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Todd Keister/MW/US/3Com) > Subject: Re: (usr-tc) HiPer gone wacko! > > > > > Try restoring the firmware from the factory default? I think it's sw 5 to > on, then reboot. Maybe replace the SIMM module? Or send it back for > warranty repair? > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Mon, 5 Apr 1999, K Mitchell wrote: > > > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems > > connecting with varied error messages, messages coming through my console > > ARC connection are misspelled or missing letters. Reboot hasn't helped. > > Here's an example of console messages coming through during the reboot: > > HiPer enabling networks on rfaces.... > > > > Configuring Networrvices..... > > > > Starting the CLI...... > > Please Waor Prompt... > > > > Running; > > ARC 4.1.72 > > NMC 5.5.5 > > DSP 1.2.5 > > Has my ARC gone bad, or is there something else I can try that may correct > > this? > > > > Thanks, > > A frustrated Kirk > > > > > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > > Keystone Connect http://www.keyconn.net > > Altoona, PA 814-941-5000 We Unlock the World > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) PRI on AMI encoding
From: Brian <signal@shreve.net>
Date: 1999-04-05 19:52:26
On Fri, 2 Apr 1999, Chris wrote: > I am setting up a chassis with an ARC and 2 HiperDSP's. Latest > versions of the code on both. Setting this up for PRI, phone company > has a DMS100 and the are running D4 and AMI on the line at 56k. Has > anyone had any luck setting a PRI up on D4 and AMI or is this just not > gonna work? I've spent hours on the phone with the telco and have Everything we run is b8zs/ESF. I have also seen lines run up in AMI/ESF. > talked to 3com and have had mixed answers from them as to whether it > will work, they start off telling me it will work and then whittle it > down to it won't work. Seems like every question I ask they say, "Yeah > it'll do that just fine" and then I call back when I'm having trouble > and they try some things and then after a while decide that its not > gonna work. Any one out there have any input on whether or not this > will work. The telco is leasing the fiber from another telco so it is > going to be a pain to get it switched over to ESF and B8ZS. > any reason the telco insists on d4/ami? > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) HiPer gone wacko!
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-05 20:00:51
On Mon, 5 Apr 1999, Paul Farber wrote: >I never really liked that console flash idea. Every new NMC seems to go >out empty, and if you run a Linix shop.. finding a windows machine to >flash a card is a minor pain in the rear. Not really... the flash process is just some fancy SNMP-ness. Has anyone tried running TCM via WINE? (I'll have to reboot to windows to install it before I can test...) --Ricky
Subject: (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation
From: Stefanita Vilcu <vsv@dnt.ro>
Date: 1999-04-05 20:07:52
Hi folks, I wonder if someone of you can tell me how can I setup an TC chassis for leased line operation. I want that the phone line to be plugged in an Analog Quad Modem and the modem "to be connected" in a speciffic interface from the HiperArc. The ARC will be configured to make ppp over that line, with no authentication, and give the same IP address every time. Of course that modem will not be available for the dual E1 card. Thank you, Stefanita Vilcu, Network Administrator - Dynamic Network Technologies, Bucharest, Romania vsv@dnt.ro
Subject: Re: (usr-tc) HiPer gone wacko!
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-05 20:12:22
On Mon, 5 Apr 1999, Paul Farber wrote: >If you'all (3Com) released the code I'm sure an enterprising individual >would port it for you. I've offered to do it for two years... all I ever managed to get was the RADIUS server source (well, there were real reasons for that tho' -- we had to have UNIX crypt()ed password support and USR wouldn't spent 5 minutes to add it to the scripting language; something so damned simple and they refused to do it. Over a year later (after I did it for them) they finally released SA6 with crypt() password capability -- "unsupported" tho'.) --Ricky PS: I will add, their build environment even two years ago had support for building linux targets. PPS: Something tells me TCM-UNIX is headed to look much more like TCM-WIN in the same fashion as HARM. (A serious error in my opinion. I've never liked seeing windows programs shoe-spooned as UNIX programs.)
Subject: Re: (usr-tc) HiPer gone wacko!
From: David Bolen <db3l@ans.net>
Date: 1999-04-05 20:36:46
Ricky Beam <jfbeam@beaker.interpath.net> writes: > Not really... the flash process is just some fancy SNMP-ness. Not the SDL-1 (non-Hiper) console flash process - that's a separate protocol. So if you've got an NMC without code, you have to perform the console process using PCSDL for which the only officially supported platform at this point is DOS/Windows. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) HiPer gone wacko!
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-05 20:39:33
Thus spake Ricky Beam >On Mon, 5 Apr 1999, Paul Farber wrote: >>I never really liked that console flash idea. Every new NMC seems to go >>out empty, and if you run a Linix shop.. finding a windows machine to >>flash a card is a minor pain in the rear. >Not really... the flash process is just some fancy SNMP-ness. Has anyone >tried running TCM via WINE? (I'll have to reboot to windows to install >it before I can test...) Have never bothered downloading it to my home box...I think I'll give it a shot and see what happens...I'll let ya know. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) HiPer gone wacko!
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-05 20:56:52
Thus spake Ricky Beam >On Mon, 5 Apr 1999, Paul Farber wrote: >>I never really liked that console flash idea. Every new NMC seems to go >>out empty, and if you run a Linix shop.. finding a windows machine to >>flash a card is a minor pain in the rear. >Not really... the flash process is just some fancy SNMP-ness. Has anyone >tried running TCM via WINE? (I'll have to reboot to windows to install >it before I can test...) For what its worth...I didn't try very hard, but it wouldn't run the installation...puked out looking for _ISRES.DLL and _SETUP.DLL (with that same case even) even though they were in the same directory (with the same case...all caps)... Anyway...I haven't mucked with wine too much, but I don't have a great need for TCM, so its not a big deal for me. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) HiPer gone wacko!
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-05 21:14:35
On Mon, 5 Apr 1999, David Bolen wrote: >Not the SDL-1 (non-Hiper) console flash process - that's a separate >protocol. So if you've got an NMC without code, you have to perform >the console process using PCSDL for which the only officially >supported platform at this point is DOS/Windows. Dead NMC... oh, well, that's different then. And no, DOSEMU doesn't work either -- PCSDL wants hardware access to the serial port. Then again, if the NMC is hosed, you really are screwed :-( I will also note, you cannot plug the broken NMC into another chassis to SNMP flash it as NMC cards don't work too well outside of slot 17. (In fact, two functional NMCs in one chassis will lock both cards up.) --Ricky
Subject: Re: (usr-tc) HiPer gone wacko!
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-05 21:18:04
On Mon, 5 Apr 1999, Jeff Mcadams wrote: >>Not really... the flash process is just some fancy SNMP-ness. Has anyone >>tried running TCM via WINE? (I'll have to reboot to windows to install >>it before I can test...) > >For what its worth...I didn't try very hard, but it wouldn't run the >installation...puked out looking for _ISRES.DLL and _SETUP.DLL (with >that same case even) even though they were in the same directory (with >the same case...all caps)... As I said, I'd have to run windows to INSTALL it. It needs some windows fancy loopback file/directory thing (samba has trouble with this too.) Once it's installed, it might actually "work" -- winzip95 ran with some slight problems (the file open dialog box had not backing or border... funny to see buttons just floating on the screen.) --Ricky
Subject: (usr-tc) RE: (USR-TC) PRI ON AMI E
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-04-06 08:29:00
To get a 64kbs you must run B8ZS, otherwise the D channel runs at 56kbs. As for ESF, it isn't technically required to run PRIs but generally telcos provision it that way as a general course of business. The biggest advantage is troubleshooting. Jeff Binkley ASA Network Computing U>On Fri, 2 Apr 1999, Chris wrote: U>> I am setting up a chassis with an ARC and 2 HiperDSP's. Latest U>> versions of the code on both. Setting this up for PRI, phone company U>> has a DMS100 and the are running D4 and AMI on the line at 56k. Has U>> anyone had any luck setting a PRI up on D4 and AMI or is this just U>> not gonna work? I've spent hours on the phone with the telco and U>> have U>Everything we run is b8zs/ESF. I have also seen lines run up in U>AMI/ESF. U>> talked to 3com and have had mixed answers from them as to whether it U>> will work, they start off telling me it will work and then whittle U>> it down to it won't work. Seems like every question I ask they say, U>> "Yeah it'll do that just fine" and then I call back when I'm having U>> trouble and they try some things and then after a while decide that U>> its not gonna work. Any one out there have any input on whether or U>> not this will work. The telco is leasing the fiber from another U>> telco so it is going to be a pain to get it switched over to ESF and U>> B8ZS. U>any reason the telco insists on d4/ami? U>> - U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U>> with "unsubscribe usr-tc" in the body of the message. U>> For information on digests or retrieving files and old messages U>> send "help" to the same address. Do not use quotes in your U>> message. U>----------------------------------------------------- U>Brian Feeny (BF304) signal@shreve.net U>318-222-2638 x 109 http://www.shreve.net/~signal U>Network Administrator ShreveNet Inc. (ASN 11881) U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. U> CMPQwk 1.42 9999
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-06 09:39:33
At 05:01 PM 4/5/99 -0500, you wrote: > > You will probably want to upgrade to latest code. Current code is now >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90 >connectivity. This combination seems to be very stable. As for this exact >issue that you are experiencing, if the reboot does not fix it, it is usually >time to re-flash the code. Since you are in need of an upgrade this is a good >time to do this. > If you don't have this code, please send me a email, I will forward it to >you. I appreciate all of the helpful replies. Fortunately the problem turned out to be somewhat less serious than the replies anticipated. Being on my way out the door to a "You can't be late under any circumstances" appointment, I failed to complete a thorough besic check before panicing. The problem turned out to be the console cable slipping out of the null-modem adaptor. Reaffixing it firmly has everything showing up fine again, apparently the user connection problems were an unrelated concidence that were all solved by routine configuration reviews. This does bring up another question though. Has anybody been running the combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not it is worth upgrading to? I know there had been reported problems with the 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working fairly well, so I've been hesitant to change it. Thanks again, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) HiPer gone wacko!
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-06 09:49:37
On Mon, 5 Apr 1999, Ricky Beam wrote: > On Mon, 5 Apr 1999, David Bolen wrote: > >Not the SDL-1 (non-Hiper) console flash process - that's a separate > >protocol. So if you've got an NMC without code, you have to perform > >the console process using PCSDL for which the only officially > >supported platform at this point is DOS/Windows. > > Dead NMC... oh, well, that's different then. And no, DOSEMU doesn't work > either -- PCSDL wants hardware access to the serial port. > > Then again, if the NMC is hosed, you really are screwed :-( I will also note, > you cannot plug the broken NMC into another chassis to SNMP flash it as NMC > cards don't work too well outside of slot 17. (In fact, two functional NMCs > in one chassis will lock both cards up.) Do you have a unix machine around there - where you can set it up with a console to the nmc? krish > > --Ricky > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) HiPer gone wacko!
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-06 09:57:40
If you have access to the console - as soon as you reboot the card you will get a menu - one of the options in the menu is to erase router config. Trying erasing the router config, and see if that fixes the card. If that does not work then get the 4.1.59 -6 code from http://totalservice.usr.com Reboot the hiper arc card and as soon as you see the word "boot" using zmodem down loas the 4.1.59-6 code regards krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 5 Apr 1999, K Mitchell wrote: > HELP! Suddenly my HiPer chassis has gone wacko. Users are having problems > connecting with varied error messages, messages coming through my console > ARC connection are misspelled or missing letters. Reboot hasn't helped. > Here's an example of console messages coming through during the reboot: > HiPer enabling networks on rfaces.... > > Configuring Networrvices..... > > Starting the CLI...... > Please Waor Prompt... > > Running; > ARC 4.1.72 > NMC 5.5.5 > DSP 1.2.5 > Has my ARC gone bad, or is there something else I can try that may correct > this? > > Thanks, > A frustrated Kirk > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) HiperNMC
From: Brian <signal@shreve.net>
Date: 1999-04-06 10:19:56
I am sure this has been asked here before, but I don't recall.........so.........what is the Aux I/O connector on the back of the HiperNMC supposed to be used for? I tried hooking my stereo up to it, but I am unable to get the HDM's to do an equalization display (<-- just a joke, but it would be cool :) ). Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased line
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 1999-04-06 10:31:13
Hi , Below is the configuration on the setup which I tested, the Quad code in still in Beta (tcs3.5), Quad to HiPer ARC - 2 Wire Leased Line setup Total Control QUAD Analog/Digital Total Control HiPer ARC Courier V.Everything Quad Code: <: 6.0.4 DS> Courier Code: <;3.0.13> Hiper ARC Code: < 4.1.59> The following is how to configure the Courier modem to connect to the Quad modem and get login prompt from the ARC Configuration for Courier is as follows: Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on courier set to on, at&L1 &b1&n14&w also set the baud rate of the DTE to 115200 Configuration of the ARC Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes Configuration of the Quad analog/digital at&L1&B1&N14 ats47.5=1 ats56.6=0 ats0=0 DIP 5 off Regards Ray Whelan Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52 Please respond to usr-tc@lists.xmission.com cc: (Ray Whelan/IE/3Com) Hi folks, I wonder if someone of you can tell me how can I setup an TC chassis for leased line operation. I want that the phone line to be plugged in an Analog Quad Modem and the modem "to be connected" in a speciffic interface from the HiperArc. The ARC will be configured to make ppp over that line, with no authentication, and give the same IP address every time. Of course that modem will not be available for the dual E1 card. Thank you, Stefanita Vilcu, Network Administrator - Dynamic Network Technologies, Bucharest, Romania vsv@dnt.ro - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-06 11:07:02
Yes, there are a number of people who are running 4.1.59-6 and 1.2.43. This combination seems stable, and to resolve most V.90 issues. This is BIG improvement in connectivity, and the 4.1.59-6 addressed some 200 issues with 4.1.72-7 code you are running. The release notes on the web site list most of the fixes in this upgrade. In tech support we are asking all customers to go to this code combination. It seems very stable, and fixes a whole slew of issues, and finally puts to bed most of the V.90 issues. There are still a few modems that won't cooperate, but as long as the End Users (your customers) upgrade to current firmware, the should connect fine. If you have any questions, were always here (24x7x365)** Todd ;-} ** of course you do need a premium contract after 8pm central or on weekends / holidays..... K Mitchell <mitch@keyconn.net> on 04/06/99 08:39:33 AM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) At 05:01 PM 4/5/99 -0500, you wrote: > > You will probably want to upgrade to latest code. Current code is now >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90 >connectivity. This combination seems to be very stable. As for this exact >issue that you are experiencing, if the reboot does not fix it, it is usually >time to re-flash the code. Since you are in need of an upgrade this is a good >time to do this. > If you don't have this code, please send me a email, I will forward it to >you. I appreciate all of the helpful replies. Fortunately the problem turned out to be somewhat less serious than the replies anticipated. Being on my way out the door to a "You can't be late under any circumstances" appointment, I failed to complete a thorough besic check before panicing. The problem turned out to be the console cable slipping out of the null-modem adaptor. Reaffixing it firmly has everything showing up fine again, apparently the user connection problems were an unrelated concidence that were all solved by routine configuration reviews. This does bring up another question though. Has anybody been running the combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not it is worth upgrading to? I know there had been reported problems with the 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working fairly well, so I've been hesitant to change it. Thanks again, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-06 11:18:58
DSP 1.2.59 was worse than 1.2.60 for us, but 1.2.43 seems much better than either. The only problem with ARC 4.1.59-6 I've seen is FreePPP on MacOS can't reliably negotiate PPP for some reason (even with all the listed workarounds)... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Tue, 6 Apr 1999, K Mitchell wrote: > At 05:01 PM 4/5/99 -0500, you wrote: > > > > You will probably want to upgrade to latest code. Current code is now > >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90 > >connectivity. This combination seems to be very stable. As for this exact > >issue that you are experiencing, if the reboot does not fix it, it is usually > >time to re-flash the code. Since you are in need of an upgrade this is a > good > >time to do this. > > If you don't have this code, please send me a email, I will forward > it to > >you. > > I appreciate all of the helpful replies. Fortunately the problem turned > out to be somewhat less serious than the replies anticipated. Being on my > way out the door to a "You can't be late under any circumstances" > appointment, I failed to complete a thorough besic check before panicing. > The problem turned out to be the console cable slipping out of the > null-modem adaptor. Reaffixing it firmly has everything showing up fine > again, apparently the user connection problems were an unrelated concidence > that were all solved by routine configuration reviews. > This does bring up another question though. Has anybody been running the > combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not it > is worth upgrading to? I know there had been reported problems with the > 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working fairly > well, so I've been hesitant to change it. > > Thanks again, > Kirk > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) frequency probe data on DSP's
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-06 11:27:04
Quick question: Can someone tell me if any current DSP betas or ERs have fixed the frequency probe reporting? This is one of the big Quad features that's still missing from DSP's. Currently on Quads, you can get the ATY11 frequency probe information (on v.34 connects) via SNMP... on DSP's, all the numbers come up as zero. ATY11 works on DSP's, but that doesn't really help you when the user is online... This, plus a LOT of off-by-one problems with logging, traps, and SNMP, is largely what's stopping us from trading out all our Quads for DSP's. (That and the Quads still seem a bit better at dealing with some Winmodems.) Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: (usr-tc) Converting to digital T1's give slower v.34 connections
From: Randy McMillan <randy@pacinfo.com>
Date: 1999-04-06 12:13:58
We are converting our modem pool to all digital lines with TC chassis with quad modems and hiper ARC cards. Some people are connecting slower on the new lines than they did on the analog lines. One customer who got 33.6 or 31.2 speeds is now getting 28.8 or 26.4 speeds (with a zoom 2919 with current zoom firmware). He doesn't seem to be able to do v.90 protocol. The T1 lines seem to be clean as I can connect at 50k+ using v.90. If I disable v.90 on my sportster, I get 28.8 downstream and 33.6 upstream, but not 33.6 down. Of course customers only see the downstream connect speed. Does anybody know of any reasons why the v.34 speeds would be slower when terminated here on a T1 as opposed to a pots line on the same chassis? Or in regard to my sportster, is there anything in disabling v.90 that would disable the 31.2 & 33.6 speeds? Any info on this would be appreciated.. Randy McMillan PacInfo
Subject: RE: (usr-tc) HiPer operator gone wacko!
From: florin_neamtu@3com.com
Date: 1999-04-06 12:36:42
That's correct. 1.2.43 is only for T1/PRI. The latest code for E1 is 1.2.59, available for download free of charge through the end of April from Totalservice site. Regards, Florin N.
Subject: (usr-tc) Alarm server sought
From: Brian <signal@shreve.net>
Date: 1999-04-06 12:39:54
Can anyone recommend a good alarm server/system for Unix to use with the Total Controls? I want to capture a mutlitude of traps from the chassis. The only one I am aware of is trapd(?) which is part of the cmu and/or ucd snmp packages. It would be a big plus if it could log/update a database, but even if it can't I can always grok the data from flat file and put it into a database. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) Total Control Parameter Reference
From: Brian <signal@shreve.net>
Date: 1999-04-06 12:49:43
Where can one get the latest Parameter Reference? The last one I have is 4.3, back from the days when 3Com would actually ship you a printed version with every purchase. I plan to print the latest and spiral bound it. Do I really need to look at doing queries to the HiperARC btw? I am use to the days when you could get most of diagnostic info (errors, alarms, etc) from the nmc. If I need to look at the HiperARC as well, where is the document that documents all its MIB(s) like the parameter reference does for the NMC? Also, has anyone made a list of traps or mibs to monitor that is a pretty good mix for diagnostics/early detection of problems? I am thinking things like LBE's for all the spans, loss of d channels, out of service conditions, BPV's on the spans etc. It would also be helpful to do graphs/stats on things like: min/max/average connect speed per modem/span/chassis etc Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-06 13:16:29
At 11:07 AM 4/6/99 -0500, "Todd Keister" <Todd_Keister@mw.3com.com> wrote: > > Yes, there are a number of people who are running 4.1.59-6 and 1.2.43. >This combination seems stable, and to resolve most V.90 issues. This is BIG >improvement in connectivity, and the 4.1.59-6 addressed some 200 issues with >4.1.72-7 code you are running. The release notes on the web site list most Nothing personal Todd, but I've been bitten by code upgrades before, that have been praised by 3Com as the fix to many problems. A number of these upgrades have resulted in more problems than they've fixed. The performance of these upgrades doesn't have the direct impact on day-to-day business for 3Com that it does for ISPs. Being small, I've learned to wait a couple of weeks and hear from bigger ISPs that are using an upgrade in production before I jump into an upgrade myself. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Total Control Parameter Reference
From: Jim Curran <jim_curran@mw.3com.com>
Date: 1999-04-06 13:19:24
Brian, As to your first question, I will defer to my colleague who wrote the Parameter Reference. But about the traps & MIB objects to monitor, we have an ISP Network Management Guide available at this URL that aims to answer your questions: ftp://totalservice.usr.com/pub/.docs/ispmgt.pdf Please let me know if it is helpful to you. Jim Curran jim_curran@mw.3com.com Please respond to usr-tc@lists.xmission.com cc: (Jim Curran/MW/US/3Com) Where can one get the latest Parameter Reference? The last one I have is 4.3, back from the days when 3Com would actually ship you a printed version with every purchase. I plan to print the latest and spiral bound it. Do I really need to look at doing queries to the HiperARC btw? I am use to the days when you could get most of diagnostic info (errors, alarms, etc) from the nmc. If I need to look at the HiperARC as well, where is the document that documents all its MIB(s) like the parameter reference does for the NMC? Also, has anyone made a list of traps or mibs to monitor that is a pretty good mix for diagnostics/early detection of problems? I am thinking things like LBE's for all the spans, loss of d channels, out of service conditions, BPV's on the spans etc. It would also be helpful to do graphs/stats on things like: min/max/average connect speed per modem/span/chassis etc Brian
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-06 14:04:48
Thus spake K Mitchell >At 11:07 AM 4/6/99 -0500, "Todd Keister" <Todd_Keister@mw.3com.com> >wrote: >>Yes, there are a number of people who are running 4.1.59-6 and 1.2.43. >>This combination seems stable, and to resolve most V.90 issues. This >>is BIG improvement in connectivity, and the 4.1.59-6 addressed some >>200 issues with 4.1.72-7 code you are running. The release notes on >>the web site list most > Nothing personal Todd, but I've been bitten by code upgrades before, > that have been praised by 3Com as the fix to many problems. I'm so glad to hear someone else say this, not just me. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Total Control Parameter Reference
From: Brian <signal@shreve.net>
Date: 1999-04-06 14:12:53
On Tue, 6 Apr 1999, Jim Curran wrote: > > > > Brian, > > As to your first question, I will defer to my colleague who wrote the Parameter > Reference. > > But about the traps & MIB objects to monitor, we have an ISP Network Management > Guide available at this URL that aims to answer your questions: > > ftp://totalservice.usr.com/pub/.docs/ispmgt.pdf > > Please let me know if it is helpful to you. > > Jim Curran > jim_curran@mw.3com.com It is :) I have downloaded that from the first time you posted it, and it is a nice peice of work. Hopefully 3Com will put even more energies into usefull documentation such as that, which I feel are very important. Brian > > > > > Please respond to usr-tc@lists.xmission.com > > To: USRobotics TC Mailing List <usr-tc@xmission.com> > cc: (Jim Curran/MW/US/3Com) > Subject: (usr-tc) Total Control Parameter Reference > > > > > > Where can one get the latest Parameter Reference? The last one I have is > 4.3, back from the days when 3Com would actually ship you a printed > version with every purchase. I plan to print the latest and spiral bound > it. > > Do I really need to look at doing queries to the HiperARC btw? I am use > to the days when you could get most of diagnostic info (errors, alarms, > etc) from the nmc. If I need to look at the HiperARC as well, where is > the document that documents all its MIB(s) like the parameter reference > does for the NMC? > > Also, has anyone made a list of traps or mibs to monitor that is a pretty > good mix for diagnostics/early detection of problems? I am thinking > things like LBE's for all the spans, loss of d channels, out of service > conditions, BPV's on the spans etc. It would also be helpful to do > graphs/stats on things like: > > min/max/average connect speed per modem/span/chassis > > etc > > Brian > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: David Bolen <db3l@ans.net>
Date: 1999-04-06 14:52:27
Jeff Mcadams <jeffm@iglou.com> writes: > I'm so glad to hear someone else say this, not just me. :) :-) I'll chime in too in agreement. But I think that, for better or worse, this is a general statement on most code for just about any hardware in our industry (or even computer hardware in general - how quickly does anyone install the latest Windows patches?) For our part, personal experience is always going to win out over vendor testing. So any new code gets lab time for specific testing, followed by burn-in testing at selected production sites for a reasonable period of time (generally 2 weeks for any proposed large scale deployment to catch any cyclical behavior) and reasonable call load before being accepted for general use. In that respect, I don't really care as much whether a code base is totally bug free (well, that's not true, I do care, but at times I have to be a realist) as much as whether or not there are any bugs that happen to get tickled in our specific environment. There's also the consideration that code with problems may still be acceptable in the absence of another choice if even with the problems, it's behaving better than the existing production code. But that holds for others as well, I expect. So even if some of the "larger" ISPs say something good or bad about a code, I'd still want to do my own testing, since their environment may not be totally representative of my own. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-06 16:16:28
Kirk: Since we have to take the calls, we very generally conservative about recommending upgrades. The reason I recommend it is the resolution of the V.90 issue, and an increase in stability over 4.1.72-7. This does NOT however imply you should ever implement an upgrade without testing. Networks are far more individualized than Snowflakes. What works on one network may have an issue on your network due some specific configuration, or unique grouping of devices with a specific configuration. The upshot: ALWAYS TEST NEW CODE!! PLEASE ( pretty please with sugar on top) We do NOT want to cause an issue on your production units. The other point you raise is equally valid. Do you have a valid business reason for this upgrade? If not, then don't upgrade. The reason I recommended this upgrade is most TC owners do want V.90 connectivity (I'm on the ISP Support team so this has been one of our most pressing issues). However, if you are a corporate user, and you have good connectivity, and no current issues, then you may not want to upgrade at this time. When in doubt, read the release notes, and see if there are any issues that affect you, or may affect you in the future. If so, then consider an upgrade, but only after your own reliability testing. We can test new code endlessly, and still not have tested the code in your environment. With all of this said, I still recommend you upgrade to the 4.1.59-6 combined with the 1.2.43 code. This code has been out since March 18th for the DSP code, and 4.1.59-6 was released on March 4th. After an upgrade to this code combination, every customer that I have spoken with reported an increase in connectivity, a reduction of V.90 complaints, and an increase in general system stability. But of course, "Your Milage May Vary." Please do note that we did release 4.1.59-1 in early February, and this code is different from the 4.1.59-6 that was released on March 4th. To determine exactly which code you have on a Harc type: _show ver and it gives the exact revision. Users of the 4.1.59-1 should upgrade to the 4.1.59-6 to resolve an issue with ISDN connectivity. Hope this answers your questions. Todd ;-} K Mitchell <mitch@keyconn.net> on 04/06/99 12:16:29 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) At 11:07 AM 4/6/99 -0500, "Todd Keister" <Todd_Keister@mw.3com.com> wrote: > > Yes, there are a number of people who are running 4.1.59-6 and 1.2.43. >This combination seems stable, and to resolve most V.90 issues. This is BIG >improvement in connectivity, and the 4.1.59-6 addressed some 200 issues with >4.1.72-7 code you are running. The release notes on the web site list most Nothing personal Todd, but I've been bitten by code upgrades before, that have been praised by 3Com as the fix to many problems. A number of these upgrades have resulted in more problems than they've fixed. The performance of these upgrades doesn't have the direct impact on day-to-day business for 3Com that it does for ISPs. Being small, I've learned to wait a couple of weeks and hear from bigger ISPs that are using an upgrade in production before I jump into an upgrade myself. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Web Ramp
From: Jim Johnson <jim@perigee.net>
Date: 1999-04-06 17:28:34
One of our customers is having a problem connecting the second channel of an ISDN Webramp to our TC HUB. I believe we have the MLPPP setup correctly and use one ARC as the MLPPP server. This setup seems to work for NT and other non-webramp customers. They emailed a PPP dump generated by the webramp which according to webramp support indicated that our hub was requesting a reconfiguration. I don't know anything about webramps so I can't tell if this is a web ramp problem or if there is something we need do to help them from our side. Our config
Subject: Re: (usr-tc) Comment from 3COM on latest DSP code please...
From: Mark Lemmert <cto@athenet.net>
Date: 1999-04-06 17:52:47
At 12:07 AM 3/19/99 +0000, you wrote: > > >Hi Curt, > >Below are the two major issues resolved from 1.2.59 to 1.2.43. > >Hope this helps. > >Regards, >David > >MR 2021 Improved V.42 compatibility with slower Win-modem clients. >MR 2029 Issue : Failure to connect rates were too high and back channel >speeds were too low. Resolution : The answer tone level was hard-coded and too >loud >to trigger the network echo cancellers in some environments. David, Regarding MR 2029, what was the actual problem symptom that this caused? Thanks. -Mark Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700
Subject: RE: (usr-tc) HiPer operator gone wacko!
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-06 18:22:12
Is it just me or is 1.2.43 only for T1 ? Thanks for any pointers/URL's if it's available for E1-PRI. Robert > -----Original Message----- > From: Todd Keister [SMTP:Todd_Keister@mw.3com.com] > Sent: mardi, 6. avril 1999 18:07 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiPer operator gone wacko! > > > > Yes, there are a number of people who are running 4.1.59-6 and > 1.2.43. > This combination seems stable, and to resolve most V.90 issues. This is > BIG > improvement in connectivity, and the 4.1.59-6 addressed some 200 issues > with > 4.1.72-7 code you are running. The release notes on the web site list > most of > the fixes in this upgrade. > In tech support we are asking all customers to go to this code > combination. > It seems very stable, and fixes a whole slew of issues, and finally puts > to bed > most of the V.90 issues. There are still a few modems that won't > cooperate, but > as long as the End Users (your customers) upgrade to current firmware, the > should connect fine. > If you have any questions, were always here (24x7x365)** > > Todd ;-} > > > > > > > ** of course you do need a premium contract after 8pm central or on > weekends / > holidays..... > > > > > > K Mitchell <mitch@keyconn.net> on 04/06/99 08:39:33 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Todd Keister/MW/US/3Com) > Subject: Re: (usr-tc) HiPer operator gone wacko! > > > > > At 05:01 PM 4/5/99 -0500, you wrote: > > > > You will probably want to upgrade to latest code. Current code is > now > >4.1.59-6, and if you upgrade your DSPs to 1.2.43 you will get better V.90 > >connectivity. This combination seems to be very stable. As for this > exact > >issue that you are experiencing, if the reboot does not fix it, it is > usually > >time to re-flash the code. Since you are in need of an upgrade this is a > good > >time to do this. > > If you don't have this code, please send me a email, I will forward > it to > >you. > > I appreciate all of the helpful replies. Fortunately the problem turned > out to be somewhat less serious than the replies anticipated. Being on my > way out the door to a "You can't be late under any circumstances" > appointment, I failed to complete a thorough besic check before panicing. > The problem turned out to be the console cable slipping out of the > null-modem adaptor. Reaffixing it firmly has everything showing up fine > again, apparently the user connection problems were an unrelated > concidence > that were all solved by routine configuration reviews. > This does bring up another question though. Has anybody been running the > combo of ARC 4.1.59-6/DSP 1.2.43 long enough to determine whether or not > it > is worth upgrading to? I know there had been reported problems with the > 4.1.59 series and my combo of ARC 4.1.72/DSP 1.2.60 has been working > fairly > well, so I've been hesitant to change it. > > Thanks again, > Kirk > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
From: Ronald Kushner <ron@glis.net>
Date: 1999-04-06 21:17:25
Randy McMillan wrote: > > We are converting our modem pool to all digital lines with TC chassis with > quad modems and hiper ARC cards. Some people are connecting slower on the > new lines than they did on the analog lines. One customer who got 33.6 or > 31.2 speeds is now getting 28.8 or 26.4 speeds (with a zoom 2919 with > current zoom firmware). He doesn't seem to be able to do v.90 protocol. The > T1 lines seem to be clean as I can connect at 50k+ using v.90. If I disable > v.90 on my sportster, I get 28.8 downstream and 33.6 upstream, but not 33.6 > down. Of course customers only see the downstream connect speed. > Does anybody know of any reasons why the v.34 speeds would be slower when > terminated here on a T1 as opposed to a pots line on the same chassis? Or > in regard to my sportster, is there anything in disabling v.90 that would > disable the 31.2 & 33.6 speeds? Any info on this would be appreciated.. There could be two issues at work. The first one is that the call is taking a different path now that it is coming in on a CH DS-1. The second is that if calls are not originating on the same switch you are terminating on, and the PSTN is not 64k clear channel, there is a possibility of added noise in the phone call because of Robed Bit Signaling(RBS) - every time the call hops between switches, usually the switch picks a new bit to rob from the phone call. If you have your DS-1's provisioned with AMI/SF signaling, you might have two different bits robbed if the call is originating on a neighboring switch, where before when things were analog there might have only been one bit robbed. If you're on the same switch as the caller, you might have one robbed bit now where you never had one in the past (the switch operated 64k clear internally). These robed bits should not stop a customer from getting a V.90 connection, unless the customer loop is of poor quality to begin with. But you will see reduced connect speeds because of the added noise. The best way to boot connect speeds is to go ISDN PRI, but that is generally more expensive than CH DS-1s and you pay a penalty of loosing one modem per span. But you get back to 64k clear channel with no conversions and usually no padding. I saw a boost when a telco I am connected to switched me from AMI/D4 to B8ZS/D5, and another boost when I switched my circuits to ISDN PRI. Unfortunatly most rural service areas do not offer ISDN PRI service. You defiantly should have your CH DS-1's provisioned as B8ZS/ESF if the switch is capable of it. There is also a possibility that they have a digital pad misconfigured on your CH DS-1, but trying to convince a telco to change the pad type or eliminate the pad can be next to impossible. -Ron GLISnet, Inc. +1 810/939.9885
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-06 22:13:28
At 04:16 PM 4/6/99 -0500, Todd Keister wrote: > > > Kirk: > > Since we have to take the calls, we very generally conservative about >recommending upgrades. The reason I recommend it is the resolution of the V.90 >issue, and an increase in stability over 4.1.72-7. This does NOT however imply >you should ever implement an upgrade without testing. Networks are far more >individualized than Snowflakes. What works on one network may have an issue on >your network due some specific configuration, or unique grouping of devices with >a specific configuration. The upshot: ALWAYS TEST NEW CODE!! PLEASE ( >pretty please with sugar on top) We do NOT want to cause an issue on your >production units. My problem is that I have only 2 DSPs in service, and an average of 40-44 modems in use during peak evening times. As much as I'd like to be able to test new code myself before putting it in front-line service, I just don't have the extra equipment to test it on. I am forced to use other ISPs experience as my testing ground because I simply can't afford to have half of my modems acting buggy. > The other point you raise is equally valid. Do you have a valid business >reason for this upgrade? If not, then don't upgrade. The reason I >recommended this upgrade is most TC owners do want V.90 connectivity (I'm on the >ISP Support team so this has been one of our most pressing issues). However, >if you are a corporate user, and you have good connectivity, and no current >issues, then you may not want to upgrade at this time. When in doubt, read the >release notes, and see if there are any issues that affect you, or may affect >you in the future. V90 is an issue for me, but not at the cost of decreased reliability elsewhere. Having had no RAS experience prior to my HiPer purchase a year ago, I'm not as well-versed as many on this list as to exactly what everything does, or all of the ways in which different aspects interact. There are times when an issue is mentioned in the release notes and I have no clue as to whether it would affect me or not. I'm busting my @$$b to learn, but I have to run a business in the meantime, and keep my customers happy. This list, and the comments of other users, have been my best guide as to whether or not a particular upgrade is likely to help or hurt my performance. > If so, then consider an upgrade, but only after your own >reliability testing. We can test new code endlessly, and still not have tested >the code in your environment. > With all of this said, I still recommend you upgrade to the 4.1.59-6 >combined with the 1.2.43 code. This code has been out since March 18th for the >DSP code, and 4.1.59-6 was released on March 4th. After an upgrade to this >code combination, every customer that I have spoken with reported an increase in >connectivity, a reduction of V.90 complaints, and an increase in general system >stability. But of course, "Your Milage May Vary." Along this line(did I mention I'm still learning?), how do I "busy-out" a DSP in order to force all calls to go to the other one so that I can upgrade them with minimal disruption to users online? One of the things I have been disappointed in is that all of the HiPer documentation I've seen assumes that the reader is well-versed in RAS equipment and terminology. I'm not stupid, and have learned a great deal on my own, but for my $12k or so would it be too much to ask for a printed document that doesn't assume that I've got 3 years of NetServer experience under my belt? Not an "Idiot's Guide", but something that at least told me what the hell effect things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system. > Please do note that we did release 4.1.59-1 in early February, and this >code is different from the 4.1.59-6 that was released on March 4th. To >determine exactly which code you have on a Harc type: _show ver and it gives >the exact revision. Users of the 4.1.59-1 should upgrade to the 4.1.59-6 to >resolve an issue with ISDN connectivity. > > > Hope this answers your questions. It clears a few things up. I do appreciate the feedback. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: (usr-tc) Telnet password
From: vito@aracnet.net
Date: 1999-04-06 22:21:13
If you for get the telnet password to a USR terminal is there away to reset the password so you can telnet into it again. Thanks Vito
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-06 22:54:38
Ditto to this. Having a PRI laying around for testing, plus a chassis is a rather tall order. Maybe 3Com could post some data from thier lab as a general expectation for others. I know the reps would LOVE to have me order a unit just for testing.. but that ain't gonna happen. I have 5 DSP's in service and although I did get another chassis, the only reason was that 2 DSP's are $8500, the entire new rack with support for a year was $10,000. I know that every phone system is different. But the release notes ALWAYS have v.90 compatibilaty issues as a resolved issue.. and also as an open one?!?!?!? BTW.. I am hovering around a 10% call failure rate with the my current installed code. Will put in 1.2.43 in a day or so to see if I can settle down the failure rates. That said.. I still think US Robotics is doing all right.... and that we should collectivly firebomb those damned generic modem factories. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 6 Apr 1999, K Mitchell wrote: > At 04:16 PM 4/6/99 -0500, Todd Keister wrote: > > > > > > Kirk: > > > > Since we have to take the calls, we very generally conservative about > >recommending upgrades. The reason I recommend it is the resolution of the > V.90 > >issue, and an increase in stability over 4.1.72-7. This does NOT however > imply > >you should ever implement an upgrade without testing. Networks are far more > >individualized than Snowflakes. What works on one network may have an > issue on > >your network due some specific configuration, or unique grouping of > devices with > >a specific configuration. The upshot: ALWAYS TEST NEW CODE!! > PLEASE ( > >pretty please with sugar on top) We do NOT want to cause an issue on your > >production units. > > My problem is that I have only 2 DSPs in service, and an average of 40-44 > modems in use during peak evening times. As much as I'd like to be able to > test new code myself before putting it in front-line service, I just don't > have the extra equipment to test it on. I am forced to use other ISPs > experience as my testing ground because I simply can't afford to have half > of my modems acting buggy. > > > The other point you raise is equally valid. Do you have a valid > business > >reason for this upgrade? If not, then don't upgrade. The reason I > >recommended this upgrade is most TC owners do want V.90 connectivity (I'm > on the > >ISP Support team so this has been one of our most pressing issues). > However, > >if you are a corporate user, and you have good connectivity, and no current > >issues, then you may not want to upgrade at this time. When in doubt, > read the > >release notes, and see if there are any issues that affect you, or may affect > >you in the future. > > V90 is an issue for me, but not at the cost of decreased reliability > elsewhere. Having had no RAS experience prior to my HiPer purchase a year > ago, I'm not as well-versed as many on this list as to exactly what > everything does, or all of the ways in which different aspects interact. > There are times when an issue is mentioned in the release notes and I have > no clue as to whether it would affect me or not. I'm busting my @$$b to > learn, but I have to run a business in the meantime, and keep my customers > happy. This list, and the comments of other users, have been my best guide > as to whether or not a particular upgrade is likely to help or hurt my > performance. > > > If so, then consider an upgrade, but only after your own > >reliability testing. We can test new code endlessly, and still not have > tested > >the code in your environment. > > With all of this said, I still recommend you upgrade to the 4.1.59-6 > >combined with the 1.2.43 code. This code has been out since March 18th > for the > >DSP code, and 4.1.59-6 was released on March 4th. After an upgrade to this > >code combination, every customer that I have spoken with reported an > increase in > >connectivity, a reduction of V.90 complaints, and an increase in general > system > >stability. But of course, "Your Milage May Vary." > > Along this line(did I mention I'm still learning?), how do I "busy-out" a > DSP in order to force all calls to go to the other one so that I can > upgrade them with minimal disruption to users online? One of the things I > have been disappointed in is that all of the HiPer documentation I've seen > assumes that the reader is well-versed in RAS equipment and terminology. > I'm not stupid, and have learned a great deal on my own, but for my $12k or > so would it be too much to ask for a printed document that doesn't assume > that I've got 3 years of NetServer experience under my belt? Not an > "Idiot's Guide", but something that at least told me what the hell effect > things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system. > > > Please do note that we did release 4.1.59-1 in early February, and this > >code is different from the 4.1.59-6 that was released on March 4th. To > >determine exactly which code you have on a Harc type: _show ver and it > gives > >the exact revision. Users of the 4.1.59-1 should upgrade to the > 4.1.59-6 to > >resolve an issue with ISDN connectivity. > > > > > > Hope this answers your questions. > > It clears a few things up. I do appreciate the feedback. > > Kirk > > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-07 09:24:51
Kirk: This thread was too long so I've killed most of it. If you want to know how to busy modems on a DSP card, without disconnecting users currently connected you need to SOFT BUSY the modems. Rather than answer your question here in this forum, I wish to send you to the 3KB knowledgebase for this solution. I know this solution works (I wrote it ;-}). The URL for 3KB is: http://knowledgebase.3com.com When you get to the question window just type "how to soft busy modems" and you will find the answer has detailed step by step instructions for soft busy, and to restore. We are urging everyone to try the 3KB first for most questions. We have over 1,000 solutions and are publishing more every day. Another very useful search is: netserver cli This gives an almost full listing of all the command line interface commands for the Netserver card. If there is ever a solution that you need, and we don't have it in 3KB, just tell the technician you speak with that this solution is NOT in 3KB, and we can then be sure to put this answer into the database. If any of you power users out there wish to have your solutions put into the database, send me a private email, and I will forward it to the proper place for review and publishing. Hope this helps. Todd ;-} K Mitchell <mitch@keyconn.net> on 04/06/99 09:13:28 PM >Along this line(did I mention I'm still learning?), how do I "busy-out" a >DSP in order to force all calls to go to the other one so that I can >upgrade them with minimal disruption to users online? One of the things I >have been disappointed in is that all of the HiPer documentation I've seen >assumes that the reader is well-versed in RAS equipment and terminology. >I'm not stupid, and have learned a great deal on my own, but for my $12k or >so would it be too much to ask for a printed document that doesn't assume >that I've got 3 years of NetServer experience under my belt? Not an >"Idiot's Guide", but something that at least told me what the hell effect >things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system. >It clears a few things up. I do appreciate the feedback. >Kirk >Kirk Mitchell-General Manager sysadmin@keyconn.net >Keystone Connect http://www.keyconn.net >Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-07 09:41:55
Paul: The testing I recommend can be as simple as putting new code on only 1 card if all you have is 2 cards. Sure, some of the larger ISPs have a seperate chassis just for reliability testing, and this is ideal. But many of our customers can't afford that luxury. On the other hand, I have had to pick up the pieces when a customer upgraded his Hyper Arc, all 30 of his DSPs on 4 chassis, all of his NMCs and the Netserver card on the chassis with Quads, all in 1 day. With many things upgraded it was not fun trying to guess which item was the "culprit" A little planing and foresight can go a long way in making an upgrade happen without headaches or difficulties. If you have multiple upgrades to undertake, upgrade 1 item and see if it works for 2-3 days first. Then try the next upgrade. This way we can see if one specific item will not play nice on your network. I hope this helps to clarify my prior statements. Thanks for using 3Com equipment. Todd ;-} Paul Farber <farber@admin.f-tech.net> on 04/06/99 09:54:38 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) Ditto to this. Having a PRI laying around for testing, plus a chassis is a rather tall order. Maybe 3Com could post some data from thier lab as a general expectation for others. I know the reps would LOVE to have me order a unit just for testing.. but that ain't gonna happen. I have 5 DSP's in service and although I did get another chassis, the only reason was that 2 DSP's are $8500, the entire new rack with support for a year was $10,000. I know that every phone system is different. But the release notes ALWAYS have v.90 compatibilaty issues as a resolved issue.. and also as an open one?!?!?!? BTW.. I am hovering around a 10% call failure rate with the my current installed code. Will put in 1.2.43 in a day or so to see if I can settle down the failure rates. That said.. I still think US Robotics is doing all right.... and that we should collectivly firebomb those damned generic modem factories. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 6 Apr 1999, K Mitchell wrote: > At 04:16 PM 4/6/99 -0500, Todd Keister wrote: > > > > > > Kirk: > > > > Since we have to take the calls, we very generally conservative about > >recommending upgrades. The reason I recommend it is the resolution of the > V.90 > >issue, and an increase in stability over 4.1.72-7. This does NOT however > imply > >you should ever implement an upgrade without testing. Networks are far more > >individualized than Snowflakes. What works on one network may have an > issue on > >your network due some specific configuration, or unique grouping of > devices with > >a specific configuration. The upshot: ALWAYS TEST NEW CODE!! > PLEASE ( > >pretty please with sugar on top) We do NOT want to cause an issue on your > >production units. > > My problem is that I have only 2 DSPs in service, and an average of 40-44 > modems in use during peak evening times. As much as I'd like to be able to > test new code myself before putting it in front-line service, I just don't > have the extra equipment to test it on. I am forced to use other ISPs > experience as my testing ground because I simply can't afford to have half > of my modems acting buggy. > > > The other point you raise is equally valid. Do you have a valid > business > >reason for this upgrade? If not, then don't upgrade. The reason I > >recommended this upgrade is most TC owners do want V.90 connectivity (I'm > on the > >ISP Support team so this has been one of our most pressing issues). > However, > >if you are a corporate user, and you have good connectivity, and no current > >issues, then you may not want to upgrade at this time. When in doubt, > read the > >release notes, and see if there are any issues that affect you, or may affect > >you in the future. > > V90 is an issue for me, but not at the cost of decreased reliability > elsewhere. Having had no RAS experience prior to my HiPer purchase a year > ago, I'm not as well-versed as many on this list as to exactly what > everything does, or all of the ways in which different aspects interact. > There are times when an issue is mentioned in the release notes and I have > no clue as to whether it would affect me or not. I'm busting my @$$b to > learn, but I have to run a business in the meantime, and keep my customers > happy. This list, and the comments of other users, have been my best guide > as to whether or not a particular upgrade is likely to help or hurt my > performance. > > > If so, then consider an upgrade, but only after your own > >reliability testing. We can test new code endlessly, and still not have > tested > >the code in your environment. > > With all of this said, I still recommend you upgrade to the 4.1.59-6 > >combined with the 1.2.43 code. This code has been out since March 18th > for the > >DSP code, and 4.1.59-6 was released on March 4th. After an upgrade to this > >code combination, every customer that I have spoken with reported an > increase in > >connectivity, a reduction of V.90 complaints, and an increase in general > system > >stability. But of course, "Your Milage May Vary." > > Along this line(did I mention I'm still learning?), how do I "busy-out" a > DSP in order to force all calls to go to the other one so that I can > upgrade them with minimal disruption to users online? One of the things I > have been disappointed in is that all of the HiPer documentation I've seen > assumes that the reader is well-versed in RAS equipment and terminology. > I'm not stupid, and have learned a great deal on my own, but for my $12k or > so would it be too much to ask for a printed document that doesn't assume > that I've got 3 years of NetServer experience under my belt? Not an > "Idiot's Guide", but something that at least told me what the hell effect > things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system. > > > Please do note that we did release 4.1.59-1 in early February, and this > >code is different from the 4.1.59-6 that was released on March 4th. To > >determine exactly which code you have on a Harc type: _show ver and it > gives > >the exact revision. Users of the 4.1.59-1 should upgrade to the > 4.1.59-6 to > >resolve an issue with ISDN connectivity. > > > > > > Hope this answers your questions. > > It clears a few things up. I do appreciate the feedback. > > Kirk > > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Telnet password
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-07 09:44:13
On Tue, 6 Apr 1999 vito@aracnet.net wrote: > If you for get the telnet password to a USR terminal is there away to > reset the password so you can telnet into it again. > If its a NETServer then you have no other option but to put dip switch 5 on and reboot the card - thus erase all the config. If its a HiPer arc and if you have radius configured then you can add a admin user user Password = password User_service_type = Administrative-User and then you can use this user to login as admin to the hiper arc card krish > Thanks > > Vito > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Totalservice BETA reforms
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-07 10:44:53
We have revised the beta process and now have all beta working through totalservice. If you visit the beta section you will see a list of active and upcoming beta projects. You will have to sign up for each beta. Once accepted you will gain access to the code on totalservice. Incase you were not aware, OSPF is in BETA now. If your interested and not in the BETA, please sign up. Drop me a note if you do so I can expedite your acceptance into the program. OSPF is part of the TCS 3.6 Beta. Mike Wronski (mike@coredump.ae.usr.com) Rogue 3Com Network Systems Engineer / BETA Engineer PGP:http://coredump.ae.usr.com/pgp iCQ:15796141 "If at first you do succeed, try not to look astonished."
Subject: Re: (usr-tc) Totalservice BETA reforms
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-04-07 12:11:29
I try an signup for the TCS 3.6 Beta and I get the following Error Occurred While Processing Request Error Diagnostic Information Parameter 3 of function DateDiff which is now "" must be a date/time value The error occurred while evaluating the expression: Expiration = DateDiff("d", "#Date#","#ExpireDate.sti_finishdate#") The error occurred while processing an element with a general identifier of (CFSET), occupying document position (193:4) to (193:77). Date/Time: 04/07/99 11:08:21 Browser: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; CNETHomeBuild03171999) Remote Address: 206.47.98.69 HTTP Referer: http://tsoweb.nsd.usr.com/beta/ Template: D:\InetPub\wwwroot\beta\logged_in.cfm ----- Original Message ----- Sent: Wednesday, April 07, 1999 11:44 AM > We have revised the beta process and now have all beta working through > totalservice. If you visit the beta section > you will see a list of active and upcoming beta projects. You will have to sign > up for each beta. Once accepted you will gain access to the code on totalservice. > > Incase you were not aware, OSPF is in BETA now. If your interested and not in the > BETA, please sign up. Drop me a > note if you do so I can expedite your acceptance into the program. OSPF is part > of the TCS 3.6 Beta. > > > --------------------------------------------------------- > Mike Wronski (mike@coredump.ae.usr.com) > Rogue 3Com Network Systems Engineer / BETA Engineer > PGP:http://coredump.ae.usr.com/pgp iCQ:15796141 > "If at first you do succeed, try not to look astonished." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) Comment from 3COM on latest DSP code please...
From: David Bachta <david_bachta@mw.3com.com>
Date: 1999-04-07 13:01:16
Hi Mark, I'm not sure if I understand your question. The problem from MR2029 was that in certain environments echo cancellers were not being completely disabled. This caused low back channel speeds and increased failure to connect rates. After investigation we discovered that our answer tone levels (the answer tone sequence includes a tone to shut off network echo cancellers) were a bit too hot for a specific manufacturer's echo canceller. The resolution was to add a configurable parameter to modify the answer tone level, S39. The default is -11db. We found that by decreasing the tone a few db the problem was resolved. Also note, that this usually only applies to long distance calls. Most carriers do not use echo cancellers on local calls. Hope this answers your question. If not, let me know. Regards, David Mark Lemmert <cto@athenet.net> on 04/06/99 05:52:47 PM Please respond to usr-tc@lists.xmission.com cc: (David Bachta/MW/US/3Com) At 12:07 AM 3/19/99 +0000, you wrote: > > >Hi Curt, > >Below are the two major issues resolved from 1.2.59 to 1.2.43. > >Hope this helps. > >Regards, >David > >MR 2021 Improved V.42 compatibility with slower Win-modem clients. >MR 2029 Issue : Failure to connect rates were too high and back channel >speeds were too low. Resolution : The answer tone level was hard-coded and too >loud >to trigger the network echo cancellers in some environments. David, Regarding MR 2029, what was the actual problem symptom that this caused? Thanks. -Mark Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
From: Randy McMillan <randy@pacinfo.com>
Date: 1999-04-07 13:25:29
The T1's are provisioned b8zs/esf. The analog calls originate and terminate in the same switch. The T1 calls terminate in a different switch, but I have been told that it is using 64k clear channel between them. So, if that is true, does robbed bit signaling affect v.34 more than v.90? Where does the digital pad get introduced, in one of the switches or on the T1 line? Thanks again for the info. Randy McMillan > > > Randy McMillan wrote: > > > > We are converting our modem pool to all digital lines with TC chassis with > > quad modems and hiper ARC cards. Some people are connecting slower on the > > new lines than they did on the analog lines. One customer who got 33.6 or > > 31.2 speeds is now getting 28.8 or 26.4 speeds (with a zoom 2919 with > > current zoom firmware). He doesn't seem to be able to do v.90 protocol. The > > T1 lines seem to be clean as I can connect at 50k+ using v.90. If I disable > > v.90 on my sportster, I get 28.8 downstream and 33.6 upstream, but not 33.6 > > down. Of course customers only see the downstream connect speed. > > Does anybody know of any reasons why the v.34 speeds would be slower when > > terminated here on a T1 as opposed to a pots line on the same chassis? Or > > in regard to my sportster, is there anything in disabling v.90 that would > > disable the 31.2 & 33.6 speeds? Any info on this would be appreciated.. > > There could be two issues at work. The first one is that the call is taking a > different path now that it is coming in on a CH DS-1. The second is that if calls are > not originating on the same switch you are terminating on, and the PSTN is not 64k > clear channel, there is a possibility of added noise in the phone call because of > Robed Bit Signaling(RBS) - every time the call hops between switches, usually the > switch picks a new bit to rob from the phone call. If you have your DS-1's provisioned > with AMI/SF signaling, you might have two different bits robbed if the call is > originating on a neighboring switch, where before when things were analog there might > have only been one bit robbed. If you're on the same switch as the caller, you might > have one robbed bit now where you never had one in the past (the switch operated 64k > clear internally). These robed bits should not stop a customer from getting a V.90 > connection, unless the customer loop is of poor quality to begin with. But you will > see reduced connect speeds because of the added noise. > > The best way to boot connect speeds is to go ISDN PRI, but that is generally more > expensive than CH DS-1s and you pay a penalty of loosing one modem per span. But you > get back to 64k clear channel with no conversions and usually no padding. I saw a > boost when a telco I am connected to switched me from AMI/D4 to B8ZS/D5, and another > boost when I switched my circuits to ISDN PRI. Unfortunatly most rural service areas > do not offer ISDN PRI service. You defiantly should have your CH DS-1's provisioned as > B8ZS/ESF if the switch is capable of it. > > There is also a possibility that they have a digital pad misconfigured on your CH > DS-1, but trying to convince a telco to change the pad type or eliminate the pad can > be next to impossible. > > -Ron > GLISnet, Inc. > +1 810/939.9885 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-07 14:13:16
I did that with the 1.2.43 DSP code... but I have not effective way to measure the reults. I will try the 3KB site you previously mentioned. Te manual should have a chaper labeled "monitoring" or "Quality Assurance". Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 7 Apr 1999, Todd Keister wrote: > > > > Paul: > > The testing I recommend can be as simple as putting new code on only 1 card > if all you have is 2 cards. Sure, some of the larger ISPs have a seperate > chassis just for reliability testing, and this is ideal. But many of our > customers can't afford that luxury. On the other hand, I have had to pick up > the pieces when a customer upgraded his Hyper Arc, all 30 of his DSPs on 4 > chassis, all of his NMCs and the Netserver card on the chassis with Quads, all > in 1 day. With many things upgraded it was not fun trying to guess which item > was the "culprit" A little planing and foresight can go a long way in making > an upgrade happen without headaches or difficulties. If you have multiple > upgrades to undertake, upgrade 1 item and see if it works for 2-3 days first. > Then try the next upgrade. This way we can see if one specific item will not > play nice on your network. > > I hope this helps to clarify my prior statements. > > Thanks for using 3Com equipment. > > Todd ;-} > > > > > > > > > Paul Farber <farber@admin.f-tech.net> on 04/06/99 09:54:38 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Todd Keister/MW/US/3Com) > Subject: Re: (usr-tc) HiPer operator gone wacko! > > > > > Ditto to this. Having a PRI laying around for testing, plus a chassis is > a rather tall order. > > Maybe 3Com could post some data from thier lab as a general expectation > for others. I know the reps would LOVE to have me order a unit just for > testing.. but that ain't gonna happen. I have 5 DSP's in service and > although I did get another chassis, the only reason was that > 2 DSP's are $8500, the entire new rack with support for a year was > $10,000. > > I know that every phone system is different. But the release notes ALWAYS > have v.90 compatibilaty issues as a resolved issue.. and also as an > open one?!?!?!? > > BTW.. I am hovering around a 10% call failure rate with the my current > installed code. Will put in 1.2.43 in a day or so to see if I can settle > down the failure rates. > > That said.. I still think US Robotics is doing all right.... and that we > should collectivly firebomb those damned generic modem factories. > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Tue, 6 Apr 1999, K Mitchell wrote: > > > At 04:16 PM 4/6/99 -0500, Todd Keister wrote: > > > > > > > > > Kirk: > > > > > > Since we have to take the calls, we very generally conservative about > > >recommending upgrades. The reason I recommend it is the resolution of the > > V.90 > > >issue, and an increase in stability over 4.1.72-7. This does NOT however > > imply > > >you should ever implement an upgrade without testing. Networks are far more > > >individualized than Snowflakes. What works on one network may have an > > issue on > > >your network due some specific configuration, or unique grouping of > > devices with > > >a specific configuration. The upshot: ALWAYS TEST NEW CODE!! > > PLEASE ( > > >pretty please with sugar on top) We do NOT want to cause an issue on your > > >production units. > > > > My problem is that I have only 2 DSPs in service, and an average of 40-44 > > modems in use during peak evening times. As much as I'd like to be able to > > test new code myself before putting it in front-line service, I just don't > > have the extra equipment to test it on. I am forced to use other ISPs > > experience as my testing ground because I simply can't afford to have half > > of my modems acting buggy. > > > > > The other point you raise is equally valid. Do you have a valid > > business > > >reason for this upgrade? If not, then don't upgrade. The reason I > > >recommended this upgrade is most TC owners do want V.90 connectivity (I'm > > on the > > >ISP Support team so this has been one of our most pressing issues). > > However, > > >if you are a corporate user, and you have good connectivity, and no current > > >issues, then you may not want to upgrade at this time. When in doubt, > > read the > > >release notes, and see if there are any issues that affect you, or may affect > > >you in the future. > > > > V90 is an issue for me, but not at the cost of decreased reliability > > elsewhere. Having had no RAS experience prior to my HiPer purchase a year > > ago, I'm not as well-versed as many on this list as to exactly what > > everything does, or all of the ways in which different aspects interact. > > There are times when an issue is mentioned in the release notes and I have > > no clue as to whether it would affect me or not. I'm busting my @$$b to > > learn, but I have to run a business in the meantime, and keep my customers > > happy. This list, and the comments of other users, have been my best guide > > as to whether or not a particular upgrade is likely to help or hurt my > > performance. > > > > > If so, then consider an upgrade, but only after your own > > >reliability testing. We can test new code endlessly, and still not have > > tested > > >the code in your environment. > > > With all of this said, I still recommend you upgrade to the 4.1.59-6 > > >combined with the 1.2.43 code. This code has been out since March 18th > > for the > > >DSP code, and 4.1.59-6 was released on March 4th. After an upgrade to this > > >code combination, every customer that I have spoken with reported an > > increase in > > >connectivity, a reduction of V.90 complaints, and an increase in general > > system > > >stability. But of course, "Your Milage May Vary." > > > > Along this line(did I mention I'm still learning?), how do I "busy-out" a > > DSP in order to force all calls to go to the other one so that I can > > upgrade them with minimal disruption to users online? One of the things I > > have been disappointed in is that all of the HiPer documentation I've seen > > assumes that the reader is well-versed in RAS equipment and terminology. > > I'm not stupid, and have learned a great deal on my own, but for my $12k or > > so would it be too much to ask for a printed document that doesn't assume > > that I've got 3 years of NetServer experience under my belt? Not an > > "Idiot's Guide", but something that at least told me what the hell effect > > things like RADIUS FILL_NULL_ATTRIBUTES or SLIP OFFLOADING have on my system. > > > > > Please do note that we did release 4.1.59-1 in early February, and this > > >code is different from the 4.1.59-6 that was released on March 4th. To > > >determine exactly which code you have on a Harc type: _show ver and it > > gives > > >the exact revision. Users of the 4.1.59-1 should upgrade to the > > 4.1.59-6 to > > >resolve an issue with ISDN connectivity. > > > > > > > > > Hope this answers your questions. > > > > It clears a few things up. I do appreciate the feedback. > > > > Kirk > > > > > > > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > > Keystone Connect http://www.keyconn.net > > Altoona, PA 814-941-5000 We Unlock the World > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-07 15:21:12
At 09:24 AM 4/7/99 -0500, Todd Keister wrote: > > If you want to know how to busy modems on a DSP card, without disconnecting >users currently connected you need to SOFT BUSY the modems. Rather than answer >your question here in this forum, I wish to send you to the 3KB knowledgebase >for this solution. What's the alternative for PRI? Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-07 15:57:29
Kirk: Actually the same procedure works for either T1 or PRI. The reviewer for my team believed that this process would not work for a DSP connected to a PRI span, but they were mistaken. I have just confirmed that this process works by testing this on a DSP card connected to a PRI span. I also got the explanation, from one of our Network Engineers. This process works because the DSP card places a "go busy" command into the modems command que to be performed when the current task completes. This process is therefore independent of the span type (either T1 or PRI**). The solution in 3KB has updated to reflect this information. Todd ;-} ** I don't work with the Eurpean E1 spans - so I don't know how these work. K Mitchell <mitch@keyconn.net> on 04/07/99 02:21:12 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) At 09:24 AM 4/7/99 -0500, Todd Keister wrote: > > If you want to know how to busy modems on a DSP card, without disconnecting >users currently connected you need to SOFT BUSY the modems. Rather than answer >your question here in this forum, I wish to send you to the 3KB knowledgebase >for this solution. What's the alternative for PRI? Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-07 15:59:19
Thus spake K Mitchell >At 09:24 AM 4/7/99 -0500, Todd Keister wrote: >> If you want to know how to busy modems on a DSP card, without >>disconnecting users currently connected you need to SOFT BUSY the >>modems. Rather than answer your question here in this forum, I wish >>to send you to the 3KB knowledgebase for this solution. >What's the alternative for PRI? If you're got a translation type that supports service messages (note, NI-2 *doesn't*) its "localoutofservice". -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-07 16:15:42
Thank you for the further clarification David. Todd ;-} David Bolen <db3l@ans.net> on 04/07/99 04:01:32 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) "Todd Keister" <Todd_Keister@mw.3com.com> writes: > Actually the same procedure works for either T1 or PRI. The > reviewer for my team believed that this process would not work for a > DSP connected to a PRI span, but they were mistaken. Well, only as long as the PRI span supports service messages. If it doesn't (e.g., NI-2 mode[*] or a custom switch type without service messages enabled on the telco end), then you can't do this. I mean, the function will be accepted and the card will try to take the channel out of service, but the remote end will ignore that and you'll end up losing calls that try to use that channel anyway. Note that even channelized T1 configurations can have problems taking a channel out of service in some configurations (for example, ground start into older channel banks). But that's much less common. Oh, and just for clarity - it isn't the "modems" that are being busied out or removed from service - it's the DS0 channels (or B channels for PRI spans). True, in most default configurations there is a one to one fixed mapping, but the actual busy/service operation is taking place on the span side of things, not on the modem. The command to request an out of service/busy operation is made to the DS0 entity. In fact, unlike the quad cards, you can't ask a HiperDSP modem to busy out or go out of service (an "offHook" command to a quad modem). > ** I don't work with the Eurpean E1 spans - so I don't know how > these work. They don't, as far as this goes, at least not E1-PRI. I'm not aware of any European switch types that support the equivalent to the service messages of domestic switch types at this time. -- David [*] Recently I think we've found some 5ESS switches with late enough software that are willing to deal with service messages even in NI-2 mode. /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) ISDN router probs. since Hiper Upgrade
From: GTI x2 Tech <x2@apollo.gti.net>
Date: 1999-04-07 16:52:56
I have 2 customers with: Cisco 766 ISDN router Ascend Pipeline 75 Who connected fine before I upgraded now cannot connect at all. My PPP settings are: PPP AUTHENTICATION DIAL_IN Users Authenticate: ANY PPP Authentication Preference: PAP System Transmit Authentication Name: HiPer PPP offloading: ENABLED CCP will be attempted for call type(s): DIGITAL UNCOMPRESSED_ANALOG I told them to set auth to PAP and it doesnt work. Ive tried to debug with no success. Is there any way to see debug output like it was on the NetServer card? (i.e. set debug 0x51). Ive tried PPP monitor and Radius monitor and it doesnt tell me anything (access-reject). I am going to loose these customers unless I can figure out whats wrong. Thanks, John Addl debug info follows: Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type 199.171.x.x 1645 199.171.x.x 1645 4 Access-Request User-Name : gbareppp User-Password : xxxxxxxxxx NAS-IP-Address : 199.171.x.x NAS-Port : 3329 Acct-Session-Id : 218119937 Interface-Index : 4585 Service-Type : 2 Framed-Protocol : PPP Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38 Chasis-Call-Slot : 14 Chasis-Call-Span : 1 Chasis-Call-Channel : 1 Calling-Station-Id : 9086040517 Called-Station-Id : 6052881 NAS-Port-Type : 2 Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type 199.171.x.x 1645 199.171.x.x 1645 4 Access-Accept Service-Type : 2 Framed-Protocol : PPP Framed-IP-Address : 208.216.x.x Framed-IP-Netmask : 255.255.255.240 Framed-Route : 208.216.x.x/28 208.216.x.x 1 Framed-Compression : 0 Idle-Timeout : 1200 Session-Timeout : 18000 Port-Limit : 2 Framed-MTU : 1500 Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type 199.171.x.x 1645 199.171.x.x 1645 5 Access-Request User-Name : gbareppp User-Password : xxxxxxxxxx NAS-IP-Address : 199.171.x.x NAS-Port : 3329 Acct-Session-Id : 218119937 Interface-Index : 4585 Service-Type : 2 Framed-Protocol : PPP Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38 Chasis-Call-Slot : 14 Chasis-Call-Span : 1 Chasis-Call-Channel : 1 Calling-Station-Id : 9086040517 Called-Station-Id : 6052881 NAS-Port-Type : 2 Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type 199.171.x.x 1645 199.171.x.x 1645 5 Access-Reject
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: David Bolen <db3l@ans.net>
Date: 1999-04-07 17:01:32
"Todd Keister" <Todd_Keister@mw.3com.com> writes: > Actually the same procedure works for either T1 or PRI. The > reviewer for my team believed that this process would not work for a > DSP connected to a PRI span, but they were mistaken. Well, only as long as the PRI span supports service messages. If it doesn't (e.g., NI-2 mode[*] or a custom switch type without service messages enabled on the telco end), then you can't do this. I mean, the function will be accepted and the card will try to take the channel out of service, but the remote end will ignore that and you'll end up losing calls that try to use that channel anyway. Note that even channelized T1 configurations can have problems taking a channel out of service in some configurations (for example, ground start into older channel banks). But that's much less common. Oh, and just for clarity - it isn't the "modems" that are being busied out or removed from service - it's the DS0 channels (or B channels for PRI spans). True, in most default configurations there is a one to one fixed mapping, but the actual busy/service operation is taking place on the span side of things, not on the modem. The command to request an out of service/busy operation is made to the DS0 entity. In fact, unlike the quad cards, you can't ask a HiperDSP modem to busy out or go out of service (an "offHook" command to a quad modem). > ** I don't work with the Eurpean E1 spans - so I don't know how > these work. They don't, as far as this goes, at least not E1-PRI. I'm not aware of any European switch types that support the equivalent to the service messages of domestic switch types at this time. -- David [*] Recently I think we've found some 5ESS switches with late enough software that are willing to deal with service messages even in NI-2 mode. /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-07 17:17:52
At 05:01 PM 4/7/99 EDT, you wrote: >"Todd Keister" <Todd_Keister@mw.3com.com> writes: > >> Actually the same procedure works for either T1 or PRI. The >> reviewer for my team believed that this process would not work for a >> DSP connected to a PRI span, but they were mistaken. > >Well, only as long as the PRI span supports service messages. If it >doesn't (e.g., NI-2 mode[*] or a custom switch type without service >messages enabled on the telco end), then you can't do this. I mean, >the function will be accepted and the card will try to take the >channel out of service, but the remote end will ignore that and you'll >end up losing calls that try to use that channel anyway. Ok, next stupid question...How do I find out if my PRI span supports service messages? This is the exact question I entered in 3KB and got no useful answer. Thanks again, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: David Bachta <david_bachta@mw.3com.com>
Date: 1999-04-07 17:28:00
Hi David, Hi Kirk, The service message counters David described below will be available in the 2.0.x GA Hiper DSP code. They are not available in the current 1.2.x GA code. Hope this helps. Regards, David >A less intrusive (except for a moment) approach that we use requires >counters in the HiperDSP code to track service messages sent and >received. I'll include below a small procedure we use, but I can't >remember if the counters in the below procedure were added just to an >ANS-specific build or if they made the mainline. If they are present >on your display output, you can use them. The gist of it is you >attempt to take something in and out of service and ensure that the >requests were ack'd by the remote end of he circuit. snip > > chdev span > span1> display spnstats > Span1 Near Time Elapsed is: 87 seconds > Span1 Near Valid Intervals is: 96 > Span1 Line Status is: > NO ALARM = TRUE > RCV FAR END LOF = FALSE > > (rest of normal stats) > > ==> Span1 Service Messages Sent: 0 > ==> Span1 Service Ack Messages Received: 0 > snip
Subject: Re: (usr-tc) HiPer operator gone wacko!
From: David Bolen <db3l@ans.net>
Date: 1999-04-07 17:40:25
K Mitchell <mitch@keyconn.net> writes: > Ok, next stupid question...How do I find out if my PRI span supports > service messages? This is the exact question I entered in 3KB and got no > useful answer. One approach is just to verify it with your circuit provider. :-) Another approach if you have more than one span in a hunt group is to take an entire span out of service and see if calls flow to the next span (or if a random/round robin distribution, do repeated test calls not show any busy or problem delivering the call), and idling the span lets calls flow back onto it. A less intrusive (except for a moment) approach that we use requires counters in the HiperDSP code to track service messages sent and received. I'll include below a small procedure we use, but I can't remember if the counters in the below procedure were added just to an ANS-specific build or if they made the mainline. If they are present on your display output, you can use them. The gist of it is you attempt to take something in and out of service and ensure that the requests were ack'd by the remote end of he circuit. - - - - - - - - - - - - - - - - - - - - - - - - - (...) Unlike the Dual-PRI card, testing service messages does not require changing this behavior and then observing how a channel reacts to an attempted service change. Instead, the HDM card keeps a continuous count of service messages sent and received, and all you need to do is take a baseline of those values, perform the service operations, and then verify that both the sent and received messages remained in sync. One thing in common with the Dual-PRI card is that this additional service message information is only available from the console, as part of the span statistics. So, getting on the console you can: > chdev span span1> display spnstats Span1 Near Time Elapsed is: 87 seconds Span1 Near Valid Intervals is: 96 Span1 Line Status is: NO ALARM = TRUE RCV FAR END LOF = FALSE (rest of normal stats) ==> Span1 Service Messages Sent: 0 ==> Span1 Service Ack Messages Received: 0 Although in theory if the span is working properly these values will either be in sync or out of sync, I think it is best that you first get current values from the card, and then always base the results of the test on an offset from those values. For example, in the above case, this card hasn't issued any service messages yet. However, if I know take a single channel locally out of service and then place it back in service (and this can be done via any normal operation such as through the NMC card with usr), I now have at the bottom of the above screen: Span1 Service Messages Sent: 2 Span1 Service Ack Messages Received: 2 This tells us that I sent two messages (one to take it out of service, and one to put it back in), and that two acknowledgements were received. This indicates that service messages are functioning on that span. If they weren't functioning properly, you would see 2 messages sent, but 0 acks (or 2 and 0 respectively on top of whatever values were previously in those counters). The counters cannot be cleared but start counting from the time the card has booted. - - - - - - - - - - - - - - - - - - - - - - - - - -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) ISDN router probs. since Hiper Upgrade
From: Brian <signal@shreve.net>
Date: 1999-04-07 19:02:28
On Wed, 7 Apr 1999, GTI x2 Tech wrote: > > > I have 2 customers with: > > Cisco 766 ISDN router > Ascend Pipeline 75 Is stack enabled on the customers equipment? did you try to disable? > > > Who connected fine before I upgraded now cannot connect at all. > > My PPP settings are: > > PPP AUTHENTICATION > DIAL_IN Users Authenticate: ANY > PPP Authentication Preference: PAP > System Transmit Authentication Name: HiPer > > PPP offloading: ENABLED > > CCP will be attempted for call type(s): DIGITAL > UNCOMPRESSED_ANALOG > > > > > I told them to set auth to PAP and it doesnt work. Ive tried to debug > with no success. > > Is there any way to see debug output like it was on the NetServer card? > (i.e. set debug 0x51). Ive tried PPP monitor and Radius monitor and it > doesnt tell me anything (access-reject). > > I am going to loose these customers unless I can figure out whats wrong. > > Thanks, > > John > > > > Addl debug info follows: > > > --------------------------------------------------------------------- > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > --------------------------------------------------------------------- > 199.171.x.x 1645 199.171.x.x 1645 4 Access-Request > --------------------------------------------------------------------- > > User-Name : gbareppp > User-Password : xxxxxxxxxx > NAS-IP-Address : 199.171.x.x > NAS-Port : 3329 > Acct-Session-Id : 218119937 > Interface-Index : 4585 > Service-Type : 2 > Framed-Protocol : PPP > Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38 > Chasis-Call-Slot : 14 > Chasis-Call-Span : 1 > Chasis-Call-Channel : 1 > Calling-Station-Id : 9086040517 > Called-Station-Id : 6052881 > NAS-Port-Type : 2 > > --------------------------------------------------------------------- > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > --------------------------------------------------------------------- > 199.171.x.x 1645 199.171.x.x 1645 4 Access-Accept > --------------------------------------------------------------------- > > Service-Type : 2 > Framed-Protocol : PPP > Framed-IP-Address : 208.216.x.x > Framed-IP-Netmask : 255.255.255.240 > Framed-Route : 208.216.x.x/28 208.216.x.x 1 > Framed-Compression : 0 > Idle-Timeout : 1200 > Session-Timeout : 18000 > Port-Limit : 2 > Framed-MTU : 1500 > > --------------------------------------------------------------------- > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > --------------------------------------------------------------------- > 199.171.x.x 1645 199.171.x.x 1645 5 Access-Request > --------------------------------------------------------------------- > > User-Name : gbareppp > User-Password : xxxxxxxxxx > NAS-IP-Address : 199.171.x.x > NAS-Port : 3329 > Acct-Session-Id : 218119937 > Interface-Index : 4585 > Service-Type : 2 > Framed-Protocol : PPP > Multilink-PPP-Endpoint-Id : 0 40 f9 12 78 38 > Chasis-Call-Slot : 14 > Chasis-Call-Span : 1 > Chasis-Call-Channel : 1 > Calling-Station-Id : 9086040517 > Called-Station-Id : 6052881 > NAS-Port-Type : 2 > > --------------------------------------------------------------------- > Source-IP Src-Port Destination-IP Dest-Port Id Packet-Type > --------------------------------------------------------------------- > 199.171.x.x 1645 199.171.x.x 1645 5 Access-Reject > --------------------------------------------------------------------- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
From: Ronald Kushner <ron@glis.net>
Date: 1999-04-07 20:57:11
Randy McMillan wrote: > > The T1's are provisioned b8zs/esf. The analog calls originate and terminate > in the same switch. The T1 calls terminate in a different switch, but I > have been told that it is using 64k clear channel between them. > So, if that is true, does robbed bit signaling affect v.34 more than v.90? > Where does the digital pad get introduced, in one of the switches or on the > T1 line? Thanks again for the info. Sounds like it might be a misconfigured digital pad then, is this through a CLEC? If it's all SS7 B8ZS/D5, the signaling is via an X25 network and does not affect call quality. There should be no robbed bits. I ran into problems with digital pads and gain problems with CLECs. That might be the first place to look. I have seen 54666 and 56000 connections with 33,600 on the backchannel since they fixed all my padding issues. (I thought these things were speed limited to 53kbps!). We tried it without a digital pad, but that was worse than having the wrong digital pad on the line. Your milage may vary. There may be digital pads on each DS-1 circuit and on your DS-1 circuit, and all should be set the same. It's the conversion of a pad mismatch that causes noise (it was explained to me that the pad eliminates bits or stuffs bits, depending on the setting) As to line problems affecting V.34 more than V.90, it appears to affect both about the same - nobody expects to see a 54,666 V.90 connection and are happy with the 49,333 connect rate. -Ron GLISnet, Inc. +1 810/939.9885
Subject: Re: (usr-tc) Slot ownerwhip
From: Brian <signal@shreve.net>
Date: 1999-04-07 21:46:49
On Thu, 8 Apr 1999, Corneliu Rudeanu wrote: > > > I am facing the following problem: > > HiPer>> list chassis > Slot Owner Description Ports Type > 1 NO Primary Rate T1 NAC 0 DYNAMIC > 2 YES Quad Digital V.34 Modem 4 DYNAMIC > 3 YES Quad Digital V.34 Modem 4 DYNAMIC > 4 YES Quad Digital V.34 Modem 4 DYNAMIC > 5 YES Quad Digital V.34 Modem 4 DYNAMIC > 6 YES Quad Digital V.34 Modem 4 DYNAMIC > 7 YES Quad Digital V.34 Modem 4 DYNAMIC > 8 YES Quad Digital V.34 Modem 4 DYNAMIC > 9 YES Quad Digital V.34 Modem 4 DYNAMIC > 10 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 11 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 12 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 13 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 14 NO Quad Anal-Digi V.34 Modem 4 DYNAMIC > 15 NO Quad Anal-Digi V.34 Modem 4 DYNAMIC > 16 NO HiPer Access Router NAC 0 DYNAMIC > HiPer>> > > In the User Manual for HiperArc it says that under special circumstances > (multiple HARCs) you can _statically_ assign the modems for load > balancing. I guess (read "hope") that this way (using set chassis slot) I > can take the ownership for slots 14 and 15. > > Yet, by default, the NMC should assign this ownership and that should work > by all means. > > Am I missing something? Is there any way I can find 'who owns' those > slots? > > Any advice appreciated. > I do not trust nmc chassis awareness. The first command in all my configs is "disable nmc chassis_awareness". I statically assign all cards to their appropriate hiper arcs. Brian > Corneliu Rudeanu > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Converting to digital T1's give slower v.34 connections
From: Randy McMillan <randy@cheetah.pacinfo.com>
Date: 1999-04-07 22:26:15
Yes it is a CLEC with SS7 between switches and b8zf/esf on the T1. I asked about digital padding, and they said their switch doesn't do padding, so there may not be any padding??? He called our T1 from his switch to our equipment as a "nailed up T1" using HDSL that didn't go through any switching, etc. How did you find out about who was padding it and where it was padded, and how did you get it resolved? Thanks again. Randy McMillan On Wed, 7 Apr 1999, Ronald Kushner wrote: > > > Randy McMillan wrote: > > > > The T1's are provisioned b8zs/esf. The analog calls originate and terminate > > in the same switch. The T1 calls terminate in a different switch, but I > > have been told that it is using 64k clear channel between them. > > So, if that is true, does robbed bit signaling affect v.34 more than v.90? > > Where does the digital pad get introduced, in one of the switches or on the > > T1 line? Thanks again for the info. > > Sounds like it might be a misconfigured digital pad then, is this through a CLEC? > > If it's all SS7 B8ZS/D5, the signaling is via an X25 network and does not affect call > quality. There should be no robbed bits. > > I ran into problems with digital pads and gain problems with CLECs. That might be the > first place to look. I have seen 54666 and 56000 connections with 33,600 on the > backchannel since they fixed all my padding issues. (I thought these things were speed > limited to 53kbps!). We tried it without a digital pad, but that was worse than having > the wrong digital pad on the line. Your milage may vary. There may be digital pads on > each DS-1 circuit and on your DS-1 circuit, and all should be set the same. It's the > conversion of a pad mismatch that causes noise (it was explained to me that the pad > eliminates bits or stuffs bits, depending on the setting) > > As to line problems affecting V.34 more than V.90, it appears to affect both about the > same - nobody expects to see a 54,666 V.90 connection and are happy with the 49,333 > connect rate. > > -Ron > GLISnet, Inc. > +1 810/939.9885 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Slot ownerwhip
From: Corneliu Rudeanu <rudy@dntis.ro>
Date: 1999-04-08 03:50:13
I am facing the following problem: HiPer>> list chassis Slot Owner Description Ports Type 1 NO Primary Rate T1 NAC 0 DYNAMIC 2 YES Quad Digital V.34 Modem 4 DYNAMIC 3 YES Quad Digital V.34 Modem 4 DYNAMIC 4 YES Quad Digital V.34 Modem 4 DYNAMIC 5 YES Quad Digital V.34 Modem 4 DYNAMIC 6 YES Quad Digital V.34 Modem 4 DYNAMIC 7 YES Quad Digital V.34 Modem 4 DYNAMIC 8 YES Quad Digital V.34 Modem 4 DYNAMIC 9 YES Quad Digital V.34 Modem 4 DYNAMIC 10 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC 11 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC 12 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC 13 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC 14 NO Quad Anal-Digi V.34 Modem 4 DYNAMIC 15 NO Quad Anal-Digi V.34 Modem 4 DYNAMIC 16 NO HiPer Access Router NAC 0 DYNAMIC HiPer>> In the User Manual for HiperArc it says that under special circumstances (multiple HARCs) you can _statically_ assign the modems for load balancing. I guess (read "hope") that this way (using set chassis slot) I can take the ownership for slots 14 and 15. Yet, by default, the NMC should assign this ownership and that should work by all means. Am I missing something? Is there any way I can find 'who owns' those slots? Any advice appreciated. Corneliu Rudeanu
Subject: Re: (usr-tc) Slot ownerwhip
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-08 07:53:40
On Thu, 8 Apr 1999, Corneliu Rudeanu wrote: > > > I am facing the following problem: > > HiPer>> list chassis > Slot Owner Description Ports Type > 1 NO Primary Rate T1 NAC 0 DYNAMIC > 2 YES Quad Digital V.34 Modem 4 DYNAMIC > 3 YES Quad Digital V.34 Modem 4 DYNAMIC > 4 YES Quad Digital V.34 Modem 4 DYNAMIC > 5 YES Quad Digital V.34 Modem 4 DYNAMIC > 6 YES Quad Digital V.34 Modem 4 DYNAMIC > 7 YES Quad Digital V.34 Modem 4 DYNAMIC > 8 YES Quad Digital V.34 Modem 4 DYNAMIC > 9 YES Quad Digital V.34 Modem 4 DYNAMIC > 10 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 11 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 12 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 13 YES Quad Anal-Digi V.34 Modem 4 DYNAMIC > 14 NO Quad Anal-Digi V.34 Modem 4 DYNAMIC > 15 NO Quad Anal-Digi V.34 Modem 4 DYNAMIC > 16 NO HiPer Access Router NAC 0 DYNAMIC > HiPer>> > > In the User Manual for HiperArc it says that under special circumstances > (multiple HARCs) you can _statically_ assign the modems for load > balancing. I guess (read "hope") that this way (using set chassis slot) I > can take the ownership for slots 14 and 15. > > Yet, by default, the NMC should assign this ownership and that should work > by all means. Every card upon bootup sends its info to NMC - Info regarding card type, status etc, based on that information NMC sends out chassis awarness information. The HiPer arc uses this info to activate the cards. In here it looks like either the NMC has not set that info or the HiPer arc has ignore that info. You could either reboot either of the cards or the NMC, or you could set it manually. In any case - I would suspect that these two cards were not on the packet or removed from the same manually once thus the hiper arc is not taking it back. krish > > Am I missing something? Is there any way I can find 'who owns' those > slots? > > Any advice appreciated. > > Corneliu Rudeanu > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Traps & Config
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-08 09:36:19
hello all Two questions, went to the 3Kb and got the info for "Capturing the configuration through the CLI". Telenetted in and did "sho config", I don't thing I could rebuild a chassis from the information it listed. I'm looking for more like the actual commands, or to tftp the config down to a hdd for safe keeping. Also, can I set up traps via the CLI? The 3KB says fire up TCM... any way to replicate the process with the good ol cmd line? Thanks! Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: (usr-tc) WTB Netserver 8 or 16 I + (still looking)
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-04-08 10:14:17
Still looking for used netserver 8I+ and 16I+ tony 435-753-5455
Subject: RE: (usr-tc) WTB Netserver 8 or 16 I + (still looking)
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-04-08 11:17:27
How many do you want and what do you want to pay for them.. I have 16 of em (8 never used) Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tony Loosle Sent: Thursday, April 08, 1999 9:14 AM Still looking for used netserver 8I+ and 16I+ tony 435-753-5455 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) CRC error on boot configuration
From: d baud <dbaud@iname.com>
Date: 1999-04-08 13:53:50
I just received a HiperCard that I installed on the chassis: I plugged the console cable to perform the quicksetup routine and I noticed that it gave me the following error as soon as it did a Save All. The error message is the following: WARNING: CRC error on boot configuration. Defaulting it (repeating for about 15 lines) At first I suspected the code used was faulty, so I reseated the card and issued the regular AT{Z} command to send the current ne040159-6.dmf code. Once finished, I try a "save all" and still nothing happens. I then decided to do a: AT{ZF} command with the same code. Unfortunately still the same error message I then called the tech people at USR, and the lady said that this might be a debug and unharmful code. So she issued some command to remove those messages and refused to tell me what it was because it was "too dificult to understand" Well now I don't get the error message when I "save all" but the following error apears at boot time: Error writing configuration to EEPROM WARNING: CRC error on boot configuration. Defaulting it Anyone had this issue before ? Donald Baud
Subject: (usr-tc) ISDN connect failures
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-04-08 15:26:41
hello, we're having a trouble with ISDN customers not being able to connect for extended periods of time. The caller will be online for any amount of time, then the connection is dropped. After that they repeatedly try to connect without success. This is happening to several makes/models of ISDN router. I can see them hitting the modem but the call never completes. No radius dialog, no ppp dialog using "mon radius" and "mon ppp". TCM shows "RingRcvd" and then "Link negotiation" in the "Operational Status of a modem" column. About 10 seconds later the call drops and the "Reason for call failure" column shows "normaUserCallClear(73)" then the cycle continues. But without intervention or any resetting on the hubs they eventually connect anywhere from 10 minutes to several hours later. I'm running 1.2.43 and 4.1.59-6. PPP offloading is enabled and PPP BACP and BAP are disabled. We have a totally different ARC chassis running the same code revisions but the problem remains with that chassis. The chassis has 6 DSP's, one ARC and one 70 AMP PSU. Any thoughts would be greatly appreciated. blake syslog output: x.x.x.x: Thu Apr 8 12:08:09: <38>At 11:11:48, Facility "Auth Facility", Level "COMMON":: The connection for call id 218235631, on if slot:14/mod:3 was dropped for user UNKNOWN x.x.x.x: Thu Apr 8 12:08:16: <38>At 11:11:55, Facility "Auth Facility", Level "VERBOSE":: A call, call id = 218235632, has arrived on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:08:47: <38>At 11:12:25, Facility "Auth Facility", Level "VERBOSE":: A call, call id = 218235633, has arrived on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:09:07: <38>At 11:12:46, Facility "Auth Facility", Level "COMMON":: A call is established, call id 218235633, on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:09:10: <38>At 11:12:49, Facility "Auth Facility", Level "COMMON":: The connection for call id 218235633, on if slot:14/mod:3 was dropped for user UNKNOWN x.x.x.x: Thu Apr 8 12:09:17: <38>At 11:12:55, Facility "Auth Facility", Level "VERBOSE":: A call, call id = 218235634, has arrived on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:09:47: <38>At 11:13:25, Facility "Auth Facility", Level "VERBOSE":: A call, call id = 218235635, has arrived on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:10:07: <38>At 11:13:46, Facility "Auth Facility", Level "COMMON":: A call is established, call id 218235635, on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:10:10: <38>At 11:13:49, Facility "Auth Facility", Level "COMMON":: The connection for call id 218235635, on if slot:14/mod:3 was dropped for user UNKNOWN x.x.x.x: Thu Apr 8 12:10:17: <38>At 11:13:56, Facility "Auth Facility", Level "VERBOSE":: A call, call id = 218235636, has arrived on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:10:32: <38>At 11:14:11, Facility "Auth Facility", Level "COMMON":: A call is established, call id 218235636, on interface slot:14/mod:3 x.x.x.x: Thu Apr 8 12:10:41: <38>At 11:14:19, Facility "Auth Facility", Level "COMMON":: The connection for call id 218235636, on if slot:14/mod:3 was dropped for user UNKNOWN
Subject: RE: (usr-tc) ISDN Connect Problem
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-04-08 15:56:09
We had the same problem with a customer who had a Adtran Express XRT. Try this from Adtrans FAQ page. I'm not=20 sure if it will help the 3000 but our symptoms were the=20 same as yours and it helped him right away. http://www.adtran.com/support/faqs/xr_xrt/listing.html The second channel is not being properly authenticated because Linux is = not able to respond to a CHAP password challenge on the second channel. Set Linux to use PAP (Password Authentication Protocol) instead of CHAP and = set register S118=3D32 on the ADTRAN Express XR=AE/XRT=AE. This setting = causes the ADTRAN Express XR=AE/XRT=AE to "spoof" the CHAP authentication on the second channel. > -----Original Message----- > From: Jim Johnson [mailto:jim@perigee.net] > Sent: Thursday, April 08, 1999 3:44 PM > To: usr-tc Mailing List > Subject: (usr-tc) ISDN Connect Problem >=20 >=20 >=20 >=20 > We are having another connect problem with an ISDN customer. =20 >=20 > He has an Adtran Express 3000. When the call is made it gets to the > username and password and then drops him, occasionally it will get > through that and we can monitor him through mon ppp. Most of those > times, he gets dropped during an IPCP Config Request. =20 > Occasionally, he > will get connected and stay connected. >=20 > I had a customer on Tues. who reported a similar problem. The IPCP > Config Request from the TC chassis was consider invalid and=20 > the call was > terminated. In both cases, the "Reason for call failure" column = shows > "normaUserCallClear(73)". >=20 > We are using ARCs w/4.1.59-6 and HDMS w/1.2.43 >=20 > Regards, >=20 > Jim Johnson >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >=20
Subject: Re: (usr-tc) ISDN connect failures
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-08 16:10:07
On Thu, 8 Apr 1999, Blake Fithen wrote: > hello, we're having a trouble with ISDN customers not being > able to connect for extended periods of time. The caller will > be online for any amount of time, then the connection is > dropped. After that they repeatedly try to connect without > success. This is happening to several makes/models of > ISDN router. I can see them hitting the modem but the call > never completes. No radius dialog, no ppp dialog using > "mon radius" and "mon ppp". TCM shows "RingRcvd" and > then "Link negotiation" in the "Operational Status of a > modem" column. About 10 seconds later the call drops and > the "Reason for call failure" column shows > "normaUserCallClear(73)" then the cycle continues. But > without intervention or any resetting on the hubs they > eventually connect anywhere from 10 minutes to several > hours later. I'm running 1.2.43 and 4.1.59-6. PPP offloading > is enabled and PPP BACP and BAP are disabled. We > have a totally different ARC chassis running the same code > revisions but the problem remains with that chassis. The > chassis has 6 DSP's, one ARC and one 70 AMP PSU. Need to find out what is happening when the call is being presented. From the information above it looks like the call is never completed. We would need enable tap on the hiper arc and see if the modem is presenting the call or not to the hiper arc. Would recommend that you open a ticket for a tech to collect info. regards krish > > Any thoughts would be greatly appreciated. > blake > > syslog output: > > x.x.x.x: Thu Apr 8 12:08:09: <38>At 11:11:48, Facility "Auth > Facility", Level "COMMON":: The connection for call id 218235631, on if > slot:14/mod:3 was dropped for user UNKNOWN > x.x.x.x: Thu Apr 8 12:08:16: <38>At 11:11:55, Facility "Auth > Facility", Level "VERBOSE":: A call, call id = 218235632, has arrived on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:08:47: <38>At 11:12:25, Facility "Auth > Facility", Level "VERBOSE":: A call, call id = 218235633, has arrived on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:09:07: <38>At 11:12:46, Facility "Auth > Facility", Level "COMMON":: A call is established, call id 218235633, on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:09:10: <38>At 11:12:49, Facility "Auth > Facility", Level "COMMON":: The connection for call id 218235633, on if > slot:14/mod:3 was dropped for user UNKNOWN > x.x.x.x: Thu Apr 8 12:09:17: <38>At 11:12:55, Facility "Auth > Facility", Level "VERBOSE":: A call, call id = 218235634, has arrived on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:09:47: <38>At 11:13:25, Facility "Auth > Facility", Level "VERBOSE":: A call, call id = 218235635, has arrived on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:10:07: <38>At 11:13:46, Facility "Auth > Facility", Level "COMMON":: A call is established, call id 218235635, on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:10:10: <38>At 11:13:49, Facility "Auth > Facility", Level "COMMON":: The connection for call id 218235635, on if > slot:14/mod:3 was dropped for user UNKNOWN > x.x.x.x: Thu Apr 8 12:10:17: <38>At 11:13:56, Facility "Auth > Facility", Level "VERBOSE":: A call, call id = 218235636, has arrived on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:10:32: <38>At 11:14:11, Facility "Auth > Facility", Level "COMMON":: A call is established, call id 218235636, on > interface slot:14/mod:3 > x.x.x.x: Thu Apr 8 12:10:41: <38>At 11:14:19, Facility "Auth > Facility", Level "COMMON":: The connection for call id 218235636, on if > slot:14/mod:3 was dropped for user UNKNOWN > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) ISDN connect failures
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-04-08 16:22:02
OK - not to be a jerk or anything but I'd rather not try to open a case just yet - with an exception of a few individuals at 3com tech support, I am thoroughly frustrated with the QOS I pay for and it's too much of a pain to tell whoever picks up the case to go find the competent ones. But that's a different problem. I Did a "add tap user blakehome screen" waited for about 10 minutes with no tap traffic output even though I was getting same dialog as before in Performance monitor with my SPID in the appropriate column. Then, all of the sudden the TAP traffic started and my ISDN device got logged in. Some TAP output with lots of "IN:" and "OUT:" from the top was lost. So what does this tell me? TAP USER blakehome on slot:14/mod:3 IN: 11: ....<abcdefghijk TAP USER blakehome on slot:14/mod:3 IN: 11: lmnopqrstuvwxyza TAP USER blakehome on slot:14/mod:3 IN: 11: bcdef TAP USER blakehome on slot:14/mod:3 IN: 12: ...=....!E..4F.. TAP USER blakehome on slot:14/mod:3 IN: 12: .@.0............ TAP USER blakehome on slot:14/mod:3 IN: 12: .. s............ TAP USER blakehome on slot:14/mod:3 IN: 12: ............. TAP USER blakehome on slot:14/mod:3 IN: 13: ...=....!E..4F.. TAP USER blakehome on slot:14/mod:3 IN: 13: .@.0............ TAP USER blakehome on slot:14/mod:3 IN: 13: .. s............ TAP USER blakehome on slot:14/mod:3 IN: 13: ............. TAP USER blakehome on slot:14/mod:3 IN: 14: ...=....!E..4F.. TAP USER blakehome on slot:14/mod:3 IN: 14: .@.0............ TAP USER blakehome on slot:14/mod:3 IN: 14: .. s............ TAP USER blakehome on slot:14/mod:3 IN: 14: ............. TAP USER blakehome on slot:14/mod:3 IN: 15: ...=....!E..4F.. TAP USER blakehome on slot:14/mod:3 IN: 15: .@.0............ TAP USER blakehome on slot:14/mod:3 IN: 15: .. s............ TAP USER blakehome on slot:14/mod:3 IN: 15: ............. TAP USER blakehome on slot:14/mod:3 OUT: 16: ...!E..<u+..~... TAP USER blakehome on slot:14/mod:3 OUT: 16: ...............< TAP USER blakehome on slot:14/mod:3 OUT: 16: abcdefghijklmnop TAP USER blakehome on slot:14/mod:3 OUT: 16: qrstuvwxyzabcdef TAP USER blakehome on slot:14/mod:3 IN: 17: ...=....!E..<F.. TAP USER blakehome on slot:14/mod:3 IN: 17: ...s............ TAP USER blakehome on slot:14/mod:3 IN: 17: ....<abcdefghijk TAP USER blakehome on slot:14/mod:3 IN: 17: lmnopqrstuvwxyza TAP USER blakehome on slot:14/mod:3 IN: 17: bcdef TAP USER blakehome on slot:14/mod:3 IN: 18: ...=....!E..4F.. TAP USER blakehome on slot:14/mod:3 IN: 18: .@./............ TAP USER blakehome on slot:14/mod:3 IN: 18: .. s............ TAP USER blakehome on slot:14/mod:3 IN: 18: ............. > -----Original Message----- > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > Sent: Thursday, April 08, 1999 4:10 PM > To: Blake Fithen > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) ISDN connect failures > > > On Thu, 8 Apr 1999, Blake Fithen wrote: > > > hello, we're having a trouble with ISDN customers not being > > able to connect for extended periods of time. The caller will > > be online for any amount of time, then the connection is > > dropped. After that they repeatedly try to connect without > > success. This is happening to several makes/models of > > ISDN router. I can see them hitting the modem but the call > > never completes. No radius dialog, no ppp dialog using > > "mon radius" and "mon ppp". TCM shows "RingRcvd" and > > then "Link negotiation" in the "Operational Status of a > > modem" column. About 10 seconds later the call drops and > > the "Reason for call failure" column shows > > "normaUserCallClear(73)" then the cycle continues. But > > without intervention or any resetting on the hubs they > > eventually connect anywhere from 10 minutes to several > > hours later. I'm running 1.2.43 and 4.1.59-6. PPP offloading > > is enabled and PPP BACP and BAP are disabled. We > > have a totally different ARC chassis running the same code > > revisions but the problem remains with that chassis. The > > chassis has 6 DSP's, one ARC and one 70 AMP PSU. > > Need to find out what is happening when the call is being presented. > From the information above it looks like the call is never > completed. We > would need enable tap on the hiper arc and see if the modem > is presenting > the call or not to the hiper arc. Would recommend that you > open a ticket > for a tech to collect info. > > regards > > krish > > > > > Any thoughts would be greatly appreciated. > > blake > > > > syslog output: > > > > x.x.x.x: Thu Apr 8 12:08:09: <38>At 11:11:48, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235631, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > x.x.x.x: Thu Apr 8 12:08:16: <38>At 11:11:55, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235632, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:08:47: <38>At 11:12:25, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235633, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:09:07: <38>At 11:12:46, > Facility "Auth > > Facility", Level "COMMON":: A call is established, call id > 218235633, on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:09:10: <38>At 11:12:49, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235633, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > x.x.x.x: Thu Apr 8 12:09:17: <38>At 11:12:55, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235634, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:09:47: <38>At 11:13:25, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235635, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:07: <38>At 11:13:46, > Facility "Auth > > Facility", Level "COMMON":: A call is established, call id > 218235635, on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:10: <38>At 11:13:49, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235635, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > x.x.x.x: Thu Apr 8 12:10:17: <38>At 11:13:56, > Facility "Auth > > Facility", Level "VERBOSE":: A call, call id = 218235636, > has arrived on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:32: <38>At 11:14:11, > Facility "Auth > > Facility", Level "COMMON":: A call is established, call id > 218235636, on > > interface slot:14/mod:3 > > x.x.x.x: Thu Apr 8 12:10:41: <38>At 11:14:19, > Facility "Auth > > Facility", Level "COMMON":: The connection for call id > 218235636, on if > > slot:14/mod:3 was dropped for user UNKNOWN > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) RIP updates on assigned pool
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-08 16:34:45
Brian Elfert said once upon a time: > >For some reason, some of my Netservers (All running 3.7.24) won't >broadcast any IPs in their assigned pool via RIP (v1). They will >broadcast static IPs not in the assigned pool. > >Any ideas? On the Cisco, I can see updates coming in, but none from any >of the IP pools on some of the Netservers. There was a bug that had this effect a long time ago. Unfortunately, I can't remember the details of it. If you search back through the archives you'll probably find me bitching about it. I seem to remember the solution was a code-update, so I don't know why you're suffering from it.
Subject: (usr-tc) multicasting over ARC's?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-08 16:35:52
Is anyone doing multicasting over their ARC's? Did you need to do anything to get it to run?
Subject: (usr-tc) ISDN Connect Problem
From: Jim Johnson <jim@perigee.net>
Date: 1999-04-08 16:43:48
We are having another connect problem with an ISDN customer. He has an Adtran Express 3000. When the call is made it gets to the username and password and then drops him, occasionally it will get through that and we can monitor him through mon ppp. Most of those times, he gets dropped during an IPCP Config Request. Occasionally, he will get connected and stay connected. I had a customer on Tues. who reported a similar problem. The IPCP Config Request from the TC chassis was consider invalid and the call was terminated. In both cases, the "Reason for call failure" column shows "normaUserCallClear(73)". We are using ARCs w/4.1.59-6 and HDMS w/1.2.43 Regards, Jim Johnson
Subject: (usr-tc) TCM vs. TFTP
From: Brian <signal@shreve.net>
Date: 1999-04-09 00:31:22
Why is TCM so slow? I started a transfer of 4.1.59-6 from TCM into 2 ARC's via Software Download. During the time of the download I was able to upgrade 6 other arc's by just using UNIX tftp. When I was finished, SDL via TCM still had a another few minutes to go! Each tftp via UNIX took just 43 seconds. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) TCM vs. TFTP
From: Brian <signal@shreve.net>
Date: 1999-04-09 01:39:14
> > Unless you're referring to tftp'ing the file directly to the ARC > itself, in which case there's a big difference between dumping it to > the flash filesystem that way versus going through the NMC's > management bus interface (which is much lower bandwidth and smaller > packet chunks). Comparing an NMC download versus a tftp right to the > ARC could certainly appear far slower. > > -- David Yes, that's what I was comparing. I thought TCM would have tftp'ed it to the ARC directly, I didn't realize it still used the NMC for ARC code transfers. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) Tftp'ing to the ARC
From: Brian <signal@shreve.net>
Date: 1999-04-09 01:43:27
Does anyone have any suggestions about what to do when your tftp to an ARC fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It worked fine in all my other ARC's. I know I can probably erase the config and start afresh, but I am hoping someone has a more recoverable solution. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) TCM vs. TFTP
From: David Bolen <db3l@ans.net>
Date: 1999-04-09 02:09:40
Brian <signal@shreve.net> writes: > During the time of the download I was able to upgrade 6 other arc's by > just using UNIX tftp. When I was finished, SDL via TCM still had a > another few minutes to go! Each tftp via UNIX took just 43 seconds. Hmm, It's hard to say for your specific test, but one possibility is to be careful to time the entire process. Unlike SDL-1 cards (like the quads), with SDL-2 (the HiPer cards) the NMC can accept a code image faster than it can actually transmit it to the appropriate cards, so there can be a lag from completion of tftp to all the code getting to the cards. cards. So while your tftp may have completed, if you check the command table for the slots involved, you may find that they aren't indicated as being done yet, since the NMC is still transmitting the code internally in the chassis. My guess is that TCM is monitoring the command table for completion before it actually declares the process done. The other thing to check is if you're comparing HiperNMCs with older 486 NMCs. The "wire speed" at which the NMC can receive the new code is far faster on the HiperNMC than the 486 NMC. Although to be honest, even in a HiperNMC case, I don't think I've seen it that fast. Unless you're referring to tftp'ing the file directly to the ARC itself, in which case there's a big difference between dumping it to the flash filesystem that way versus going through the NMC's management bus interface (which is much lower bandwidth and smaller packet chunks). Comparing an NMC download versus a tftp right to the ARC could certainly appear far slower. -- David
Subject: Re: (usr-tc) TCM vs. TFTP
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-09 02:14:52
Just curious -- When you did the Unix tftp, did you tftp it directly to the ARC, or to the NMC? TCM sends it to the NMC. The Perl script I wrote for flashing cards also sends it to the NMC (using Unix tftp), and it's exactly as slow as TCM -- pretty much the same transfer time you're seeing. I think the last one I did said about 11 Kbits/sec. My Sprint PCS phone transmits data faster than that :) So if you're doing ARCs, tftping directly to the ARC is probably the way to go (I've never tried it), but it's kinda hard to do that with DSP's, Quads, NETservers, or whatever else... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Fri, 9 Apr 1999, Brian wrote: > > Why is TCM so slow? I started a transfer of 4.1.59-6 from TCM into 2 > ARC's via Software Download. > > During the time of the download I was able to upgrade 6 other arc's by > just using UNIX tftp. When I was finished, SDL via TCM still had a > another few minutes to go! Each tftp via UNIX took just 43 seconds. > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) TCM vs. TFTP
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-09 02:14:52
Just curious -- When you did the Unix tftp, did you tftp it directly to the ARC, or to the NMC? TCM sends it to the NMC. The Perl script I wrote for flashing cards also sends it to the NMC (using Unix tftp), and it's exactly as slow as TCM -- pretty much the same transfer time you're seeing. I think the last one I did said about 11 Kbits/sec. My Sprint PCS phone transmits data faster than that :) So if you're doing ARCs, tftping directly to the ARC is probably the way to go (I've never tried it), but it's kinda hard to do that with DSP's, Quads, NETservers, or whatever else... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Fri, 9 Apr 1999, Brian wrote: > > Why is TCM so slow? I started a transfer of 4.1.59-6 from TCM into 2 > ARC's via Software Download. > > During the time of the download I was able to upgrade 6 other arc's by > just using UNIX tftp. When I was finished, SDL via TCM still had a > another few minutes to go! Each tftp via UNIX took just 43 seconds. > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) TCM vs. TFTP
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-09 02:18:24
On Fri, 9 Apr 1999, David Bolen wrote: > The other thing to check is if you're comparing HiperNMCs with older > 486 NMCs. The "wire speed" at which the NMC can receive the new code > is far faster on the HiperNMC than the 486 NMC. Now here's something I've been meaning to ask about.. I've heard *very* little about this "HiPer NMC", other than it seems to be Pentium based (what speed?) rather than 486 based. What else is different about it exactly? Are there any applications yet that require a Pentium one instead of a 486(SX)? Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: RE: (usr-tc) ISDN connect failures
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-09 10:21:43
On Thu, 8 Apr 1999, Blake Fithen wrote: > OK - not to be a jerk or anything but I'd rather not try to open > a case just yet - with an exception of a few individuals at 3com > tech support, I am thoroughly frustrated with the QOS I pay for > and it's too much of a pain to tell whoever picks up the case to > go find the competent ones. But that's a different problem. > Well we need to access your chassis and debug the DSP and the hiper arc. For this we need to get someone in support to work with you. And this requires a ticket. Open a support ticket and send me an email with the ticket number - I will talk with the tech and get help him analyze the problem. > I Did a "add tap user blakehome screen" waited for about 10 > minutes with no tap traffic output even though I was getting > same dialog as before in Performance monitor with my SPID in the > appropriate column. Then, all of the sudden the TAP traffic > started and my ISDN device got logged in. Some TAP output with > lots of "IN:" and "OUT:" from the top was lost. So what does > this tell me? > This does not tell me much either - we need ascii and hex dump to see what is happening. regards krish > TAP USER blakehome on slot:14/mod:3 IN: 11: ....<abcdefghijk > TAP USER blakehome on slot:14/mod:3 IN: 11: lmnopqrstuvwxyza > TAP USER blakehome on slot:14/mod:3 IN: 11: bcdef > TAP USER blakehome on slot:14/mod:3 IN: 12: ...=....!E..4F.. > TAP USER blakehome on slot:14/mod:3 IN: 12: .@.0............ > TAP USER blakehome on slot:14/mod:3 IN: 12: .. s............ > TAP USER blakehome on slot:14/mod:3 IN: 12: ............. > TAP USER blakehome on slot:14/mod:3 IN: 13: ...=....!E..4F.. > TAP USER blakehome on slot:14/mod:3 IN: 13: .@.0............ > TAP USER blakehome on slot:14/mod:3 IN: 13: .. s............ > TAP USER blakehome on slot:14/mod:3 IN: 13: ............. > TAP USER blakehome on slot:14/mod:3 IN: 14: ...=....!E..4F.. > TAP USER blakehome on slot:14/mod:3 IN: 14: .@.0............ > TAP USER blakehome on slot:14/mod:3 IN: 14: .. s............ > TAP USER blakehome on slot:14/mod:3 IN: 14: ............. > TAP USER blakehome on slot:14/mod:3 IN: 15: ...=....!E..4F.. > TAP USER blakehome on slot:14/mod:3 IN: 15: .@.0............ > TAP USER blakehome on slot:14/mod:3 IN: 15: .. s............ > TAP USER blakehome on slot:14/mod:3 IN: 15: ............. > TAP USER blakehome on slot:14/mod:3 OUT: 16: ...!E..<u+..~... > TAP USER blakehome on slot:14/mod:3 OUT: 16: ...............< > TAP USER blakehome on slot:14/mod:3 OUT: 16: abcdefghijklmnop > TAP USER blakehome on slot:14/mod:3 OUT: 16: qrstuvwxyzabcdef > TAP USER blakehome on slot:14/mod:3 IN: 17: ...=....!E..<F.. > TAP USER blakehome on slot:14/mod:3 IN: 17: ...s............ > TAP USER blakehome on slot:14/mod:3 IN: 17: ....<abcdefghijk > TAP USER blakehome on slot:14/mod:3 IN: 17: lmnopqrstuvwxyza > TAP USER blakehome on slot:14/mod:3 IN: 17: bcdef > TAP USER blakehome on slot:14/mod:3 IN: 18: ...=....!E..4F.. > TAP USER blakehome on slot:14/mod:3 IN: 18: .@./............ > TAP USER blakehome on slot:14/mod:3 IN: 18: .. s............ > TAP USER blakehome on slot:14/mod:3 IN: 18: ............. > > > > > -----Original Message----- > > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > > Sent: Thursday, April 08, 1999 4:10 PM > > To: Blake Fithen > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) ISDN connect failures > > > > > > On Thu, 8 Apr 1999, Blake Fithen wrote: > > > > > hello, we're having a trouble with ISDN customers not being > > > able to connect for extended periods of time. The caller will > > > be online for any amount of time, then the connection is > > > dropped. After that they repeatedly try to connect without > > > success. This is happening to several makes/models of > > > ISDN router. I can see them hitting the modem but the call > > > never completes. No radius dialog, no ppp dialog using > > > "mon radius" and "mon ppp". TCM shows "RingRcvd" and > > > then "Link negotiation" in the "Operational Status of a > > > modem" column. About 10 seconds later the call drops and > > > the "Reason for call failure" column shows > > > "normaUserCallClear(73)" then the cycle continues. But > > > without intervention or any resetting on the hubs they > > > eventually connect anywhere from 10 minutes to several > > > hours later. I'm running 1.2.43 and 4.1.59-6. PPP offloading > > > is enabled and PPP BACP and BAP are disabled. We > > > have a totally different ARC chassis running the same code > > > revisions but the problem remains with that chassis. The > > > chassis has 6 DSP's, one ARC and one 70 AMP PSU. > > > > Need to find out what is happening when the call is being presented. > > From the information above it looks like the call is never > > completed. We > > would need enable tap on the hiper arc and see if the modem > > is presenting > > the call or not to the hiper arc. Would recommend that you > > open a ticket > > for a tech to collect info. > > > > regards > > > > krish > > > > > > > > Any thoughts would be greatly appreciated. > > > blake > > > > > > syslog output: > > > > > > x.x.x.x: Thu Apr 8 12:08:09: <38>At 11:11:48, > > Facility "Auth > > > Facility", Level "COMMON":: The connection for call id > > 218235631, on if > > > slot:14/mod:3 was dropped for user UNKNOWN > > > x.x.x.x: Thu Apr 8 12:08:16: <38>At 11:11:55, > > Facility "Auth > > > Facility", Level "VERBOSE":: A call, call id = 218235632, > > has arrived on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:08:47: <38>At 11:12:25, > > Facility "Auth > > > Facility", Level "VERBOSE":: A call, call id = 218235633, > > has arrived on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:09:07: <38>At 11:12:46, > > Facility "Auth > > > Facility", Level "COMMON":: A call is established, call id > > 218235633, on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:09:10: <38>At 11:12:49, > > Facility "Auth > > > Facility", Level "COMMON":: The connection for call id > > 218235633, on if > > > slot:14/mod:3 was dropped for user UNKNOWN > > > x.x.x.x: Thu Apr 8 12:09:17: <38>At 11:12:55, > > Facility "Auth > > > Facility", Level "VERBOSE":: A call, call id = 218235634, > > has arrived on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:09:47: <38>At 11:13:25, > > Facility "Auth > > > Facility", Level "VERBOSE":: A call, call id = 218235635, > > has arrived on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:10:07: <38>At 11:13:46, > > Facility "Auth > > > Facility", Level "COMMON":: A call is established, call id > > 218235635, on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:10:10: <38>At 11:13:49, > > Facility "Auth > > > Facility", Level "COMMON":: The connection for call id > > 218235635, on if > > > slot:14/mod:3 was dropped for user UNKNOWN > > > x.x.x.x: Thu Apr 8 12:10:17: <38>At 11:13:56, > > Facility "Auth > > > Facility", Level "VERBOSE":: A call, call id = 218235636, > > has arrived on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:10:32: <38>At 11:14:11, > > Facility "Auth > > > Facility", Level "COMMON":: A call is established, call id > > 218235636, on > > > interface slot:14/mod:3 > > > x.x.x.x: Thu Apr 8 12:10:41: <38>At 11:14:19, > > Facility "Auth > > > Facility", Level "COMMON":: The connection for call id > > 218235636, on if > > > slot:14/mod:3 was dropped for user UNKNOWN > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) CRC error on boot configuration
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-09 10:26:23
On Thu, 8 Apr 1999, d baud wrote: > I just received a HiperCard that I installed on the chassis: > I plugged the console cable to perform the quicksetup routine and I > noticed that it gave me the following error as soon as it did a Save > All. > The error message is the following: > WARNING: CRC error on boot configuration. Defaulting it > (repeating for about 15 lines) > > At first I suspected the code used was faulty, so I reseated the card > and issued the regular AT{Z} command to send the current ne040159-6.dmf > code. Once finished, I try a "save all" and still nothing happens. > > I then decided to do a: AT{ZF} command with the same code. > Unfortunately still the same error message > > I then called the tech people at USR, and the lady said that this might > be a debug and unharmful code. So she issued some command to remove > those messages and refused to tell me what it was because it was "too > dificult to understand" > Well now I don't get the error message when I "save all" but the > following error apears at boot time: > Error writing configuration to EEPROM > WARNING: CRC error on boot configuration. Defaulting it EEPROM ... Downloading code does not write to the EEPROM. This looks like that for some reason the EEPROM has been erased. What is the ticket number? that way can get access to your card and see what is being done. As far as I know there is no debug code etc. Get me the ticket number will talk to the lady. krish > > Anyone had this issue before ? > > Donald Baud > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) RIP updates on assigned pool
From: Brian Elfert <brian@citilink.com>
Date: 1999-04-09 10:27:32
On Thu, 8 Apr 1999, Pete Ashdown wrote: > >Any ideas? On the Cisco, I can see updates coming in, but none from any > >of the IP pools on some of the Netservers. > > There was a bug that had this effect a long time ago. Unfortunately, I > can't remember the details of it. If you search back through the archives > you'll probably find me bitching about it. I seem to remember the solution > was a code-update, so I don't know why you're suffering from it. David Bolen helped me fix this. RIPv1 is classful. It was just broadcasting the route for the /24 since the /32s are in that /24. Adding the dialup /24s to the netmask table with a netmask of 255.255.255.255 fixed things right up. Now, I'm thinking of switching to RIPv2. Anybody have any tips on doing that? Is it worth it? Brian
Subject: Re: (usr-tc) TCM vs. TFTP
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-09 10:28:16
On Fri, 9 Apr 1999, Brian wrote: > > Why is TCM so slow? I started a transfer of 4.1.59-6 from TCM into 2 > ARC's via Software Download. > > During the time of the download I was able to upgrade 6 other arc's by > just using UNIX tftp. When I was finished, SDL via TCM still had a > another few minutes to go! Each tftp via UNIX took just 43 seconds. Using TCM you are sending the code to the nmc which is then sending the file via management bus to the hiper arc - which is slow. krish > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Tftp'ing to the ARC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-09 10:29:38
On Fri, 9 Apr 1999, Brian wrote: > > Does anyone have any suggestions about what to do when your tftp to an ARC > fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It > worked fine in all my other ARC's. > > I know I can probably erase the config and start afresh, but I am hoping > someone has a more recoverable solution. You can program the hiper arc to get the file on boot up from a tftp server. do a set bootr ip ? you will see the command necessary krish > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) ISDN connect failures
From: matthews <matthews@brunnet.net>
Date: 1999-04-09 12:17:51
On Friday, April 09, 1999 12:22 PM, Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] wrote: > Well we need to access your chassis and debug the DSP and the hiper arc. > For this we need to get someone in support to work with you. And this > requires a ticket. Open a support ticket and send me an email with the > ticket number - I will talk with the tech and get help him analyze the > problem. > Is it possible to open a ticket without a support contract?
Subject: Re: (usr-tc) RIP updates on assigned pool
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-09 12:20:06
Thus spake Brian Elfert >Now, I'm thinking of switching to RIPv2. Anybody have any tips on doing >that? Is it worth it? RIPv2 is pretty much backward compatible with RIPv2, so just switch your stuff to start using RIPv2 and it'll pretty much just work. I'd start with your cisco router to begin with, and then switch everything else. Yes, its most definitely worth it. Things just work better when you have a routing protocol that has an understanding of netmasks. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) For sale USR Netserver 8I
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-04-09 13:35:22
For sale, USR Netserver 8I box. has v.90 installed. tony
Subject: Re: (usr-tc) TCM vs. TFTP
From: David Bolen <db3l@ans.net>
Date: 1999-04-09 14:09:35
Brian <signal@shreve.net> writes: > Yes, that's what I was comparing. I thought TCM would have tftp'ed it to > the ARC directly, I didn't realize it still used the NMC for ARC code > transfers. If you think about it, it makes sense. TCM only knows the IP address (and community strings and such) for your NMC. Everything it does is via the NMC, downloads included. To directly do the ARC, it would have to know all the individual IP addresses and maintain separate connections to them, not to mention having to do distinct tftps rather than a single one via the NMC. Not to mention handling the ARC completely separately from any other card. It's a bit slower, but it's more standardized to stick with NMC approach, which is what we also do with our tools. An ARC download may take 10-12 minutes or so (although it doesn't grow linearly with multiple cards) but it's handled just as another component compared to all other cards, which I consider a big advantage. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) RIP updates on assigned pool
From: David Bolen <db3l@ans.net>
Date: 1999-04-09 14:13:12
Brian Elfert <brian@citilink.com> writes: > Now, I'm thinking of switching to RIPv2. Anybody have any tips on doing > that? Is it worth it? To my mind it depends on your configuration, and what you do with those routes after they leave the NETServer. When it comes down to it, all RIPv2 is going to buy you is the ability to announce an arbitrary prefix size. In our case, the routes never do anything more than get installed on a local Cisco (propagation beyond that point is not from RIP redistribution), so we've never bothered to switch beyond RIPv1. It does the job of getting that last "next hop" right just fine. However, if you're automatically redistributing such routes into other IGPs such as OSPF or IBGP then RIPv2 may permit you to avoid injecting host routes and instead use more appropriate prefix sizes. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) TCM vs. TFTP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-09 14:23:37
Thus spake David Bolen >Brian <signal@shreve.net> writes: >> Yes, that's what I was comparing. I thought TCM would have tftp'ed >> it to the ARC directly, I didn't realize it still used the NMC for >> ARC code transfers. >If you think about it, it makes sense. TCM only knows the IP address >(and community strings and such) for your NMC. Everything it does is >via the NMC, downloads included. >To directly do the ARC, it would have to know all the individual IP >addresses and maintain separate connections to them, not to mention >having to do distinct tftps rather than a single one via the NMC. Not >to mention handling the ARC completely separately from any other card. Very true in all cases...however one minor nit here. :) It is conceivable that TCM could come up with the IP addresses of the Arcs...it would just have to hit the NMC's SNMP agent to get them. Keeping in mind that the NMC can get the IP address for the Arc via the management bus. Yes, this is extremely convoluted and pointless, but it *could* be done. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Configuring a "silent" TC
From: Corneliu Rudeanu <rudy@dntis.ro>
Date: 1999-04-09 17:43:19
Ok I have a TC with the following cards: HiperNMC 3.0/5.6.2, HiperArc 19.0.0/4.1.11, 14 QuadModemV34 and a E1 PRI which I upgraded to CAS 1.2.09 for compatibility with local PTT. I configured the modems' source to priTdm, I made the DS0<-> Modem configuration and set Modem Call Routing method to fixedAssignement. When I try to make a dialup connection (from a client, via E1 phone numbers) I hear nothing (no rings). While enabling Call Control debugs from the CAS Debug (pressing ^D ; btw: this keyboard shortcut is not documented, as far as I read; are there any more?) I get the following debug lines: Menu Selection: (1-18):ds0_res_call_type: dsl: 0, intid: 0, ds0: 1, bct: 73, err: 0 verdict: 1 get_fixed_mdm: span=0, ds0=2, mdm_id=4, err=0 release_ds0: span=0, ds0=2 sfn:ucc_null,evt:20-SETUP_IND,tcid:3328,ucid:0000000C ERR:ucc_gen_error,ucc_setup_in_call,uccidm_allow_mdm_calls,fail,drop_call:,err:0 Note: releasing uccb, DE-ALLOC tcid:3328, ucid: 0000000C release_ds0: span=0, ds0=2 uccu_release_bchs > DE-ALLOC ucid: c release_ds0: span=0, ds0=2 Again, displaying 'Call Control General Error Counters' I get: Menu Selection: (1-18):13 Print Call Control General Error Count Call Control General Error Counters: Din Drop Call no Free MDM: 0 Din Drop Call MDMs not allowed: 15 Din Drop Call MDM(s) reject call: 0 Din Drop Call MDM(s) setup to: 0 Din Drop Call no TDM TS avail: 0 Yet, I'd note that configuring the modems for NIC source, everything worked OK. Any hints? Corneliu Rudeanu DNT Romania
Subject: (usr-tc) netopia
From: Brian <signal@shreve.net>
Date: 1999-04-09 18:53:43
Any issues known between Netopia ISDN routers and 1.2.43/4.1.59-6? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Tftp'ing to the ARC
From: Brian <signal@shreve.net>
Date: 1999-04-09 21:04:14
On Fri, 9 Apr 1999, Tatai SV Krishnan wrote: > On Fri, 9 Apr 1999, Brian wrote: > > > > > Does anyone have any suggestions about what to do when your tftp to an ARC > > fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It > > worked fine in all my other ARC's. > > > > I know I can probably erase the config and start afresh, but I am hoping > > someone has a more recoverable solution. > > You can program the hiper arc to get the file on boot up from a tftp > server. > do a set bootr ip ? > you will see the command necessary But aren't the odds that if I was unable to tftp the netserve.dmf into the ARC, that the arc won't be able to tftp the file into itself upon bootup either? I mean, woudln't I still probably need to erase the config? > > krish > > > > > Brian > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Tftp'ing to the ARC
From: Brian <signal@shreve.net>
Date: 1999-04-09 21:04:14
On Fri, 9 Apr 1999, Tatai SV Krishnan wrote: > On Fri, 9 Apr 1999, Brian wrote: > > > > > Does anyone have any suggestions about what to do when your tftp to an ARC > > fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It > > worked fine in all my other ARC's. > > > > I know I can probably erase the config and start afresh, but I am hoping > > someone has a more recoverable solution. > > You can program the hiper arc to get the file on boot up from a tftp > server. > do a set bootr ip ? > you will see the command necessary But aren't the odds that if I was unable to tftp the netserve.dmf into the ARC, that the arc won't be able to tftp the file into itself upon bootup either? I mean, woudln't I still probably need to erase the config? > > krish > > > > > Brian > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) USR S&A
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-04-10 00:37:20
We purchased a small ISP and need to extract their RADIUS user auth db from USR S&A, text delimited would be fine. Does anyone know how to do this? --jeff ============================================================================ Jeffrey A. Lynch | JORSM Internet, Regional Internet Services email: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
Subject: Re: (usr-tc) USR S&A
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-10 01:48:40
On Sat, 10 Apr 1999, Jeff Lynch wrote: >We purchased a small ISP and need to extract their RADIUS user auth db >from USR S&A, text delimited would be fine. Does anyone know how to do >this? Is it an Access database, postgres database, or text file? As for the later two, the answer is yes. For a small fee, I can generate almost whatever format you want and even remove the USR password encryption :-) --Ricky
Subject: Re: (usr-tc) USR S&A
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-04-10 09:03:48
On Sat, 10 Apr 1999, Ricky Beam wrote: > On Sat, 10 Apr 1999, Jeff Lynch wrote: > >We purchased a small ISP and need to extract their RADIUS user auth db > >from USR S&A, text delimited would be fine. Does anyone know how to do > >this? > > Is it an Access database, postgres database, or text file? Access. Since this was the first time laying hands on USR S&A I couldn't find the clicks to get a view of the user table to save as text delim. > > As for the later two, the answer is yes. For a small fee, I can generate > almost whatever format you want and even remove the USR password > encryption :-) > Hmm, no way to export the user table from the Access version? We just bought a small ISP that's being shut down on Monday. Yeah, it's a kind of fire sale, but there's not that many, so we decided to give it a shot. One of our urgent problems is that neither of us use any realm designations for logins which rules out most proxy solutions. We have paper signup forms with handwritten passwords so we could muttle through with manual data entry. ============================================================================ Jeffrey A. Lynch | JORSM Internet, Regional Internet Services email: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
Subject: Re: (usr-tc) USR S&A
From: Brian <signal@shreve.net>
Date: 1999-04-10 11:07:01
On Sat, 10 Apr 1999, Ricky Beam wrote: > On Sat, 10 Apr 1999, Jeff Lynch wrote: > >We purchased a small ISP and need to extract their RADIUS user auth db > >from USR S&A, text delimited would be fine. Does anyone know how to do > >this? > > Is it an Access database, postgres database, or text file? > > As for the later two, the answer is yes. For a small fee, I can generate > almost whatever format you want and even remove the USR password > encryption :-) > USR S&A works with Postgres? > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) USR S&A
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-10 11:56:48
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Saturday, April 10, 1999 11:07 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) USR S&A | | |On Sat, 10 Apr 1999, Ricky Beam wrote: | |> On Sat, 10 Apr 1999, Jeff Lynch wrote: |> >We purchased a small ISP and need to extract their RADIUS user auth db |> >from USR S&A, text delimited would be fine. Does anyone know how to do |> >this? |> |> Is it an Access database, postgres database, or text file? |> |> As for the later two, the answer is yes. For a small fee, I can generate |> almost whatever format you want and even remove the USR password |> encryption :-) |> | |USR S&A works with Postgres? | UNIX version does. -M
Subject: RE: (usr-tc) USR S&A
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1999-04-10 12:55:42
USR folks, we need to export a user table from the windows/access version. --jeff ============================================================================ Jeffrey A. Lynch | JORSM Internet, Regional Internet Services email: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 On Sat, 10 Apr 1999, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > |Sent: Saturday, April 10, 1999 11:07 AM > |To: usr-tc@lists.xmission.com > |Subject: Re: (usr-tc) USR S&A > | > | > |On Sat, 10 Apr 1999, Ricky Beam wrote: > | > |> On Sat, 10 Apr 1999, Jeff Lynch wrote: > |> >We purchased a small ISP and need to extract their RADIUS user auth db > |> >from USR S&A, text delimited would be fine. Does anyone know how to do > |> >this? > |> > |> Is it an Access database, postgres database, or text file? > |> > |> As for the later two, the answer is yes. For a small fee, I can generate > |> almost whatever format you want and even remove the USR password > |> encryption :-) > |> > | > |USR S&A works with Postgres? > | > > UNIX version does. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > ============================================================================ Jeffrey A. Lynch | JORSM Internet, Regional Internet Services email: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995
Subject: Re: (usr-tc) Tftp'ing to the ARC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-10 17:32:08
On Fri, 9 Apr 1999, Brian wrote: > On Fri, 9 Apr 1999, Tatai SV Krishnan wrote: > > > On Fri, 9 Apr 1999, Brian wrote: > > > > > > > > Does anyone have any suggestions about what to do when your tftp to an ARC > > > fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It > > > worked fine in all my other ARC's. > > > > > > I know I can probably erase the config and start afresh, but I am hoping > > > someone has a more recoverable solution. > > > > You can program the hiper arc to get the file on boot up from a tftp > > server. > > do a set bootr ip ? > > you will see the command necessary > > But aren't the odds that if I was unable to tftp the netserve.dmf into the > ARC, that the arc won't be able to tftp the file into itself upon bootup > either? I mean, woudln't I still probably need to erase the config? > No - the boot process is completely separate process and it copies the new code to flash diffently then a regular tftp process. This process generally works - if this fails there your flash format is required. krish > > > > > krish > > > > > > > > Brian > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) USR S&A
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-10 17:34:19
On Sat, 10 Apr 1999, Jeff Lynch wrote: > We purchased a small ISP and need to extract their RADIUS user auth db > from USR S&A, text delimited would be fine. Does anyone know how to do > this? You can get the users info into a access database and then export it to text format. krish > > --jeff > > ============================================================================ > Jeffrey A. Lynch | JORSM Internet, Regional Internet Services > email: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana > Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN > Autoresponse: info@jorsm.com | Quality Service, Affordable Prices > http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Passwords getting corrupted
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-11 14:46:55
Our radius server (radiator) can log the cleartext passwords sent by the client. I've noticed an interesting pattern, failed attempts followed by succesfull one, with only the last character of the password changed. It has been happening hundreds of times per day. An example would be a failed attempt with the password "cooki^X" followed by an succesfull attempt of "cookie". The transformation isn't fixed, if the same user fails again, it might be "cookiZ" he tries before "cookie". We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. I haven't noticed any correlation between modem speeds, x2/v.90, or anything other that it only appears to be happening on our USR chassis. -- Aaron Nabil
Subject: Re: (usr-tc) Passwords getting corrupted
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-11 20:12:45
Tatai SV Krishnan writes... >On Sun, 11 Apr 1999, Aaron Nabil wrote: >> Our radius server (radiator) can log the cleartext passwords sent by >> the client. I've noticed an interesting pattern, failed attempts followed >> by succesfull one, with only the last character of the password changed. It >> has been happening hundreds of times per day. >> >Is it possible for you to use the tap feature to capture this info? >I have heard reports of this but I have not been able to get any one to >work with me on this. If you can either run tap to syslog and capture >the data or if this is reproduceble on demand then it would be easy for >us to identify the problem. It seems to be associated with particular users, I've sent mail to one to see if he can call in while I'm capturing. >If running tap is a problem then you can try disabling ppp offloading and >see if this problem exits. That would give us somegood info. It's possible I could disable ppp offloading on one card and track to see if the problem doesn't exist there. What is the performance hit of disabling offloading? I'm running 3 DSP's per ARC. -- Aaron Nabil
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-11 20:24:40
On Sun, 11 Apr 1999, Aaron Nabil wrote: > > Our radius server (radiator) can log the cleartext passwords sent by > the client. I've noticed an interesting pattern, failed attempts followed > by succesfull one, with only the last character of the password changed. It > has been happening hundreds of times per day. > > An example would be a failed attempt with the password "cooki^X" > followed by an succesfull attempt of "cookie". The transformation isn't > fixed, if the same user fails again, it might be "cookiZ" he tries before > "cookie". Is it possible for you to use the tap feature to capture this info? I have heard reports of this but I have not been able to get any one to work with me on this. If you can either run tap to syslog and capture the data or if this is reproduceble on demand then it would be easy for us to identify the problem. If running tap is a problem then you can try disabling ppp offloading and see if this problem exits. That would give us somegood info. regards krish > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > I haven't noticed any correlation between modem speeds, x2/v.90, or > anything other that it only appears to be happening on our USR chassis. > > -- > Aaron Nabil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-11 22:32:05
On Sun, 11 Apr 1999, Tatai SV Krishnan wrote: > On Sun, 11 Apr 1999, Aaron Nabil wrote: >=20 > >=20 > > Our radius server (radiator) can log the cleartext passwords sent by > > the client. I've noticed an interesting pattern, failed attempts follo= wed=20 > > by succesfull one, with only the last character of the password changed= =2E It > > has been happening hundreds of times per day. > >=20 > > An example would be a failed attempt with the password "cooki^X"=20 > > followed by an succesfull attempt of "cookie". The transformation isn'= t > > fixed, if the same user fails again, it might be "cookiZ" he tries befo= re > > "cookie". >=20 > Is it possible for you to use the tap feature to capture this info? > I have heard reports of this but I have not been able to get any one to= =20 > work with me on this. If you can either run tap to syslog and capture=20 > the data or if this is reproduceble on demand then it would be easy for= =20 > us to identify the problem. >=20 > If running tap is a problem then you can try disabling ppp offloading and= =20 > see if this problem exits. That would give us somegood info. Ugh, not good. [signal@norad radacct]$ tail -500 password.log |grep juicy Sun Apr 11 22:11:44 1999:923886704:juicy:d00ms:ENCRYPTED:PASS Sun Apr 11 22:12:53 1999:923886773:juicy:d00mI:ENCRYPTED:FAIL Sun Apr 11 22:13:12 1999:923886792:juicy:d00ms:ENCRYPTED:PASS [signal@norad radacct]$ tail -500 password.log |grep thunder Sun Apr 11 22:15:17 1999:923886917:thunder:tbon=EC:ENCRYPTED:FAIL Sun Apr 11 22:15:29 1999:923886929:thunder:tbone:ENCRYPTED:PASS Sun Apr 11 22:25:31 1999:923887531:thunder:tbone:ENCRYPTED:PASS (usernames have been changed to protect the innocent :) ) So the short of it, is that I am seeing this too. Yes I am running ppp offloading as per the release notes. I would say their is a problem. Hopefully this will be a quick one, and a fix will be released soon. Perhaps others can do a check of their RADIUS password logs and look for this type of activity. >=20 > regards > krish >=20 > >=20 > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSP= s. > >=20 > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > anything other that it only appears to be happening on our USR chassis. > >=20 > > --=20 > > Aaron Nabil > >=20 > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > >=20 >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >=20 Brian Feeny (BF304) signal@shreve.net =20 318-222-2638 x 109=09http://www.shreve.net/~signal =20 Network Administrator ShreveNet Inc. (ASN 11881) =09 =20
Subject: (usr-tc) No handshake..
From: Customer Support <webster@yore.net>
Date: 1999-04-11 22:53:37
This is a multi-part message in MIME format. ------=_NextPart_000_0058_01BE846E.22867A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At about 4 this afternoon the TC's DSP's stopped moving data. One of the = clients that were online at the time said they got a "illegal = instruction" fault and where disconnected. I first tried to dial into = the box and found that, although the DSP would pick-up the line, there = was no handshake. Everything looked normal as far as the status = indicators go on the front of the TC cards. I cycled the power using the on/off switch and all the tests seemed = to go just fine. I tried moving the DSP to another slot. I've checked to = make sure that the modems were enabled(using the telnet command "enable = modem_group slot:1") and the show command shows all modems as active. I checked with the phone company (SWBell) and they said they checked = the PRI and everything was OK. I'm running 1.2.5 on the DSP's and 4.1.72 on the ARC and 5.6.2 on = the NMC. Any ideas? I'll be happy to provide any other information. Ray (AKA Webster) ------=_NextPart_000_0058_01BE846E.22867A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>At about 4 this afternoon the TC's = DSP's stopped=20 moving data. One of the clients that were online at the time said they = got a=20 &quot;illegal instruction&quot; fault and where disconnected. I first = tried to=20 dial into the box and found that, although the DSP would pick-up the = line, there=20 was no handshake. Everything looked normal as far as the status = indicators go on=20 the front of the TC cards.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I cycled the = power using the=20 on/off switch and all the tests seemed to go just fine. I tried moving = the DSP=20 to another slot. I've checked to make sure that the modems were = enabled(using=20 the telnet command &quot;enable modem_group slot:1&quot;) and the show = command=20 shows all modems as active.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I checked with = the phone=20 company (SWBell) and they said they checked the PRI and everything was=20 OK.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; I'm running = 1.2.5 on=20 the DSP's and 4.1.72 on the ARC and 5.6.2 on the NMC.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; Any ideas? I'll = be happy to=20 provide any other information.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 = size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 Ray (AKA Webster)<BR></FONT></DIV></BODY></HTML> ------=_NextPart_000_0058_01BE846E.22867A20--
Subject: Re: (usr-tc) No handshake..
From: Customer Support <webster@yore.net>
Date: 1999-04-12 03:57:44
This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01BE8498.9EAAC640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Customer Support <webster@yore.net> To: usr-tc@xmission.com <usr-tc@xmission.com> Date: Sunday, April 11, 1999 10:55 PM Subject: (usr-tc) No handshake.. =20 =20 At about 4 this afternoon the TC's DSP's stopped moving data. One of = the clients that were online at the time said they got a "illegal = instruction" fault and where disconnected. I first tried to dial into = the box and found that, although the DSP would pick-up the line, there = was no handshake. Everything looked normal as far as the status = indicators go on the front of the TC cards. I cycled the power using the on/off switch and all the tests = seemed to go just fine. I tried moving the DSP to another slot. I've = checked to make sure that the modems were enabled(using the telnet = command "enable modem_group slot:1") and the show command shows all = modems as active. I checked with the phone company (SWBell) and they said they = checked the PRI and everything was OK. I'm running 1.2.5 on the DSP's and 4.1.72 on the ARC and 5.6.2 = on the NMC. Any ideas? I'll be happy to provide any other information. =20 Ray (AKA Webster) =20 More to add... I've been trying various things to find something suspect and I = found that if you begin punching random numbers on the telephone after = you dial the trunk number, the handshake will begin. I've checked in = again with the phone co. (SWBell) and they say they are checking their = tranlations now. It seems to me the problem lies with a switch = somewhere. Anyone? ------=_NextPart_000_00B5_01BE8498.9EAAC640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 = HTML//EN"> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: = 5px"> <DIV><FONT face=3DArial size=3D2><B>-----Original = Message-----</B><BR><B>From:=20 </B>Customer Support &lt;<A=20 href=3D"mailto:webster@yore.net">webster@yore.net</A>&gt;<BR><B>To: = </B><A=20 href=3D"mailto:usr-tc@xmission.com">usr-tc@xmission.com</A> &lt;<A=20 = href=3D"mailto:usr-tc@xmission.com">usr-tc@xmission.com</A>&gt;<BR><B>Dat= e:=20 </B>Sunday, April 11, 1999 10:55 PM<BR><B>Subject: </B>(usr-tc) No=20 handshake..<BR><BR></DIV></FONT> <DIV><FONT color=3D#000000 size=3D2>At about 4 this afternoon the = TC's DSP's=20 stopped moving data. One of the clients that were online at the time = said=20 they got a &quot;illegal instruction&quot; fault and where = disconnected. I=20 first tried to dial into the box and found that, although the DSP = would=20 pick-up the line, there was no handshake. Everything looked normal = as far as=20 the status indicators go on the front of the TC cards.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I cycled the = power using=20 the on/off switch and all the tests seemed to go just fine. I tried = moving=20 the DSP to another slot. I've checked to make sure that the modems = were=20 enabled(using the telnet command &quot;enable modem_group = slot:1&quot;) and=20 the show command shows all modems as active.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I checked = with the phone=20 company (SWBell) and they said they checked the PRI and everything = was=20 OK.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; I'm = running 1.2.5=20 on the DSP's and 4.1.72 on the ARC and 5.6.2 on the = NMC.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; Any ideas? = I'll be happy=20 to provide any other information.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000=20 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ray (AKA=20 Webster)</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT color=3D#000000=20 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 = size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 More to add...</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; I've been = trying various=20 things to find something suspect and I found that if you begin = punching=20 random numbers on the telephone after you dial the trunk number, the = handshake will begin. I've checked in again with the phone co. = (SWBell) and=20 they say they are checking their tranlations now. It seems to me the = problem=20 lies with a switch somewhere.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; = Anyone?</FONT></DIV> <DIV><FONT color=3D#000000 = size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_00B5_01BE8498.9EAAC640--
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 07:55:25
> Tatai SV Krishnan writes... > >On Sun, 11 Apr 1999, Aaron Nabil wrote: > >> Our radius server (radiator) can log the cleartext passwords sent by > >> the client. I've noticed an interesting pattern, failed attempts followed > >> by succesfull one, with only the last character of the password changed. It > >> has been happening hundreds of times per day. > >> > >Is it possible for you to use the tap feature to capture this info? > >I have heard reports of this but I have not been able to get any one to > >work with me on this. If you can either run tap to syslog and capture > >the data or if this is reproduceble on demand then it would be easy for > >us to identify the problem. > > It seems to be associated with particular users, I've sent mail to one > to see if he can call in while I'm capturing. Then you can just add tap for these users. When ever they log in the info will be logged to syslog. > > >If running tap is a problem then you can try disabling ppp offloading and > >see if this problem exits. That would give us somegood info. > > It's possible I could disable ppp offloading on one card and track > to see if the problem doesn't exist there. Unfortunately it is not possible to disable ppp offloading on one card. You have to disable it on all the cards. > > What is the performance hit of disabling offloading? I'm running 3 DSP's > per ARC. I do not have a specific number or percentage. When you disable ppp offloading the ppp framing is done by hiper arc software compared to modem which is done in hardware. I would say users will not notice the difference. krish > > -- > Aaron Nabil >
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 08:00:14
On Sun, 11 Apr 1999, Brian wrote: > On Sun, 11 Apr 1999, Tatai SV Krishnan wrote: >=20 > > On Sun, 11 Apr 1999, Aaron Nabil wrote: > >=20 > > >=20 > > > Our radius server (radiator) can log the cleartext passwords sent by > > > the client. I've noticed an interesting pattern, failed attempts fol= lowed=20 > > > by succesfull one, with only the last character of the password chang= ed. It > > > has been happening hundreds of times per day. > > >=20 > > > An example would be a failed attempt with the password "cooki^X"=20 > > > followed by an succesfull attempt of "cookie". The transformation is= n't > > > fixed, if the same user fails again, it might be "cookiZ" he tries be= fore > > > "cookie". > >=20 > > Is it possible for you to use the tap feature to capture this info? > > I have heard reports of this but I have not been able to get any one to= =20 > > work with me on this. If you can either run tap to syslog and capture= =20 > > the data or if this is reproduceble on demand then it would be easy for= =20 > > us to identify the problem. > >=20 > > If running tap is a problem then you can try disabling ppp offloading a= nd=20 > > see if this problem exits. That would give us somegood info. >=20 >=20 > Ugh, not good. >=20 > [signal@norad radacct]$ tail -500 password.log |grep juicy > Sun Apr 11 22:11:44 1999:923886704:juicy:d00ms:ENCRYPTED:PASS > Sun Apr 11 22:12:53 1999:923886773:juicy:d00mI:ENCRYPTED:FAIL > Sun Apr 11 22:13:12 1999:923886792:juicy:d00ms:ENCRYPTED:PASS >=20 > [signal@norad radacct]$ tail -500 password.log |grep thunder > Sun Apr 11 22:15:17 1999:923886917:thunder:tbon=EC:ENCRYPTED:FAIL > Sun Apr 11 22:15:29 1999:923886929:thunder:tbone:ENCRYPTED:PASS > Sun Apr 11 22:25:31 1999:923887531:thunder:tbone:ENCRYPTED:PASS >=20 > (usernames have been changed to protect the innocent :) ) I understand the problem - but need a tap to see what exactly is being=20 sent to the radius. Could you enable tap for juicy and tunder? krish >=20 > So the short of it, is that I am seeing this too. Yes I am running ppp > offloading as per the release notes. I would say their is a problem. > Hopefully this will be a quick one, and a fix will be released soon. >=20 > Perhaps others can do a check of their RADIUS password logs and look for > this type of activity. > >=20 > > regards > > krish > >=20 > > >=20 > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperD= SPs. > > >=20 > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > anything other that it only appears to be happening on our USR chassi= s. > > >=20 > > > --=20 > > > Aaron Nabil > > >=20 > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > >=20 > >=20 > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > >=20 >=20 > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net =20 > 318-222-2638 x 109=09http://www.shreve.net/~signal =20 > Network Administrator ShreveNet Inc. (ASN 11881) =09 =20 >=20 >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >=20
Subject: Re: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-12 08:22:35
> > I understand the problem - but need a tap to see what exactly is being > sent to the radius. Could you enable tap for juicy and tunder? > Can I just enable syslog tap for that user on the ARC? Or do I have to do it via RADIUS (the user is entirley in RADIUS)? Can you give me an example of how to tap the user? I will get you a file with some info in it. > krish > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > offloading as per the release notes. I would say their is a problem. > > Hopefully this will be a quick one, and a fix will be released soon. > > > > Perhaps others can do a check of their RADIUS password logs and look for > > this type of activity. > > > > > > regards > > > krish > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > -- > > > > Aaron Nabil > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Passwords getting corrupted
From: Steve Lalonde <steve@enta.net>
Date: 1999-04-12 08:26:39
Im getting exactly the same here, and it always affects the same users 4.1.59-6 on hiperARCs and 1.2.59 on hiperDSPs Were in the UK so its E1/PRI versions of code Steve Lalonde Systems Manager ENTANET International Ltd Most usefull Unix command :- man man Most Dangerous Unix command :- rm -rf / ----- Original Message ----- Cc: Aaron Nabil <nabil@spiritone.com> Sent: 12 April 1999 04:32 > On Sun, 11 Apr 1999, Tatai SV Krishnan wrote: > > > On Sun, 11 Apr 1999, Aaron Nabil wrote: > > > > > > > > Our radius server (radiator) can log the cleartext passwords sent b= y > > > the client. I've noticed an interesting pattern, failed attempts followed > > > by succesfull one, with only the last character of the password changed. It > > > has been happening hundreds of times per day. > > > > > > An example would be a failed attempt with the password "cooki^X" > > > followed by an succesfull attempt of "cookie". The transformation isn't > > > fixed, if the same user fails again, it might be "cookiZ" he tries before > > > "cookie". > > > > Is it possible for you to use the tap feature to capture this info? > > I have heard reports of this but I have not been able to get any one = to > > work with me on this. If you can either run tap to syslog and captur= e > > the data or if this is reproduceble on demand then it would be easy f= or > > us to identify the problem. > > > > If running tap is a problem then you can try disabling ppp offloading and > > see if this problem exits. That would give us somegood info. > > > Ugh, not good. > > [signal@norad radacct]$ tail -500 password.log |grep juicy > Sun Apr 11 22:11:44 1999:923886704:juicy:d00ms:ENCRYPTED:PASS > Sun Apr 11 22:12:53 1999:923886773:juicy:d00mI:ENCRYPTED:FAIL > Sun Apr 11 22:13:12 1999:923886792:juicy:d00ms:ENCRYPTED:PASS > > [signal@norad radacct]$ tail -500 password.log |grep thunder > Sun Apr 11 22:15:17 1999:923886917:thunder:tbon=EC:ENCRYPTED:FAIL > Sun Apr 11 22:15:29 1999:923886929:thunder:tbone:ENCRYPTED:PASS > Sun Apr 11 22:25:31 1999:923887531:thunder:tbone:ENCRYPTED:PASS > > (usernames have been changed to protect the innocent :) ) > > So the short of it, is that I am seeing this too. Yes I am running ppp > offloading as per the release notes. I would say their is a problem. > Hopefully this will be a quick one, and a fix will be released soon. > > Perhaps others can do a check of their RADIUS password logs and look fo= r > this type of activity. > > > > regards > > krish > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > anything other that it only appears to be happening on our USR chassis. > > > > > > -- > > > Aaron Nabil > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com= " > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages se= nd > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 08:43:46
On Mon, 12 Apr 1999, Brian wrote: > > > > I understand the problem - but need a tap to see what exactly is being > > sent to the radius. Could you enable tap for juicy and tunder? > > > > Can I just enable syslog tap for that user on the ARC? Or do I have to do > it via RADIUS (the user is entirley in RADIUS)? Can you give me an > example of how to tap the user? I will get you a file with some info in > it. > > You can enable syslog tap for the user. Add tap user <username> fomrat <ascii/hex> output syslog That is to it. if you do not have asyslog host specified then in the above tap command you can speficy the syslog host address. krish > > > krish > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > offloading as per the release notes. I would say their is a problem. > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > this type of activity. > > > > > > > > regards > > > > krish > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > -- > > > > > Aaron Nabil > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: Re: (usr-tc) Passwords getting corrupted
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-12 09:03:32
Mike Wronski writes... >|Tatai SV Krishnan writes... >|>On Sun, 11 Apr 1999, Aaron Nabil wrote: >|>> Our radius server (radiator) can log the cleartext passwords sent by >|>> the client. I've noticed an interesting pattern, failed attempts followed >|>> by succesfull one, with only the last character of the password changed. It >|>> has been happening hundreds of times per day. >|>> >|>Is it possible for you to use the tap feature to capture this info? >|>I have heard reports of this but I have not been able to get any one to >|>work with me on this. If you can either run tap to syslog and capture >|>the data or if this is reproduceble on demand then it would be easy for >|>us to identify the problem. >| >|It seems to be associated with particular users, I've sent mail to one >|to see if he can call in while I'm capturing. > >Do these users have >8 char passwords??? No, it happens irrespective of password length. I've seen it on 4 character passwords. -- Aaron Nabil
Subject: Re: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-12 09:33:39
On Mon, 12 Apr 1999, Tatai SV Krishnan wrote: > On Mon, 12 Apr 1999, Brian wrote: > > > > > > > I understand the problem - but need a tap to see what exactly is being > > > sent to the radius. Could you enable tap for juicy and tunder? > > > > > > > Can I just enable syslog tap for that user on the ARC? Or do I have to do > > it via RADIUS (the user is entirley in RADIUS)? Can you give me an > > example of how to tap the user? I will get you a file with some info in > > it. > > > > > > You can enable syslog tap for the user. Add tap user <username> fomrat > <ascii/hex> output syslog > > That is to it. if you do not have asyslog host specified then in the > above tap command you can speficy the syslog host address. Well, I will certainly give this a try. I will tap maybe 5 users, so I can get something fast. The thing is, is their a way via RADIUS VSA to do this? I say this, because we have alot of chassis (well not alot, but over 14 ARC's or so) and I really don't want to have to do this on all 14 because I don't know where he is going to login at :). If a VSA will work , perhaps give me an example, otherwise, I'll just set the tap up on all arc's. Brian > > krish > > > > > > > krish > > > > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > > offloading as per the release notes. I would say their is a problem. > > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > > this type of activity. > > > > > > > > > > regards > > > > > krish > > > > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > > > -- > > > > > > Aaron Nabil > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Passwords getting corrupted
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-12 09:53:21
Mike Wronski writes... >he can call in while I'm capturing. >|> >|>Do these users have >8 char passwords??? >| >|No, it happens irrespective of password length. I've seen it on 4 character >|passwords. >| > >How about your secret length?? Any special chars (not A-z 0-9).. I am just >fishing here. 9 characters long, all within [A-Za-z0-9]. -- Aaron Nabil
Subject: RE: (usr-tc) Passwords getting corrupted
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-12 10:36:57
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil |Sent: Sunday, April 11, 1999 10:13 PM |To: Tatai SV Krishnan |Cc: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Passwords getting corrupted | | |Tatai SV Krishnan writes... |>On Sun, 11 Apr 1999, Aaron Nabil wrote: |>> Our radius server (radiator) can log the cleartext passwords sent by |>> the client. I've noticed an interesting pattern, failed attempts followed |>> by succesfull one, with only the last character of the password changed. It |>> has been happening hundreds of times per day. |>> |>Is it possible for you to use the tap feature to capture this info? |>I have heard reports of this but I have not been able to get any one to |>work with me on this. If you can either run tap to syslog and capture |>the data or if this is reproduceble on demand then it would be easy for |>us to identify the problem. | |It seems to be associated with particular users, I've sent mail to one |to see if he can call in while I'm capturing. Do these users have >8 char passwords??? |>If running tap is a problem then you can try disabling ppp offloading and |>see if this problem exits. That would give us somegood info. | |It's possible I could disable ppp offloading on one card and track |to see if the problem doesn't exist there. | |What is the performance hit of disabling offloading? I'm running 3 DSP's |per ARC. Its minimal. You can turn it back after the test.. Its just a good inidictor for us as to where the problem may be. -M
Subject: Re: (usr-tc) Passwords getting corrupted
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-12 10:51:42
On Mon, 12 Apr 1999, Brian wrote: >Well, I will certainly give this a try. I will tap maybe 5 users, so I >can get something fast. The thing is, is their a way via RADIUS VSA to do >this? I say this, because we have alot of chassis (well not alot, but >over 14 ARC's or so) and I really don't want to have to do this on all 14 >because I don't know where he is going to login at :). > >If a VSA will work , perhaps give me an example, otherwise, I'll just set >the tap up on all arc's. Think about what you are asking for... the tap has to active before it's generated any RADIUS traffic at all. If you are just looking for a fast way to turn the tap on/off on multiple ARC's, I'd look in the SNMP stuff -- the ARC is completely SNMP managable :-) The answer is "yes." A syslog tap can be activated via RADDIUS, but they would have to be logged in for it to be active which it the whole problem. --Ricky
Subject: Re: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-12 10:57:12
On Mon, 12 Apr 1999, Tatai SV Krishnan wrote: > On Mon, 12 Apr 1999, Brian wrote: > > > Well, I will certainly give this a try. I will tap maybe 5 users, so I > > can get something fast. The thing is, is their a way via RADIUS VSA to do > > this? I say this, because we have alot of chassis (well not alot, but > > over 14 ARC's or so) and I really don't want to have to do this on all 14 > > because I don't know where he is going to login at :). > > > > If a VSA will work , perhaps give me an example, otherwise, I'll just set > > the tap up on all arc's. > > VSa will work - but only after authentication. Thus you may never > capture the problem. ahh, good point. So the TAP goes into effect as soon as it gets a username sent to the ARC and BEFORE it gets a password sent? Brian > > krish > > > > > Brian > > > > > > > > > > > > krish > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > > > > offloading as per the release notes. I would say their is a problem. > > > > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > > > > this type of activity. > > > > > > > > > > > > > > regards > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > > > > > > > -- > > > > > > > > Aaron Nabil > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-12 11:01:18
On Mon, 12 Apr 1999, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil > |Sent: Sunday, April 11, 1999 10:13 PM > |To: Tatai SV Krishnan > |Cc: usr-tc@lists.xmission.com > |Subject: Re: (usr-tc) Passwords getting corrupted > | > | > |Tatai SV Krishnan writes... > |>On Sun, 11 Apr 1999, Aaron Nabil wrote: > |>> Our radius server (radiator) can log the cleartext passwords sent by > |>> the client. I've noticed an interesting pattern, failed attempts followed > |>> by succesfull one, with only the last character of the password changed. It > |>> has been happening hundreds of times per day. > |>> > |>Is it possible for you to use the tap feature to capture this info? > |>I have heard reports of this but I have not been able to get any one to > |>work with me on this. If you can either run tap to syslog and capture > |>the data or if this is reproduceble on demand then it would be easy for > |>us to identify the problem. > | > |It seems to be associated with particular users, I've sent mail to one > |to see if he can call in while I'm capturing. > > Do these users have >8 char passwords??? No, they do not, a variety of lengths. Brian > > > |>If running tap is a problem then you can try disabling ppp offloading and > |>see if this problem exits. That would give us somegood info. > | > |It's possible I could disable ppp offloading on one card and track > |to see if the problem doesn't exist there. > | > |What is the performance hit of disabling offloading? I'm running 3 DSP's > |per ARC. > > Its minimal. You can turn it back after the test.. Its just a good inidictor for > us as to where the problem may be. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 11:11:37
On Mon, 12 Apr 1999, Brian wrote: > Well, I will certainly give this a try. I will tap maybe 5 users, so I > can get something fast. The thing is, is their a way via RADIUS VSA to do > this? I say this, because we have alot of chassis (well not alot, but > over 14 ARC's or so) and I really don't want to have to do this on all 14 > because I don't know where he is going to login at :). > > If a VSA will work , perhaps give me an example, otherwise, I'll just set > the tap up on all arc's. VSa will work - but only after authentication. Thus you may never capture the problem. krish > > Brian > > > > > > > krish > > > > > > > > > > > krish > > > > > > > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > > > offloading as per the release notes. I would say their is a problem. > > > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > > > this type of activity. > > > > > > > > > > > > regards > > > > > > krish > > > > > > > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > > > > > -- > > > > > > > Aaron Nabil > > > > > > > > > > > > > > - > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: RE: (usr-tc) Passwords getting corrupted
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-12 11:23:25
he can call in while I'm capturing. |> |>Do these users have >8 char passwords??? | |No, it happens irrespective of password length. I've seen it on 4 character |passwords. | How about your secret length?? Any special chars (not A-z 0-9).. I am just fishing here. -M
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 11:31:13
On Mon, 12 Apr 1999, Brian wrote: > > ahh, good point. So the TAP goes into effect as soon as it gets a > username sent to the ARC and BEFORE it gets a password sent? The vsa attributes will take effect as soon as the authentication is over. Both user name and password should first get through then the attributes are sent out. krish > > Brian > > > > > > krish > > > > > > > > Brian > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > > > > > offloading as per the release notes. I would say their is a problem. > > > > > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > > > > > this type of activity. > > > > > > > > > > > > > > > > regards > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Aaron Nabil > > > > > > > > > > > > > > > > > > - > > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > > > > > > > - > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: Re: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-12 11:46:53
On Mon, 12 Apr 1999, Tatai SV Krishnan wrote: > On Mon, 12 Apr 1999, Brian wrote: > > > > ahh, good point. So the TAP goes into effect as soon as it gets a > > username sent to the ARC and BEFORE it gets a password sent? > > The vsa attributes will take effect as soon as the authentication is > over. Both user name and password should first get through then the > attributes are sent out. > > krish Right I understand. I am asking about a traditional "add tap user foo blah blah", does that tap take effect after the username is sent but before the password is sent? Becuase all I did was log into each arc and setup a tap for 5 different users. > > > > > Brian > > > > > > > > > > krish > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > > > > > > offloading as per the release notes. I would say their is a problem. > > > > > > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > > > > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > > > > > > this type of activity. > > > > > > > > > > > > > > > > > > regards > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Aaron Nabil > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) Passwords getting corrupted
From: Brian <signal@shreve.net>
Date: 1999-04-12 11:50:17
On Mon, 12 Apr 1999, Mike Wronski wrote: > he can call in while I'm capturing. > |> > |>Do these users have >8 char passwords??? > | > |No, it happens irrespective of password length. I've seen it on 4 character > |passwords. > | > > How about your secret length?? Any special chars (not A-z 0-9).. I am just > fishing here. our secret is only alpha, no special characters > > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 12:10:16
On Mon, 12 Apr 1999, Brian wrote: > On Mon, 12 Apr 1999, Tatai SV Krishnan wrote: > > > On Mon, 12 Apr 1999, Brian wrote: > > > > > > ahh, good point. So the TAP goes into effect as soon as it gets a > > > username sent to the ARC and BEFORE it gets a password sent? > > > > The vsa attributes will take effect as soon as the authentication is > > over. Both user name and password should first get through then the > > attributes are sent out. > > > > krish > > > Right I understand. I am asking about a traditional "add tap user foo > blah blah", does that tap take effect after the username is sent but > before the password is sent? Becuase all I did was log into each arc and > setup a tap for 5 different users. As soon as the user name is received - it does not wait for the password. I will check this out also - just to be sure. krish > > > > > > > > > > Brian > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > > > So the short of it, is that I am seeing this too. Yes I am running ppp > > > > > > > > > offloading as per the release notes. I would say their is a problem. > > > > > > > > > Hopefully this will be a quick one, and a fix will be released soon. > > > > > > > > > > > > > > > > > > Perhaps others can do a check of their RADIUS password logs and look for > > > > > > > > > this type of activity. > > > > > > > > > > > > > > > > > > > > regards > > > > > > > > > > krish > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are running V4.1.59 - 6 on our hiperARCs and 1.2.43 on the hiperDSPs. > > > > > > > > > > > > > > > > > > > > > > I haven't noticed any correlation between modem speeds, x2/v.90, or > > > > > > > > > > > anything other that it only appears to be happening on our USR chassis. > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Aaron Nabil > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > > For information on digests or retrieving files and old messages send > > > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >
Subject: RE: (usr-tc) Passwords getting corrupted
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-12 12:15:35
On Mon, 12 Apr 1999, Brian wrote: As soon as the user name is sent the tap starts - Here is a log 1}$}%\}3}#} }-G~ NO CARRIER TAP USER tkrishna on slot:2/mod:1 OUT: 6: ...!............ TAP USER tkrishna on slot:2/mod:1 OUT: 6: ......A......... TAP USER tkrishna on slot:2/mod:1 OUT: 6: ... TAP USER tkrishna on slot:2/mod:1 OUT: 7: ...!............ TAP USER tkrishna on slot:2/mod:1 OUT: 7: ......A......... TAP USER tkrishna on slot:2/mod:1 OUT: 7: ... TAP USER tkrishna on slot:2/mod:1 OUT: 8: ...!............ TAP USER tkrishna on slot:2/mod:1 OUT: 8: ......A......... TAP USER tkrishna on slot:2/mod:1 OUT: 8: ... TAP USER tkrishna on slot:2/mod:1 OUT: 9: ...!............ TAP USER tkrishna on slot:2/mod:1 OUT: 9: ......A......... TAP USER tkrishna on slot:2/mod:1 OUT: 9: > On Mon, 12 Apr 1999, Mike Wronski wrote: > > > he can call in while I'm capturing. > > |> > > |>Do these users have >8 char passwords??? > > | > > |No, it happens irrespective of password length. I've seen it on 4 character > > |passwords. > > | > > > > How about your secret length?? Any special chars (not A-z 0-9).. I am just > > fishing here. > > our secret is only alpha, no special characters > > > > > > > -M > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) 23in. and 19in. racks
From: Frank Basso <frank@got.net>
Date: 1999-04-12 12:38:23
Chatsworth products have adapter flanges. -Frank ----- Original Message ----- Sent: Monday, April 12, 1999 11:27 AM > Hello, we are going to put our USR stuff, 3640, and other 19inch > stuff into a somewhat "tight" location that requires us to use 23 > inch racks. Does anyone have recommendations on any type > of conversion device/anything that will make our 19 inch stuff fit > nice and snugly into the 23 inch racks?? > > thanks for your time, blake > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) 23in. and 19in. racks
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-04-12 13:27:59
Hello, we are going to put our USR stuff, 3640, and other 19inch stuff into a somewhat "tight" location that requires us to use 23 inch racks. Does anyone have recommendations on any type of conversion device/anything that will make our 19 inch stuff fit nice and snugly into the 23 inch racks?? thanks for your time, blake
Subject: Re: (usr-tc) Traps & Config
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-04-12 13:32:26
paul, from what I understand, you want to use config of one hiper arc to config another hiper arc. lets call the first hiper arc A and the other is B. on the cli of A : set bulk_file (any name) save config list files See if the file is there, tftp this file to the other hiper arc. and then on the cli of B: reset config the hiper arc would automatically load with the config. Paul, keep in mind that the dynamic parameters will not be seen- only the ones manually entered. Let me give you an example, on the first hiper arc, you have 3 dynamic hdms they will not show up when you do reset config on the other hiper arc. the parameters that you will see are the ip addresses of the default gateway, accounting server etc. also, the hiper arc B has to be given an ip address - so basic config needs to be done, it needs to be on a network. this is also on 3kb now. Ahmed arc, if you h On Thu, 8 Apr 1999, Paul Farber wrote: > hello all > > Two questions, went to the 3Kb and got the info for "Capturing the > configuration through the CLI". Telenetted in and did "sho config", I > don't thing I could rebuild a chassis from the information it listed. I'm > looking for more like the actual commands, or to tftp the config down to a > hdd for safe keeping. > > Also, can I set up traps via the CLI? The 3KB says fire up TCM... any way > to replicate the process with the good ol cmd line? > > Thanks! > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) fs: USR Network Hardware
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-12 15:16:04
5- USR TC Chassis dual 45a 1- USR TC chassis dual 70a, fan tray 28- USR Quad digital NACS 1- Netserver PRI 1- Dual PRI 1- NMC 15- USR Quad analog/digital 5- AS5100 cards (Cisco 2511) 6- Netserver 16I+ 2- MP16 4- Netserver 16 v34 2- Netserver 8 v34 All sold with 30 day warranty Steve Rivera sales@wrca.net 732-833-2111 Check out product information and inventory. http://www.wrca.net NEW! M-F 9:00-6:30 EST / 24HR EMAIL support and sales ''''''''''''''''''''''''''''''''''''''''''''''' De-installed ISP,CLEC,LEC Net-Hardware Wanted ' '''''''''''''''''''''''''''''''''''''''''''''''
Subject: RE: (usr-tc) fs: USR Network Hardware
From: Greg Genge <greg@dynavar.com>
Date: 1999-04-12 15:39:57
Hi Steve, This is greg@dynavar.com (using Cam's email) I am interested in buying all 6 Netserver16I's. What price would you give me for those. I actually could use 10. I have a customer I can resell them to if the price is right. How much for 1 and for 6? And How much for the Dual PRI card? Would you take $800. Please reply to greg@dynavar.com Regards, Greg At 04:12 PM 12/04/99 -0400, you wrote: >Prices required >John > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera >> Sent: Monday, April 12, 1999 3:16 PM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) fs: USR Network Hardware >> >> >> 5- USR TC Chassis dual 45a >> 1- USR TC chassis dual 70a, fan tray >> 28- USR Quad digital NACS >> 1- Netserver PRI >> 1- Dual PRI >> 1- NMC >> 15- USR Quad analog/digital >> 5- AS5100 cards (Cisco 2511) >> 6- Netserver 16I+ >> 2- MP16 >> 4- Netserver 16 v34 >> 2- Netserver 8 v34 >> >> >> All sold with 30 day warranty >> >> >> >> Steve Rivera sales@wrca.net 732-833-2111 >> Check out product information and inventory. >> http://www.wrca.net NEW! >> M-F 9:00-6:30 EST / 24HR EMAIL support and sales >> ''''''''''''''''''''''''''''''''''''''''''''''' >> De-installed ISP,CLEC,LEC Net-Hardware Wanted ' >> ''''''''''''''''''''''''''''''''''''''''''''''' >> >> >> >> >> >> >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) fs: USR Network Hardware
From: John Verreault <verreaul@aei.ca>
Date: 1999-04-12 16:12:47
Prices required John > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve Rivera > Sent: Monday, April 12, 1999 3:16 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) fs: USR Network Hardware > > > 5- USR TC Chassis dual 45a > 1- USR TC chassis dual 70a, fan tray > 28- USR Quad digital NACS > 1- Netserver PRI > 1- Dual PRI > 1- NMC > 15- USR Quad analog/digital > 5- AS5100 cards (Cisco 2511) > 6- Netserver 16I+ > 2- MP16 > 4- Netserver 16 v34 > 2- Netserver 8 v34 > > > All sold with 30 day warranty > > > > Steve Rivera sales@wrca.net 732-833-2111 > Check out product information and inventory. > http://www.wrca.net NEW! > M-F 9:00-6:30 EST / 24HR EMAIL support and sales > ''''''''''''''''''''''''''''''''''''''''''''''' > De-installed ISP,CLEC,LEC Net-Hardware Wanted ' > ''''''''''''''''''''''''''''''''''''''''''''''' > > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased lineoperation
From: Stefanita Vilcu <vsv@dnt.ro>
Date: 1999-04-12 19:27:23
I have tried the same, but I am not able to get the prompt. Best Regards, -vsv Ray Whelan wrote: > Hi , > > Below is the configuration on the setup which I tested, the Quad code in still > in Beta (tcs3.5), > > Quad to HiPer ARC - 2 Wire Leased Line setup > > Total Control QUAD Analog/Digital > Total Control HiPer ARC > Courier V.Everything > Quad Code: <: 6.0.4 DS> > Courier Code: <;3.0.13> > Hiper ARC Code: < 4.1.59> > > The following is how to configure the Courier modem to connect to the Quad > modem and get login prompt from the ARC > > Configuration for Courier is as follows: > Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on > courier set to on, > at&L1 &b1&n14&w also set the baud rate of the DTE to 115200 > > Configuration of the ARC > Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes > > Configuration of the Quad analog/digital > at&L1&B1&N14 > ats47.5=1 > ats56.6=0 > ats0=0 > > DIP 5 off > > Regards > Ray Whelan > > Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52 > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Ray Whelan/IE/3Com) > Subject: (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation > > Hi folks, > > I wonder if someone of you can tell me how can I setup an TC chassis for > leased line operation. > I want that the phone line to be plugged in an Analog Quad Modem and the > modem "to be connected" in a speciffic interface from the HiperArc. The > ARC will be configured to make ppp over that line, with no > authentication, and give the same IP address every time. Of course that > modem will not be available for the dual E1 card. > > Thank you, > > Stefanita Vilcu, Network Administrator - Dynamic Network Technologies, > Bucharest, Romania > vsv@dnt.ro
Subject: (usr-tc) multiple questions
From: Stefanita Vilcu <vsv@dnt.ro>
Date: 1999-04-12 19:30:51
-
Subject: (usr-tc) multiple questions
From: Stefanita Vilcu <vsv@dnt.ro>
Date: 1999-04-12 19:43:16
Hi, Sorry for the empty message, here I my issues, maybe sbm. can help me: I have an analog-digital modem configured to get the phone signal from the nic (not from the E1 card) and to route it in the Hiper ARC. The modem is configured as a dial-in modem, but the Init-script associated with the line sends at&l1 making from it a leased line one. My problem is that I receive nothing from the HiperARC. The modems stay connected until timed-out but no character is sended (banner or ppp). After timeout the quad modem resets and link again in leased mode, and so on, the syslog debug shows nothing. Is there a way to see if something is sent in the modem, from the HiperARC? How can I configure a line to make ppp with no authentication and static Ip address? TIA -vsv
Subject: (usr-tc) plz. help, I see no way out
From: Stefanita Vilcu <vsv@dnt.ro>
Date: 1999-04-12 21:18:07
Hi. I have a modem configured for "nic" not for "priT1" and the following configuration I made in the hiperarc: HiPer>> show chassis slot 15 CHASSIS SLOT 15 SETTINGS Owner: YES Description: Quad Modem Number of Ports: 4 Type: STATIC Console: NO HiPer>> add iniT_SCRIPT answer commAND "ata" HiPer>> set switchED interfaCE slot:15/mod:2 iniT_SCRIPT answer connected with this modem is a courier in which I send "atd" the modems connect but I receive nothing from the HiperARC. Please advise. I have only one ideea, to get drunk! but I don't think it is usefull with the hiperarc :-( . Thank you -vsv --- Stefanita Vilcu, Network Administrator - Dynamic Network Technologies, Bucharest, Romania vsv@dnt.ro
Subject: Re: (usr-tc) Problems with Winmodems
From: Brian <signal@shreve.net>
Date: 1999-04-13 07:55:48
On Tue, 13 Apr 1999, Marcelo Souza wrote: > > > Recently we receive some complains from users of USR V.90 > Winmodems (model 5698) in connecting our Hiper TC. > Is there any known problem with these modems? > > The chassis : > > DSP : 1.1.91 > ARC : 4.0.29 > NMC : 5.5.1 my opinion would be to upgrade to the latest service release of arc/hdm code. God knows the code you are running has alot of problems, especially memory leaks. Brian > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Problems with Winmodems
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-13 09:00:37
At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote: > > Recently we receive some complains from users of USR V.90 >Winmodems (model 5698) in connecting our Hiper TC. > Is there any known problem with these modems? Winmodems are notorious for problems, but the latest firmware upgrade has been working well here. I believe it's 5.32, check at http://808hi.com/56k/x2-lucent.htm Also, there are ARC and DSP upgrades available that will help with a lot of v90 connectivity issues. The most recent are; ARC 4.1.59-6 DSP 1.2.43(PRI/T-1) DSP 1.2.59(E-1) All are available free on the totalservice website even if you don't have a support contract. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: (usr-tc) Problems with Winmodems
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-04-13 09:29:55
Recently we receive some complains from users of USR V.90 Winmodems (model 5698) in connecting our Hiper TC. Is there any known problem with these modems? The chassis : DSP : 1.1.91 ARC : 4.0.29 NMC : 5.5.1 - Marcelo
Subject: (usr-tc) DS1 Line Code Violations
From: Mark A. Cooper <mcooper@fais.net>
Date: 1999-04-13 09:32:23
I have been monitoring the current interval statistics on the channelized T1 lines into my Hiper DSP chassis. The buildout is D4/B8ZS. I am seeing a lot of linecode violations but it doesn't seem to be effecting anything. Is this anything to worry with? Something to look at in the DS1 or DS0 settings? Phone company problem? Errored Seconds 756 Severely Errored Seconds 0 Severely Errored Framing Seconds 0 Unavailable Seconds 0 Controlled Slip Seconds 0 Path Coding Violations 0 Line Errored Seconds 756 Bursty Errored Seconds 0 Degraded Minutes 12 Line Code Violations 84410 *************************** Mark A. Cooper, Owner Technical Support Associates Fayette Area Internet Services 135 W. Travis La Grange, TX 78945 409.968.3999 ***************************
Subject: Re: (usr-tc) Problems with Winmodems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-13 09:45:19
Thus spake K Mitchell >At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote: >> Recently we receive some complains from users of USR V.90 >>Winmodems (model 5698) in connecting our Hiper TC. >> Is there any known problem with these modems? >Winmodems are notorious for problems, but the latest firmware upgrade has >been working well here. I believe it's 5.32, check at >http://808hi.com/56k/x2-lucent.htm Whoa, Kirk...he was talking about 3Com/USR winmodems...while they function on the same basic principles, the code is very different. :) Yes, 5.32 and later on the Lucent's is good, but 3Com winmodems are a different matter entirely. > Also, there are ARC and DSP upgrades available that will help with a lot >of v90 connectivity issues. The most recent are; >ARC 4.1.59-6 >DSP 1.2.43(PRI/T-1) >DSP 1.2.59(E-1) >All are available free on the totalservice website even if you don't have a >support contract. Yes, upgrading to these versions would be a huge improvement...still not perfect (my infamous ticket 58316 has just been reopened...fun joy...its now a toddler, had its first birthday a week or so ago), but much better. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Problems with Winmodems
From: Alessandro Alves <aalves@mpcnet.com.br>
Date: 1999-04-13 09:56:56
Marcelo, The version of Hiper DSP/ARC are very old ..... and you will have some problems to connect a Winmodem to the TC, after upgrade you'll have more success. As vers=F5es que voc=EA est=E1 usando na Hiper DSP e ARC s=E3o muito velhas= ..... e realmente existem alguns problemas para se conectar o Winmodem ao TC, atualizando estas vers=F5es, voc=EA ter=E1 mais sucesso. Um abra=E7o Alessandro Suporte T=E9cnico 3Com/US Robotics Network Express At 09:29 AM 4/13/99 -0300, you wrote: > > > Recently we receive some complains from users of USR V.90 >Winmodems (model 5698) in connecting our Hiper TC. > Is there any known problem with these modems? > > The chassis : > > DSP : 1.1.91 =20 > ARC : 4.0.29 > NMC : 5.5.1 > >- Marcelo > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >=20
Subject: Re: (usr-tc) Tftp'ing to the ARC
From: norm_miller@3com.com
Date: 1999-04-13 10:51:51
Kalev, This is also documented in 3KB at http://knowledgebase.3com.com/ To set up an ARC to ask for code, BootRom needs to be configured. You can do this via the setup menu that is displayed during the boot process or configure it via set commands. Below are the commands that need to be set, you can make a do file if you want. SET BOOTROM BOOT INTERFACE eth:1 SET BOOTROM IP INTERFACE eth:1 ADDRESS 199.37.208.112 NETMASK 255.255.255.224 GATEWAY 199.37.208.161 SET BOOTROM IP INTERFACE eth:1 LOADFILE netserve.dmf TFTP_BOOT ONCE TFTPSERVER 199.37.210.23 SAVE ALL To view your BOOTROM sttings use SHOW BOOTROM IP INTERFACE eth:1 SHOW BOOTROM SETTINGS When you want an ARC to request a file, place the appropriate file renamed to netserve.dmf into the directory on your pc that you have configured as the default download directory for the TFTPServer application. Start the TFTPServer application on your pc, telnet to the shelf you want to work with and do a SET BOOTROM CONFIG BOOTMODE NETWORK reboot when the ARC reboots it will do a TFTP GET to the TFTPServer and download the file, it will also set the BOOTMODE back to FLASH. This is substantially faster then doing a download via TCM. We have a little TFTP server package that one of our guys wrote for folks that you can pull off of our website at http://infodeli.3com.com/software/utilities_for_windows_32_bit.htm regards, /norm "Kalev Nurklik" <kalev@mail.lbi.ee> on 04/13/99 06:44:09 AM Please respond to usr-tc@lists.xmission.com cc: (Norm Miller/US/3Com) > On Fri, 9 Apr 1999, Tatai SV Krishnan wrote: > > > On Fri, 9 Apr 1999, Brian wrote: > > > > > > > > Does anyone have any suggestions about what to do when your tftp to an ARC > > > fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It > > > worked fine in all my other ARC's. > > > > > > I know I can probably erase the config and start afresh, but I am hoping > > > someone has a more recoverable solution. > > > > You can program the hiper arc to get the file on boot up from a tftp > > server. > > do a set bootr ip ? > > you will see the command necessary > > But aren't the odds that if I was unable to tftp the netserve.dmf into the > ARC, that the arc won't be able to tftp the file into itself upon bootup > either? I mean, woudln't I still probably need to erase the config? Maybe but as I mentioned once before the reboot seem to defrag flash on the ARC so probably this will work. If rebooting Your ARC couple of times isn't very troublesome then do this - *before reboot do "list files" on ARC and check what "Deleted Sectors" value is. After reload check "list files" again. Deletes Sectors should be considerably smaller - You have more room for new files. > > > > krish > > > > > > > > Brian > > > > > > __________________________________ Kalev Nurklik MicroLink Online Sakala 19, 10141 Tallinn, Estonia Tel: +372 6 308 909 Fax: +372 6 308 901 E-mail: k.nurklik@online.ee http://www.online.ee - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Problems with Winmodems
From: Alessandro Alves <aalves@mpcnet.com.br>
Date: 1999-04-13 10:59:30
Hi all, The code 1.2.59(E-1) is for E1-PRI, the custumer uses E1/R2 Brazil, he has to use a beta code for E1/R2-Brazil. At 09:00 AM 4/13/99 -0400, you wrote: >At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote: >> >> Recently we receive some complains from users of USR V.90 >>Winmodems (model 5698) in connecting our Hiper TC. >> Is there any known problem with these modems? > >Winmodems are notorious for problems, but the latest firmware upgrade has >been working well here. I believe it's 5.32, check at >http://808hi.com/56k/x2-lucent.htm > Also, there are ARC and DSP upgrades available that will help with a lot >of v90 connectivity issues. The most recent are; >ARC 4.1.59-6 >DSP 1.2.43(PRI/T-1) >DSP 1.2.59(E-1) >All are available free on the totalservice website even if you don't have a >support contract. > >Kirk > > > >Kirk Mitchell-General Manager sysadmin@keyconn.net >Keystone Connect http://www.keyconn.net >Altoona, PA 814-941-5000 We Unlock the World > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Problems with Winmodems
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-13 13:14:19
At 09:45 AM 4/13/99 -0400, you wrote: >Thus spake K Mitchell >>At 09:29 AM 4/13/99 -0300, Marcelo Souza <mpsouza@centroin.com.br> wrote: >>> Recently we receive some complains from users of USR V.90 >>>Winmodems (model 5698) in connecting our Hiper TC. >>> Is there any known problem with these modems? > >>Winmodems are notorious for problems, but the latest firmware upgrade has >>been working well here. I believe it's 5.32, check at >>http://808hi.com/56k/x2-lucent.htm > >Whoa, Kirk...he was talking about 3Com/USR winmodems...while they >function on the same basic principles, the code is very different. :) > >Yes, 5.32 and later on the Lucent's is good, but 3Com winmodems are a >different matter entirely. My mistake. I had just gotten in from working overnight and failed to read line 1 to the end before starting on line. >Yes, upgrading to these versions would be a huge improvement...still not >perfect (my infamous ticket 58316 has just been reopened...fun joy...its >now a toddler, had its first birthday a week or so ago), but much >better. As noted in my conversation with Todd on the list last week, I'm still at ARC 4.1.72/DSP 1.2.60 till I see some satisfactory reports on the newer code. Thanks for the correction, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Tftp'ing to the ARC
From: Kalev Nurklik <kalev@mail.lbi.ee>
Date: 1999-04-13 13:44:09
> On Fri, 9 Apr 1999, Tatai SV Krishnan wrote: > > > On Fri, 9 Apr 1999, Brian wrote: > > > > > > > > Does anyone have any suggestions about what to do when your tftp to an ARC > > > fails? I am trying to tftp "netserve.dmf" to an arc, and it failed. It > > > worked fine in all my other ARC's. > > > > > > I know I can probably erase the config and start afresh, but I am hoping > > > someone has a more recoverable solution. > > > > You can program the hiper arc to get the file on boot up from a tftp > > server. > > do a set bootr ip ? > > you will see the command necessary > > But aren't the odds that if I was unable to tftp the netserve.dmf into the > ARC, that the arc won't be able to tftp the file into itself upon bootup > either? I mean, woudln't I still probably need to erase the config? Maybe but as I mentioned once before the reboot seem to defrag flash on the ARC so probably this will work. If rebooting Your ARC couple of times isn't very troublesome then do this - *before reboot do "list files" on ARC and check what "Deleted Sectors" value is. After reload check "list files" again. Deletes Sectors should be considerably smaller - You have more room for new files. > > > > krish > > > > > > > > Brian > > > > > > __________________________________ Kalev Nurklik MicroLink Online Sakala 19, 10141 Tallinn, Estonia Tel: +372 6 308 909 Fax: +372 6 308 901 E-mail: k.nurklik@online.ee http://www.online.ee
Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 1999-04-13 16:45:30
Hi Stefanita, First are you getting modems sync up. and if so and you just garbage across your screen ? You must used Quad code from TCS3.5 Beta , older code did have problems. Ray Whelan Stefanita Vilcu <vsv@dnt.ro> on 12/04/99 17:27:23 Please respond to usr-tc@lists.xmission.com cc: (Ray Whelan/IE/3Com) I have tried the same, but I am not able to get the prompt. Best Regards, -vsv Ray Whelan wrote: > Hi , > > Below is the configuration on the setup which I tested, the Quad code in still > in Beta (tcs3.5), > > Quad to HiPer ARC - 2 Wire Leased Line setup > > Total Control QUAD Analog/Digital > Total Control HiPer ARC > Courier V.Everything > Quad Code: <: 6.0.4 DS> > Courier Code: <;3.0.13> > Hiper ARC Code: < 4.1.59> > > The following is how to configure the Courier modem to connect to the Quad > modem and get login prompt from the ARC > > Configuration for Courier is as follows: > Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on > courier set to on, > at&L1 &b1&n14&w also set the baud rate of the DTE to 115200 > > Configuration of the ARC > Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes > > Configuration of the Quad analog/digital > at&L1&B1&N14 > ats47.5=1 > ats56.6=0 > ats0=0 > > DIP 5 off > > Regards > Ray Whelan > > Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52 > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Ray Whelan/IE/3Com) > Subject: (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation > > Hi folks, > > I wonder if someone of you can tell me how can I setup an TC chassis for > leased line operation. > I want that the phone line to be plugged in an Analog Quad Modem and the > modem "to be connected" in a speciffic interface from the HiperArc. The > ARC will be configured to make ppp over that line, with no > authentication, and give the same IP address every time. Of course that > modem will not be available for the dual E1 card. > > Thank you, > > Stefanita Vilcu, Network Administrator - Dynamic Network Technologies, > Bucharest, Romania > vsv@dnt.ro - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased
From: Vadim Tulinov <vadim_tulinov@rrc.ru>
Date: 1999-04-13 19:58:03
Hello! Ray Whelan wrote: > Hi Stefanita, > > First are you getting modems sync up. > and if so and you just garbage across your screen ? > You must used Quad code from TCS3.5 Beta , older code did have problems. As far as I know, TCS3.5 is last relise for Netserver Analog60/PRI. Can Netserver support leased line operation with TCS3.5 too? > > > Ray Whelan > > Stefanita Vilcu <vsv@dnt.ro> on 12/04/99 17:27:23 > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Ray Whelan/IE/3Com) > Subject: Re: (usr-tc) Digital/Analog QuadModem + HiperARC leased lineoperation > > I have tried the same, but I am not able to get the prompt. > > Best Regards, > > -vsv > > Ray Whelan wrote: > > > Hi , > > > > Below is the configuration on the setup which I tested, the Quad code in still > > in Beta (tcs3.5), > > > > Quad to HiPer ARC - 2 Wire Leased Line setup > > > > Total Control QUAD Analog/Digital > > Total Control HiPer ARC > > Courier V.Everything > > Quad Code: <: 6.0.4 DS> > > Courier Code: <;3.0.13> > > Hiper ARC Code: < 4.1.59> > > > > The following is how to configure the Courier modem to connect to the Quad > > modem and get login prompt from the ARC > > > > Configuration for Courier is as follows: > > Pins 3 and 4 of courier to pins 3 and 4 of the Quad modem DIP switch five on > > courier set to on, > > at&L1 &b1&n14&w also set the baud rate of the DTE to 115200 > > > > Configuration of the ARC > > Set chassis slot 2 type static card_type quad_i_modem port 4 owner yes > > > > Configuration of the Quad analog/digital > > at&L1&B1&N14 > > ats47.5=1 > > ats56.6=0 > > ats0=0 > > > > DIP 5 off > > > > Regards > > Ray Whelan > > > > Stefanita Vilcu <vsv@dnt.ro> on 05/04/99 18:07:52 > > > > Please respond to usr-tc@lists.xmission.com > > > > To: usr-tc@lists.xmission.com > > cc: (Ray Whelan/IE/3Com) > > Subject: (usr-tc) Digital/Analog QuadModem + HiperARC leased line operation > > > > Hi folks, > > > > I wonder if someone of you can tell me how can I setup an TC chassis for > > leased line operation. > > I want that the phone line to be plugged in an Analog Quad Modem and the > > modem "to be connected" in a speciffic interface from the HiperArc. The > > ARC will be configured to make ppp over that line, with no > > authentication, and give the same IP address every time. Of course that > > modem will not be available for the dual E1 card. > > > > Thank you, > > > > Stefanita Vilcu, Network Administrator - Dynamic Network Technologies, > > Bucharest, Romania > > vsv@dnt.ro > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Best regards, Vadim Tulinov. -
Subject: (usr-tc) 3com v90 Winmodems -> 1.2.43 code
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1999-04-14 09:01:58
This doesn't work. I have a pair of customers in different cities that dial into 4.1.72/1.2.43 based chassis, with their brand new Dell computers. Imagine that, it doesn't work.. or it doesn't work well, at all. The users are complaining of incredibly slow connections, and I have no idea where to go from here. Does 3com have newer winmodem code that fixes the problem? Has anyone come up with a solution for this? Thnx. -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 The "-ell 65532" is an undocumented switch. THIS is the magic twinkle dust. Works better if you wave a dead chicken at the same time... Causes lights on the disks to go bonkers for a while. -- DEC Mailing List
Subject: (usr-tc) Caller ID on Chan T1?
From: Jeff Carneal <jeff@apex.net>
Date: 1999-04-14 09:22:42
Forgive me if this has been discusess before, but after searching the archives I found no mention of it. We're running channelized T1 into hipers with e&m wink signaling, and I've noticed that Calling-Station-ID is set to "" in the radiusd logs. Now, Called-Station-ID is set properly, but we're not getting the calling station. Additionally, I'm quite positive that the telco is sending 10 digits for ANI, 10 digits for DNIS on every call (mf digit signaling). Is caller ID simply not supported on channelized T1 on the hipers? Any other thoughts? -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.
Subject: Re: (usr-tc) Caller ID on Chan T1?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-14 10:27:12
On Wed, 14 Apr 1999, Jeff Carneal wrote: > > Forgive me if this has been discusess before, but after searching the > archives I found no mention of it. > > We're running channelized T1 into hipers with e&m wink signaling, and I've > noticed that Calling-Station-ID is set to "" in the radiusd logs. Now, > Called-Station-ID is set properly, but we're not getting the calling > station. > > Additionally, I'm quite positive that the telco is sending 10 digits for > ANI, 10 digits for DNIS on every call (mf digit signaling). Is caller ID > simply not supported on channelized T1 on the hipers? Any other thoughts? > Check the DSP settings - Make sure that you have it set to receive 10 digits krish > -- > Jeff Carneal - Sys Admin - Apex Internet > jeff@apex.net http://www.apex.net (502) 442-5363 > > The opinions expressed above aren't really mine. > They belong to someone else who also refuses to > take responsibility for them. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) WYB USR Telco card Dual PRI/T-1
From: access1 <access1@simplyweb.net>
Date: 1999-04-14 10:34:38
we want to buy 1 maybe 2 Dual PRI/T-1 USR Telco card sets. ( we found one at a fair price so far). request reasonable for this used equip., please send price privately to above. We need one soon. thanks.
Subject: (usr-tc) Clear Channel or Not?
From: Brian M. Gordon <administrator@westelcom.com>
Date: 1999-04-14 10:47:37
I usually order PRI so I am not as farmilar with channalized or switched T1 service. The telephone company I just spoke to asked if I wanted Clear channel or not? Any ideas what the best thing to use for Total control Hiper DSP's? Thanks, Brian Gordon Network Administrator Westelcom Internet 518-566-8376 114 Voice 518-566-8348 Fax http://home.westelcom.com administrator@westelcom.com
Subject: Re: (usr-tc) WTB Netserver 8 or 16 I + (still looking)
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-04-14 12:40:20
Eric, This first 16I is DOA. it will not pick up or answer calls. We are trying the second one right now. I'll let you know how it goes. tony Eric Billeter wrote: > How many do you want and what do you want to pay for them.. > > I have 16 of em (8 never used) > > Eric T. Billeter Cable One > Internet Engineer 1314 North 3rd Street > ebilleter@cableone.net Phoenix, AZ 85004 > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tony Loosle > Sent: Thursday, April 08, 1999 9:14 AM > To: isp-equipment@isp-equipment.com; usr-tc@lists.xmission.com > Subject: (usr-tc) WTB Netserver 8 or 16 I + (still looking) > > Still looking for used netserver 8I+ and 16I+ > > tony > 435-753-5455 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) WYB USR Telco card Dual PRI/T-1
From: access1 <access1@simplyweb.net>
Date: 1999-04-14 13:32:37
got it covered. thanks Steve Rivera wrote: > whats fair. I have them:) > > At 10:34 AM 4/14/99 -0700, you wrote: > >we want to buy 1 maybe 2 Dual PRI/T-1 USR Telco card sets. ( we found > >one at a fair price so far). request reasonable for this used equip., > >please send price privately to above. We need one soon. thanks. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Clear Channel or Not?
From: Wayne Barber <barberw@tidewater.net>
Date: 1999-04-14 14:04:50
Yes, you want Clear Channel if you can get it. This is a T1 with B8ZS and ESF which doesn't rob bits the way AMI and SF does. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian M. Gordon > Sent: Wednesday, April 14, 1999 10:48 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Clear Channel or Not? > Importance: High > > > I usually order PRI so I am not as farmilar with channalized or > switched T1 > service. The telephone company I just spoke to asked if I wanted Clear > channel or not? Any ideas what the best thing to use for Total control > Hiper DSP's? > > Thanks, > > Brian Gordon > Network Administrator > Westelcom Internet > 518-566-8376 114 Voice > 518-566-8348 Fax > http://home.westelcom.com > administrator@westelcom.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) WYB USR Telco card Dual PRI/T-1
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-14 16:00:00
whats fair. I have them:) At 10:34 AM 4/14/99 -0700, you wrote: >we want to buy 1 maybe 2 Dual PRI/T-1 USR Telco card sets. ( we found >one at a fair price so far). request reasonable for this used equip., >please send price privately to above. We need one soon. thanks. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) VPN Tunnel to Linux box
From: Brian <signal@shreve.net>
Date: 1999-04-14 16:09:57
I am wanting to setup a single Tunnel from the ARC to a linux box, using the tunneling supported by linux (I believe linux will do PPTP). Does anyone have an example of at least the ARC side of the setup, and perhaps even some notes on the Linux side? I believe the ARC supports l2tp and pptp right? does it do ipsec? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) WTB Netserver 8 or 16 I + (still looking)
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-14 17:12:33
Tony, was this unit refurbished or new? was this unit At 12:40 PM 4/14/99 -0600, you wrote: >Eric, > This first 16I is DOA. it will not pick up or answer calls. We are >trying the second one right now. I'll let you know how it goes. > >tony > > >Eric Billeter wrote: > >> How many do you want and what do you want to pay for them.. >> >> I have 16 of em (8 never used) >> >> Eric T. Billeter Cable One >> Internet Engineer 1314 North 3rd Street >> ebilleter@cableone.net Phoenix, AZ 85004 >> >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tony Loosle >> Sent: Thursday, April 08, 1999 9:14 AM >> To: isp-equipment@isp-equipment.com; usr-tc@lists.xmission.com >> Subject: (usr-tc) WTB Netserver 8 or 16 I + (still looking) >> >> Still looking for used netserver 8I+ and 16I+ >> >> tony >> 435-753-5455 >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) 3com v90 Winmodems -> 1.2.43 code
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-04-14 17:51:04
We had a lot of complaints from users with "new" computers too. But usually the installed modem code on their pc was a 1-3 months old. I think there have been several revisions to the LT and Rockwell code already this year. Bottom line- upgrade the client modem. We run DSP1.2.43/ARC4.1.11 (will upgrade to 4.1.59-6 soon) and after users with poor connect speeds did an upgrade on their end, everything is great. These upgrades are very easy also. Below is an excerpt from a list message on 3-26-99, it really helped me! Regards, Scott Boggs United Bank ======================================== Here's the lowdown: LT Winmodems: download the latest driver: 5.39. You can get it from http://www.tidewater.net/56k.shtml. Rockwell 56k PCI: these can be either HCF or ITU modems. HCF are real crap. They need in init string of +ms=v34 to turn off all 56k attempts. The ITU (or non-HCF) Rockwells use an init string of +ms=11,1 or update the drivers from the manufacturer's site. iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that came with MacAddict(?) in January ( I think. I don't get the mag). Go to http://www.56k.com for more info on the init strings. Wayne Barber Coastal Telco Services =========================================== > -----Original Message----- > From: Gilles Melanson [SMTP:gilles@vianet.on.ca] > Sent: Wednesday, April 14, 1999 9:02 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) 3com v90 Winmodems -> 1.2.43 code > > This doesn't work. > > I have a pair of customers in different cities that dial into > 4.1.72/1.2.43 based chassis, with their brand new Dell computers. >
Subject: Re: (usr-tc) VPN Tunnel to Linux box
From: slack <jhansen@xmission.com>
Date: 1999-04-14 17:59:13
On Wed, Apr 14, 1999 at 06:23:21PM -0500, Mike Wronski wrote: > > | > |I am wanting to setup a single Tunnel from the ARC to a linux box, using > |the tunneling supported by linux (I believe linux will do PPTP). Does > |anyone have an example of at least the ARC side of the setup, and perhaps > |even some notes on the Linux side? > | > |I believe the ARC supports l2tp and pptp right? does it do ipsec? > | > > PPTP server on linux? I have seen the PPTP client but not a server. Can you point > me to where you saw PPTP server for linux?? > http://www.moretonbay.com/vpn/pptp.html -- Jason Hansen jhansen@xmission.com
Subject: RE: (usr-tc) Clear Channel or Not?
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-04-14 18:09:04
In order to support v.90/x2/kflex, your lines must be trunk side config rather that a line side config. This nearly killed me last Jan. Line side termination has an additional Digital/analog conversion that will kill 56k connections. Thanks, Scott Boggs United Bank > -----Original Message----- > From: Brian M. Gordon [SMTP:administrator@westelcom.com] > Sent: Wednesday, April 14, 1999 10:48 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Clear Channel or Not? > Importance: High > > I usually order PRI so I am not as farmilar with channalized or switched > T1 > service. The telephone company I just spoke to asked if I wanted Clear > channel or not? Any ideas what the best thing to use for Total control > Hiper DSP's? > > Thanks, > > Brian Gordon > Network Administrator > Westelcom Internet > 518-566-8376 114 Voice > 518-566-8348 Fax > http://home.westelcom.com > administrator@westelcom.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) VPN Tunnel to Linux box
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-14 18:23:21
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Wednesday, April 14, 1999 4:10 PM |To: USRobotics TC Mailing List |Subject: (usr-tc) VPN Tunnel to Linux box | | | |I am wanting to setup a single Tunnel from the ARC to a linux box, using |the tunneling supported by linux (I believe linux will do PPTP). Does |anyone have an example of at least the ARC side of the setup, and perhaps |even some notes on the Linux side? | |I believe the ARC supports l2tp and pptp right? does it do ipsec? | PPTP server on linux? I have seen the PPTP client but not a server. Can you point me to where you saw PPTP server for linux?? -M
Subject: (usr-tc) OID For Active Digital/ISDN Sessions
From: TM <myers@kwiknet.net>
Date: 1999-04-14 21:17:30
Does anyone know the OID to get the number of active Digital/ISDN sessions? I have the OID for the number of active modems (1.3.6.1.4.1.429.4.2.1.10.0). Thanks...
Subject: Re: (usr-tc) OID For Active Digital/ISDN Sessions
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-14 22:35:43
Thus spake TM >Does anyone know the OID to get the number of active Digital/ISDN >sessions? I have the OID for the number of active modems >(1.3.6.1.4.1.429.4.2.1.10.0). I'm assuming this OID is from the HiPer Arc, not the NMC? At least that was the only way I could get a response... If that is the case, then this OID gives you the number of active session...period. It (from what I can tell) makes no distinctions between ISDN and modem calls. In other words, since its from the Arc, it gives you the number of active users, which can be either an ISDN or a modem call. About the only way I could think of to get number of ISDN calls would be to walk the mdmCsModulationType and divide up which modulations are modem modulations and which are ISDN (v.110, v.120, x75, and asyncsyncppp being the main ISDN ones. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) off-hook here, off-hook there?
From: Ray Bagby <rbagby@yore.net>
Date: 1999-04-15 02:05:48
I'm just about going to have to tell some paid-in-full, non-camping clients that they should find another Internet Service Provider because they keep getting dropped after only 90 to 120 seconds. These people are in another area-code with an independent phone company. I'm using SWBell. The inde guy says his equipment is not getting an off-hook which would start his billing timer, this in turn is activating the toll-fraud event which disconnects the call. I've talked to Bell folks who "see" the off-hook in places hundreds of miles away from here and I've talked to the folks at 3Com who logged on from Chicago and had no problem. There-fore other people in different exchanges have no trouble staying connected. It's just in this independent's system that I'm having trouble. The SWBell folks have been great about trying to find the problem but they're not seeing any trouble anywhere in their system. I'm using a TC chassis with a T1 going into a DSP running 1.2.5, HiPer ARC NAC running 4.1.72 and NMC on 5.6.2. (I've been told I should up-grade but I've also been told it would not help the problem and the release notes for the 4.1.59-6 says I should run it with NMC 5.5.5 and they are not giving that one away!) My question: is there some setting somewhere I could change that would not allow this independent phone company to "get" the off-hook and still allow basically everybody else to "see" the off-hook? Anybody every dealt with this problem before? In other words: HELP!!! Thank you, Ray
Subject: (usr-tc) Todays Special on AS5100 cards
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-15 10:40:22
5 in stock. All in new condition. $500 each. Cisco AS51-16A-E Steve Rivera sales@wrca.net 732-833-2111 Check out product information and inventory. http://www.wrca.net NEW! M-F 9:00-6:30 EST / 24HR EMAIL support and sales ''''''''''''''''''''''''''''''''''''''''''''''' De-installed ISP,CLEC,LEC Net-Hardware Wanted ' '''''''''''''''''''''''''''''''''''''''''''''''
Subject: RE: (usr-tc) VPN Tunnel to Linux box
From: Brian <signal@shreve.net>
Date: 1999-04-15 10:58:47
On Wed, 14 Apr 1999, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > |Sent: Wednesday, April 14, 1999 4:10 PM > |To: USRobotics TC Mailing List > |Subject: (usr-tc) VPN Tunnel to Linux box > | > | > | > |I am wanting to setup a single Tunnel from the ARC to a linux box, using > |the tunneling supported by linux (I believe linux will do PPTP). Does > |anyone have an example of at least the ARC side of the setup, and perhaps > |even some notes on the Linux side? > | > |I believe the ARC supports l2tp and pptp right? does it do ipsec? > | > > PPTP server on linux? I have seen the PPTP client but not a server. Can you point > me to where you saw PPTP server for linux?? > http://www.moretonbay.com/vpn/pptp.html perhaps someone @3Com can do a test to see if your implementation of PPTP will work with this. Hopefully it will! I will do my own testing as well, but I have never used 3Com PPTP on the ARC so hopefully I will get it right. > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) VPN Tunnel to Linux box
From: Brian <signal@shreve.net>
Date: 1999-04-15 11:25:08
Ok, it would seem that all that needs to be done is something like this: On linux PPTP server: pptp --localip ip.of.thismachine --remoteip ip.of.hiperarc From reading the documentation it would seem no configuration should be necessary on the HiperARC. And I hope I read this right. It appears, it can be entirly done in RADIUS which would be nice. Something like this perhaps: pptp Auth-Type = "Unix-PW" Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-IP-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Max-Channels = "2", Framed-Routing = "None", Framed-Compression = "Van-Jacobson-TCP-IP", Tunnel-Type=PPTP, Tunnel-Server-Endpoint = "ip.of.pptpserver" Is that all that is needed? I am assuming "Tunnel-Password", "Tunnel-Security", etc are all optional parameters, and that all RADIUS really needs to tell the ARC is the Tunnel Type and Endpoint. Brian ----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Filters
From: Brian <signal@shreve.net>
Date: 1999-04-15 11:35:03
On Thu, 15 Apr 1999, Paul Farber wrote: > Hello all, just wondering if someone could check my simple IP filter that > I want to implement. The filter will go on the eth0 interface. > > #filter > IP: > 010 AND src-addr = 207.044.065.000/24; > 020 ACCEPT dst-addr = 000.000.000.000/0; > 030 AND src-addr = 000.000.000.000/0; > 040 ACCEPT dst-addr = 207.044.065.000/24; > 050 DENY; > > I know there is a way to assign filters via RADIUS for each caller, but > all I want to make sure I only send/recieve packets with their IP as the > originating/destination.. ie kill spoofers, keep alive pings etc. they can still spoof any ip's in 207.44.65.0............ Using a RADIUS that supports "hint assigned" such as RADIATOR (http://www.open.com.au/radiator/) will assign each user a dynamic filter such that it blocks everything but their ip and netmask. > > What would a radius assigned filter look like? How do I get the IP to set > up filtering? I am using CISTRON on LINUX. Will share the results and > maybe write a FAQ once this is done.. there seems to be litte explination > on doing this. > > Thanks. > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) Filters
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-15 11:37:50
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber |Sent: Thursday, April 15, 1999 11:22 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Filters | | |Hello all, just wondering if someone could check my simple IP filter that |I want to implement. The filter will go on the eth0 interface. | |#filter |IP: |010 AND src-addr = 207.044.065.000/24; |020 ACCEPT dst-addr = 000.000.000.000/0; |030 AND src-addr = 000.000.000.000/0; |040 ACCEPT dst-addr = 207.044.065.000/24; |050 DENY; How about output filter: #filter IP: 010 ACCEPT dst-addr = 207.44.65.0/C; 020 DENY; Input filter #filter IP: 010 ACCEPT src-addr = 207.44.65.0/C; 020 DENY; |I know there is a way to assign filters via RADIUS for each caller, but |all I want to make sure I only send/recieve packets with their IP as the |originating/destination.. ie kill spoofers, keep alive pings etc. | |What would a radius assigned filter look like? How do I get the IP to set |up filtering? I am using CISTRON on LINUX. Will share the results and |maybe write a FAQ once this is done.. there seems to be litte explination |on doing this. | Radius sends the filter in multiple instances of the VSA "IP-In-Filter" 0x9000 or "IP-Out-Filter" 0x9003. The format will be the same excluding the "#filter" and "IP:" tokens. ... IP-In-Filter = "010 ACCEPT src-addr = 207.44.65.0/C;" IP-In-Filter = "020 DENY;" ... -M
Subject: RE: (usr-tc) VPN Tunnel to Linux box
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-15 11:42:53
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Thursday, April 15, 1999 11:25 AM |To: USRobotics TC Mailing List |Subject: RE: (usr-tc) VPN Tunnel to Linux box | | | | |Ok, it would seem that all that needs to be done is something like this: | |On linux PPTP server: | |pptp --localip ip.of.thismachine --remoteip ip.of.hiperarc | | |>From reading the documentation it would seem no configuration should be |necessary on the HiperARC. And I hope I read this right. It appears, it |can be entirly done in RADIUS which would be nice. Something like this |perhaps: | |pptp Auth-Type = "Unix-PW" | Service-Type = "Framed-User", | Framed-Protocol = "PPP", | Framed-IP-Address = "255.255.255.254", | Framed-Netmask = "255.255.255.255", | Framed-MTU = "1500", | Max-Channels = "2", | Framed-Routing = "None", | Framed-Compression = "Van-Jacobson-TCP-IP", | Tunnel-Type=PPTP, | Tunnel-Server-Endpoint = "ip.of.pptpserver" | | |Is that all that is needed? I am assuming "Tunnel-Password", |"Tunnel-Security", etc are all optional parameters, and that all RADIUS |really needs to tell the ARC is the Tunnel Type and Endpoint. | Thats it. You do need to use NT or linux though. The server notes state that Win9X is not supported yet. I have not used the linux pptpd yet.. When I do, I will post my results.. -M
Subject: (usr-tc) Filters
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-15 12:21:49
Hello all, just wondering if someone could check my simple IP filter that I want to implement. The filter will go on the eth0 interface. #filter IP: 010 AND src-addr = 207.044.065.000/24; 020 ACCEPT dst-addr = 000.000.000.000/0; 030 AND src-addr = 000.000.000.000/0; 040 ACCEPT dst-addr = 207.044.065.000/24; 050 DENY; I know there is a way to assign filters via RADIUS for each caller, but all I want to make sure I only send/recieve packets with their IP as the originating/destination.. ie kill spoofers, keep alive pings etc. What would a radius assigned filter look like? How do I get the IP to set up filtering? I am using CISTRON on LINUX. Will share the results and maybe write a FAQ once this is done.. there seems to be litte explination on doing this. Thanks. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: Re: (usr-tc) off-hook here, off-hook there?
From: Ronald Kushner <ron@glis.net>
Date: 1999-04-15 12:42:31
Ray Bagby wrote: > > I'm just about going to have to tell some paid-in-full, non-camping > clients that they should find another Internet Service Provider because they > keep getting dropped after only 90 to 120 seconds. These people are in > another area-code with an independent phone company. I'm using SWBell. The > inde guy says his equipment is not getting an off-hook which would start his > billing timer, this in turn is activating the toll-fraud event which > disconnects the call. <snip> > My question: is there some setting somewhere I could change that would > not allow this independent phone company to "get" the off-hook and still > allow basically everybody else to "see" the off-hook? Anybody every dealt > with this problem before? In other words: HELP!!! This is known as a supervision problem. When your equipment answers, it sends a wink back to the switch telling it that the phone line was answered, and that wink is translated by your switch into supervision signals (on hook/ off hook) that get transmitted over the SS7 network. Usually the wink is heard as a click when you call into your equipment. If you have a trunk side DS-1, they usually do not ring and you can hear the supervision click or wink before the modem answers. I am not sure how this works on ISDN PRI, I imagine the D channel is used to transmit supervision signals, since I can not hear the wink when I call my equipment. The supervision signals are now transmitted by the telcos out of band via the SS7 network. If the telco is not SS7 capable (doubtful these days) the terminating switch in the SS7 network should send the inband signals to the other telco. I really doubt your equipment is not sending a wink or signal saying it's on hook, most modern switches will disconnect the call before 4 minutes because of toll fraud involving older switches in the network. So you would have a problem with your SBC customers as well. The only way you can fix this is to pound SBC, they will have to put a protocol analyzer into the X25 network to ensure supervision signals are sent to the other telco. As long as you get the lingo down right, you'll find the right dim bulb that will know how the fix your problem. If you don't get anywhere, file a complaint with your state public service commission. How small is this independent telephone company? Is it a local call for their customers to call your numbers? -Ron GLISnet, Inc. +1 810/939.9885
Subject: RE: (usr-tc) VPN Tunnel to Linux box
From: Brian <signal@shreve.net>
Date: 1999-04-15 12:54:56
> Thats it. You do need to use NT or linux though. The server notes state that > Win9X is not supported yet. > I have not used the linux pptpd yet.. When I do, I will post my results.. Thanks mike, I too will post if I get the ARC->Linux PPTP tunnel working. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Filters
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-15 13:24:53
Brian writes... >On Thu, 15 Apr 1999, Paul Farber wrote: > >> . . . >> I know there is a way to assign filters via RADIUS for each caller, but >> all I want to make sure I only send/recieve packets with their IP as the >> originating/destination.. ie kill spoofers, keep alive pings etc. > >they can still spoof any ip's in 207.44.65.0............ > >Using a RADIUS that supports "hint assigned" such as RADIATOR >(http://www.open.com.au/radiator/) will assign each user a dynamic filter >such that it blocks everything but their ip and netmask. Way overkill. Just enable the built-in anti-spoofing code, it'll check the source address matches the assigned address. It's documented in the latest hiperarc release notes. -- Aaron Nabil
Subject: (usr-tc) x2
From: Griggs Jim <griggs_jim@prc.com>
Date: 1999-04-15 13:43:30
I have a Netserver/8 (Not the PLUS version) purchased circa mid '97 that has x2 capable modems onboard. -- At least according to the ATI7 response. I have set the dip switch on the back of the unit to allow up to 57600 connect speed, but I am still not getting anything above 24000 even from a phone line that I can routinely connect to elsewhere at 480000 or higher. Am I missing an AT command somewhere ?? Even without a firmware upgrade to v.90 I should still get a higher connection rate than 24k.
Subject: Re: (usr-tc) Proxy ARP
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-15 14:17:28
enable ip proXY_ARP_ALL_DIALIN krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 15 Apr 1999, Jamie Orzechowski wrote: > Hi There ... I remeber setting up my ARC a long while ago and having to = > enable proxy arp ... I cannot find this command anywhere ... does nayone = > know how to enable proxy arp on the ARC??? ...=20 >
Subject: (usr-tc) strange LIST CONN
From: Brian <signal@shreve.net>
Date: 1999-04-15 14:18:11
Is anyone else seeing alot of DIALIN INVALID 00- -0000 00:00:00 in LIST CONN since upgrading to 4.1.59-6? slot:1/mod:13 joshw DIALIN PPP 15-APR-1999 19:15:43 slot:1/mod:14 mc2 DIALIN PPP 15-APR-1999 14:20:00 slot:1/mod:15 DIALIN INVALID 00- -0000 00:00:00 slot:1/mod:16 mrmc DIALIN PPP 15-APR-1999 13:04:40 slot:1/mod:17 small DIALIN PPP 15-APR-1999 18:37:55 Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) strange LIST CONN
From: Brian <signal@shreve.net>
Date: 1999-04-15 14:18:11
Is anyone else seeing alot of DIALIN INVALID 00- -0000 00:00:00 in LIST CONN since upgrading to 4.1.59-6? slot:1/mod:13 joshw DIALIN PPP 15-APR-1999 19:15:43 slot:1/mod:14 mc2 DIALIN PPP 15-APR-1999 14:20:00 slot:1/mod:15 DIALIN INVALID 00- -0000 00:00:00 slot:1/mod:16 mrmc DIALIN PPP 15-APR-1999 13:04:40 slot:1/mod:17 small DIALIN PPP 15-APR-1999 18:37:55 Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) Proxy ARP
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-04-15 14:19:12
This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BE874A.EF6ED3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi There ... I remeber setting up my ARC a long while ago and having to = enable proxy arp ... I cannot find this command anywhere ... does nayone = know how to enable proxy arp on the ARC??? ...=20 ------=_NextPart_000_000D_01BE874A.EF6ED3A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Hi There ... I remeber setting up my ARC a long = while ago and=20 having to enable proxy arp ... I cannot find this command anywhere ... = does=20 nayone know how to enable proxy arp on the ARC??? ...=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_000D_01BE874A.EF6ED3A0--
Subject: Re: (usr-tc) Filters
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-15 14:42:30
Aaron Nabil said once upon a time: >Way overkill. Just enable the built-in anti-spoofing code, it'll >check the source address matches the assigned address. It's documented >in the latest hiperarc release notes. Does this take into account framed-route(s)?
Subject: Re: (usr-tc) Caller ID on Chan T1?
From: Jeff Carneal <jeff@apex.net>
Date: 1999-04-15 15:03:17
On Wed, 14 Apr 1999, Tatai SV Krishnan wrote: > > Additionally, I'm quite positive that the telco is sending 10 digits for > > ANI, 10 digits for DNIS on every call (mf digit signaling). Is caller ID > > simply not supported on channelized T1 on the hipers? Any other thoughts? > > > > Check the DSP settings - Make sure that you have it set to receive 10 digits After looking in TCM, I don't see a place to make such a setting. I see only "Number of DTMF Tones", which should not apply in this case because we're using MF signaling. With DTMF you have to know how many digits to read, but with MF you have the KP and ST to mark the beginning and end of the digit strings, so I would think this would be unnecessary. Am I looking in the wrong place or is there some other thing I'm missing here? -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.
Subject: RE: (usr-tc) 3com v90 Winmodems -> 1.2.43 code
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1999-04-15 15:29:38
Is it my understanding that the 3com PCI Winmodem is Rockwell based, and that 3com makes a modem that can't connect to its own terminal servers? Everyone is talking about LTs, which have nothing to do with 3com Winmodems. Rockwell? Krish? Krish? Tell me it isn't so. Please tell me there's a solution for users with the latest 3com Winmodem Upgrade, from the web page. /gm -- > We had a lot of complaints from users with "new" computers too. > But usually the installed modem code on their pc was a 1-3 months old. > I think there have been several revisions to the LT and Rockwell code > already this year. > Bottom line- upgrade the client modem. > We run DSP1.2.43/ARC4.1.11 (will upgrade to 4.1.59-6 soon) and after > users with poor connect speeds did an upgrade on their end, everything is > great. > These upgrades are very easy also. > > Below is an excerpt from a list message on 3-26-99, it really helped me! > Regards, > Scott Boggs > United Bank > > ======================================== > Here's the lowdown: > LT Winmodems: download the latest driver: 5.39. You can get it from > http://www.tidewater.net/56k.shtml. > > Rockwell 56k PCI: these can be either HCF or ITU modems. HCF are real crap. > They need in init string of +ms=v34 to turn off all 56k attempts. The ITU > (or non-HCF) Rockwells use an init string of +ms=11,1 or update the drivers > from the manufacturer's site. > > iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that > came with MacAddict(?) in January ( I think. I don't get the mag). > > Go to http://www.56k.com for more info on the init strings. > > Wayne Barber > Coastal Telco Services > =========================================== > > > -----Original Message----- > > From: Gilles Melanson [SMTP:gilles@vianet.on.ca] > > Sent: Wednesday, April 14, 1999 9:02 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) 3com v90 Winmodems -> 1.2.43 code > > > > This doesn't work. > > > > I have a pair of customers in different cities that dial into > > 4.1.72/1.2.43 based chassis, with their brand new Dell computers. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 The "-ell 65532" is an undocumented switch. THIS is the magic twinkle dust. Works better if you wave a dead chicken at the same time... Causes lights on the disks to go bonkers for a while. -- DEC Mailing List
Subject: Re: (usr-tc) strange LIST CONN
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-15 16:06:22
Thus spake Brian >Is anyone else seeing alot of >DIALIN INVALID 00- -0000 00:00:00 >in LIST CONN since upgrading to 4.1.59-6? >slot:1/mod:13 joshw DIALIN PPP 15-APR-1999 19:15:43 >slot:1/mod:14 mc2 DIALIN PPP 15-APR-1999 14:20:00 >slot:1/mod:15 DIALIN INVALID 00- -0000 00:00:00 >slot:1/mod:16 mrmc DIALIN PPP 15-APR-1999 13:04:40 >slot:1/mod:17 small DIALIN PPP 15-APR-1999 18:37:55 I'm seeing it with 4.1.59-2, but what I've found is that those seem to be ports that are currently handshaking. ie, the modem has picked up, but hasn't synced up yet. After this, it'll go to DIALIN PPP with no userid, then a userid will be added. Again, I haven't investigated this in depth, but it seems to be how things are working from just seeing at while watching other stuff. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) strange LIST CONN
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-15 16:36:13
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Thursday, April 15, 1999 3:06 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) strange LIST CONN | | |Thus spake Brian |>Is anyone else seeing alot of |>DIALIN INVALID 00- -0000 00:00:00 | |>in LIST CONN since upgrading to 4.1.59-6? | |>slot:1/mod:13 joshw DIALIN PPP 15-APR-1999 19:15:43 |>slot:1/mod:14 mc2 DIALIN PPP 15-APR-1999 14:20:00 |>slot:1/mod:15 DIALIN INVALID 00- -0000 | 00:00:00 |>slot:1/mod:16 mrmc DIALIN PPP 15-APR-1999 13:04:40 |>slot:1/mod:17 small DIALIN PPP 15-APR-1999 18:37:55 | |I'm seeing it with 4.1.59-2, but what I've found is that those seem to |be ports that are currently handshaking. ie, the modem has picked up, |but hasn't synced up yet. After this, it'll go to DIALIN PPP with no |userid, then a userid will be added. That is a correct observation. It is a transient state for the port. -M
Subject: RE: (usr-tc) Filters
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-15 16:36:13
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Thursday, April 15, 1999 3:43 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Filters | | |Aaron Nabil said once upon a time: | |>Way overkill. Just enable the built-in anti-spoofing code, it'll |>check the source address matches the assigned address. It's documented |>in the latest hiperarc release notes. | |Does this take into account framed-route(s)? | No.. The feature only checks the ip assigned to the interface. -M
Subject: (usr-tc) TAP does not use facility
From: Brian <signal@shreve.net>
Date: 1999-04-15 17:10:08
I have a ARC which is set as follows: HiPer>> list sysLOGS SYSLOG SINKS SysLog Log Level Msg Count Facility Allow all Auth levels 208.206.76.27 UNUSUAL 1061143 LOG_LOCAL1YES HiPer>> list tap Id Type Perm Interface User Out Fmt Facility Levl Address 1 USER No bolinger SYSL ASC LOG_LOCAL7VERB 2 USER No dandeb SYSL ASC LOG_LOCAL7VERB 3 USER No bayoupub SYSL ASC LOG_LOCAL7VERB 4 USER No jacobe SYSL ASC LOG_LOCAL7VERB 5 USER No dblak SYSL ASC LOG_LOCAL7VERB So basically this ARC logs to log_local1. I setup 5 tap users which log to log_local7. But guess where the tap really logs? log_local1. So it would appear that setting the facility for a tap user doesn't work, and that it uses the facility of the arc instead. Is this the way things are supposed to work? If so what is the facility for a tap user for? ARC code is 4.1.59-6. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) off-hook here, off-hook there?
From: Ray Bagby <rbagby@yore.net>
Date: 1999-04-15 17:37:02
> <snip> > > My question: is there some setting somewhere I could change that would > > not allow this independent phone company to "get" the off-hook and still > > allow basically everybody else to "see" the off-hook? Anybody every dealt > > with this problem before? In other words: HELP!!! > > This is known as a supervision problem. When your equipment answers, it sends a wink > back to the switch telling it that the phone line was answered, and that wink is > translated by your switch into supervision signals (on hook/ off hook) that get > transmitted over the SS7 network. Usually the wink is heard as a click when you call > into your equipment. If you have a trunk side DS-1, they usually do not ring and you > can hear the supervision click or wink before the modem answers. > > How small is this independent telephone company? Is it a local call for their > customers to call your numbers? Hi Ron, thanks for replying, No, it's not a local call for the folks there, in fact they're in another area code and the company involved is pretty small. We finally did resolve the problem though. Seems that setting the "Dial In Address" to 'no address' took care of it. Now the question is: what happened Sunday afternoon to change things? I checked the hard copy of the settings against the settings after the problems started and nothing changed here. I guess I should just be happy things are working again. ;-) Thanks again... ray
Subject: Re: (usr-tc) Filters
From: Brian <signal@shreve.net>
Date: 1999-04-15 17:41:51
On Thu, 15 Apr 1999, Aaron Nabil wrote: > Brian writes... > >On Thu, 15 Apr 1999, Paul Farber wrote: > > > >> . . . > >> I know there is a way to assign filters via RADIUS for each caller, but > >> all I want to make sure I only send/recieve packets with their IP as the > >> originating/destination.. ie kill spoofers, keep alive pings etc. > > > >they can still spoof any ip's in 207.44.65.0............ > > > >Using a RADIUS that supports "hint assigned" such as RADIATOR > >(http://www.open.com.au/radiator/) will assign each user a dynamic filter > >such that it blocks everything but their ip and netmask. > > Way overkill. Just enable the built-in anti-spoofing code, it'll > check the source address matches the assigned address. It's documented > in the latest hiperarc release notes. The problem with that code though, if I remember right, is that it always assumes a subnet mask of 255.255.255.255 does it not? > > > -- > Aaron Nabil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) strange LIST CONN
From: Brian <signal@shreve.net>
Date: 1999-04-15 18:20:13
On Thu, 15 Apr 1999, K Mitchell wrote: > At 04:06 PM 4/15/99 -0400, you wrote: > >Thus spake Brian > >>Is anyone else seeing alot of > >>DIALIN INVALID 00- -0000 00:00:00 > > > >I'm seeing it with 4.1.59-2, but what I've found is that those seem to > >be ports that are currently handshaking. ie, the modem has picked up, > >but hasn't synced up yet. After this, it'll go to DIALIN PPP with no > >userid, then a userid will be added. > > I've seen the same thing through every code revision I've had. The > sequence appears to be: DIALIN INVALID 00- -0000 00:00:00, then the > session start time is added, then changes to DIALIN PPP, then the user ID > is added last. > AFAIK it's nothing to be concerned about. Well what it was, is that I saw modems in it nonstop. Which is kinda neat cause it shows you a modem that won't handshake. I software downloaded code to that card again, and it started working fine. So if you ever see that string non-stop I guess thats a sign of a possible bad modem. Brian > > Kirk > > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) strange LIST CONN
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-15 18:49:45
At 04:06 PM 4/15/99 -0400, you wrote: >Thus spake Brian >>Is anyone else seeing alot of >>DIALIN INVALID 00- -0000 00:00:00 > >I'm seeing it with 4.1.59-2, but what I've found is that those seem to >be ports that are currently handshaking. ie, the modem has picked up, >but hasn't synced up yet. After this, it'll go to DIALIN PPP with no >userid, then a userid will be added. I've seen the same thing through every code revision I've had. The sequence appears to be: DIALIN INVALID 00- -0000 00:00:00, then the session start time is added, then changes to DIALIN PPP, then the user ID is added last. AFAIK it's nothing to be concerned about. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: (usr-tc) DSP's per Chassis
From: Greg Owens <gowens@magnolia-net.com>
Date: 1999-04-15 20:05:07
I know some of you have spoke on this this before, but refresh my memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do most of you feel this is OK to do or is now the time to break that extra chassis out of the closet and start filling it. Thanks In advance for your suggestions Greg Owens Magnolia Internet Services
Subject: Re: (usr-tc) TAP does not use facility
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-15 20:09:28
Thus spake Brian >I have a ARC which is set as follows: >So basically this ARC logs to log_local1. I setup 5 tap users which log >to log_local7. But guess where the tap really logs? log_local1. >So it would appear that setting the facility for a tap user doesn't work, >and that it uses the facility of the arc instead. Is this the way things >are supposed to work? If so what is the facility for a tap user for? >ARC code is 4.1.59-6. Hrmm...4.1.59-2 got this right. I have normal syslogs going to log_local3 and tap's going to log_local6. Works like a charm here. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) x2 Status question
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-15 20:24:56
I have a customer who is unable to connect at higher than 28.8 with his "USR 56k/v34 Fax" internal modem, product code 00568700(can't find any more specific info). My DSP sees only v34 modulation and channelNoSymbolRate(13) under x2 status. Any ideas? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) strange LIST CONN
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-15 20:27:03
At 06:20 PM 4/15/99 -0500, Brian wrote: >> >> I've seen the same thing through every code revision I've had. The >> sequence appears to be: DIALIN INVALID 00- -0000 00:00:00, then the >> session start time is added, then changes to DIALIN PPP, then the user ID >> is added last. >> AFAIK it's nothing to be concerned about. > >Well what it was, is that I saw modems in it nonstop. Which is kinda neat >cause it shows you a modem that won't handshake. I software downloaded >code to that card again, and it started working fine. So if you ever see >that string non-stop I guess thats a sign of a possible bad modem. Did <list co> show this continuously, or only when someone was trying to connect on that channel? Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) x2 Status question
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-15 20:47:27
That's probably "channel can't support 3200 symbol rate"... it's the user's phone line (or the telco's network serving him), not your end... (unless *all* your users are like that) Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Thu, 15 Apr 1999, K Mitchell wrote: > I have a customer who is unable to connect at higher than 28.8 with his > "USR 56k/v34 Fax" internal modem, product code 00568700(can't find any more > specific info). My DSP sees only v34 modulation and channelNoSymbolRate(13) > under x2 status. > Any ideas? > > Thanks, > Kirk
Subject: Re: (usr-tc) strange LIST CONN
From: Brian <signal@shreve.net>
Date: 1999-04-15 21:09:19
On Thu, 15 Apr 1999, K Mitchell wrote: > At 06:20 PM 4/15/99 -0500, Brian wrote: > >> > >> I've seen the same thing through every code revision I've had. The > >> sequence appears to be: DIALIN INVALID 00- -0000 00:00:00, then the > >> session start time is added, then changes to DIALIN PPP, then the user ID > >> is added last. > >> AFAIK it's nothing to be concerned about. > > > >Well what it was, is that I saw modems in it nonstop. Which is kinda neat > >cause it shows you a modem that won't handshake. I software downloaded > >code to that card again, and it started working fine. So if you ever see > >that string non-stop I guess thats a sign of a possible bad modem. > > Did <list co> show this continuously, or only when someone was trying to > connect on that channel? well we were on first available hunting on a busy chassis, so it looked continous since it was always being hit by someone > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) ISDN calls not authenticating on a HiperDSP card
From: das <das@gol.com>
Date: 1999-04-15 21:18:14
Hi, I hope that someone can help me with this. I've got a HiperDSP card running 1.2.2 that will not authenticate users. Analog calls authenticate fine and the connection is established. There are no other problems with any of the quads or the other HiperDSP card in the same chassis. I have tried hardware/software resets on the card as well as a software reset on the modems. I have rebooted the Netserver card (3.8.1) as well. The card was originally at 1.2.5 but I reflashed it to 1.2.2 to see if that would have any effect. Nothing has worked yet. Does anyone have any suggestions? das -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ____________________________________________
Subject: Re: (usr-tc) off-hook here, off-hook there?
From: Ronald Kushner <ron@glis.net>
Date: 1999-04-15 23:23:57
Ray Bagby wrote: > Hi Ron, thanks for replying, > No, it's not a local call for the folks there, in fact they're in > another area code and the company involved is pretty small. We finally did > resolve the problem though. Seems that setting the "Dial In Address" to 'no > address' took care of it. Now the question is: what happened Sunday > afternoon to change things? I checked the hard copy of the settings against > the settings after the problems started and nothing changed here. I guess I > should just be happy things are working again. ;-) > Thanks again... ray Wow, cool. It is possiable that the long distance telco might not have been billing customers for calling your equipment and they caught it, or they upgraded thier switch. Apperantly whatever the DNIS was doing, it confused the network to think as if the call was never answered. Hmm, you might have been sending an additional wink across the trunk - dunno what that does. I never thought about it, but the trunks delivered by the telcos might have some strange security loopholes, since they were designed to talk to other switches. -Ron GLISnet, Inc. +1 810/939.9885
Subject: Re: (usr-tc) Filters
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-15 23:37:01
Brian writes... >On Thu, 15 Apr 1999, Aaron Nabil wrote: > >> Brian writes... >> >On Thu, 15 Apr 1999, Paul Farber wrote: >> > >> >> . . . >> >> I know there is a way to assign filters via RADIUS for each caller, but >> >> all I want to make sure I only send/recieve packets with their IP as the >> >> originating/destination.. ie kill spoofers, keep alive pings etc. >> > >> >they can still spoof any ip's in 207.44.65.0............ >> > >> >Using a RADIUS that supports "hint assigned" such as RADIATOR >> >(http://www.open.com.au/radiator/) will assign each user a dynamic filter >> >such that it blocks everything but their ip and netmask. >> >> Way overkill. Just enable the built-in anti-spoofing code, it'll >> check the source address matches the assigned address. It's documented >> in the latest hiperarc release notes. > >The problem with that code though, if I remember right, is that it always >assumes a subnet mask of 255.255.255.255 does it not? Might be, but since that's what all of my subnet masks are, it's never been a problem. :) -- Aaron Nabil
Subject: Re: (usr-tc) x2 Status question
From: Rob Bachta <rob_bachta@mw.3com.com>
Date: 1999-04-16 00:08:50
Hello Kirk, The x2Status <channelNoSymbolRate> can mean a few things : 1. The line the user dialed from did not support a symbol rate of a least 3200, which is required for a x2/v.90 connection. If this is the case, they probably made a 3000 symbol rate v.34 connection at 26400bps, or lower. A client that can not obtain a 3200 symbol rate, can indicate an impairment on that line. These may be of a temporary nature, like an electrical storm, but might also be a noisy line due to wiring, faulty handset plugged into the modems phone port, long loop length, or numerous other reasons. Is this client seeing this every time or randomly? Are they making a v.34 or v.34+ connection? What is the symbol rate for this call? Have them check <Extra Settings> and look for a AT command that a 'friend of a friend' says worked great him. 2. It is possible to see this status when a client initially makes a v.90/x2 connection, but later during the call falls back to v.34, because line conditions have changed. To check for this type of condition, look at the initial connection rate to see if it is greater than 33600, or 33333 which would indicate a v.90/x2 connection. 3. The client side modem disabled 3429 & 3200 symbol rates. 4. The TC modem had 3429 & 3200 symbol rates disabled. I am working on adding the x2Status messages, and possible meanings to the x2shoot4.pdf document currently on TotalService. I guess I need to try harder ;) Regards, Rob K Mitchell <mitch@keyconn.net> on 04/15/99 05:24:56 PM Please respond to usr-tc@lists.xmission.com cc: (Rob Bachta/MW/US/3Com) I have a customer who is unable to connect at higher than 28.8 with his "USR 56k/v34 Fax" internal modem, product code 00568700(can't find any more specific info). My DSP sees only v34 modulation and channelNoSymbolRate(13) under x2 status. Any ideas? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) DSP's per Chassis
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-16 09:32:54
Has 3com fixed thier Multi chassis PPP problem yet? The old netserver and even some of the ARC code from the past would not do multilink accross chassis. If this is a concern (for ISDN cust.) you may want to make sure that you have the code that remedies this. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 15 Apr 1999, Jamie Orzechowski wrote: > we currently has a chasis with 10 DSP's and it's been working fine since > november 1998 ... we are about to split it up between 2 chassis though just > to be safe though ... > > -----Original Message----- > From: Greg Owens <gowens@magnolia-net.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, April 15, 1999 9:05 PM > Subject: (usr-tc) DSP's per Chassis > > > >I know some of you have spoke on this this before, but refresh my > >memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do > >most of you feel this is OK to do or is now the time to break that extra > >chassis out of the closet and start filling it. Thanks In advance for your > >suggestions > > Greg Owens > >Magnolia Internet Services > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Re: off-hook here, off-hook there?
From: Chris <helpchris@rconnect.com>
Date: 1999-04-16 09:37:01
I had a similar problem, only both my telco and my customer's telco are both small independents and it is a local call for my customer to call my equipment. It was dropping the call after about 5 minutes. I set the Dial in Address to noAddress and it fixed the problem that I have been pushing on both telco's to fix for over a month. I'm don't know why it fixed it, but it did. Would be nice to know why it fixed it. They are both on DMS100 and they are T1 not PRI. Chris Henderson Rural Connections ~ Information Services http://www.rconnect.com > >---------------------------------------------------------------------- > >Date: Thu, 15 Apr 1999 23:23:57 -0400 >From: Ronald Kushner <ron@glis.net> >Subject: Re: (usr-tc) off-hook here, off-hook there? > >Ray Bagby wrote: > >> Hi Ron, thanks for replying, >> No, it's not a local call for the folks there, in fact they're in >> another area code and the company involved is pretty small. We finally did >> resolve the problem though. Seems that setting the "Dial In Address" to 'no >> address' took care of it. Now the question is: what happened Sunday >> afternoon to change things? I checked the hard copy of the settings against >> the settings after the problems started and nothing changed here. I guess I >> should just be happy things are working again. ;-) >> Thanks again... ray > >Wow, cool. It is possiable that the long distance telco might not have been >billing >customers for calling your equipment and they caught it, or they upgraded thier >switch. Apperantly whatever the DNIS was doing, it confused the network to >think as if >the call was never answered. > >Hmm, you might have been sending an additional wink across the trunk - dunno >what that >does. I never thought about it, but the trunks delivered by the telcos might >have some >strange security loopholes, since they were designed to talk to other >switches. > >- -Ron >GLISnet, Inc. >+1 810/939.9885 >
Subject: Re: (usr-tc) Filters
From: Brian <signal@shreve.net>
Date: 1999-04-16 09:48:12
> >The problem with that code though, if I remember right, is that it always > >assumes a subnet mask of 255.255.255.255 does it not? > > Might be, but since that's what all of my subnet masks are, it's > never been a problem. :) nod. Alot of isp's route /28's and whatnot to customers and so this isn't a great thing for them. I would really like to see 3Com expand the functionality to include the appropriate netmask on the filter. All the information is their, so they just have to use it. They could use framed-route as well. It would be great to have something like this built into the NAS and then we wouldn't have to worry about building dynamic filters in RADIUS. The bigger you are the more of a problem it is, with users spoofing and playing games and that taking up more of your admins time. I am glad 3Com is moving in the direction where they have this capibility, I just think it can be polished a bit more, but I am patient :) > > > -- > Aaron Nabil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) DSP's per Chassis
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-16 09:48:35
Thus spake Paul Farber >Has 3com fixed thier Multi chassis PPP problem yet? The old netserver >and even some of the ARC code from the past would not do multilink >accross chassis. If this is a concern (for ISDN cust.) you may want to >make sure that you have the code that remedies this. The NETServer is still as broken as ever, and because of licensing reasons, will stay that way. The only way out of that quagmire is to annoy 3Com enough until they agree to do the right thing and replace NETServers that are being used in Multi-Chassis MultiLink scenarios with Arcs. So far, 3Com has not shown any inclination to avoid screwing over their customers though (in this situation, and in others)...we'll see what comes of it. (Kurtiss, I never heard back from you about this either ;) With respect to Arcs, I haven't found any glaring problems with Multi-Chassis Multilink on them yet. We're still fairly new to them and still working out some minor issues with them...nothing major, mostly just still figuring out how they work in depth. They seem to be pretty solid though. (4.1.59-2 fwiw) >On Thu, 15 Apr 1999, Jamie Orzechowski wrote: >> we currently has a chasis with 10 DSP's and it's been working fine >> since november 1998 ... we are about to split it up between 2 chassis >> though just to be safe though ... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) x2 Status question
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-16 09:55:07
At 12:08 AM 4/16/99 -0700, you wrote: > >Is this client seeing this every time or randomly? >Are they making a v.34 or v.34+ connection? >What is the symbol rate for this call? >Have them check <Extra Settings> and look for a AT command that a 'friend of a >friend' says worked great him. > >2. It is possible to see this status when a client initially makes a v.90/x2 >connection, but later during the call falls back to v.34, because line >conditions have changed. To check for this type of condition, look at the >initial connection rate to see if it is greater than 33600, or 33333 which would >indicate a v.90/x2 connection. Each time I've looked at his connection, it was a straight v34 connection with 28.8 initial and current connection speeds. >3. The client side modem disabled 3429 & 3200 symbol rates. How would I determine this? >4. The TC modem had 3429 & 3200 symbol rates disabled. I don't think this would be the case, as I'm seeing plenty of successful v90 and x2 connections with appropriate connection speeds. >I am working on adding the x2Status messages, and possible meanings to the >x2shoot4.pdf document currently on TotalService. I guess I need to try harder Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) DSP's per Chassis
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-04-16 09:56:59
multi chassis multilink?? I now have 2 arc's and was wondering how I can set this up?? ----- Original Message ----- Sent: Friday, April 16, 1999 9:48 AM > Thus spake Paul Farber > >Has 3com fixed thier Multi chassis PPP problem yet? The old netserver > >and even some of the ARC code from the past would not do multilink > >accross chassis. If this is a concern (for ISDN cust.) you may want to > >make sure that you have the code that remedies this. > > The NETServer is still as broken as ever, and because of licensing > reasons, will stay that way. The only way out of that quagmire is to > annoy 3Com enough until they agree to do the right thing and replace > NETServers that are being used in Multi-Chassis MultiLink scenarios with > Arcs. So far, 3Com has not shown any inclination to avoid screwing over > their customers though (in this situation, and in others)...we'll see > what comes of it. (Kurtiss, I never heard back from you about this > either ;) > > With respect to Arcs, I haven't found any glaring problems with > Multi-Chassis Multilink on them yet. We're still fairly new to them and > still working out some minor issues with them...nothing major, mostly > just still figuring out how they work in depth. They seem to be pretty > solid though. (4.1.59-2 fwiw) > > >On Thu, 15 Apr 1999, Jamie Orzechowski wrote: > >> we currently has a chasis with 10 DSP's and it's been working fine > >> since november 1998 ... we are about to split it up between 2 chassis > >> though just to be safe though ... > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: (usr-tc) syslog + PPP critical message going at the console.
From: Roy, Richard <richard.roy@nbtel.nb.ca>
Date: 1999-04-16 09:58:38
We are using 4.1.59-6 HA code and I'm using syslog to capture logs. If a user enter a wrong password, I receive a critical PPP message on the console. Here an example: Version 4.0.35 # tail auth.log | grep rro Apr 15 11:30:51 stjhts18c.nbnet.nb.ca At 14:30:51, Facility "Auth Facility", Lev el "COMMON":: Port slot:15/mod:13 unable to authenticate user - RADIUS failure f or: rro Version 4.1.59-6 Apr 15 11:48:06 mctnts05c.nbnet.nb.ca At 14:48:06, Facility "Auth Facility", Lev el "COMMON":: Port slot:14/mod:1 unable to authenticate user - RADIUS failure fo r: rro Apr 15 11:48:06 mctnts05c.nbnet.nb.ca At 14:48:06, Facility "PPP", Level "CRITIC AL":: PPP login failed on slot:14/mod:1 id: 218105418 username: rro As you can see, 4.1.59-6 adds an extra record in the log. I called 3Com support and they recommend me to do the following: set accounting log_unauthenticated_calls false It didn't stop the error message going at the console. Also, I changed the loglevel for facility PPP and still have the same behaviors. If someone has a solution to stop "Critical PPP" error messages going at the console, please let me know. Thank you. Richard Roy NBTel Internet www.nbtel.nb.ca <http://www.nbtel.nb.ca> www.nbnet.nb.ca
Subject: Re: (usr-tc) DSP's per Chassis
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-16 10:04:59
At 08:05 PM 4/15/99 -0500, you wrote: >I know some of you have spoke on this this before, but refresh my >memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do >most of you feel this is OK to do or is now the time to break that extra >chassis out of the closet and start filling it. Thanks In advance for your >suggestions On a somewhat related note, currently my chassis is: 14 YES 24 Channel High Density Modem 23 DYNAMIC NO 15 YES 24 Channel High Density Modem 23 DYNAMIC NO 16 YES HiPer Access Router NAC 0 DYNAMIC NO 17 NMC with slots 1-13 empty. This is how it came. I'll be adding 1 or 2 DSPs shortly and want to place them in slots 3 & 4, while moving 14 & 15 to 1 & 2 respectively. Is there anything I need to do to make sure the cards retain their setting as I move them and the chassis recognizes them in their new home? Chassis awareness is enabled. Thanks again, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) DSP's per Chassis
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-16 11:41:01
Thus spake Jamie Orzechowski >multi chassis multilink?? I now have 2 arc's and was wondering how I >can set this up?? You have to set up MPIP (Multilink PPP Inter-span Protocol I think is what that stands for). Basically, you set up NTP on all your systems to make sure their time is synced up, then set up one as an MPIP server, set mpip server_state on, add mpip client <ip address of MPIP client> sharedsecret <mpip sharedsecret> type hiper, (be sure to add the MPIP server as a client of itself), then on the MPIP client machines, you do add mpip server <ip address of mpip server> sharedsecret <mpip shared secret> priority 1. You add mpip client entries on the mpip server for each of your mpip clients, and on each mpip client add the mpip server entry. Then they'll cooperate when they get multi-link calls and everything should just work. :) Do make sure you have ntp set up and enabled though as the times on the systems have to be within a few seconds of each other for them to be able to do this trick. :) >> Thus spake Paul Farber >> >Has 3com fixed thier Multi chassis PPP problem yet? The old >> >netserver and even some of the ARC code from the past would not do >> >multilink accross chassis. If this is a concern (for ISDN cust.) >> >you may want to make sure that you have the code that remedies this. >> >> The NETServer is still as broken as ever, and because of licensing >> reasons, will stay that way. The only way out of that quagmire is to >> annoy 3Com enough until they agree to do the right thing and replace >> NETServers that are being used in Multi-Chassis MultiLink scenarios >> with Arcs. So far, 3Com has not shown any inclination to avoid >> screwing over their customers though (in this situation, and in >> others)...we'll see what comes of it. (Kurtiss, I never heard back >> from you about this either ;) >> >> With respect to Arcs, I haven't found any glaring problems with >> Multi-Chassis Multilink on them yet. We're still fairly new to them >> and still working out some minor issues with them...nothing major, >> mostly just still figuring out how they work in depth. They seem to >> be pretty solid though. (4.1.59-2 fwiw) >> >> >On Thu, 15 Apr 1999, Jamie Orzechowski wrote: >> >> we currently has a chasis with 10 DSP's and it's been working fine >> >> since november 1998 ... we are about to split it up between 2 >> >> chassis though just to be safe though ... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) SET PPP DNS question
From: Randy Cosby <dcosby@infowest.com>
Date: 1999-04-16 11:57:22
_sho ver V4.1.59 - 6 Wookie>> help set ppp dns The possible SET PPP DNS_USAGE commands are: SET PPP DNS_USAGE [ NONE PPP SYSTEM ] or any unique abbreviation of the keywords I can find no mention in release notes or the hiperarc command reference for 4.1.11 about the difference between NONE, PPP and SYSTEM. They just say this is off or on. What's the difference between system and ppp? Thanks, Randy
Subject: Re: (usr-tc) DSP's per Chassis
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-16 12:02:23
Why do I have a sneaky feeling that doing multi chassis multi link PPP is WAY simpler on other RAS racks? It seems that this is a workaround to a problem that 3Com has yet to properly address. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Fri, 16 Apr 1999, Jeff Mcadams wrote: > Thus spake Jamie Orzechowski > >multi chassis multilink?? I now have 2 arc's and was wondering how I > >can set this up?? > > You have to set up MPIP (Multilink PPP Inter-span Protocol I think is > what that stands for). Basically, you set up NTP on all your systems to > make sure their time is synced up, then set up one as an MPIP server, > set mpip server_state on, add mpip client <ip address of MPIP client> > sharedsecret <mpip sharedsecret> type hiper, (be sure to add the MPIP > server as a client of itself), then on the MPIP client machines, you do > add mpip server <ip address of mpip server> sharedsecret <mpip shared > secret> priority 1. > > You add mpip client entries on the mpip server for each of your mpip > clients, and on each mpip client add the mpip server entry. Then > they'll cooperate when they get multi-link calls and everything should > just work. :) > > Do make sure you have ntp set up and enabled though as the times on the > systems have to be within a few seconds of each other for them to be > able to do this trick. :) > > >> Thus spake Paul Farber > >> >Has 3com fixed thier Multi chassis PPP problem yet? The old > >> >netserver and even some of the ARC code from the past would not do > >> >multilink accross chassis. If this is a concern (for ISDN cust.) > >> >you may want to make sure that you have the code that remedies this. > >> > >> The NETServer is still as broken as ever, and because of licensing > >> reasons, will stay that way. The only way out of that quagmire is to > >> annoy 3Com enough until they agree to do the right thing and replace > >> NETServers that are being used in Multi-Chassis MultiLink scenarios > >> with Arcs. So far, 3Com has not shown any inclination to avoid > >> screwing over their customers though (in this situation, and in > >> others)...we'll see what comes of it. (Kurtiss, I never heard back > >> from you about this either ;) > >> > >> With respect to Arcs, I haven't found any glaring problems with > >> Multi-Chassis Multilink on them yet. We're still fairly new to them > >> and still working out some minor issues with them...nothing major, > >> mostly just still figuring out how they work in depth. They seem to > >> be pretty solid though. (4.1.59-2 fwiw) > >> > >> >On Thu, 15 Apr 1999, Jamie Orzechowski wrote: > >> >> we currently has a chasis with 10 DSP's and it's been working fine > >> >> since november 1998 ... we are about to split it up between 2 > >> >> chassis though just to be safe though ... > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) DSP's per Chassis
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-16 12:04:52
Thus spake Paul Farber >Why do I have a sneaky feeling that doing multi chassis multi link PPP >is WAY simpler on other RAS racks? >It seems that this is a workaround to a problem that 3Com has yet to >properly address. I don't know that its a workaround really...more just a matter of how that chose to implement it. Most other RAS systems use a broadcast'ish method of advertising and finding multilink bundles for multi-chassis support. Different strokes for different folks. Each has plusses and minuses (cue MZ's rant about using back-end servers being a "Bad Thing" here). It *has*, however, taken 3Com a *really* long time to get this to be reliable...I don't know how long it did take, or is taking, other RAS vendors to get this to be reliable...but I'd be surprised if took them that long. *shrug* >On Fri, 16 Apr 1999, Jeff Mcadams wrote: >> Thus spake Jamie Orzechowski >> >multi chassis multilink?? I now have 2 arc's and was wondering how I >> >can set this up?? >> >> You have to set up MPIP (Multilink PPP Inter-span Protocol I think is >> what that stands for). Basically, you set up NTP on all your systems >> to make sure their time is synced up, then set up one as an MPIP >> server, set mpip server_state on, add mpip client <ip address of MPIP >> client> sharedsecret <mpip sharedsecret> type hiper, (be sure to add >> the MPIP server as a client of itself), then on the MPIP client >> machines, you do add mpip server <ip address of mpip server> >> sharedsecret <mpip shared secret> priority 1. >> >> You add mpip client entries on the mpip server for each of your mpip >> clients, and on each mpip client add the mpip server entry. Then >> they'll cooperate when they get multi-link calls and everything >> should just work. :) >> >> Do make sure you have ntp set up and enabled though as the times on >> the systems have to be within a few seconds of each other for them to >> be able to do this trick. :) >> >> >> Thus spake Paul Farber >> >> >Has 3com fixed thier Multi chassis PPP problem yet? The old >> >> >netserver and even some of the ARC code from the past would not >> >> >do multilink accross chassis. If this is a concern (for ISDN >> >> >cust.) you may want to make sure that you have the code that >> >> >remedies this. >> >> >> >> The NETServer is still as broken as ever, and because of licensing >> >> reasons, will stay that way. The only way out of that quagmire is >> >> to annoy 3Com enough until they agree to do the right thing and >> >> replace NETServers that are being used in Multi-Chassis MultiLink >> >> scenarios with Arcs. So far, 3Com has not shown any inclination >> >> to avoid screwing over their customers though (in this situation, >> >> and in others)...we'll see what comes of it. (Kurtiss, I never >> >> heard back from you about this either ;) >> >> >> >> With respect to Arcs, I haven't found any glaring problems with >> >> Multi-Chassis Multilink on them yet. We're still fairly new to >> >> them and still working out some minor issues with them...nothing >> >> major, mostly just still figuring out how they work in depth. >> >> They seem to be pretty solid though. (4.1.59-2 fwiw) >> >> >> >> >On Thu, 15 Apr 1999, Jamie Orzechowski wrote: >> >> >> we currently has a chasis with 10 DSP's and it's been working >> >> >> fine since november 1998 ... we are about to split it up >> >> >> between 2 chassis though just to be safe though ... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) DSP's per Chassis
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-16 12:06:43
Thus spake Robert von Bismarck >The ARC 4.1.72-7 has a very nasty memory leak when doing Multi-chassis PPP, >I recommend upgrading to 4.1.59-2. This is the only problem we have seen so >far, not very much demand for it though... Actually, I'd suggest 4.1.59-6, which is the service release. We're only on -2 because -6 apparently (from what I've been able to determine) is missing a really teeny, tiny feature, that unfortunately we need, so I'm still on -2. Hopefully, with the next release or SR, I'll catch up with the rest of the world, though I'm suspecting that'll be the 4.2 release which I proly won't want to touch until at least the second SR of 4.2. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Configuring a "silent" TC
From: florin_neamtu@3com.com
Date: 1999-04-16 12:24:28
TCM, selecteaza modemul (sau grupul de modeme, selectind LED-ul,-rile respective), Program Settings, Line Interface Options , Line interface source schimba pe "nic" si salveaza modoficarile Did you try : TCM: select chanel's LED(s) - "Configure " - "Program Settings" - "Line Interface Source" and make sure is set for t1tdm (to use tdm bus, nic would be for NIC call termination). Give it a try. Regads, Florin
Subject: (usr-tc) Netserver 8/16 I and Multilink PPP
From: Netlink Hardware admin <hw@netlinkcom.com>
Date: 1999-04-16 12:50:39
Has anyone on this list successfully configured a Netserver 8/16 I (Plus) to accept Multilink PPP connections? Does the Multilink PPP on these only work with ISDN, or will solutions such as Diamond's Shotgun technology work? Thanks, Curt
Subject: RE: (usr-tc) SET PPP DNS question
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-16 13:29:25
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Cosby |Sent: Friday, April 16, 1999 12:57 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) SET PPP DNS question | | |_sho ver |V4.1.59 - 6 |Wookie>> help set ppp dns | |The possible SET PPP DNS_USAGE commands are: | SET PPP DNS_USAGE [ NONE PPP SYSTEM ] |or any unique abbreviation of the keywords | |I can find no mention in release notes or the hiperarc command |reference for 4.1.11 about |the difference between NONE, PPP and SYSTEM. They just say this is off |or on. What's the |difference between system and ppp? This relates to DNS servers sent to the client during IPCP. NONE = Dont send any. PPP = Send the ones configured for PPP "show PPP" SYSTEM = Send the onces configured for the HARC "list dns servers" -M
Subject: (usr-tc) hdm-analyzer.pl
From: Brian <signal@shreve.net>
Date: 1999-04-16 13:41:16
This may be of use to some. I wrote a quick program that analyzes # of calles arrived at an hdm vs. # of calls established and then prints the results. Its real rough but it works. It parses the syslog output of an ARC. I found I had a modem that took 1000+ calls and none got established, and so I flashed it real quick, really handy tool. Perhaps some of you use something like this, just something else, maybe even better: #!/usr/bin/perl # hdm-analyzer - Analyzes calls arrived vs. calls established # from ARC syslog files. # Usage: hdm-analyzer.pl <filename> <arc> # $|=1; $==56; $^L=" "; $date=`date "+%x %X"`; $file=$ARGV[0]; $choice=$ARGV[1]; open(FILE,"$file"); while(<FILE>) { ($arc,$slotmod)=(split)[3,9]; if ($choice eq $arc) { if(/arrived on interface (\S+)/) { $slotmod_a{$1}++;; } elsif(/call id \d+, on interface (\S+)/) { $slotmod_e{$1}++; } } } close(FILE); foreach (sort keys %slotmod_a) { $percent=( (($slotmod_e{$_}/$slotmod_a{$_}) *100)); write; } format STDOUT_TOP = @|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| "Modem Health Check - file: $file - chassis: $choice" @|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| "$date" slot:x/mod:y Calls Arrived Calls Established Percent Success ------------ -------------- ----------------- --------------- . format STDOUT = @<<<<<<<<<<<<< @<<<<<<<<<<<< @<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<< $_,$slotmod_a{$_},$slotmod_e{$_},$percent . output looks like: Modem Health Check - file: mar - chassis: mar1 04/16/99 13:39:12 slot:x/mod:y Calls Arrived Calls Established Percent Success ------------ -------------- ----------------- --------------- slot:1/mod:12 4 4 100 slot:1/mod:13 4 3 75 slot:1/mod:19 4 4 100 slot:1/mod:22 2 2 100 slot:1/mod:5 6 6 100 slot:1/mod:7 2 2 100 slot:1/mod:8 1 1 100 slot:1/mod:9 1 1 100 slot:2/mod:1 2 2 100 slot:2/mod:10 1 2 200 slot:2/mod:12 1 1 100 slot:2/mod:13 1 1 100 slot:2/mod:2 3 3 100 slot:2/mod:6 2 1 50 slot:2/mod:9 1 2 200 etc. After a days worth of calls on a busy chassis, gives real good data. Anything under 80% is pretty bad. I have a 75% at the top, but thats only off a sample set of data that had only 4 calls, not enough for a good determination. The reason for the few 200%'s i have, is simply because the syslog output I had started after a call arrival but before a call establish, so I ended up with 1 more establish than I should have. I am going to have it actually grok callid's and discard that type of data so it won't show those 200%'s etc. It helped me solve some problems so I wanted to post it in hopes someone else has good luck with it. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) multicasting over ARC's?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-16 15:50:03
On Thu, 8 Apr 1999, Pete Ashdown wrote: > Is anyone doing multicasting over their ARC's? Did you need to do anything > to get it to run? There are a few customer who I know are using the ARC for IGMP/multi cast. You need to enable igmp on ther interface. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) hdm-analyzer.pl (revised)
From: Brian <signal@shreve.net>
Date: 1999-04-16 16:38:38
Ok, this version of the hdm-analyzer actually tracks call id #'s and makes sure it doesn't tally a call established unless it had a call arrived for a particular id (to prevent > 100%, and skewed data). I won't post this here anymore after this, if anyone ever wants up update on what I have done with it, you can just email me. I plan to probably put some DBI::DBD stuff in their and have it poke into a database, and then update an mrtg graph with two lines showing the comparison of call arrived against call established. Brian #!/usr/bin/perl # hdm-analyzer - Analyzes calls arrived vs. calls established # from ARC syslog files. # Usage: hdm-analyzer.pl <filename> <arc> # <signal@shreve.net> $|=1; $==56; $^L=" "; $date=`date "+%x %X"`; $file=$ARGV[0]; $choice=$ARGV[1]; open(FILE,"$file"); while(<FILE>) { ($arc,$slotmod)=(split)[3,9]; if ($choice eq $arc) { if(/call id = (\d+), has arrived on interface (\S+)/) { $idtrack{$1}=1; $slotmod_a{$2}++;; } elsif((/call id (\d+), on interface (\S+)/) && ($idtrack{$1} == 1)) { $slotmod_e{$2}++; } } } close(FILE); foreach (sort keys %slotmod_a) { $percent=( (($slotmod_e{$_}/$slotmod_a{$_}) *100)); $failed=$slotmod_a{$_}-$slotmod_e{$_}; write; } format STDOUT_TOP = @|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| "Modem Health Check - file: $file - chassis: $choice" @|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| "$date" slot:x/mod:y Calls Arrived Calls Established Failed Attempts Percent Success ------------ -------------- ----------------- ---------------
Subject: Re: (usr-tc) multicasting over ARC's?
From: erick_mancera@3com.com
Date: 1999-04-16 16:59:49
I was using this configuration with a customer in a test environment. I don't remember which version of ARC we were using, but I think it shall work with latest code. Best Regards, Erick Mancera set ip multicast proxy interface eth:1 set ip igmp eth:1 multicast_forwarding enabled set network user default igmp routing enabled multicast_forwarding enabled multicast_proxy enable set ip igmp slot:14/mod:1 routing enabled multicast_forwarding enabled multicast_proxy enable Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 04/16/99 04:50:03 PM Please respond to usr-tc@lists.xmission.com cc: usr-tc@lists.xmission.com (Erick Mancera/MX/3Com) On Thu, 8 Apr 1999, Pete Ashdown wrote: > Is anyone doing multicasting over their ARC's? Did you need to do anything > to get it to run? There are a few customer who I know are using the ARC for IGMP/multi cast. You need to enable igmp on ther interface. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Brian <signal@shreve.net>
Date: 1999-04-16 17:18:10
On Fri, 16 Apr 1999, Paul Farber wrote: > We'll be in this same prediciment shortly. > > Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it > would suck if the ARC has a 7 DSP limit. > > 3Com are you listening? But why, I mean 5 hdm's per arc is pretty good deal. We run our chassis 10HDM's + 2 ARC's. Why? Because when you buy alot of chassis, their is no shortage of chassis and arcs, so why not use them? This way each arc has to do less load. Also its great having 2 arc's in a chassis even if you only have say 3 hdm's. Then remotely, if an arc should go out (and they do go out :) ), you just re-assign the ownership of the hdm's to the other arc, and everything continues to work great, great redundancy. Have you been buying double up kits and not complete chasiss? Is that why you don't have more arcs? For the difference in price between a full bundle and the double up kit, you could easily sell the nmc, chassis, power supplies and make it all back plus some, or keep the gear, or some of it, for spares. > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Fri, 16 Apr 1999, Randy Doran wrote: > > > I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code. > > We have 53 PRIs in the hunt group and it hunts round robin from the switch, > > i.e. it fills up the entire hunt group evenly. I had one 14 PRI chassis > > with a single ARC in this hunt. The calls filled up all 14 of those PRIs. > > But we started to get random regular busy signals on the hunt number when > > we were no where near filled up. I added a second HiPerARC back to the > > chassis and the busy signals stopped. My guess is that the ARC might not > > be able to handle too many incoming call setups all at once and it sends > > out a busy signal. Some calls get through and then it eventually fills up. > > Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it > > can handle the load. just a guess. > > > > Randy Doran > > RAS-Network Engineer > > CyberGate e.spire Internet Services > > > > At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote: > > >As long as you do not use IPX - Hiper arc will support 14 DSPs > > >4.1.59 code > > >krish > > > > > >----------------------------------------- > > > \ T.S.V. Krishnan \ > > > \ Network System Engineer \ ( : - : ) > > > \ 3Com ............ \ > > > ----------------------------------------------/ > > >tkrishna@bubba.ae.usr.com > > >----------------------------/ http://interproc.ae.usr.com ----/ > > >The Yadda Yadda Search - for simple anwers - > > http://interproc.ae.usr.com/tkb.html > > >-------------------------------------------------------------------------\ > > > Any Sufficiently advanced bug is indistinguishable for a feature. > > > - Rick Kulawiec > > >-------------------------------------------------------------------------/ > > > > > >On Tue, 16 Feb 1999, Randy Cosby wrote: > > > > > >> Not really an answer, but do you still need 2 ARC's for a full chassis? I > > >> thought with 4.1.72 and later, one ARC can handle a full chasis quite > > >> easily. If not, please correct me, cause I'm about to add my 11th card > > with > > >> 4.1.59 :) > > >> > > >> Randy > > >> > > >> > -----Original Message----- > > >> > From: owner-usr-tc@lists.xmission.com > > >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader > > >> > Sent: Tuesday, February 16, 1999 4:51 PM > > >> > To: usr-tc@lists.xmission.com > > >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration > > >> > > > >> > > > >> > We are an ISP with dialin PPP only that is authenticated by Radius. > > >> > We have just purchase a 14 DSP, 2 ARC chassis. Our experience to-date is > > >> > with only 10 DSP, 2 ARC chassis. Previously we have split a > > >> > single class C > > >> > between the 2 ARCs and have 121 IPs assigned to each. Question: How to > > >> > combine parts of two class Cs to a single card. For example 120 address > > >> > from 1.2.3.xxx and 49 from 1.2.4.xxx. I know I should be able to set up > > >> > ippool for each part of each class C, but I don't know if the ARC's > > >> > ethernet port needs to have an address from each class C or just one > > or if > > >> > it can be assigned an address from another class C completely. > > >> > > > >> > > > >> > > > >> > > > >> > - > > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> > with "unsubscribe usr-tc" in the body of the message. > > >> > For information on digests or retrieving files and old messages send > > >> > "help" to the same address. Do not use quotes in your message. > > >> > > > >> > > >> > > >> - > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the message. > > >> For information on digests or retrieving files and old messages send > > >> "help" to the same address. Do not use quotes in your message. > > >> > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Randy Doran <randydoran@usa.net>
Date: 1999-04-16 17:39:24
I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code. We have 53 PRIs in the hunt group and it hunts round robin from the switch, i.e. it fills up the entire hunt group evenly. I had one 14 PRI chassis with a single ARC in this hunt. The calls filled up all 14 of those PRIs. But we started to get random regular busy signals on the hunt number when we were no where near filled up. I added a second HiPerARC back to the chassis and the busy signals stopped. My guess is that the ARC might not be able to handle too many incoming call setups all at once and it sends out a busy signal. Some calls get through and then it eventually fills up. Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it can handle the load. just a guess. Randy Doran RAS-Network Engineer CyberGate e.spire Internet Services At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote: >As long as you do not use IPX - Hiper arc will support 14 DSPs >4.1.59 code >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ > >On Tue, 16 Feb 1999, Randy Cosby wrote: > >> Not really an answer, but do you still need 2 ARC's for a full chassis? I >> thought with 4.1.72 and later, one ARC can handle a full chasis quite >> easily. If not, please correct me, cause I'm about to add my 11th card with >> 4.1.59 :) >> >> Randy >> >> > -----Original Message----- >> > From: owner-usr-tc@lists.xmission.com >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader >> > Sent: Tuesday, February 16, 1999 4:51 PM >> > To: usr-tc@lists.xmission.com >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration >> > >> > >> > We are an ISP with dialin PPP only that is authenticated by Radius. >> > We have just purchase a 14 DSP, 2 ARC chassis. Our experience to-date is >> > with only 10 DSP, 2 ARC chassis. Previously we have split a >> > single class C >> > between the 2 ARCs and have 121 IPs assigned to each. Question: How to >> > combine parts of two class Cs to a single card. For example 120 address >> > from 1.2.3.xxx and 49 from 1.2.4.xxx. I know I should be able to set up >> > ippool for each part of each class C, but I don't know if the ARC's >> > ethernet port needs to have an address from each class C or just one or if >> > it can be assigned an address from another class C completely. >> > >> > >> > >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) DSP's per Chassis
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-16 17:56:13
The ARC 4.1.72-7 has a very nasty memory leak when doing Multi-chassis PPP, I recommend upgrading to 4.1.59-2. This is the only problem we have seen so far, not very much demand for it though... Cheers, Robert -----Original Message----- From: Paul Farber [SMTP:farber@admin.f-tech.net] Sent: vendredi, 16. avril 1999 15:33 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) DSP's per Chassis Has 3com fixed thier Multi chassis PPP problem yet? The old netserver and even some of the ARC code from the past would not do multilink accross chassis. If this is a concern (for ISDN cust.) you may want to make sure that you have the code that remedies this. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 15 Apr 1999, Jamie Orzechowski wrote: > we currently has a chasis with 10 DSP's and it's been working fine since > november 1998 ... we are about to split it up between 2 chassis though just > to be safe though ... > > -----Original Message----- > From: Greg Owens <gowens@magnolia-net.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, April 15, 1999 9:05 PM > Subject: (usr-tc) DSP's per Chassis > > > >I know some of you have spoke on this this before, but refresh my > >memory....We are about to add our 8th DSP card to our HyperArc Chassis. Do > >most of you feel this is OK to do or is now the time to break that extra > >chassis out of the closet and start filling it. Thanks In advance for your > >suggestions > > Greg Owens > >Magnolia Internet Services > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-16 18:05:16
We'll be in this same prediciment shortly. Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it would suck if the ARC has a 7 DSP limit. 3Com are you listening? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Fri, 16 Apr 1999, Randy Doran wrote: > I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code. > We have 53 PRIs in the hunt group and it hunts round robin from the switch, > i.e. it fills up the entire hunt group evenly. I had one 14 PRI chassis > with a single ARC in this hunt. The calls filled up all 14 of those PRIs. > But we started to get random regular busy signals on the hunt number when > we were no where near filled up. I added a second HiPerARC back to the > chassis and the busy signals stopped. My guess is that the ARC might not > be able to handle too many incoming call setups all at once and it sends > out a busy signal. Some calls get through and then it eventually fills up. > Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it > can handle the load. just a guess. > > Randy Doran > RAS-Network Engineer > CyberGate e.spire Internet Services > > At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote: > >As long as you do not use IPX - Hiper arc will support 14 DSPs > >4.1.59 code > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > >On Tue, 16 Feb 1999, Randy Cosby wrote: > > > >> Not really an answer, but do you still need 2 ARC's for a full chassis? I > >> thought with 4.1.72 and later, one ARC can handle a full chasis quite > >> easily. If not, please correct me, cause I'm about to add my 11th card > with > >> 4.1.59 :) > >> > >> Randy > >> > >> > -----Original Message----- > >> > From: owner-usr-tc@lists.xmission.com > >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader > >> > Sent: Tuesday, February 16, 1999 4:51 PM > >> > To: usr-tc@lists.xmission.com > >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration > >> > > >> > > >> > We are an ISP with dialin PPP only that is authenticated by Radius. > >> > We have just purchase a 14 DSP, 2 ARC chassis. Our experience to-date is > >> > with only 10 DSP, 2 ARC chassis. Previously we have split a > >> > single class C > >> > between the 2 ARCs and have 121 IPs assigned to each. Question: How to > >> > combine parts of two class Cs to a single card. For example 120 address > >> > from 1.2.3.xxx and 49 from 1.2.4.xxx. I know I should be able to set up > >> > ippool for each part of each class C, but I don't know if the ARC's > >> > ethernet port needs to have an address from each class C or just one > or if > >> > it can be assigned an address from another class C completely. > >> > > >> > > >> > > >> > > >> > - > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> > with "unsubscribe usr-tc" in the body of the message. > >> > For information on digests or retrieving files and old messages send > >> > "help" to the same address. Do not use quotes in your message. > >> > > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-16 18:05:16
We'll be in this same prediciment shortly. Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it would suck if the ARC has a 7 DSP limit. 3Com are you listening? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Fri, 16 Apr 1999, Randy Doran wrote: > I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code. > We have 53 PRIs in the hunt group and it hunts round robin from the switch, > i.e. it fills up the entire hunt group evenly. I had one 14 PRI chassis > with a single ARC in this hunt. The calls filled up all 14 of those PRIs. > But we started to get random regular busy signals on the hunt number when > we were no where near filled up. I added a second HiPerARC back to the > chassis and the busy signals stopped. My guess is that the ARC might not > be able to handle too many incoming call setups all at once and it sends > out a busy signal. Some calls get through and then it eventually fills up. > Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it > can handle the load. just a guess. > > Randy Doran > RAS-Network Engineer > CyberGate e.spire Internet Services > > At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote: > >As long as you do not use IPX - Hiper arc will support 14 DSPs > >4.1.59 code > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > >-------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > >-------------------------------------------------------------------------/ > > > >On Tue, 16 Feb 1999, Randy Cosby wrote: > > > >> Not really an answer, but do you still need 2 ARC's for a full chassis? I > >> thought with 4.1.72 and later, one ARC can handle a full chasis quite > >> easily. If not, please correct me, cause I'm about to add my 11th card > with > >> 4.1.59 :) > >> > >> Randy > >> > >> > -----Original Message----- > >> > From: owner-usr-tc@lists.xmission.com > >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader > >> > Sent: Tuesday, February 16, 1999 4:51 PM > >> > To: usr-tc@lists.xmission.com > >> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration > >> > > >> > > >> > We are an ISP with dialin PPP only that is authenticated by Radius. > >> > We have just purchase a 14 DSP, 2 ARC chassis. Our experience to-date is > >> > with only 10 DSP, 2 ARC chassis. Previously we have split a > >> > single class C > >> > between the 2 ARCs and have 121 IPs assigned to each. Question: How to > >> > combine parts of two class Cs to a single card. For example 120 address > >> > from 1.2.3.xxx and 49 from 1.2.4.xxx. I know I should be able to set up > >> > ippool for each part of each class C, but I don't know if the ARC's > >> > ethernet port needs to have an address from each class C or just one > or if > >> > it can be assigned an address from another class C completely. > >> > > >> > > >> > > >> > > >> > - > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> > with "unsubscribe usr-tc" in the body of the message. > >> > For information on digests or retrieving files and old messages send > >> > "help" to the same address. Do not use quotes in your message. > >> > > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-17 02:01:37
Thus spake Paul Farber >We'll be in this same prediciment shortly. >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it >would suck if the ARC has a 7 DSP limit. >3Com are you listening? From my understanding...the limit for a single Arc is more typically 10 DSP's. Obviously you can't do 20 DSP's in a chassis, so 7 is often quoted as that would be a full to capacity chassis (14 DSP's, 2 Arcs). >On Fri, 16 Apr 1999, Randy Doran wrote: >> I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code. >> We have 53 PRIs in the hunt group and it hunts round robin from the switch, >> i.e. it fills up the entire hunt group evenly. I had one 14 PRI chassis >> with a single ARC in this hunt. The calls filled up all 14 of those PRIs. >> But we started to get random regular busy signals on the hunt number when >> we were no where near filled up. I added a second HiPerARC back to the >> chassis and the busy signals stopped. My guess is that the ARC might not >> be able to handle too many incoming call setups all at once and it sends >> out a busy signal. Some calls get through and then it eventually fills up. >> Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it >> can handle the load. just a guess. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) DSP's per Chassis
From: MegaZone <megazone@megazone.org>
Date: 1999-04-17 03:36:03
Once upon a time Paul Farber shaped the electrons to say... >Why do I have a sneaky feeling that doing multi chassis multi link PPP is >WAY simpler on other RAS racks? Because it is, at least on PortMasters and MAXen. Cisco can be kind of complex - but that's an IOS trademark. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-17 22:46:34
Has any progress been made on the problem of 4.1.59-6 munging users passwords? I have seen some cases as of late where it actually hosed almost the whole password and not just the last character. This seems to be pretty common problem as well. I can't see that it actually effects only certain users, it seems almost random. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) Old 'No Accounting-Stop' issue
From: Corneliu Rudeanu <rudy@dntis.ro>
Date: 1999-04-18 07:27:24
I know it's not a new issue: sometimes I get no accounting stop radius packets when the user disconnects. AFAIK there is no solution, even with the (beta) TCS. 3.6. Is this correct? (I wish it would not...) Is there any 'hand made' solution? As far as I seen, if an user(name) disconnect once without any acctStop packet being generated, he wouldn't get any acctStop packets even next times he connects/disconnects. All the other users' sessions were handled ok, but doesn't make me feel better. The only way I could get some acctStop packets for that user was to reboot the HiperArc. And I don't call this a solution. Any hints? Did anyone try to watch (from the radius server) the Alive packets to decide if a session is 'still there'? Are those packets to be trusted or they are generated in the same probabilistic way? :/) Any idea appreciated. Corneliu Rudeanu DNT Romania
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-18 14:23:02
Brian writes... >Has any progress been made on the problem of 4.1.59-6 munging users >passwords? I have seen some cases as of late where it actually hosed >almost the whole password and not just the last character. This seems to >be pretty common problem as well. I can't see that it actually effects >only certain users, it seems almost random. It only affected certain users here, in fact in would hit them every time they called in. Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP. -a
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-18 18:55:55
On Sun, 18 Apr 1999, Aaron Nabil wrote: > Brian writes... > >Has any progress been made on the problem of 4.1.59-6 munging users > >passwords? I have seen some cases as of late where it actually hosed > >almost the whole password and not just the last character. This seems to > >be pretty common problem as well. I can't see that it actually effects > >only certain users, it seems almost random. > > It only affected certain users here, in fact in would hit them > every time they called in. > > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP. what negative effects can one expect from ppp offloading? > > -a > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-18 19:29:00
On Sun, 18 Apr 1999, Brian wrote: > On Sun, 18 Apr 1999, Aaron Nabil wrote: > > > Brian writes... > > >Has any progress been made on the problem of 4.1.59-6 munging users > > >passwords? I have seen some cases as of late where it actually hosed > > >almost the whole password and not just the last character. This seems to > > >be pretty common problem as well. I can't see that it actually effects > > >only certain users, it seems almost random. > > > > It only affected certain users here, in fact in would hit them > > every time they called in. > > > > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP. > > > what negative effects can one expect from ppp offloading? > correction: that should read "from not using ppp offloading". > > > > -a > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) DSP's per Chassis
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1999-04-18 22:23:54
: Once upon a time Paul Farber shaped the electrons to say... : >Why do I have a sneaky feeling that doing multi chassis multi link PPP is : >WAY simpler on other RAS racks? : : Because it is, at least on PortMasters and MAXen. Cisco can be kind of : complex - but that's an IOS trademark. Bah, as Dogbert would say. IOS just doesn't assume you're a dialup ISP. And if you are, there are copious, easily-accessible documents describing the setup process, and the theory behind it.
Subject: Re: (usr-tc) Stack Compression on Webramp causing problems
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-04-19 08:57:00
your message is from awhile ago. Did you find the problem? was the compression the reason for the problem? How did you turn it off?? thanks!! tony Mark Lemmert wrote: > I have several webramp customers that are having trouble. I've > isolated the problem with 3com and if I turn off 'stack compression' > on the webramp everything should work fine. > > I've looked through all the webramp pdf docs and I can't find anywhere > the command or place on the web interface to set this on or off. > Does anybody know how to do this? Thanks! > > -Mark Lemmert AthEnet Data Exchange > Chief Technical Officer 888-919-8700 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: mmm3@cornell.edu
Date: 1999-04-19 09:26:39
>No, not great redundany, there seems to be a limit of how many DSP's the >ARC can handle, so for a 10-14 DSP chassis, you would need 3 ARC's, as no >ONE card would be able to handle all the DPS's reliably. It's my understanding (and I've been know to be wrong...) that you're limited to two ARCs in a chassis. ********************************************************* Michelle M. Mogil N&CS, Network Operations Center Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-19 09:32:02
Paul Farber said once upon a time: >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it >would suck if the ARC has a 7 DSP limit. I have been running with 11 DSP's per chassis for almost as long as the HiPer system has been out. It works just fine, and segments nicely (253 ISDN B channels = /24 subnet - 1).
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-19 09:58:54
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Sunday, April 18, 1999 7:29 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) 4.1.59-6 hosing passwords | | |On Sun, 18 Apr 1999, Brian wrote: | |> On Sun, 18 Apr 1999, Aaron Nabil wrote: |> |> > Brian writes... |> > >Has any progress been made on the problem of 4.1.59-6 munging users |> > >passwords? I have seen some cases as of late where it actually hosed |> > >almost the whole password and not just the last character. This seems to |> > >be pretty common problem as well. I can't see that it actually effects |> > >only certain users, it seems almost random. |> > |> > It only affected certain users here, in fact in would hit them |> > every time they called in. |> > |> > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP. |> |> |> what negative effects can one expect from ppp offloading? |> | |correction: that should read "from not using ppp offloading". | Not much from a performance standpoint. The feature allows the DSP's to share some of the overhead of PPP with the HARC. (Normally the modem does not have any knowledge of PPP its only a data pipe). By disabling offloading the HARC will handle all aspects of the PPP termination. The HARC has more than enough power to do this with almost no noticalbe change in performance to the dial user. How many DSP's does your HARC control? -M
Subject: Re: (usr-tc) Stack Compression on Webramp causing problems
From: sagarwal@crash.ae.usr.com
Date: 1999-04-19 10:06:27
In the webramp GUI if you go to the advanced configuration section you will find the option to disable the STAC compression. From the command line you can use the setprofile command to do the same. setprofile "-n < profile id> -S < 1- enable 0 - disable>" Sanjay On Mon, 19 Apr 1999, Tony Loosle wrote: > your message is from awhile ago. Did you find the problem? was the > compression the reason for the problem? How did you turn it off?? > > thanks!! > > tony > > > Mark Lemmert wrote: > > > I have several webramp customers that are having trouble. I've > > isolated the problem with 3com and if I turn off 'stack compression' > > on the webramp everything should work fine. > > > > I've looked through all the webramp pdf docs and I can't find anywhere > > the command or place on the web interface to set this on or off. > > Does anybody know how to do this? Thanks! > > > > -Mark Lemmert AthEnet Data Exchange > > Chief Technical Officer 888-919-8700 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) tricking the HiperARC init string
From: Stefanita Vilcu <vsv@dnt.ro>
Date: 1999-04-19 10:35:58
Hi, I am looking for a metod to skip the init string sended by the HiperARC to the modem when it initializes for the first time the modem. The issue is that my modem is configured on leased line and the HiperARC resets the &L1 switch. The Init String from the interface configuration is sent after the modem resets (I've tried to put &L1 in the InitString on the set switched interface command). TIA, -vsv -- Stefanita Valeriu Vilcu, Network Administrator Dynamic Network Technologies Calea Victoriei 155, bl. D1, sc. 8, et. 2 tel: +40-1-2106863 fax: +40-1-3122745 e-mail: vsv@dnt.ro http://www.dnt.ro/~vsv/
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Chris Peltier <cpeltier@netcarrier.com>
Date: 1999-04-19 11:27:42
> |> what negative effects can one expect from ppp offloading? > |> Will this effect Webramp users? -Chris
Subject: RE: (usr-tc) DSP's per Chassis
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-19 12:08:38
Heh... it's like winblows (tm), it works fine after revision 2 ;-) --- Robert von Bismarck Network Systems Engineer Petrel Communications SA / SPAN Tel : +41 22 304 47 47 Fax : +41 22 300 48 43 e-mail : rvb@petrel.ch -----Original Message----- From: Jeff Mcadams [SMTP:jeffm@iglou.com] Sent: vendredi, 16. avril 1999 18:07 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) DSP's per Chassis Thus spake Robert von Bismarck >The ARC 4.1.72-7 has a very nasty memory leak when doing Multi-chassis PPP, >I recommend upgrading to 4.1.59-2. This is the only problem we have seen so >far, not very much demand for it though... Actually, I'd suggest 4.1.59-6, which is the service release. We're only on -2 because -6 apparently (from what I've been able to determine) is missing a really teeny, tiny feature, that unfortunately we need, so I'm still on -2. Hopefully, with the next release or SR, I'll catch up with the rest of the world, though I'm suspecting that'll be the 4.2 release which I proly won't want to touch until at least the second SR of 4.2. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) T1 receive levels
From: Brian Elfert <brian@citilink.com>
Date: 1999-04-19 13:38:26
How can I determine the receive level on a span on a T1 card? Brian
Subject: (usr-tc) Lost ISDN connectivity
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-04-19 14:13:25
We rebooted out TC last night and lost the ability for ISDN users to connect. Nothing had changed that we know of. We had previously disabled ppp offloading to accomodate our webramp users. Once we enabled it, the ISDN users could connect. We disabled it again so the webramps could come in, and now everything seems to work. Any explanations? I have followed the webramp issues for some time, and disabling the ppp offloading is the only fix that seems to work. Has anyone found a more definitive answer? How/why does this affect my ISDN customers? Samuel S. Lowe Director, Data Network Services UniversalCom, Inc. slowe@universalcom.net
Subject: (usr-tc) ISDN calls being dropped at authentication
From: das <das@gol.com>
Date: 1999-04-19 14:17:37
Hello, I posted this a while ago and didn't get a response. If anyone can help with this, I would appreciate it. I've got a HiperDSP card running 1.2.2 that will not authenticate users. Analog calls authenticate fine and the connection is established. There are no other problems with any of the quads or the other HiperDSP card in the same chassis. I have tried hardware/software resets on the card as well as a software reset on the modems. I have rebooted the Netserver card (3.8.1) as well. The card was originally at 1.2.5 but I reflashed it to 1.2.2 to see if that would have any effect. Nothing has worked yet. Does anyone have any suggestions? -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ____________________________________________
Subject: RE: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Paul Curnock <paul_curnock@pervasive.co.uk>
Date: 1999-04-19 14:31:52
I believe that new code is being beta tested to allow a single HiperARC to support the entire chassis(but this is to try to provide load sharing over multiple ARCs). I'm pretty sure that you can have more than two ARCs per chassis to provide alternate services based on DNIS numbers?, but I think that you need a HiperNMC to speed things up a bit. -----Original Message----- From: mmm3@cornell.edu [mailto:mmm3@cornell.edu] Sent: 19 April 1999 14:27 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet >No, not great redundany, there seems to be a limit of how many DSP's the >ARC can handle, so for a 10-14 DSP chassis, you would need 3 ARC's, as no >ONE card would be able to handle all the DPS's reliably. It's my understanding (and I've been know to be wrong...) that you're limited to two ARCs in a chassis. ********************************************************* Michelle M. Mogil N&CS, Network Operations Center Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) ISDN calls being dropped at authentication
From: Paul Curnock <paul_curnock@pervasive.co.uk>
Date: 1999-04-19 14:34:53
Have you checked that at*v2=0 setting you the modems? Just a suggestion... -----Original Message----- From: das [mailto:das@gol.com] Sent: 19 April 1999 06:18 To: usr-tc@lists.xmission.com Subject: (usr-tc) ISDN calls being dropped at authentication Hello, I posted this a while ago and didn't get a response. If anyone can help with this, I would appreciate it. I've got a HiperDSP card running 1.2.2 that will not authenticate users. Analog calls authenticate fine and the connection is established. There are no other problems with any of the quads or the other HiperDSP card in the same chassis. I have tried hardware/software resets on the card as well as a software reset on the modems. I have rebooted the Netserver card (3.8.1) as well. The card was originally at 1.2.5 but I reflashed it to 1.2.2 to see if that would have any effect. Nothing has worked yet. Does anyone have any suggestions? -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ____________________________________________ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) WTB USR NetServer PRI
From: access1 <access1@simplyweb.net>
Date: 1999-04-19 14:51:19
We need a NetServer PRI card set as a back-up. Anyone, please provide availability and a great price so we can buy one. Prefer p/n 002469 but will also accept 00972. COD cashiers to seller. _________________________________
Subject: (usr-tc) Looping LCP with Cisco 700 series
From: ROC Services <rocsoft@itol.com>
Date: 1999-04-19 14:59:01
Yet another interesting, maybe HiPer-related issue: I've got an ISDN customer who's unable to connect with a Cisco 766 router. Others with Cisco 7xx series routers seem to have no problem. This guy had a Cisco technician on the phone, who mentioned that I need to obtain a patch from 3Com to deal with "looping LCP" and that 3Com would know "exactly what I'm talking about." On this end, it looks like the HiPer's doing exactly what it should be. We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats. The Cisco tech says that the router never sees the ACK. Is this a 3Com issue, or a Cisco issue? I'm pointing my finger at the 766, Cisco is pointing fingers at the HiPer. HARC 4.1.59-6, HDSP 2.1.43 PPP Offloading is currently disabled, because it seems to eliminate the password-munging problem that has been discussed lately. I tried enabling it and it didn't make any difference. RECEIVE_ACCM is also disabled, it seems I recall something about certain ISDN routers becoming unhappy with that setting enabled. I've seen my share of problems with the 760 series of routers, and wouldn't mind at all telling the customer to get an 800 series, which we've never had any trouble with. But, since this Cisco tech seems firmly convinced that it's a 3Com issue and that a fix is available, I thought I'd send it in the general direction of 3Com and some users of 3Com equipment. Here's the "mon ppp" output, which to me looks like the HiPer is doing exactly what it should be: Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 54 86 e1 99 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_ACK MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 54 86 e1 99 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_ACK MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11
Subject: (usr-tc) Looping LCP with Cisco 700 series
From: ROC Services <rocsoft@itol.com>
Date: 1999-04-19 14:59:01
Yet another interesting, maybe HiPer-related issue: I've got an ISDN customer who's unable to connect with a Cisco 766 router. Others with Cisco 7xx series routers seem to have no problem. This guy had a Cisco technician on the phone, who mentioned that I need to obtain a patch from 3Com to deal with "looping LCP" and that 3Com would know "exactly what I'm talking about." On this end, it looks like the HiPer's doing exactly what it should be. We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats. The Cisco tech says that the router never sees the ACK. Is this a 3Com issue, or a Cisco issue? I'm pointing my finger at the 766, Cisco is pointing fingers at the HiPer. HARC 4.1.59-6, HDSP 2.1.43 PPP Offloading is currently disabled, because it seems to eliminate the password-munging problem that has been discussed lately. I tried enabling it and it didn't make any difference. RECEIVE_ACCM is also disabled, it seems I recall something about certain ISDN routers becoming unhappy with that setting enabled. I've seen my share of problems with the 760 series of routers, and wouldn't mind at all telling the customer to get an 800 series, which we've never had any trouble with. But, since this Cisco tech seems firmly convinced that it's a 3Com issue and that a fix is available, I thought I'd send it in the general direction of 3Com and some users of 3Com equipment. Here's the "mon ppp" output, which to me looks like the HiPer is doing exactly what it should be: Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 54 86 e1 99 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_ACK MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 54 86 e1 99 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_ACK MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11
Subject: (usr-tc) For Sale Cisco 2501 & 1602
From: access1 <access1@simplyweb.net>
Date: 1999-04-19 15:07:24
FOR SALE Cisco 2501 --New - never registered, all new box, manuals etc. IP/IPX feature set. $1500. Cisco 1602 (3 ea.) -- New -- never registered, all new box, manuals etc. IP/IPX feature set. $1100 ea. Sell separate. terms: COD cashiers or Credit card.
Subject: (usr-tc) WTB USR NetServer PRI cards
From: ryan ryan <sales.ryan@usa.net>
Date: 1999-04-19 15:40:47
We're looking for a USR PRI NetServer card set. Can use USR pn/ 002469 o= r 00972. please reasonable price. NIC and NAC set. = ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=3D= 1
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-19 15:49:10
Brian said once upon a time: > >On Mon, 19 Apr 1999, Pete Ashdown wrote: > >> Paul Farber said once upon a time: >> >> >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it >> >would suck if the ARC has a 7 DSP limit. >> >> I have been running with 11 DSP's per chassis for almost as long as the >> HiPer system has been out. It works just fine, and segments nicely (253 >> ISDN B channels = /24 subnet - 1). > >Pete, so thats 11 DSP's per arc as well? (you said "per chassis" I was >unclear to the number of ARC's you meant). Yes, 1 ARC per chassis. I'm a cheapskate.
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-19 16:38:48
> > Not much from a performance standpoint. The feature allows the DSP's to share > some of the overhead of PPP with the HARC. (Normally the modem does not have any > knowledge of PPP its only a data pipe). By disabling offloading the HARC will > handle all aspects of the PPP termination. The HARC has more than enough power to > do this with almost no noticalbe change in performance to the dial user. How > many DSP's does your HARC control? 5 per arc. I have heard disabling ppp offloading fixes the passwords from getting munged in 1.2.43. If this is the case, than certainly everyone should do it right? > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) 14 DSP, 1 ARC chassis doesn't work yet
From: Brian <signal@shreve.net>
Date: 1999-04-19 16:40:05
On Mon, 19 Apr 1999, Pete Ashdown wrote: > Paul Farber said once upon a time: > > >Have 5 DPS's in place with one ARC, but will have the 6+7th in shortly, it > >would suck if the ARC has a 7 DSP limit. > > I have been running with 11 DSP's per chassis for almost as long as the > HiPer system has been out. It works just fine, and segments nicely (253 > ISDN B channels = /24 subnet - 1). Pete, so thats 11 DSP's per arc as well? (you said "per chassis" I was unclear to the number of ARC's you meant). > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Looping LCP with Cisco 700 series
From: sagarwal@crash.ae.usr.com
Date: 1999-04-19 16:48:06
Cisco 766 Router works fine with Hiper ARC 4.1.59-6 and HDSP 1.2.43 code. What are you trying to setup MLPPP or MPIP. Is Cisco 766 setup to do CHAP or PAP. I tested MPIP with Cisco 766 and it worked fine. There is no patch on our side. Some thing to do with Cisco configuration. Also install the latest code on Cisco 766 router. Regards Sanjay Agarwal On Mon, 19 Apr 1999, ROC Services wrote: > Yet another interesting, maybe HiPer-related issue: > > I've got an ISDN customer who's unable to connect with a Cisco 766 router. > Others with Cisco 7xx series routers seem to have no problem. This guy > had a Cisco technician on the phone, who mentioned that I need to obtain a > patch from 3Com to deal with "looping LCP" and that 3Com would know > "exactly what I'm talking about." > > On this end, it looks like the HiPer's doing exactly what it should be. > We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats. The Cisco > tech says that the router never sees the ACK. > > Is this a 3Com issue, or a Cisco issue? I'm pointing my finger at the > 766, Cisco is pointing fingers at the HiPer. > > HARC 4.1.59-6, HDSP 2.1.43 > > PPP Offloading is currently disabled, because it seems to eliminate the > password-munging problem that has been discussed lately. I tried enabling > it and it didn't make any difference. RECEIVE_ACCM is also disabled, it > seems I recall something about certain ISDN routers becoming unhappy with > that setting enabled. > > I've seen my share of problems with the 760 series of routers, and > wouldn't mind at all telling the customer to get an 800 series, which > we've never had any trouble with. But, since this Cisco tech seems firmly > convinced that it's a 3Com issue and that a fix is available, I thought > I'd send it in the general direction of 3Com and some users of 3Com > equipment. > > Here's the "mon ppp" output, which to me looks like the HiPer is doing > exactly what it should be: > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 54 86 e1 99 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_ACK MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 54 86 e1 99 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_ACK MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Looping LCP with Cisco 700 series
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-19 17:26:28
On Mon, 19 Apr 1999, ROC Services wrote: > Yet another interesting, maybe HiPer-related issue: > > I've got an ISDN customer who's unable to connect with a Cisco 766 router. > Others with Cisco 7xx series routers seem to have no problem. This guy > had a Cisco technician on the phone, who mentioned that I need to obtain a > patch from 3Com to deal with "looping LCP" and that 3Com would know > "exactly what I'm talking about." Wov - interesting - So cisco does not not why there is a LCP loop? All it is that the Cisco/Hiper arc are not convering on IPCP and the other end is telling you thatit is receiving the same LCP that it sent Basically your connection either got dropped or disconnected. krish > > On this end, it looks like the HiPer's doing exactly what it should be. > We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats. The Cisco > tech says that the router never sees the ACK. > > Is this a 3Com issue, or a Cisco issue? I'm pointing my finger at the > 766, Cisco is pointing fingers at the HiPer. > > HARC 4.1.59-6, HDSP 2.1.43 > > PPP Offloading is currently disabled, because it seems to eliminate the > password-munging problem that has been discussed lately. I tried enabling > it and it didn't make any difference. RECEIVE_ACCM is also disabled, it > seems I recall something about certain ISDN routers becoming unhappy with > that setting enabled. > > I've seen my share of problems with the 760 series of routers, and > wouldn't mind at all telling the customer to get an 800 series, which > we've never had any trouble with. But, since this Cisco tech seems firmly > convinced that it's a 3Com issue and that a fix is available, I thought > I'd send it in the general direction of 3Com and some users of 3Com > equipment. > > Here's the "mon ppp" output, which to me looks like the HiPer is doing > exactly what it should be: > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 54 86 e1 99 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_ACK MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 54 86 e1 99 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:2/mod:14 > LCP CFG_REQ MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > Outgoing PPP Data on interface: slot:2/mod:14 > LCP CFG_ACK MRU 05 f2 > MAGIC_NUM 00 12 6d 71 > MPP_MRRU 07 08 > MPP_ENDPTID 03 00 40 f9 13 6f 6d > LINK_DESCR 00 11 > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Andres Kroonmaa <andre@ml.ee>
Date: 1999-04-19 18:50:52
On 19 Apr 99, at 9:58, Mike Wronski <usr-tc@lists.xmission.com> wrote: > |> > Brian writes... > |> > >Has any progress been made on the problem of 4.1.59-6 munging users > |> > >passwords? I have seen some cases as of late where it actually hosed > |> > >almost the whole password and not just the last character. This seems to > |> > >be pretty common problem as well. I can't see that it actually effects > |> > >only certain users, it seems almost random. > |> > > |> > It only affected certain users here, in fact in would hit them > |> > every time they called in. > |> > > |> > Turning off ppp offloading fixed it, so it must be a bug in the HiperDSP. > |> > |> what negative effects can one expect from ppp offloading? > | > |correction: that should read "from not using ppp offloading". > > Not much from a performance standpoint. The feature allows the DSP's to share > some of the overhead of PPP with the HARC. (Normally the modem does not have any > knowledge of PPP its only a data pipe). By disabling offloading the HARC will > handle all aspects of the PPP termination. The HARC has more than enough power to > do this with almost no noticalbe change in performance to the dial user. How > many DSP's does your HARC control? I've been assuming that making modem aware of PPP framing makes it possible for modem to do "per-packet" instead of "per-v42-buffer" compression, and that being the whole point of PPP offloading. With modem not knowing or caring what it is piping, it would love to wait for more data to come from HARC before sending a buffer to remote end. This could translate into increased latency for small packets like acks. But I'm not sure if this is sane assumption, as ARC and modems are communicating with packets anyway. I'd agree that turning off PPP offloading has little to no impact on HARC's CPU utilisation, but is it the same with client perception of performance? If so, then what's the point in this offloading altogether (other than adding another nice place in code to introduce bugs)? Mike, could you clarify on that matter? PS. Can anyone from 3com shed some light on when hdm E1-PRI service release it out? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Senior Network Engineer Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------
Subject: (usr-tc) TC chassis not taking incoming calls on part of T1 span
From: Mike McHenry <mmchen@minn.net>
Date: 1999-04-19 22:56:40
Hello all, I have a problem that is driving me crazy and I am leaning towards hardware failure. We have several TC chassis, each with one 386 T1 card, 12 Digital Quad modem cards, 1 HiperArc card, 1 16 meg NMC card. Several weeks ago one of the T1 cards starting acting up and would not accept incoming calls on the SPAN 1. The card was sent to USR for repair and was not-so-promptly returned to us with a note saying there was no problem found. There was also a note saying that the card was reflashed to version 4.2.99 and that this version was required for the card to function properly. <RANT ON> Now the first problem is 4.2.99 is not even available for download! 4.2.1 is the latest code for the Channelized T1 card and has been stable for over a year so I can't imagine why my card was reflashed to 4.2.99. This is not the first faulty card that has been sent in for a RMA and sent back to me with a note saying there was nothing wrong. My network of Total Control chassis is falling apart and it is not even being repaired when I send it in! <RANT OFF> I have seen this problem three times, each time after an unplanned power outage. About 20 modems on my chassis are not accepting any calls. The calls are being routed in across the T1, I can verify this by swapping T1s. The problem is definately NOT with the telco. The problem is also NOT with the quad modems as I can swap modems back and forth and the same 20 positions in the chassis will not take incoming calls. It is NOT a configuration issue such as the common t1tdm setting or the answer packet bus only setting. The Hiper ARC card is shown as the owner of all the cards in question when doing a list chassis. The T1 channels are active and are not OOS. The packet bus sessions appear to be up but I see no traffic on the affected channels, see below for a partial copy of a list pbus sessions: tc-2.minn.net> list pbus seSSIONS Interface Slot Channel Session Rpkts Spkts PktSize slot:2/mod:4 2 4 259 20575 18650 4096 slot:3/mod:1 3 1 512 62358 64852 4096 slot:3/mod:2 3 2 513 16674 14924 4096 slot:3/mod:3 3 3 514 0 0 4096 slot:3/mod:4 3 4 515 0 0 4096 slot:4/mod:1 4 1 768 0 0 4096 slot:4/mod:2 4 2 769 0 0 4096 slot:4/mod:3 4 3 770 0 0 4096 slot:4/mod:4 4 4 771 0 0 4096 I have tried power cycling the chassis, soft resets on the cards, hard resets on the cards, reflashing all of the cards, reseating the cards, checking the in house cabling, swapping cards with different chassis. In every case the problem seems to follow the T1 card. All of the cards are running the latest service patch code, 5.10.9 for the quads, 4.2.1 for the T1 card, 4.1.59 for the Hiper ARC, 5.5.5 for the 16meg NMC. The settings on the T1 card are correct, I have checked them about 30 times today and have also reset them a few times to make sure the settings were taking correctly. I have seen other people with very similar problems on this list, however I have yet to find a solution in the archives. Am I overlooking something here? I feel like I am bashing my head against a brick wall. Of course I do NOT want to ship this card back to USR/3com and let them look at it for another two weeks to tell me there is nothing wrong with it. I tried to call today and explain that this card was sent in for repair and was NOT repaired in the hopes that I could talk to an engineer to see why the card was sent back when it still appears to be faulty. No go, I was not allowed to talk to anyone as I do not have a service contract! Having a chassis down for two weeks in unacceptable, having it down for another two weeks because the problem wasn't fixed the first time is ludicrous! At this point I am about ready to ship the whole damn chassis in for repair and tell them the whole thing doesn't work! :) Either that or kick the thing a few times. I am entirely unhappy with these pieces of equipment and their reliability. I have probably spent 50-100 hours in the last year in dealing with problems that should have never existed. Any suggestions would be appreciated, sorry about the ranting :) Mike McHenry
Subject: Re: (usr-tc) WTB USR NetServer PRI cards
From: access1 <access1@simplyweb.net>
Date: 1999-04-20 10:12:56
pass. thanks for the response. Steve Rivera wrote: > $1500 for the netserver pri card with nic. > > At 03:40 PM 4/19/99 MDT, you wrote: > >We're looking for a USR PRI NetServer card set. Can use USR pn/ 002469 or > >00972. please reasonable price. NIC and NAC set. > > > >____________________________________________________________________ > >Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Munich Recovery
From: Michael E. Ezzell <mezzell@networkacg.com>
Date: 1999-04-20 12:36:01
Could someone explain these? Apr 20 06:45:47 argon MUNICH RECOVERY 29 (Action request timeout) Apr 20 11:25:23 argon MUNICH RECOVERY 30 (Action request timeout) Apr 20 11:52:30 argon MUNICH RECOVERY 31 (Action request timeout) They are coming from my Netserver... and I am having problems with ISDN connections (from Cisco 762s and 1604s) becoming very doggy and dropping most packets, or just suddenly failing to pass data. Sometimes this condition remedies itself, but other times I have to knock down the connection from the Netserver. When the remote router dials back in, all is well... for a time. Thanks ___________________________ Michael Ezzell, DNRC Internet Services Director The Austin Consultant Group Oklahoma City, Oklahoma 405-848-0941 mailto:mezzell@networkacg.com mailto:staff@accessacg.net
Subject: Re: (usr-tc) WTB USR NetServer PRI cards
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-20 12:46:10
$1500 for the netserver pri card with nic. At 03:40 PM 4/19/99 MDT, you wrote: >We're looking for a USR PRI NetServer card set. Can use USR pn/ 002469 or >00972. please reasonable price. NIC and NAC set. > >____________________________________________________________________ >Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) WTB: Modem Pool 16 and MP/16-I
From: Thomas Blauvelt <blauvelt@aldus.northnet.org>
Date: 1999-04-20 13:18:22
We are looking to purchase a few of the discontinued Modem Pool 16 (part number 00939) and the Modem Pool 16-I (part number 01219) boxes. New or used. Anyone know where these are available? Thanks. tom blauvelt Thomas Blauvelt NorthNet Internet Services, Inc. North Country Reference & Research Resources Council blauvelt@northnet.org 7 Commerce Lane Canton NY 13617 USA (315) 386-4569
Subject: (usr-tc) Problems with RIPv2 and Cisco Routers
From: Matthew E. Pearson <mpearson@tiac.net>
Date: 1999-04-20 14:02:20
Anyone ever see a weird problem that a TC running RIPv2 doesnt properly send its updates to a Cisco 2501 router? We are setup to accept ripv1 and v2 from the local ether but we aren't getting squat. The same identical TC config talks to the Cisco 7500 series boxes we have but the Cisco2501s have no clue. They are running IOS 11.1 . Any help would be appreciated.
Subject: RE: (usr-tc) Looping LCP with Cisco 700 series
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-20 18:17:57
I had a problem with Cisco 7xx series not connecting to an ARC/DSP chassis in the beginning of ARC-DSP times. This was fixed long ago by an ARC software upgrade (was ER 4.0.53 I think...) It does MLPPP nicely now, with BOD and all... For info : I'm running 4.1.72-7 and 1.2.5 (when will the new E1-PRI-HDM code be out ?) This "looping LCP" thing seems to be very cisco-related, a 1603 (running IOS 11.3 IP-PLUS) will loop about 4-5 times before beginning IPCP negotiation I'd love to check if the bug's still there with IOS 12.x but I don't have that IOS handy for my routers... Guess it'll have to wait for a while then. --- Robert von Bismarck Network Systems Engineer Petrel Communications SA / SPAN Tel : +41 22 304 47 47 Fax : +41 22 300 48 43 e-mail : rvb@petrel.ch -----Original Message----- From: ROC Services [SMTP:rocsoft@itol.com] Sent: lundi, 19. avril 1999 21:59 To: usr-tc@lists.xmission.com Subject: (usr-tc) Looping LCP with Cisco 700 series Yet another interesting, maybe HiPer-related issue: I've got an ISDN customer who's unable to connect with a Cisco 766 router. Others with Cisco 7xx series routers seem to have no problem. This guy had a Cisco technician on the phone, who mentioned that I need to obtain a patch from 3Com to deal with "looping LCP" and that 3Com would know "exactly what I'm talking about." On this end, it looks like the HiPer's doing exactly what it should be. We get a CFG_REQ, and send a CFG_ACK, and the cycle repeats. The Cisco tech says that the router never sees the ACK. Is this a 3Com issue, or a Cisco issue? I'm pointing my finger at the 766, Cisco is pointing fingers at the HiPer. HARC 4.1.59-6, HDSP 2.1.43 PPP Offloading is currently disabled, because it seems to eliminate the password-munging problem that has been discussed lately. I tried enabling it and it didn't make any difference. RECEIVE_ACCM is also disabled, it seems I recall something about certain ISDN routers becoming unhappy with that setting enabled. I've seen my share of problems with the 760 series of routers, and wouldn't mind at all telling the customer to get an 800 series, which we've never had any trouble with. But, since this Cisco tech seems firmly convinced that it's a 3Com issue and that a fix is available, I thought I'd send it in the general direction of 3Com and some users of 3Com equipment. Here's the "mon ppp" output, which to me looks like the HiPer is doing exactly what it should be: Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 54 86 e1 99 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_ACK MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 54 86 e1 99 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:2/mod:14 LCP CFG_REQ MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 Outgoing PPP Data on interface: slot:2/mod:14 LCP CFG_ACK MRU 05 f2 MAGIC_NUM 00 12 6d 71 MPP_MRRU 07 08 MPP_ENDPTID 03 00 40 f9 13 6f 6d LINK_DESCR 00 11 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-04-20 19:19:13
Do we need to reboot for this to take effect? disaBLE ppp ofFLOADING Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Monday, April 19, 1999 4:39 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords > > > > > > Not much from a performance standpoint. The feature allows the > DSP's to share > > some of the overhead of PPP with the HARC. (Normally the modem > does not have any > > knowledge of PPP its only a data pipe). By disabling offloading > the HARC will > > handle all aspects of the PPP termination. The HARC has more than > enough power to > > do this with almost no noticalbe change in performance to the > dial user. How > > many DSP's does your HARC control? > > 5 per arc. I have heard disabling ppp offloading fixes the passwords from > getting munged in 1.2.43. If this is the case, than certainly everyone > should do it right? >
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-20 19:45:29
On Tue, 20 Apr 1999, Marshall Morgan wrote: > Do we need to reboot for this to take effect? > > disaBLE ppp ofFLOADING No - you do not need to reboot. For the past two weeks we have been trying to reproduce the problem but have not been successful so far - Any chance that one of you can help us getting a trace - tap or anything that would help? krish > > Marshall Morgan > > Internet Doorway, Inc. (aka NETDOOR) > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > Sent: Monday, April 19, 1999 4:39 PM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords > > > > > > > > > > Not much from a performance standpoint. The feature allows the > > DSP's to share > > > some of the overhead of PPP with the HARC. (Normally the modem > > does not have any > > > knowledge of PPP its only a data pipe). By disabling offloading > > the HARC will > > > handle all aspects of the PPP termination. The HARC has more than > > enough power to > > > do this with almost no noticalbe change in performance to the > > dial user. How > > > many DSP's does your HARC control? > > > > 5 per arc. I have heard disabling ppp offloading fixes the passwords from > > getting munged in 1.2.43. If this is the case, than certainly everyone > > should do it right? > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Looping LCP with Cisco 700 series
From: Andrey Zimin <horgi@mtu.ru>
Date: 1999-04-20 20:59:19
> For info : I'm running 4.1.72-7 and 1.2.5 (when will the new E1-PRI-HDM code > be out ?) It out, but 3COM's web administrator not insert it in SL... :-)) Need fix for hands.sys :-/ === Good luck! Andrey Zimin AVZ7-RIPE
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: pferraro@wna-linknet.com
Date: 1999-04-20 22:38:23
We have been running this code along with the 1.2.43 DSP code for a couple of weeks. We are using Merit Radiusd. These are Channelized T-1s The radius user file has the standard DEFAULT user and a couple of separate entries for ISDN and Static IPs. It also authenticates for our HiperArc/Quad modem hub. This hub is running 4.1.72-7 on the HiperArc and the 5.9.10 code on the quads. We were a little reluctant to put the 4.1.59-6 code up, but to date, we have not had any problems with passwords being "MUNGED" These are supporting about 1000 customers! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Tue, 20 Apr 1999, Tatai SV Krishnan wrote: > On Tue, 20 Apr 1999, Marshall Morgan wrote: > > > Do we need to reboot for this to take effect? > > > > disaBLE ppp ofFLOADING > > No - you do not need to reboot. For the past two weeks we have been > trying to reproduce the problem but have not been successful so far - Any > chance that one of you can help us getting a trace - tap or anything that > would help? > > krish > > > > > Marshall Morgan > > > > Internet Doorway, Inc. (aka NETDOOR) > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > Sent: Monday, April 19, 1999 4:39 PM > > > To: usr-tc@lists.xmission.com > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords > > > > > > > > > > > > > > Not much from a performance standpoint. The feature allows the > > > DSP's to share > > > > some of the overhead of PPP with the HARC. (Normally the modem > > > does not have any > > > > knowledge of PPP its only a data pipe). By disabling offloading > > > the HARC will > > > > handle all aspects of the PPP termination. The HARC has more than > > > enough power to > > > > do this with almost no noticalbe change in performance to the > > > dial user. How > > > > many DSP's does your HARC control? > > > > > > 5 per arc. I have heard disabling ppp offloading fixes the passwords from > > > getting munged in 1.2.43. If this is the case, than certainly everyone > > > should do it right? > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Rick <rick@monmouth.com>
Date: 1999-04-20 22:52:04
Krish, could you kindly add some well-deserved insight as to the disable/disable topic regarding ppp offloading on the arc. I have been an avid fan of yourself (without a doubt you devote more of your time and effort then any other 3com employee) for the last few years and we have experienced an increase in the amount ppp-negotiation failures in the last month or two. We currently run 4.1.59-6 on the arc and 1.2.43 with the dsp and your 3com literature expouses the use of 'enable ppp offloading' yet the mailing list seems to suggest the opposite. I would appreciate any thoughts yourself or Mike can add on this subject... thanks
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-21 14:19:44
On Tue, 20 Apr 1999, Tatai SV Krishnan wrote: > On Tue, 20 Apr 1999, Marshall Morgan wrote: > > > Do we need to reboot for this to take effect? > > > > disaBLE ppp ofFLOADING > > No - you do not need to reboot. For the past two weeks we have been > trying to reproduce the problem but have not been successful so far - Any > chance that one of you can help us getting a trace - tap or anything that > would help? I tried that, and it really screwed my logs up, because it would appear that the facility is broken in tap syslog on 4.1.59-6. I set it to log to local6, but it logged to the syslog facility of the ARC instead of the facility I set for the tap user. Is this a known issue? > > krish > > > > > Marshall Morgan > > > > Internet Doorway, Inc. (aka NETDOOR) > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > Sent: Monday, April 19, 1999 4:39 PM > > > To: usr-tc@lists.xmission.com > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords > > > > > > > > > > > > > > Not much from a performance standpoint. The feature allows the > > > DSP's to share > > > > some of the overhead of PPP with the HARC. (Normally the modem > > > does not have any > > > > knowledge of PPP its only a data pipe). By disabling offloading > > > the HARC will > > > > handle all aspects of the PPP termination. The HARC has more than > > > enough power to > > > > do this with almost no noticalbe change in performance to the > > > dial user. How > > > > many DSP's does your HARC control? > > > > > > 5 per arc. I have heard disabling ppp offloading fixes the passwords from > > > getting munged in 1.2.43. If this is the case, than certainly everyone > > > should do it right? > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-21 15:18:00
On Wed, 21 Apr 1999, Tatai SV Krishnan wrote: > On Wed, 21 Apr 1999, Brian wrote: > > > On Tue, 20 Apr 1999, Tatai SV Krishnan wrote: > > > > > On Tue, 20 Apr 1999, Marshall Morgan wrote: > > > > > > > Do we need to reboot for this to take effect? > > > > > > > > disaBLE ppp ofFLOADING > > > > > > No - you do not need to reboot. For the past two weeks we have been > > > trying to reproduce the problem but have not been successful so far - Any > > > chance that one of you can help us getting a trace - tap or anything that > > > would help? > > > > I tried that, and it really screwed my logs up, because it would appear > > that the facility is broken in tap syslog on 4.1.59-6. I set it to log to > > local6, but it logged to the syslog facility of the ARC instead of the > > facility I set for the tap user. Is this a known issue? > > > Looks more like a syslogd issue, if configured for local6 the logs are > sent out as local6. What is OS here ? Solaris? Linux? > > Also we can do a snoop on the wire to find out what is being sent out by > the HiPer arc - I have setup local7 and the logs here go to local7 ok, I can double check, but I had local7 going to a seperate file in syslog, and it still came out the facility of the hiper. I will check again though. > > krish > > > > > > > > > > krish > > > > > > > > > > > Marshall Morgan > > > > > > > > Internet Doorway, Inc. (aka NETDOOR) > > > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > > > > > > > > -----Original Message----- > > > > > From: owner-usr-tc@lists.xmission.com > > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > > > Sent: Monday, April 19, 1999 4:39 PM > > > > > To: usr-tc@lists.xmission.com > > > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords > > > > > > > > > > > > > > > > > > > > > > Not much from a performance standpoint. The feature allows the > > > > > DSP's to share > > > > > > some of the overhead of PPP with the HARC. (Normally the modem > > > > > does not have any > > > > > > knowledge of PPP its only a data pipe). By disabling offloading > > > > > the HARC will > > > > > > handle all aspects of the PPP termination. The HARC has more than > > > > > enough power to > > > > > > do this with almost no noticalbe change in performance to the > > > > > dial user. How > > > > > > many DSP's does your HARC control? > > > > > > > > > > 5 per arc. I have heard disabling ppp offloading fixes the passwords from > > > > > getting munged in 1.2.43. If this is the case, than certainly everyone > > > > > should do it right? > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-21 15:23:50
On Wed, 21 Apr 1999, Brian wrote: > On Tue, 20 Apr 1999, Tatai SV Krishnan wrote: > > > On Tue, 20 Apr 1999, Marshall Morgan wrote: > > > > > Do we need to reboot for this to take effect? > > > > > > disaBLE ppp ofFLOADING > > > > No - you do not need to reboot. For the past two weeks we have been > > trying to reproduce the problem but have not been successful so far - Any > > chance that one of you can help us getting a trace - tap or anything that > > would help? > > I tried that, and it really screwed my logs up, because it would appear > that the facility is broken in tap syslog on 4.1.59-6. I set it to log to > local6, but it logged to the syslog facility of the ARC instead of the > facility I set for the tap user. Is this a known issue? > Looks more like a syslogd issue, if configured for local6 the logs are sent out as local6. What is OS here ? Solaris? Linux? Also we can do a snoop on the wire to find out what is being sent out by the HiPer arc - I have setup local7 and the logs here go to local7 krish > > > > > krish > > > > > > > > Marshall Morgan > > > > > > Internet Doorway, Inc. (aka NETDOOR) > > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > > > > > > -----Original Message----- > > > > From: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > > > Sent: Monday, April 19, 1999 4:39 PM > > > > To: usr-tc@lists.xmission.com > > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords > > > > > > > > > > > > > > > > > > Not much from a performance standpoint. The feature allows the > > > > DSP's to share > > > > > some of the overhead of PPP with the HARC. (Normally the modem > > > > does not have any > > > > > knowledge of PPP its only a data pipe). By disabling offloading > > > > the HARC will > > > > > handle all aspects of the PPP termination. The HARC has more than > > > > enough power to > > > > > do this with almost no noticalbe change in performance to the > > > > dial user. How > > > > > many DSP's does your HARC control? > > > > > > > > 5 per arc. I have heard disabling ppp offloading fixes the passwords from > > > > getting munged in 1.2.43. If this is the case, than certainly everyone > > > > should do it right? > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) 4.1.59-6 hosing passwords
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-21 15:39:12
I have sucessfully used the 6 different log facilitys with 59-6.. Dont know what is happening with your settup.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Wednesday, April 21, 1999 3:18 PM |To: Tatai SV Krishnan |Cc: usr-tc@lists.xmission.com; Marshall Morgan |Subject: RE: (usr-tc) 4.1.59-6 hosing passwords | | |On Wed, 21 Apr 1999, Tatai SV Krishnan wrote: | |> On Wed, 21 Apr 1999, Brian wrote: |> |> > On Tue, 20 Apr 1999, Tatai SV Krishnan wrote: |> > |> > > On Tue, 20 Apr 1999, Marshall Morgan wrote: |> > > |> > > > Do we need to reboot for this to take effect? |> > > > |> > > > disaBLE ppp ofFLOADING |> > > |> > > No - you do not need to reboot. For the past two weeks we have been |> > > trying to reproduce the problem but have not been successful so far - Any |> > > chance that one of you can help us getting a trace - tap or anything that |> > > would help? |> > |> > I tried that, and it really screwed my logs up, because it would appear |> > that the facility is broken in tap syslog on 4.1.59-6. I set it to log to |> > local6, but it logged to the syslog facility of the ARC instead of the |> > facility I set for the tap user. Is this a known issue? |> > |> Looks more like a syslogd issue, if configured for local6 the logs are |> sent out as local6. What is OS here ? Solaris? Linux? |> |> Also we can do a snoop on the wire to find out what is being sent out by |> the HiPer arc - I have setup local7 and the logs here go to local7 | |ok, I can double check, but I had local7 going to a seperate file in |syslog, and it still came out the facility of the hiper. I will check |again though. | | |> |> krish |> |> |> > |> > > |> > > krish |> > > |> > > > |> > > > Marshall Morgan |> > > > |> > > > Internet Doorway, Inc. (aka NETDOOR) |> > > > 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 |> > > > |> > > > > -----Original Message----- |> > > > > From: owner-usr-tc@lists.xmission.com |> > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |> > > > > Sent: Monday, April 19, 1999 4:39 PM |> > > > > To: usr-tc@lists.xmission.com |> > > > > Subject: RE: (usr-tc) 4.1.59-6 hosing passwords |> > > > > |> > > > > |> > > > > > |> > > > > > Not much from a performance standpoint. The feature allows the |> > > > > DSP's to share |> > > > > > some of the overhead of PPP with the HARC. (Normally the modem |> > > > > does not have any |> > > > > > knowledge of PPP its only a data pipe). By disabling offloading |> > > > > the HARC will |> > > > > > handle all aspects of the PPP termination. The HARC has more than |> > > > > enough power to |> > > > > > do this with almost no noticalbe change in performance to the |> > > > > dial user. How |> > > > > > many DSP's does your HARC control? |> > > > > |> > > > > 5 per arc. I have heard disabling ppp offloading fixes the |passwords from |> > > > > getting munged in 1.2.43. If this is the case, than |certainly everyone |> > > > > should do it right? |> > > > > |> > > > |> > > > |> > > > - |> > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> > > > with "unsubscribe usr-tc" in the body of the message. |> > > > For information on digests or retrieving files and old messages send |> > > > "help" to the same address. Do not use quotes in your message. |> > > > |> > > |> > > - |> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> > > with "unsubscribe usr-tc" in the body of the message. |> > > For information on digests or retrieving files and old messages send |> > > "help" to the same address. Do not use quotes in your message. |> > > |> > |> > ----------------------------------------------------- |> > Brian Feeny (BF304) signal@shreve.net |> > 318-222-2638 x 109 http://www.shreve.net/~signal |> > Network Administrator ShreveNet Inc. (ASN 11881) |> > |> > |> > - |> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> > with "unsubscribe usr-tc" in the body of the message. |> > For information on digests or retrieving files and old messages send |> > "help" to the same address. Do not use quotes in your message. |> > |> | |----------------------------------------------------- |Brian Feeny (BF304) signal@shreve.net |318-222-2638 x 109 http://www.shreve.net/~signal |Network Administrator ShreveNet Inc. (ASN 11881) | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |
Subject: (usr-tc) USR TC for sale w/Hiper ARC
From: C Thompson <cthompson@wingnet.net>
Date: 1999-04-21 17:21:43
We are looking at the possiblity of selling one of our USR/3com Total Control racks. Specs are as follows: Rackmount chassis Integrated fan tray 1 70 amp PS 1 NMC with memory upgrade 1 Dual PRI/T1 card 12 digital/analog quad modem cards 1 Hiper ARC card (relatively new) Asking price = around $7250 Contact me if interested, or if you wish to register a bid. Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Things are more like they are today than they ever were before.
Subject: (usr-tc) Multiple TC Chassis 48 Port and HiPer Arc cards for sale, DSP
From: Greg Genge <greg@dynavar.com>
Date: 1999-04-21 17:22:22
I Have a customer upgrading to all DSP Cards and we have a number of Total Control Shelves currently in production coming out soon. These all have Dual Pri/T1, 48 Quad Digital, HiPer Arc card and HiPer NMC all running latest code and ALL X2/V.90 enabled. from what I have seen these should go for between $5500 and $7000 US each depending on Quantity, most are in Dual 45Amp chassis and include the Fan tray (can be upgraded to newer 70Amp integrated Fan tray chassis for additional charge). If you are interested, send me your bid, Include how much, How many you would like. I need these all to be gone by May 15th and will ship reasonable offers that come in. I also have a number of Arc cards, taking offers for these as well around $2000 each USD. Also have lots of NMC and Netserver memory upgrades $100 US each, 2 or more $75 each. Also have Regards, Greg . . . . . Questions, Call me at 877-Dynavar Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.
Subject: (usr-tc) 3446-0 HiPer DSP Cardsets Only $8335 trade 12Quads for 2 FREE
From: Greg Genge <greg@dynavar.com>
Date: 1999-04-21 17:33:30
We have a huge inventory of DSP Cardsets 48 ports, 003446-0 for only $8335 brand new (only for this list's members). Then you can trade in 12 Quad cards and get another 48 ports of DSP cards for FREE from 3COM. For details on our website, go to: http://www.dynavar.com/product/3com/3com.htm AND YES WE ARE AN NSP AUTHORIZED 3COM TOTAL CONTROL RESELLER (Largest in Canada), Price includes delivery anywhere in US or Canada. We also have sets of used Quad cards going for $3995 US OBO. that you can trade in. Better pricing on multiple sets. Questions call Greg at 877-DYNAVAR toll free. Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.
Subject: (usr-tc) ARC Traps
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-04-21 18:33:22
Hello all I need to set up traps on the ol ARC to debug these call failures we seem to have to live with. I can get the ARC to syslog to my Linux box, but no traps ever come out of the damned thing. I 3kb'ed it and they assume that I am gonna use thier alarm server (it seems). I am using UCD-SNMP 3.5.3 and it will accept cold start traps from local linux boxes, but the ARC dosen't want to caugh them up. And I know that I am getting call failures. Does the normal syslog report call failures? The ARC chatters alot.. but from what I have so far there have been no call failures (i wish). Thanks. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net
Subject: (usr-tc) ISDN call debug
From: huix@990.net
Date: 1999-04-22 02:13:36
Generated by Net Ease Web mail system! ------net924747216-ease15216---- Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by slack.xmission.com id LAA10987 Hi,=20 I monitor PPP call use ppp ficility, set ficility ppp loglevel verbose I get call information and find ISDN canot build MP during LCP phase, who can tell me it is which end canot accept MP option? __________________________________________________ =BB=B6=D3=AD=CA=B9=D3=C3=BD=F0=C1=EA=C8=C8=CF=DF=C3=E2=B7=D1=B5=E7=D7=D3=D3= =CA=BC=FE=CF=B5=CD=B3http://www.990.net ------net924747216-ease15216---- Content-Type: text/plain; name="\isdn.txt" Content-Disposition: attachment; filename="\isdn.txt" Content-Transfer-Encoding: 8bit At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_add_portal]: set add portal c ondition call_id 503318028At 03:28:36, Facility "PPP", Level "COMMON":: [csm_drv _state_change] bundle 15, link 20857464, state 1 At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_send_session_start_banner]: N o user yet, don't have to send initial banner At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_get_and_set_drv_control]: Dig ital call,CCP flag 1 At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_get_and_set_drv_control]: Off load, driver says YES At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_set_drv_accm]:set rx accm fff fffff tx accm ffffffff At 03:28:36, Facility "PPP", Level "COMMON":: [ppp_set_drv_accm]:set rx accm fff fffff tx accm ffffffff At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_makereq] asking for MMRU: 15 14 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_makereq] asking for MMRU: 15 14 At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:36, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:36, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:36, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:37, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:37, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "COMMON":: [psm_chkreq]: remote asking for UN IMP option: d, len: 3 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "COMMON":: [psm_open(LCP)]: PPP Connection Op en At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_set_drv_accm]:set rx accm 0 t x accm 0 At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_load_config]: LOCAL_IP_ADDR 0 xa4e00f4 At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_load_config]:NS addresses fro m User Config PRIM DNS 0, SEC DNS 0 , PRIM NBNS 0, PRIM NBNS 0 At 03:28:38, Facility "PPP", Level "VERBOSE":: [ppp_send_msg_to_td]: sending TUN DISP_QUERY_REQ At 03:28:38, Facility "PPP", Level "VERBOSE":: [ppp_process_main]: TD_QUERY_RSP At 03:28:38, Facility "PPP", Level "VERBOSE":: [ppp_process_main]: No tunneling protocol will be involved At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "COMMON":: [psm_open(PAP)]: PPP Connection Op en At 03:28:38, Facility "PPP", Level "COMMON":: [psm_sendgetopt (IPCP)] At 03:28:38, Facility "PPP", Level "COMMON":: [psm_sendgetopt]: connection typ e ConnChangeNormal At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_sendgetopt]: profile id set to 2e004. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_sendgetopt]: connection id set to 9c0000. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_sendgetopt]: connection typ e set to dial in. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_sendgetopt]: number of opti ons set to 2. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_sendgetopt]: Local Ip addre ss set to 0xa4e00f4. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_sengetopt]: Remote IP addre ss set to 0x0. At 03:28:38, Facility "PPP", Level "UNUSUAL":: [sendgetopt] Layer IPCP sent GetO pt, new state = AWAITING_ADD_PORTAL At 03:28:38, Facility "PPP", Level "COMMON":: [psm_send_dns_req (IPCP)] At 03:28:38, Facility "PPP", Level "COMMON":: [psm_start] : Taking globally conf igured NBNS - Primary 0 , Seconadry 0 At 03:28:38, Facility "PPP", Level "COMMON":: [psm_rcvreq]: RX'd UNEXPECTED PKT( IPCP): State: STARTING, CP code: Config Req At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_get_option_rsp]: RETURN_STATU S = 0 At 03:28:38, Facility "PPP", Level "UNUSUAL":: [get_option_rsp] prot 1 notified, new state = ATTACHED At 03:28:38, Facility "PPP", Level "UNUSUAL":: [get_option_rsp] PDB CHAIN NOW LO OKS LIKE THIS: At 03:28:38, Facility "PPP", Level "UNUSUAL":: Unsupported protocol 0 At 03:28:38, Facility "PPP", Level "UNUSUAL":: IP, pdb 22882f8 At 03:28:38, Facility "PPP", Level "COMMON":: [ppp_dns_ns_rsp]: DNS response, Pr im a4e001e Sec a4a001e At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1 At 03:28:38, Facility "PPP", Level "COMMON":: [psm_open(CCP)]: PPP Connection Op en At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:39, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:40, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:40, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate PRIM DNS At 03:28:41, Facility "PPP", Level "VERBOSE":: Primary DNS addr rcvd : 0 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate PRIM NBNS At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate SEC DNS At 03:28:41, Facility "PPP", Level "VERBOSE":: Secondary DNS addr rcvd : 0 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate SEC NBNS At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate PRIM DNS At 03:28:41, Facility "PPP", Level "VERBOSE":: Primary DNS addr rcvd : 0 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate SEC DNS At 03:28:41, Facility "PPP", Level "VERBOSE":: Secondary DNS addr rcvd : 0 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:41, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate PRIM DNS At 03:28:42, Facility "PPP", Level "VERBOSE":: Primary DNS addr rcvd : a4e001e At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_chkreq]: remote asking to ne gotiate SEC DNS At 03:28:42, Facility "PPP", Level "VERBOSE":: Secondary DNS addr rcvd : a4a001e At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: switching on layer (I PCP) At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: i = 0 At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: option ACKed At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: i = 1 At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: option ACKed At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: i = 2 At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: option ACKed At 03:28:42, Facility "PPP", Level "COMMON":: [verify_op]: about to go open At 03:28:42, Facility "PPP", Level "COMMON":: [psm_open(IPCP)]: PPP Connection O pen At 03:28:42, Facility "PPP", Level "COMMON":: [psm_open]: Add route to peer (a4e 00f4) from host yuan At 03:28:42, Facility "PPP", Level "COMMON":: [csm_fwdr_state_change] bundle 15, proto_type 1, state 1 At 03:28:42, Facility "PPP", Level "UNUSUAL":: [fwdr_state_change] prot 1, DRV_A CTIVE At 03:28:42, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: MPP sync estab lished on seq #0. At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:42, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:42, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:43, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:43, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:43, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:44, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:44, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:44, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:44, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:45, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:45, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:46, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:47, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:47, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:47, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:47, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:47, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:47, Facility "PPP", Level "COMMON":: M = 14, first END seq = 12 At 03:28:47, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 1 2, M = 14 At 03:28:47, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:47, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:48, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:48, Facility "PPP", Level "COMMON":: M = 18, first END seq = 16 At 03:28:48, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 1 6, M = 18 At 03:28:48, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:50, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:50, Facility "PPP", Level "COMMON":: M = 1d, first END seq = 1a At 03:28:50, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 1 a, M = 1d At 03:28:50, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:50, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:51, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:51, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:51, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:51, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:52, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:53, Facility "PPP", Level "COMMON":: M = 22, first END seq = 20 At 03:28:53, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2 0, M = 22 At 03:28:53, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:53, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:54, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:55, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:55, Facility "PPP", Level "COMMON":: M = 27, first END seq = 24 At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2 4, M = 27 At 03:28:55, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:55, Facility "PPP", Level "COMMON":: M = 2c, first END seq = 2a At 03:28:55, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2 a, M = 2c At 03:28:55, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:55, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:56, Facility "PPP", Level "COMMON":: M = 30, first END seq = 2e At 03:28:56, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 2 e, M = 30 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:56, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:57, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:58, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:59, Facility "PPP", Level "COMMON":: M = 34, first END seq = 32 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3 2, M = 34 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:28:59, Facility "PPP", Level "COMMON":: M = 38, first END seq = 36 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3 6, M = 38 At 03:28:59, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:28:59, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:00, Facility "PPP", Level "COMMON":: M = 3c, first END seq = 3a At 03:29:00, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3 a, M = 3c At 03:29:00, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:00, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:00, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:01, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:01, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:01, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:01, Facility "PPP", Level "COMMON":: M = 40, first END seq = 3e At 03:29:01, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 3 e, M = 40 At 03:29:01, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:01, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:02, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:02, Facility "PPP", Level "COMMON":: M = 43, first END seq = 42 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4 2, M = 43 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:02, Facility "PPP", Level "COMMON":: M = 47, first END seq = 45 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4 5, M = 47 At 03:29:02, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:02, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:03, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:03, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:03, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:03, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:04, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:04, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:04, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:04, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:04, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:04, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:04, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:05, Facility "PPP", Level "COMMON":: M = 4c, first END seq = 49 At 03:29:05, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4 9, M = 4c At 03:29:05, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:05, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:05, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:06, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:06, Facility "PPP", Level "COMMON":: M = 50, first END seq = 4e At 03:29:06, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 4 e, M = 50 At 03:29:06, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:06, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:07, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:07, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:07, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:08, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:08, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:09, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:10, Facility "PPP", Level "COMMON":: M = 54, first END seq = 52 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 5 2, M = 54 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:10, Facility "PPP", Level "COMMON":: M = 58, first END seq = 56 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 5 6, M = 58 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:10, Facility "PPP", Level "COMMON":: M = 5e, first END seq = 5a At 03:29:10, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 5 a, M = 5e At 03:29:10, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:10, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:11, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:11, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:12, Facility "PPP", Level "UNUSUAL":: [psm_rx_pkt]: FREAKY: MS CPP rx'd with no COMP BIT SET At 03:29:12, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:13, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:13, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:13, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:13, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:13, Facility "PPP", Level "COMMON":: M = 62, first END seq = 60 At 03:29:13, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6 0, M = 62 At 03:29:13, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:13, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:14, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:14, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:14, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:14, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:15, Facility "PPP", Level "COMMON":: M = 67, first END seq = 64 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6 4, M = 67 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:15, Facility "PPP", Level "COMMON":: M = 6c, first END seq = 6a At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6 a, M = 6c At 03:29:15, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:15, Facility "PPP", Level "COMMON":: M = 70, first END seq = 6e At 03:29:15, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 6 e, M = 70 At 03:29:15, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:15, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:16, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:16, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:16, Facility "PPP", Level "COMMON":: [psm_send_frames] DID NOT COMPRESS , ms_cmp_ret = 80 At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:16, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:17, Facility "PPP", Level "COMMON":: M = 75, first END seq = 72 At 03:29:17, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 7 2, M = 75 At 03:29:17, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:17, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:18, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1 At 03:29:18, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: lost frag(s) d etected... At 03:29:18, Facility "PPP", Level "COMMON":: M = 79, first END seq = 77 At 03:29:18, Facility "PPP", Level "COMMON":: [psm_rx_mpp_frame]: rlsing frame 7 7, M = 79 At 03:29:18, Facility "PPP", Level "COMMON":: [psm_sendresetreq(CCP)] ------net924747216-ease15216------
Subject: (usr-tc) Accepting 2400bps modem connections on HDM
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-22 10:11:10
Hi, What do I need to set up in an HDM to accept a pure 2400 bps (V.22bis) connection ? I have several customers who'd like to dial in with some handheld modems that will only do V.22bis or Group3 FAX... Thanks for any infos... Robert
Subject: IMAC?? (usr-tc)
From: Brian M. Gordon <administrator@westelcom.com>
Date: 1999-04-22 10:12:06
I have Hiper DSP's And Hiper ARC all newest code. Whats the deal with IMAC is it totally incompatable unless you drop it down to V.34? Brian Gordon, MCP, A+ Network Administrator Westelcom Internet 518-566-8376 Voice 518-566-8348 Fax http://home.westelcom.com administrator@westelcom.com
Subject: RE: IMAC?? (usr-tc)
From: Wayne Barber <barberw@tidewater.net>
Date: 1999-04-22 10:22:46
They need to install the Apple Modem Updater 1.2.1 which has been out since at least January. How you get it to them can be a problem if they don't have the floppy drive. I've heard it came on the CD with the January MacAddict magazine. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian M. Gordon > Sent: Thursday, April 22, 1999 10:12 AM > To: usr-tc@lists.xmission.com > Subject: IMAC?? (usr-tc) > > > I have Hiper DSP's And Hiper ARC all newest code. > > Whats the deal with IMAC is it totally incompatable unless you > drop it down > to V.34? > > Brian Gordon, MCP, A+ > Network Administrator > Westelcom Internet > 518-566-8376 Voice > 518-566-8348 Fax > http://home.westelcom.com > administrator@westelcom.com > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) FS: USR QUAD ANALOG/DIGITAL MODEMS
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-04-22 11:13:21
Hello- We are slowly replenishing our stock of USR Total Control Units and parts. We now have (100+) Quad Analog/Digital Modems - V.34 USR# 000793-04 $175.00 each (NAC only) Also (6) Netserver PRI cards (NAC & NIC) USR#69-001393-00 Rev. 1 w/ token ring NIC USR#69001827-00 Rev. C $OFFER (20) AC PSU 45A Power Supplies $OFFER More chassis in next week. ( I hope) With Warmest Regards, Andrew Shlensky **************************** PC Global, Incorporated (305) 667-2111 TEL (305) 667-3636 FAX URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089
Subject: (usr-tc) OK...this is a weird one...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-22 11:23:09
Alright...I've got a few of my HiPer Arcs around here...had one in service here in our main location here in Louisville, no problems. Get all the calls off of it and moved over to other equipment so I can take it down to our POP in Lexington and replace two NETServers with it. (this was yesterday). I take out the two NETServers (chassis had 4 DSP's and two NETServers there) and plug the HiPer Arc into it. The HiPer Arc decides its going to do it long pause during boot-up thing. This is the thing I ran into before where it pauses about 45 seconds between each letter of "Loading kernel ... OK" during bootup...meaning the boot up process takes about 10 minutes. Last time this happened to me I did the AT{FZ} thing during bootup to format and reflash the card with the image and it fixed it. Down in Lexington yesterday, I didn't have a platform that I could run zmodem on (I was connected to the console with an old Wyse60 terminal), so I put the NETServers back in and bring the HiPer Arc back to Louisville to play with it some more here. I plug it in to a chassis this morning (the original one it was in before I took it out to take down to Lexington), and it boots up immediately, no pauses. So for yucks, I take it out and put it in a different chassis here in Louisville, and again, it boots up with no pauses. All three chassis are getting clocking from the backplane (backplaneActive), the Lexington chassis and the second Louisville chassis have NMC versions 5.5.1, the first Louisville chassis has NMC version 5.5.5, the second Louisville chassis doesn't have any other cards in it at all! All chassis have the integrated fan tray with enhanced packet bus and all. Boot Rom version on the Arc is 1.16. I can't think of anything else that would be of any significance here. One of the NETServers is fully functioning in slot 16 of the Lexington chassis where I had plugged the HiPer Arc in. The Arc was power cycled and reseated multiple times while in the Lexington chassis. Anyone have any enlightenment to share here? I'm out of ideas. I'm planning on going back tomorrow and planning on taking a laptop with me rather than the terminal so I can do a zmodem transfer (with flash format) if necessary to get this thing working in that chassis. I'd *really* rather have an idea of what's causing rather than blindly trying the flash format and have that *possibly* not fix it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) HiperDSP Question
From: John Verreault <verreaul@aei.ca>
Date: 1999-04-22 11:24:53
I have one DSP card with a daughtercard. All of my other DSP cards do not have a daughtercard. Question: What is the daughtercard for??? Thanks John
Subject: (usr-tc) tele com tests
From: Brian <signal@shreve.net>
Date: 1999-04-22 11:33:01
Anyone check out the April 19th issue of tele com? They did tests on RAS boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel. Surprisingly, the 3Com box had the lowest density! I guess 3Com is sort of behind now in that area, even though they were one of the first to offer the higher density boxes. The Nortel 1800 looks like it is going to be a really nice box. the 3Com ARC based box (4.1.59) had the 2nd highest call completion rates, only to be beat by the Nortel box by .8%. the 3Com box was one of the most expensive (only the lucent was more expensive). The 3Com gear did not do well on the stress test IMHO. And reading thru the article, trying to find flaws, it looked like a pretty good test. They do not mention what version of DSP code was in use however, I am assuming 1.2.60, but I really don't know. Can anyone from 3com perhaps give insight on the stress test results, and possibly why the 3Com box would score so poorly? The throughput of the Assured Access, Ascend, and Cisco boxes was pretty much the same, and very good. Nortel, Lucent and 3Com seemed more chaotic, with large jumps in throughput between different sized packets. The 3Com performed over 25% better with packets of 1518 and 256 in size vs packets of 108 in size. It really appears alot was done to level the playing field to make this a fair test. I do not know whether 1 or 2 ARC's were used, and that may have all the difference in the world as to why the tests scored the way they did. They used 383 ports simultaneously per box to do the test, and I am not sure whether that was e1 or t1 code and how many hdm's and how many arcs. Does anyone know? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) tele com tests
From: Netlink Hardware admin <hw@netlinkcom.com>
Date: 1999-04-22 12:16:33
Were you able to view this article online, or do you have the printed version? What URL? I went to http://www.teledotcom.com but did not find this article. Thanks, Curt On Thu, 22 Apr 1999, Brian wrote: > > Anyone check out the April 19th issue of tele com? They did tests on RAS > boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel. ><SNIP>
Subject: (usr-tc) RE: (3Com - TotalControl): Lucent WildWire/V.90 Modems Not Connecting
From: Hofmann <jay@iglou.com>
Date: 1999-04-22 13:21:56
I have a user that can connect but gets very poor speeds. Here is a copy of the logs he sent. 04-20-1999 22:48:02.42 - Lucent V90+DSL WildWire Modem in use. 04-20-1999 22:48:02.43 - Modem type: Lucent V90+DSL WildWire Modem 04-20-1999 22:48:02.43 - Modem inf path: LTBLIZDF.INF 04-20-1999 22:48:02.43 - Modem inf section: Modem_PNP_DSVD 04-20-1999 22:48:02.57 - 115200,N,8,1 04-20-1999 22:48:02.57 - 57600,N,8,1 04-20-1999 22:48:02.57 - Initializing modem. 04-20-1999 22:48:02.58 - Send: AT<cr> 04-20-1999 22:48:02.58 - Recv: AT<cr> 04-20-1999 22:48:02.58 - Recv: <cr><lf>OK<cr><lf> 04-20-1999 22:48:02.58 - Interpreted response: Ok 04-20-1999 22:48:02.58 - Send: AT &F E0 &C1 &D2 V1 S0=0\V1<cr> 04-20-1999 22:48:03.11 - Recv: AT &F E0 &C1 &D2 V1 S0=0\V1<cr> 04-20-1999 22:48:03.11 - Recv: <cr><lf>OK<cr><lf> 04-20-1999 22:48:03.11 - Interpreted response: Ok 04-20-1999 22:48:03.11 - Send: ATS7=60S30=0L0M1\N3%C1&K3B0B15B2N0\J1X4<cr> 04-20-1999 22:48:03.12 - Recv: <cr><lf>OK<cr><lf> 04-20-1999 22:48:03.12 - Interpreted response: Ok 04-20-1999 22:48:03.12 - Dialing. 04-20-1999 22:48:03.12 - Send: ATDT;<cr> 04-20-1999 22:48:06.04 - Recv: <cr><lf>OK<cr><lf> 04-20-1999 22:48:06.04 - Interpreted response: Ok 04-20-1999 22:48:06.04 - Dialing. 04-20-1999 22:48:06.04 - Send: ATDT#######<cr> 04-20-1999 22:48:30.54 - Recv: <cr><lf>CONNECT 26400 V42bis<cr><lf> 04-20-1999 22:48:30.54 - Interpreted response: Connect 04-20-1999 22:48:30.54 - Connection established at 26400bps. 04-20-1999 22:48:30.54 - Error-control on. 04-20-1999 22:48:30.54 - Data compression on. Jay Hofmann Email: jayh@iglou.com Technical Support Team Leader Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Netserver messages
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-04-22 13:39:13
I have one TC with Netserver that is giving lots of the following syslog messages: Apr 22 11:48:51 netserver1 S19 didn't get online! status=-1, connect_fail=36, link_fail=31 Apr 22 12:22:54 netserver1 S43 didn't get online! status=-1, connect_fail=79, link_fail=31 What does it mean? U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.6.22 Build date: Aug 1 1997 Build time: 16:52:40 NMC v5.5.5 - Marcelo
Subject: Re: (usr-tc) tele com tests
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-04-22 13:49:23
Here is the article: http://www.data.com/issue/990421/ras.html ----- Original Message ----- Sent: Thursday, April 22, 1999 12:16 PM > > Were you able to view this article online, or do you have the printed > version? What URL? > > I went to http://www.teledotcom.com but did not find this article. > > Thanks, > Curt > > On Thu, 22 Apr 1999, Brian wrote: > > > > > Anyone check out the April 19th issue of tele com? They did tests on RAS > > boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel. > ><SNIP> > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Quad v.32 terbo Upgrade
From: Greg Coffey <greg@coffey.com>
Date: 1999-04-22 14:12:59
Can a v32terbo quad modem be upgraded firmware to v.34 or even v.90? I have five of them and they appear to be double sided. Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ==================================================================== 142 S. Center St. 3Com v.90 56k $20 in Casper & Douglas Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, http://WWW.COFFEY.COM Wheatland, Pinedale, Lander & Lusk, WY
Subject: Re: (usr-tc) HiperDSP Question
From: David Bachta <david_bachta@mw.3com.com>
Date: 1999-04-22 15:31:22
Hi John, Sounds like you have an E1 card. The daughtercard adds the necessary hardware (additional DSPs) to allow the HDSP to be used in an E1 environment. The card can still be used in a T1 environment, as long as you have T1/PRI code running on it. Regards, David "John Verreault" <verreaul@aei.ca> on 04/22/99 10:24:53 AM Please respond to usr-tc@lists.xmission.com cc: (David Bachta/MW/US/3Com) I have one DSP card with a daughtercard. All of my other DSP cards do not have a daughtercard. Question: What is the daughtercard for??? Thanks John - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) MPIP, RIP and ping/traceroute
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-22 16:01:28
I'm trying to set up my first MPIP connections with HiPerARC's I have some problems with RIP updates and IP routing. My gateway router seems to get a little confused with two entries in its RIP routing table. Router# sh ip route rip [ deleted items] R g.h.i.j [120/1] via a.r.c.1, 00:00:13, FastEthernet0/0 g.h.i.j [120/1] via a.r.c.2, 00:00:22, FastEthernet0/0 Router# ping g.h.i.j Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to g.h.i.j, timeout is 2 seconds: !..!! Success rate is 60 percent (3/5), round-trip min/avg/max = 56/57/60 ms The pings go through slowly (I tried with a 64k connection, and it is okay and much faster) and are not even all ACKed... I tried doing a download with the ISDN device (a zyxel prestige router) and got a lousy 3.5kb/s. with single-channel ISDN I get about 7.5kb/s. Is there something special about MPIP, or is it simply lousy ? I'm running ARC 4.1.72-7 and 1.2.5 on the DSP's (yeah, I should upgrade to 4.1.59-6 now that 1.2.43 is out for the E1 HDM's, but I'm lazy and overfilled with work) Here's the setup of my PoP ARC 1 with 5 DSP's and ARC2 with 5 DSP's, and ARC3 (spare) acting as MPIP server All the DSP's are in the same hunt group. I did SET NETWORK USER default PPP MAX_CHANNELS 1 to disable MLPPP for all users unless specified otherwise I set up MPIP like this : ARC1 : SET NTP PRIMARY_SERVER a.b.c.d ENABLE NTP ADD MPIP SERVER w.x.y.z SHAREDSECRET CRYPT SET MPIP CLIENT_STATE ON ARC2 : Same as ARC1 ARC3: SET NTP PRIMARY_SERVER a.b.c.d ENABLE NTP ADD MPIP CLIENT a.r.c.1 SHAREDSECRET CRYPT TYPE HIPER ADD MPIP CLIENT a.r.c.2 SHAREDSECRET CRYPT TYPE HIPER The RADIUS entry for the user is : test Password = "mpip" , Expiration = "Dec 24 2010" User-Service-Type = Framed-User, Framed-Address = g.h.i.j, Framed-Netmask = 255.255.255.255, Port-Limit = 2 The ARC's are all in different subnets, I don't know if that matters... Thanks for any help, because the salesmen are chasing me to get 128k MLPPP up and running... Robert
Subject: (usr-tc) NETServer vs. Arc bus usage
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-22 16:06:51
OK...have done some looking around...and I have an idea about my earlier issue (where the HARC was loading so slowly on bootup)... If I remember correctly, someone posted not to long ago a summary of what busses were available in the mid-plane of the chassis...among them were an ISA bus and a PCI bus (per slot?). If I'm correct, the NETServer I believe uses the ISA bus to communicate with its NIC card and the HARC uses the PCI bus to communicate with its NIC card. Since I'm using a NETServer in the same slot that I had the HARC earlier, and the HARC boots up normally in other chassis...I would suspect that the HARC is possibly having trouble with the PCI bus on that slot? At least this seems reasonable. Anyone have any thoughts on this? I didn't get any responses to my earlier post...would love to hear from some 3Com people about this possibility. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) OK...this is a weird one...
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-22 16:11:22
On Thu, 22 Apr 1999, Jeff Mcadams wrote: >This is the thing I ran into before where it pauses about 45 seconds >between each letter of "Loading kernel ... OK" during bootup...meaning >the boot up process takes about 10 minutes. Last time this happened to >me I did the AT{FZ} thing during bootup to format and reflash the card >with the image and it fixed it. Down in Lexington yesterday, I didn't >have a platform that I could run zmodem on (I was connected to the >console with an old Wyse60 terminal), so I put the NETServers back in >and bring the HiPer Arc back to Louisville to play with it some more >here. That sounds like a problem between the NIC and NAC. I have seen the same thing. After some rather forceful reseating of the cards, it worked just fine. My bigest problem is/was having a netblazer plugged into the consoles of the chassis. If the netblazer port is not active, then the ARC freezes during boot up -- looking at flow control? None of the other cards display this behavior (well, maybe the DSP card does.) --Ricky
Subject: Re: (usr-tc) HARC upgrade
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-04-22 16:50:49
Scott: If you issue the command "save all" then all of your configuration will be saved into NV-RAM, and will still be there after you reboot, or change code. I have been told that the Harc acts as if it has 3 memory areas (but this is not necessarily the physical configuration). There is "active ram" where things are actually done, then there are 2 areas of NV-RAM: one for the code, and another for the configuration. When you download new software it simply replaces the software in the "NV-RAM for Code" area. This is why you must reboot a card after you download new code. It must be moved from the NVRAM to the "active" RAM, where it is then implemented. Many users download code during the day, and then issue the reboot command during off hours, so as not to kick off too many End Users. Hope this helps. Todd ;-} Scott Boggs <sboggs@unitedbank.net> on 04/22/99 03:56:52 PM Please respond to usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) The HARC I got with the original chassis had 4.1.11 code. I have the 4.1.59-6 code ready to load with TCM. I am wondering about my current config and setup. Will a new load blank my current settings? Example- Radius server ip, syslog server ip. I also have a few static routes set up in the routing table. Will those be safe? Basically- does the process simply load the code, reboot, and start running again with new fixes and features? Thanks, Scott Boggs United Bank - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) OK...this is a weird one...
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-22 16:52:27
On Thu, 22 Apr 1999, Ricky Beam wrote: > just fine. My bigest problem is/was having a netblazer plugged into the > consoles of the chassis. If the netblazer port is not active, then the > ARC freezes during boot up -- looking at flow control? None of the other > cards display this behavior (well, maybe the DSP card does.) This might not have anything to do with your problem (and I *really* doubt it's Jeff's problem), but try flipping dip switch 5 on the ARC. Somewhere between ARC 4.0.x and 4.1.x releases, this dip switch became a "ignore modem control signals" switch or something similar... I'd cooked up a custom 3-wire serial cable to connect the console port to a terminal server and it stopped working around then. It stopped working with 16 meg NMC's too. It still works on 4 meg NMC's, DSP's, Dual PRI's, and NETservers, none of which seem to care about anything but transmit, receive, and ground on the console. It doesn't cause the card to lock up though, just stops the console from printing almost everything... so maybe this is something else. By the way... does anyone have a good RJ45-to-RJ45 cable to connect a 3com console port to any other vendor's serial ports -- such as a Cisco aux port? 3com uses one pinout, and Cisco, Xyplex, and Livingston/Lucent (and probably the rest of the world) all use a different one. On the "standard" pinout, the middle pair are both ground, and the next pair out are transmit/receive, so you could use an RJ11 cable if you didn't need modem control, and you can do a null modem cable by just flipping a connector over at one end (i.e. cisco console cables). But I can't even get 3com's RJ45->DB25 console cables connected to a Cisco console cable with Cisco's DB25 adapter on it. For some reason I've been unable to get a working pinout despite tons of time with an RS232 breakout box. It should be really damn simple but I'm having a hard time. (brain... not... functioning...) Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: (usr-tc) HARC upgrade
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-04-22 16:56:52
The HARC I got with the original chassis had 4.1.11 code. I have the 4.1.59-6 code ready to load with TCM. I am wondering about my current config and setup. Will a new load blank my current settings? Example- Radius server ip, syslog server ip. I also have a few static routes set up in the routing table. Will those be safe? Basically- does the process simply load the code, reboot, and start running again with new fixes and features? Thanks, Scott Boggs United Bank
Subject: RE: (usr-tc) HiperDSP Question
From: John Verreault <verreaul@aei.ca>
Date: 1999-04-22 17:59:18
Thanks, I had just figured that out. You have to SDL the T1 code for it to recognize the card. John > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bachta > Sent: Thursday, April 22, 1999 4:31 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiperDSP Question > > > > > Hi John, > > Sounds like you have an E1 card. The daughtercard adds the > necessary hardware > (additional DSPs) to allow the HDSP to be used in an E1 > environment. The card > can still be used in a T1 environment, as long as you have T1/PRI > code running > on it. > > Regards, > David > > > > > > > "John Verreault" <verreaul@aei.ca> on 04/22/99 10:24:53 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (David Bachta/MW/US/3Com) > Subject: (usr-tc) HiperDSP Question > > > > > I have one DSP card with a daughtercard. > > All of my other DSP cards do not have a daughtercard. > > Question: What is the daughtercard for??? > > Thanks > John > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) OK...this is a weird one...
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-22 21:01:09
On Thu, 22 Apr 1999, Mike Andrews wrote: >This might not have anything to do with your problem (and I *really* doubt >it's Jeff's problem), but try flipping dip switch 5 on the ARC. I started to suggest that to Jeff, but I doubt it would do anything. In my case, that made no difference at all. >It doesn't cause the card to lock up though, just stops the console from >printing almost everything... so maybe this is something else. It's not so much "locked up" but more hung waiting to transmit data to the console. It just stops doing what it's doing right there and waits for the console to go active (hardware flow control) before continuing to transmit data and complete the boot up seq. I found that to be very annoying at the time, but never took the time to point it out to 3Com. (Being alpha code, there were muchmore important things to complain about.) --Ricky
Subject: Re: (usr-tc) tele com tests
From: Brian <signal@shreve.net>
Date: 1999-04-23 11:10:58
On Thu, 22 Apr 1999, Netlink Hardware admin wrote: > > Were you able to view this article online, or do you have the printed > version? What URL? > > I went to http://www.teledotcom.com but did not find this article. I have the actual article entitled "Montoer RASs: Growing Pains?" by David Newman. Their maybe some info at www.data.com/issue/990421/ras.html > > Thanks, > Curt > > On Thu, 22 Apr 1999, Brian wrote: > > > > > Anyone check out the April 19th issue of tele com? They did tests on RAS > > boxes from 3Com, Ascend, Assured Access, Cisco, Lucent, and Nortel. > ><SNIP> > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) 14 DSP, 1 ARC chassis does work!!!
From: Randy Doran <randydoran@usa.net>
Date: 1999-04-23 11:49:13
My mistake, one HiPerARC does handle 14 DSPs just fine. It was just a coincidence that my busy signals cleared up when I added the second ARCs to each chassis. It was only temporary and they returned. It turned out to be a Bell screw up, they added 8 new T1 PRIs to our hunt and didn't add any additional paths to the group. We had 51 PRIs and only 989 paths (should be 1173.) Since it was hunting roundRobin from the 5ESS switch the calls filled up the 51 PRIs evenly until it reached 989 calls then we would get busies. There were still empty modems on every DSP so I couldn't pin point the problem to any particular card. I assumed it was that the ARCs couldn't handle the load. I want to use only one ARC per chassis because we have over 80 chassis in our network. At about $6K a pop that's a savings of about $480K!!! At 05:39 PM 4/16/99 -0400, you wrote: >I finally got around to trying 14 DSPs and one HiPerARC with 4.1.59 code. >We have 53 PRIs in the hunt group and it hunts round robin from the switch, >i.e. it fills up the entire hunt group evenly. I had one 14 PRI chassis >with a single ARC in this hunt. The calls filled up all 14 of those PRIs. >But we started to get random regular busy signals on the hunt number when >we were no where near filled up. I added a second HiPerARC back to the >chassis and the busy signals stopped. My guess is that the ARC might not >be able to handle too many incoming call setups all at once and it sends >out a busy signal. Some calls get through and then it eventually fills up. > Maybe with only 7 PRIs to an ARC not so many calls hit it at once and it >can handle the load. just a guess. > > Randy Doran > RAS-Network Engineer > CyberGate e.spire Internet Services > >At 07:31 PM 2/16/99 -0600, Tatai SV Krishnan wrote: >>As long as you do not use IPX - Hiper arc will support 14 DSPs >>4.1.59 code >>krish >> >>----------------------------------------- >> \ T.S.V. Krishnan \ >> \ Network System Engineer \ ( : - : ) >> \ 3Com ............ \ >> ----------------------------------------------/ >>tkrishna@bubba.ae.usr.com >>----------------------------/ http://interproc.ae.usr.com ----/ >>The Yadda Yadda Search - for simple anwers - >http://interproc.ae.usr.com/tkb.html >>-------------------------------------------------------------------------\ >> Any Sufficiently advanced bug is indistinguishable for a feature. >> - Rick Kulawiec >>-------------------------------------------------------------------------/ >> >>On Tue, 16 Feb 1999, Randy Cosby wrote: >> >>> Not really an answer, but do you still need 2 ARC's for a full chassis? I >>> thought with 4.1.72 and later, one ARC can handle a full chasis quite >>> easily. If not, please correct me, cause I'm about to add my 11th card >with >>> 4.1.59 :) >>> >>> Randy >>> >>> > -----Original Message----- >>> > From: owner-usr-tc@lists.xmission.com >>> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mailing List Reader >>> > Sent: Tuesday, February 16, 1999 4:51 PM >>> > To: usr-tc@lists.xmission.com >>> > Subject: (usr-tc) 14 DSP, 2ARC chassis configuration >>> > >>> > >>> > We are an ISP with dialin PPP only that is authenticated by Radius. >>> > We have just purchase a 14 DSP, 2 ARC chassis. Our experience to-date is >>> > with only 10 DSP, 2 ARC chassis. Previously we have split a >>> > single class C >>> > between the 2 ARCs and have 121 IPs assigned to each. Question: How to >>> > combine parts of two class Cs to a single card. For example 120 address >>> > from 1.2.3.xxx and 49 from 1.2.4.xxx. I know I should be able to set up >>> > ippool for each part of each class C, but I don't know if the ARC's >>> > ethernet port needs to have an address from each class C or just one >or if >>> > it can be assigned an address from another class C completely. >>> > >>> > >>> > >>> > >>> > - >>> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> > with "unsubscribe usr-tc" in the body of the message. >>> > For information on digests or retrieving files and old messages send >>> > "help" to the same address. Do not use quotes in your message. >>> > >>> >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >>> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1999-04-23 12:38:19
On Fri, 23 Apr 1999, Robb Bryn wrote: > I'll admit, I'm new to 10/100 switching technology and don't know if this is > normal. It's definitely not what I was expecting. Anyone have similar > setups with switches? The TC doesnt like certain hubs and switches. For example it completely brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other equipment has ever had problems with this hub, just the TC. I dont know why the TC is so touchy although I suspect its buggy or completly broken 10/100 autodetect. -Dan
Subject: Re: (usr-tc) MPIP, RIP and ping/traceroute
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-23 14:01:41
Thus spake Robert von Bismarck >I'm trying to set up my first MPIP connections with HiPerARC's >I have some problems with RIP updates and IP routing. My gateway router >seems to get a little confused with two entries in its RIP routing table. > Router# sh ip route rip >[ deleted items] >R g.h.i.j [120/1] via a.r.c.1, 00:00:13, FastEthernet0/0 > g.h.i.j [120/1] via a.r.c.2, 00:00:22, FastEthernet0/0 >Router# ping g.h.i.j >Type escape sequence to abort. >Sending 5, 100-byte ICMP Echoes to g.h.i.j, timeout is 2 seconds: >!..!! >Success rate is 60 percent (3/5), round-trip min/avg/max = 56/57/60 ms >Is there something special about MPIP, or is it simply lousy ? Well...I don't think you're seeing any lousyness of MPIP here. I think you're just plain seeing MPIP not working at all. Perhaps config isn't quite right yet. Couple of ideas off the top of my head...is the time set on all the Arcs (via NTP) and synced up correctly? (within a few seconds of each other). Is the server_state on in your MPIP server? Is your MPIP server set up to use itself as its own MPIP server? Is your MPIP server set up as a client of itself? Is your MPIP server's client table populated with all your MPIP client machines? Do all your MPIP client machines have the correct MPIP server configured? Do all the shared secrets match in these configurations? These are the base things you need to have set up correctly for MPIP to work. >ARC3: >SET NTP PRIMARY_SERVER a.b.c.d >ENABLE NTP >ADD MPIP CLIENT a.r.c.1 SHAREDSECRET CRYPT TYPE HIPER >ADD MPIP CLIENT a.r.c.2 SHAREDSECRET CRYPT TYPE HIPER Add: set mpip server_state on add mpip client <mpip server's ip> sharedsecret crypt type hiper I *think* that should take care of it all. >The ARC's are all in different subnets, I don't know if that matters... Shouldn't. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Randy Cosby <dcosby@infowest.com>
Date: 1999-04-23 14:22:24
HP 2424M 10/100 for me. Great $200 rebate. Hope it works :) Randy -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jim Johnson Sent: Friday, April 23, 1999 2:20 PM How about a HP ProCurve 2224 10/100 switch. We just ordered it! Robb Bryn wrote: > > We recently tried to upgrade all of our Internet related equipment to 100Mps > and experienced severe performance degradation for our dialup users. The > basic scenario is that we were saturating our 10Mpbs network with extraneous > net traffic so we decided to put all Internet related equip on an unmanaged > 10/100 Fast Ethernet Switch (the Dlink DES-1008). All routers, a TC Hub > with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch. > > What we found was that the TChub started failing to resolve DNS on a first > attempt (it was actually timing out), the second attempt always worked. > Alot of sites for our users stopped working (specifically allot of > shockwave/flash sites). Mac users consistently got Socket broken messages. > All other machines on the switch were performing exceptionally well, the TC > unit just kinda died. If we move it all back to a plain 10Mps non-switching > hub everything is beautiful again. > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > normal. It's definitely not what I was expecting. Anyone have similar > setups with switches? > > Thanks > Robb Bryn > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Curt Shambeau <curt@execpc.com>
Date: 1999-04-23 14:54:09
> On Fri, 23 Apr 1999, Robb Bryn wrote: > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > > normal. It's definitely not what I was expecting. Anyone have similar > > setups with switches? No problem when plugged into Bay Networks 350T/450T switches. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Senior Vice President - Exec-PC, Inc. |
Subject: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Robb Bryn <rbryn@cape-fear.net>
Date: 1999-04-23 15:28:45
We recently tried to upgrade all of our Internet related equipment to 100Mps and experienced severe performance degradation for our dialup users. The basic scenario is that we were saturating our 10Mpbs network with extraneous net traffic so we decided to put all Internet related equip on an unmanaged 10/100 Fast Ethernet Switch (the Dlink DES-1008). All routers, a TC Hub with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch. What we found was that the TChub started failing to resolve DNS on a first attempt (it was actually timing out), the second attempt always worked. Alot of sites for our users stopped working (specifically allot of shockwave/flash sites). Mac users consistently got Socket broken messages. All other machines on the switch were performing exceptionally well, the TC unit just kinda died. If we move it all back to a plain 10Mps non-switching hub everything is beautiful again. I'll admit, I'm new to 10/100 switching technology and don't know if this is normal. It's definitely not what I was expecting. Anyone have similar setups with switches? Thanks Robb Bryn
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-04-23 15:48:32
same here ... I plugged in a new HARC to a Alteon AceDirectory switch which was set to auto and it didn;t work at all I had to force 100mb/sec ... ----- Original Message ----- Sent: Friday, April 23, 1999 3:38 PM > On Fri, 23 Apr 1999, Robb Bryn wrote: > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > > normal. It's definitely not what I was expecting. Anyone have similar > > setups with switches? > > The TC doesnt like certain hubs and switches. For example it completely > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > equipment has ever had problems with this hub, just the TC. I dont know > why the TC is so touchy although I suspect its buggy or completly broken > 10/100 autodetect. > > -Dan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Ronald Kushner <ron@glis.net>
Date: 1999-04-23 15:50:32
Dan Hollis wrote: > > On Fri, 23 Apr 1999, Robb Bryn wrote: > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > > normal. It's definitely not what I was expecting. Anyone have similar > > setups with switches? > > The TC doesnt like certain hubs and switches. For example it completely > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > equipment has ever had problems with this hub, just the TC. I dont know > why the TC is so touchy although I suspect its buggy or completly broken > 10/100 autodetect. Has anyone compiled a list of known good or known bad auto-detecting 10/100 switching hubs when used with a Total Control? If not, readers can e-mail me off the list telling me about your experiences with different switching hubs connected to the Total Control chassis and I will post the results to the list. -Ron GLISnet, Inc. +1 810/939.9885
Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Robb Bryn <rbryn@cape-fear.net>
Date: 1999-04-23 15:55:49
I don't know if the problem is the autodetect or not. The Hub talks to the rest of the network fine, the switch picks it up as 100Mps. Is there a good way to test for packet loss from the HARC to another device on the switch? Thanks Robb Bryn > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski > Sent: Friday, April 23, 1999 3:49 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch... > > > same here ... I plugged in a new HARC to a Alteon > AceDirectory switch which > was set to auto and it didn;t work at all I had to force 100mb/sec ... > > ----- Original Message ----- > From: Dan Hollis <goemon@sasami.anime.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, April 23, 1999 3:38 PM > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch... > > > > On Fri, 23 Apr 1999, Robb Bryn wrote: > > > I'll admit, I'm new to 10/100 switching technology and > don't know if > this is > > > normal. It's definitely not what I was expecting. Anyone > have similar > > > setups with switches? > > > > The TC doesnt like certain hubs and switches. For example > it completely > > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > > equipment has ever had problems with this hub, just the TC. > I dont know > > why the TC is so touchy although I suspect its buggy or > completly broken > > 10/100 autodetect. > > > > -Dan > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-23 16:13:51
On Fri, 23 Apr 1999, Dan Hollis wrote: > On Fri, 23 Apr 1999, Robb Bryn wrote: > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > > normal. It's definitely not what I was expecting. Anyone have similar > > setups with switches? > > The TC doesnt like certain hubs and switches. For example it completely > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > equipment has ever had problems with this hub, just the TC. I dont know > why the TC is so touchy although I suspect its buggy or completly broken > 10/100 autodetect. How about a Cisco Catalyst 2924? We were thinking of getting one... anyone? Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Jim Johnson <jim@perigee.net>
Date: 1999-04-23 16:19:49
How about a HP ProCurve 2224 10/100 switch. We just ordered it! Robb Bryn wrote: > > We recently tried to upgrade all of our Internet related equipment to 100Mps > and experienced severe performance degradation for our dialup users. The > basic scenario is that we were saturating our 10Mpbs network with extraneous > net traffic so we decided to put all Internet related equip on an unmanaged > 10/100 Fast Ethernet Switch (the Dlink DES-1008). All routers, a TC Hub > with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch. > > What we found was that the TChub started failing to resolve DNS on a first > attempt (it was actually timing out), the second attempt always worked. > Alot of sites for our users stopped working (specifically allot of > shockwave/flash sites). Mac users consistently got Socket broken messages. > All other machines on the switch were performing exceptionally well, the TC > unit just kinda died. If we move it all back to a plain 10Mps non-switching > hub everything is beautiful again. > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > normal. It's definitely not what I was expecting. Anyone have similar > setups with switches? > > Thanks > Robb Bryn > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: pferraro@wna-linknet.com
Date: 1999-04-23 16:37:27
We are running the Intel Express 220T and have not experienced any problems... ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Fri, 23 Apr 1999, Dan Hollis wrote: > On Fri, 23 Apr 1999, Robb Bryn wrote: > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > > normal. It's definitely not what I was expecting. Anyone have similar > > setups with switches? > > The TC doesnt like certain hubs and switches. For example it completely > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > equipment has ever had problems with this hub, just the TC. I dont know > why the TC is so touchy although I suspect its buggy or completly broken > 10/100 autodetect. > > -Dan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-04-23 16:43:06
We use HP ProCurve switches and they work great. No problems with the TC or anything else we plug into them. Samuel S. Lowe Director, Data Network Services UniversalCom, Inc. slowe@universalcom.net ----- Original Message ----- Sent: Friday, April 23, 1999 3:13 PM >
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: K Mitchell <tech@keyconn.net>
Date: 1999-04-23 16:55:14
At 03:50 PM 4/23/99 -0400, you wrote: >> The TC doesnt like certain hubs and switches. For example it completely >> brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other >> equipment has ever had problems with this hub, just the TC. I dont know >> why the TC is so touchy although I suspect its buggy or completly broken >> 10/100 autodetect. Plugged my HiPer into a NetGear FS308 a couple of weeks ago and it's been humming along nicely. Auto-detect picks up 100mbs from the ARC and 10mbs from NMC. Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Brian <signal@shreve.net>
Date: 1999-04-23 17:05:19
On Fri, 23 Apr 1999, Jamie Orzechowski wrote: > same here ... I plugged in a new HARC to a Alteon AceDirectory switch which > was set to auto and it didn;t work at all I had to force 100mb/sec ... Yes, I have seen the same with the Alteon AD2. However, the Foundry Serveriron and Fastiron products seem to get the autosensing down right every time all *all* equipment. > > ----- Original Message ----- > From: Dan Hollis <goemon@sasami.anime.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, April 23, 1999 3:38 PM > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch... > > > > On Fri, 23 Apr 1999, Robb Bryn wrote: > > > I'll admit, I'm new to 10/100 switching technology and don't know if > this is > > > normal. It's definitely not what I was expecting. Anyone have similar > > > setups with switches? > > > > The TC doesnt like certain hubs and switches. For example it completely > > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > > equipment has ever had problems with this hub, just the TC. I dont know > > why the TC is so touchy although I suspect its buggy or completly broken > > 10/100 autodetect. > > > > -Dan > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Brian <signal@shreve.net>
Date: 1999-04-23 17:06:22
On Fri, 23 Apr 1999, Marcelo Souza wrote: > > Try to find if the TC is trying to use a full duplex on a swtich > that doesn't support or is configured to half-duplex. It would be great if you could get the duplex status of the tc hub from the CLI..........and force it from the CLI, that would be good too. I hate having to rely 100% on auto-sensing. > If your swtich have a monitor software you could be able to see > what kind of error the port is showing. > Here we have no problems with BayStack 350T. > > - Marcelo > > On Fri, 23 Apr 1999, Robb Bryn wrote: > > |We recently tried to upgrade all of our Internet related equipment to 100Mps > |and experienced severe performance degradation for our dialup users. The > |basic scenario is that we were saturating our 10Mpbs network with extraneous > |net traffic so we decided to put all Internet related equip on an unmanaged > |10/100 Fast Ethernet Switch (the Dlink DES-1008). All routers, a TC Hub > |with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch. > | > |What we found was that the TChub started failing to resolve DNS on a first > |attempt (it was actually timing out), the second attempt always worked. > |Alot of sites for our users stopped working (specifically allot of > |shockwave/flash sites). Mac users consistently got Socket broken messages. > |All other machines on the switch were performing exceptionally well, the TC > |unit just kinda died. If we move it all back to a plain 10Mps non-switching > |hub everything is beautiful again. > | > |I'll admit, I'm new to 10/100 switching technology and don't know if this is > |normal. It's definitely not what I was expecting. Anyone have similar > |setups with switches? > | > |Thanks > |Robb Bryn > | > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - Marcelo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) Wisecoms anyone?
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-04-23 17:16:18
Hello, I have a fairly big client who needs some modems to connect to our USR TC's (latest code, HiPer ARCs, half Quads/half DSPs). They have had intermittent connection problems, resulting in a lot of error 650 (the computer you have dialed is not answering)... but they claimed to have pulled off some 44Kb/s connections, too. Anyone know of a 'magic' string that will help out a Wisecom WS5614ES3 External modem? Thanx in advance... BTW, my TCView script is now updated to 0.93 with some minor fixes and some new features thanks to help by Dale Hege. http://www.dandy.net/~amadei ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-04-23 18:13:06
Try to find if the TC is trying to use a full duplex on a swtich that doesn't support or is configured to half-duplex. If your swtich have a monitor software you could be able to see what kind of error the port is showing. Here we have no problems with BayStack 350T. - Marcelo On Fri, 23 Apr 1999, Robb Bryn wrote: |We recently tried to upgrade all of our Internet related equipment to 100Mps |and experienced severe performance degradation for our dialup users. The |basic scenario is that we were saturating our 10Mpbs network with extraneous |net traffic so we decided to put all Internet related equip on an unmanaged |10/100 Fast Ethernet Switch (the Dlink DES-1008). All routers, a TC Hub |with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch. | |What we found was that the TChub started failing to resolve DNS on a first |attempt (it was actually timing out), the second attempt always worked. |Alot of sites for our users stopped working (specifically allot of |shockwave/flash sites). Mac users consistently got Socket broken messages. |All other machines on the switch were performing exceptionally well, the TC |unit just kinda died. If we move it all back to a plain 10Mps non-switching |hub everything is beautiful again. | |I'll admit, I'm new to 10/100 switching technology and don't know if this is |normal. It's definitely not what I was expecting. Anyone have similar |setups with switches? | |Thanks |Robb Bryn | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo
Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
From: dns-admin@netsol.net
Date: 1999-04-23 18:40:51
Had it for 6 month, first one worked one weeks then died. After we had it replaced, the newer unit is working since. Liping Chen > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews > Sent: Friday, April 23, 1999 1:14 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch... > > > On Fri, 23 Apr 1999, Dan Hollis wrote: > > > On Fri, 23 Apr 1999, Robb Bryn wrote: > > > I'll admit, I'm new to 10/100 switching technology and > don't know if this is > > > normal. It's definitely not what I was expecting. Anyone > have similar > > > setups with switches? > > > > The TC doesnt like certain hubs and switches. For example > it completely > > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > > equipment has ever had problems with this hub, just the TC. > I dont know > > why the TC is so touchy although I suspect its buggy or > completly broken > > 10/100 autodetect. > > How about a Cisco Catalyst 2924? We were thinking of getting one... > anyone? > > > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital > Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A > computer without a > Microsoft operating system is like a dog without a brick tied > to its head." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Chris Peltier <cpeltier@netcarrier.com>
Date: 1999-04-23 19:50:33
> How about a Cisco Catalyst 2924? We were thinking of getting one... > anyone? > Cataylst 2924s and 2916s work just fine in our network. It even works with the new enterprise software on these switches (for physical LAN partitioning on the same unit). -Chris
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-04-23 20:24:48
On Fri, 23 Apr 1999, Brian wrote: |> Try to find if the TC is trying to use a full duplex on a swtich |> that doesn't support or is configured to half-duplex. | |It would be great if you could get the duplex status of the tc hub from |the CLI..........and force it from the CLI, that would be good too. I |hate having to rely 100% on auto-sensing. Yes. But I can force the switch port to change, monitor the statistics on the console and chosse the best option. - Marcelo |> If your swtich have a monitor software you could be able to see |> what kind of error the port is showing. |> Here we have no problems with BayStack 350T. |> |> - Marcelo |> |> On Fri, 23 Apr 1999, Robb Bryn wrote: |> |> |We recently tried to upgrade all of our Internet related equipment to 100Mps |> |and experienced severe performance degradation for our dialup users. The |> |basic scenario is that we were saturating our 10Mpbs network with extraneous |> |net traffic so we decided to put all Internet related equip on an unmanaged |> |10/100 Fast Ethernet Switch (the Dlink DES-1008). All routers, a TC Hub |> |with Hiper Arc, DNS servers, mail servers, etc. all went on the same switch. |> | |> |What we found was that the TChub started failing to resolve DNS on a first |> |attempt (it was actually timing out), the second attempt always worked. |> |Alot of sites for our users stopped working (specifically allot of |> |shockwave/flash sites). Mac users consistently got Socket broken messages. |> |All other machines on the switch were performing exceptionally well, the TC |> |unit just kinda died. If we move it all back to a plain 10Mps non-switching |> |hub everything is beautiful again. |> | |> |I'll admit, I'm new to 10/100 switching technology and don't know if this is |> |normal. It's definitely not what I was expecting. Anyone have similar |> |setups with switches? |> | |> |Thanks |> |Robb Bryn |> | |> | |> |- |> | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> | with "unsubscribe usr-tc" in the body of the message. |> | For information on digests or retrieving files and old messages send |> | "help" to the same address. Do not use quotes in your message. |> | |> |> - Marcelo |> |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. |> | |----------------------------------------------------- |Brian Feeny (BF304) signal@shreve.net |318-222-2638 x 109 http://www.shreve.net/~signal |Network Administrator ShreveNet Inc. (ASN 11881) | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch..
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-04-23 23:18:00
-> On Fri, 23 Apr 1999, Robb Bryn wrote: -> > I'll admit, I'm new to 10/100 switching technology and don't know if this -> is > normal. It's definitely not what I was expecting. Anyone have similar -> > setups with switches? -> -> The TC doesnt like certain hubs and switches. For example it completely -> brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other equipment -> has ever had problems with this hub, just the TC. I dont know why the TC is -> so touchy although I suspect its buggy or completly broken 10/100 -> autodetect. We have one on a Bay Networks 28K (yes, I realize old technology) switch but it works great. No performance problems whatsoever. HiperArc and NMC. Jeff binkley ASA Network Computing
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch..
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-04-23 23:20:00
-> same here ... I plugged in a new HARC to a Alteon AceDirectory switch which -> was set to auto and it didn;t work at all I had to force 100mb/sec ... Have HiperArc and Netservers connected to Bay Networks 28000 switches and works in auto, 10k and 100k modes just fine. Jeff binkley ASA Network Computing
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: ispcnsl001@aol.com
Date: 1999-04-24 00:58:27
In a message dated 4/23/99 2:51:11 PM US Eastern Standard Time, mhz@ripnet.com writes: > same here ... I plugged in a new HARC to a Alteon AceDirectory switch which > was set to auto and it didn;t work at all I had to force 100mb/sec ... I saw the same problem on an anritsu 10/100/1000 switch. Forcing 100 fixed it.
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Greg Owens <gowens@magnolia-net.com>
Date: 1999-04-24 10:35:48
We are about to install a CeLAN brand, model DuFastHUB-16As next week....anyone using one of these successfully? -----Original Message----- >On Fri, 23 Apr 1999, Robb Bryn wrote: >> I'll admit, I'm new to 10/100 switching technology and don't know if this is >> normal. It's definitely not what I was expecting. Anyone have similar >> setups with switches? > >The TC doesnt like certain hubs and switches. For example it completely >brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other >equipment has ever had problems with this hub, just the TC. I dont know >why the TC is so touchy although I suspect its buggy or completly broken >10/100 autodetect. > >-Dan > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch...
From: K Mitchell <mitch@keyconn.net>
Date: 1999-04-24 11:06:12
At 03:50 PM 4/23/99 -0400, you wrote: >> The TC doesnt like certain hubs and switches. For example it completely >> brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other >> equipment has ever had problems with this hub, just the TC. I dont know >> why the TC is so touchy although I suspect its buggy or completly broken >> 10/100 autodetect. Plugged my HiPer into a NetGear FS308 a couple of weeks ago and it's been humming along nicely. Auto-detect picks up 100mbs from the ARC and 10mbs from NMC. Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Wisecoms anyone?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-24 12:07:05
On Fri, 23 Apr 1999, Stephen Amadei wrote: > > Hello, > > I have a fairly big client who needs some modems to connect to our > USR TC's (latest code, HiPer ARCs, half Quads/half DSPs). They have had > intermittent connection problems, resulting in a lot of error 650 (the > computer you have dialed is not answering)... but they claimed to have > pulled off some 44Kb/s connections, too. Anyone know of a 'magic' string > that will help out a Wisecom WS5614ES3 External modem? Thanx in Never heard about these modems - Is this rockwell chipset or Lucent? A lot depends upon whoes chipset the customer is using - Based on this info you also need to find out or get traces when the error occurs. Syslog, tap if possible would help a lot. Also I suggest you open a ticket with support so that a tech can investigate and identify the problems. regards krish > advance... > > BTW, my TCView script is now updated to 0.93 with some minor fixes and > some new features thanks to help by Dale Hege. > http://www.dandy.net/~amadei > > ----Steve > Stephen Amadei > Director of MIS > Dandy Connections, Inc. > Atlantic City, NJ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Wisecoms anyone?
From: Stephen Amadei <amadei@dandy.net>
Date: 1999-04-24 16:46:15
On Sat, 24 Apr 1999, Tatai SV Krishnan wrote: > Never heard about these modems - Is this rockwell chipset or Lucent? > A lot depends upon whoes chipset the customer is using - Based on this > info you also need to find out or get traces when the error occurs. > Syslog, tap if possible would help a lot. Well, this is part of my problem... I couldn't find anywhere on the Wisecom webpages which describes the chipset... and my customer doesn't know either. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ
Subject: Re: (usr-tc) Wisecoms anyone?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-24 17:14:52
On Sat, 24 Apr 1999, Stephen Amadei wrote: > On Sat, 24 Apr 1999, Tatai SV Krishnan wrote: > > > Never heard about these modems - Is this rockwell chipset or Lucent? > > A lot depends upon whoes chipset the customer is using - Based on this > > info you also need to find out or get traces when the error occurs. > > Syslog, tap if possible would help a lot. > > Well, this is part of my problem... I couldn't find anywhere on the > Wisecom webpages which describes the chipset... and my customer doesn't > know either. If the modem responds to the at commands - then all you need is to send a ati3 Based on that response we can say whether its lucent or rockwell. krish > > ----Steve > Stephen Amadei > Director of MIS > Dandy Connections, Inc. > Atlantic City, NJ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) PPP session start message problem
From: G. Douglas Davidson <douglas@city-net.com>
Date: 1999-04-24 22:12:07
--PART-BOUNDARY=.19904242212.ZM167051.city-net.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 X-Zm-Decoding-Hint: mimencode -q -u Content-Transfer-Encoding: quoted-printable Hello, I am having a heck of a time getting my HyperArc version 4.1.59_6 to outp= ut the PPP startup message. I can see it set apparently correctly when I do a "= show ppp". I am switching up form an older Netserver. This message used to b= e produced by the "pppmsg" switch on that box. Under Netserver I get: PPP session from (209.176.114.196) to 206.102.159.78 beginning....~#=C0!}= !}!} } Under HyperArc I get: ~#=C0!}!}!} }?}!}$}%=DC}"}&=FF=FF}%}&a=FA=C2u}'}"}(}"}1}$}%=DC}3}#} =D4=AB= ~~#=C0!}!}"} }? Persons with older scripting logins are having problems with this. This = only occurs when the user selects the PPP option from within a Radius menu. A= uto detection of PPP works fine. Any help would be appreciated. -- =
Subject: Re: (usr-tc) PPP session start message problem
From: G. Douglas Davidson <douglas@city-net.com>
Date: 1999-04-25 11:46:19
--PART-BOUNDARY=.19904251146.ZM234395.city-net.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 X-Zm-Decoding-Hint: mimencode -q -u Content-Transfer-Encoding: quoted-printable On Apr 24, 10:12pm, G. Douglas Davidson wrote: > Subject: (usr-tc) PPP session start message problem > > [ Text > Encoded with "quoted-printable" ] : > > Hello, > > I am having a heck of a time getting my HyperArc version 4.1.59_6 to ou= tput the > PPP startup message. I can see it set apparently correctly when I do a= "show > ppp". I am switching up form an older Netserver. This message used to= be > produced by the "pppmsg" switch on that box. > > Under Netserver I get: > > PPP session from (209.176.114.196) to 206.102.159.78 beginning....~#=C0= !}!}!} } > > Under HyperArc I get: > > ~#=C0!}!}!} }?}!}$}%=DC}"}&=FF=FF}%}&a=FA=C2u}'}"}(}"}1}$}%=DC}3}#} =D4= =AB~~#=C0!}!}"} }? > > Persons with older scripting logins are having problems with this. Thi= s only > occurs when the user selects the PPP option from within a Radius menu. = Auto > detection of PPP works fine. > > Any help would be appreciated. enable authentication hint_assigned Argh. -- =
Subject: Re: (usr-tc) PPP session start message problem
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-25 13:23:38
On Sat, 24 Apr 1999, G. Douglas Davidson wrote: > Hello, > > I am having a heck of a time getting my HyperArc version 4.1.59_6 to outp= > ut the > PPP startup message. I can see it set apparently correctly when I do a "= > show > ppp". I am switching up form an older Netserver. This message used to b= > e > produced by the "pppmsg" switch on that box. To do this - you have to do the following 1. Make sure that you have a IP pool, and that its a public ip pool. 2. enable authe hint -on the hiper arc Thats the would set up the message and when you dial you will see the message appear. krish > > Under Netserver I get: > > PPP session from (209.176.114.196) to 206.102.159.78 beginning....~#=C0!}= > !}!} } > > Under HyperArc I get: > > ~#=C0!}!}!} }?}!}$}%=DC}"}&=FF=FF}%}&a=FA=C2u}'}"}(}"}1}$}%=DC}3}#} =D4=AB= > ~~#=C0!}!}"} }? > > Persons with older scripting logins are having problems with this. This = > only > occurs when the user selects the PPP option from within a Radius menu. A= > uto > detection of PPP works fine. > > Any help would be appreciated. > > -- = > > ----- > G Douglas Davidson | CityNet, Inc. > douglas@city-net.com | Pittsburgh, PA > voice: 412.481.5406 | fax: 412.431.1315 >
Subject: (usr-tc) Short or long haul??
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-04-26 09:41:29
This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BE8FC8.F61428A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are using PRI's and I was wondering which I should use?? Short or = long haul and what DB should it be set to?? right now it's on DB26 and = long haul ... are there any performance issues? ------=_NextPart_000_002C_01BE8FC8.F61428A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>We are using PRI's and I was wondering which I = should use??=20 Short or long haul and what DB should it be set to??&nbsp; right now = it's on=20 DB26 and long haul ... are there any performance=20 issues?</FONT></DIV></BODY></HTML> ------=_NextPart_000_002C_01BE8FC8.F61428A0--
Subject: (usr-tc) Quad v.32 terbo Upgrade
From: Greg Coffey <greg@coffey.com>
Date: 1999-04-26 10:13:09
Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90? I have five of them and they appear to be double sided. What software would I need? Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ==================================================================== 142 S. Center St. 3Com v.90 56k $20 in Casper & Douglas Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, http://WWW.COFFEY.COM Wheatland, Pinedale, Lander & Lusk, WY
Subject: Re: (usr-tc) cistron radius and VSA's
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-26 10:40:48
On Mon, 26 Apr 1999, Mike Andrews wrote: > I'm experimenting with the idea of switching to Cistron radius (beta16, > the latest), and I'm having problems with it not logging 3com VSA's > correctly. > > I'm getting tons of "unknown attribute xxxx received" every time it gets > an accounting packet. If you get a trace of the packet - either using tcpdump or snoop - we can see what exactly the hiper arc sends. If the hiper arc sends the packet correctly then should debug the Radius server. krish > > By throwing some debugging code in to see how it's parsing the dictionary > files, it appears to be putting the USR attributes in memory with 0x20000 > appended to their values... for example: > > ATTRIB_NMC USR-Event-Id 0xBFBE integer > > gets stored in memory as attribute "0x2bfbe". But in the "unknown > attribute" message, the number there is 0x3bfbe instead. So it's reading > the dictionary OK, and it's parsing the packet OK, but it's getting the > "vendor number" wrong by 1. I'm not sure if this is a parser bug or a > dictionary problem or something else. > > > > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a > Microsoft operating system is like a dog without a brick tied to its head." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) cistron radius and VSA's
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-26 11:10:12
I'm experimenting with the idea of switching to Cistron radius (beta16, the latest), and I'm having problems with it not logging 3com VSA's correctly. I'm getting tons of "unknown attribute xxxx received" every time it gets an accounting packet. By throwing some debugging code in to see how it's parsing the dictionary files, it appears to be putting the USR attributes in memory with 0x20000 appended to their values... for example: ATTRIB_NMC USR-Event-Id 0xBFBE integer gets stored in memory as attribute "0x2bfbe". But in the "unknown attribute" message, the number there is 0x3bfbe instead. So it's reading the dictionary OK, and it's parsing the packet OK, but it's getting the "vendor number" wrong by 1. I'm not sure if this is a parser bug or a dictionary problem or something else. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: Re: (usr-tc) cistron radius and VSA's
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-26 12:20:21
On Mon, 26 Apr 1999, Tatai SV Krishnan wrote: > On Mon, 26 Apr 1999, Mike Andrews wrote: > > > I'm experimenting with the idea of switching to Cistron radius (beta16, > > the latest), and I'm having problems with it not logging 3com VSA's > > correctly. > > > > I'm getting tons of "unknown attribute xxxx received" every time it gets > > an accounting packet. > > If you get a trace of the packet - either using tcpdump or snoop - we can > see what exactly the hiper arc sends. If the hiper arc sends the packet > correctly then should debug the Radius server. I already know it's a Radius server problem... I have a hacked-up Livingston Radius already doing the VSA's correctly. I'm just trying to switch from Livingston to Cistron. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: Re: (usr-tc) Short or long haul??
From: Brian <signal@shreve.net>
Date: 1999-04-26 12:29:20
On Mon, 26 Apr 1999, Jamie Orzechowski wrote: > We are using PRI's and I was wondering which I should use?? Short or > long haul and what DB should it be set to?? right now it's on DB26 > and long haul ... are there any performance issues? > I just select short haul nic, since its alot easier for me to think in terms of feet than db :). Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Quad v.32 terbo Upgrade
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-26 12:41:26
Thus spake Greg Coffey >Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90? Yes. >I have five of them and they appear to be double sided. What software >would I need? Get the latest...5.9.9 I believe for double sided...5.10.9 is the other...grab them both and TCM will figure it out for you on its own. :) And, if they aren't digital capable modems, v.90 isn't going to do much good for you...(well...quads can do client side of x2 and v.90 I believe). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Quad v.32 terbo Upgrade
From: David Bolen <db3l@ans.net>
Date: 1999-04-26 12:50:47
Jeff Mcadams <jeffm@iglou.com> writes: > Thus spake Greg Coffey > >Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90? > > Yes. Hmm, I may be wrong, but I don't think that's true. The quad modem hardware changed back in '94 with the introduction of the V.34 cards (double sided design originally, single sided later), so the existing quad V.34/x2/V.90 code base won't run on the older V.32 quad hardware platform. And since the first code base to come out for the cards back then was for V.34, anything that is limited to V.32 only is likely to be the older hardware platform, as opposed to a quad card that simply hadn't been upgraded enough. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) Quad v.32 terbo Upgrade
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-26 12:58:46
Thus spake David Bolen >Jeff Mcadams <jeffm@iglou.com> writes: >> Thus spake Greg Coffey >> >Can a v32Terbo quad modem be upgraded firmware to v.34 or even v.90? >> Yes. >Hmm, I may be wrong, but I don't think that's true. Hrmm...perhaps I'm wrong...I could've sworn I had some quads down there silk-screened with v.32terbo on them, but going and looking, the only ones I can find are the old dual cards (mixture of v.32terbo and v.34 cards in those). And, yes, we still have some of the old dual modem cards in service....:)....*with* 35 (yes, that's not a typo for 45) amp power supplies. :) Last time Tom Goodman was down here he asked if he could just touch them. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) New 3Com ISP Home Page
From: David Cartwright <david_cartwright@mw.3com.com>
Date: 1999-04-26 13:18:59
--0__=3vWwQc5HmcamoCbusgT7iIR0fIMcqkk1JF2VjqbxQwhZ871Bftum8o5s Content-type: text/plain; charset=us-ascii Content-Disposition: inline 3Com Carrier CSO recently launched a new technical support web site for ISPs! The site contains a wide range of information and links to other useful sites. Whether you need to locate a V.90 troubleshooting guide, a CLI Quick Reference Guide for HiPer ARC, find out if a product is Year 2000 compliant, determine which versions of software code are compatible or need answers to other technical support and service questions, you can find the answer on the ISP Home Page. The site also has links to other 3Com web-based services Knowledgebase and Case Tracker. 3Com Knowledgebase where you can easily and quickly access the self-service database to find solutions to help diagnose and solve installation, configuration, and upgrade issues with 3Com products. It's a free, interactive self-service database of technical information to help you maximize the performance of your network 24-hours a day, seven days a week. ISPs with 3Com service contracts can access 3Com technical support case information using 3Com Case Tracker. The ISP Technical Support Home Page includes documentation, release notes and configuration procedures for the following products: HiPer Arc HiPer DSP NetServer RADIUS QUAD NMC Note: A service contract is required for some software and utilities. To Access the ISP Technical Support Home Page? Visit the web site: http://totalservice.3com.com/ then click on ISP Home Page To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forums - http://totalservice.3com.com/forums/ To access the 3Com Knowledgebase - http://knowledgebase.3com.com To access 3Com Carrier documentation - http://totalservice.3com.com/documents/ To view 3Com Carrier Service Offerings - http://totalservice.3com.com/services/ --0__=3vWwQc5HmcamoCbusgT7iIR0fIMcqkk1JF2VjqbxQwhZ871Bftum8o5s Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KM0NvbSBDYXJyaWVyIENTTyByZWNlbnRseSBsYXVuY2hlZCBhIG5ldyB0 ZWNobmljYWwgc3VwcG9ydCB3ZWIgc2l0ZSBmb3INCklTUHMhJm5ic3A7IFRoZSBzaXRlIGNvbnRh aW5zIGEgd2lkZSByYW5nZSBvZiBpbmZvcm1hdGlvbiBhbmQgbGlua3MgdG8NCm90aGVyIHVzZWZ1 bCBzaXRlcy4mbmJzcDsgV2hldGhlciB5b3UgbmVlZCB0byBsb2NhdGUgYSBWLjkwIHRyb3VibGVz aG9vdGluZw0KZ3VpZGUsIGEgQ0xJIFF1aWNrIFJlZmVyZW5jZSBHdWlkZSBmb3IgSGlQZXIgQVJD LCBmaW5kIG91dCBpZiBhIHByb2R1Y3QNCmlzIFllYXIgMjAwMCBjb21wbGlhbnQsIGRldGVybWlu ZSB3aGljaCB2ZXJzaW9ucyBvZiBzb2Z0d2FyZSBjb2RlIGFyZSBjb21wYXRpYmxlDQpvciBuZWVk IGFuc3dlcnMgdG8gb3RoZXIgdGVjaG5pY2FsIHN1cHBvcnQgYW5kIHNlcnZpY2UgcXVlc3Rpb25z LCB5b3UgY2FuDQpmaW5kIHRoZSBhbnN3ZXIgb24gdGhlIElTUCBIb21lIFBhZ2UuDQo8cD5UaGUg c2l0ZSBhbHNvIGhhcyBsaW5rcyB0byBvdGhlciAzQ29tIHdlYi1iYXNlZCBzZXJ2aWNlcyBLbm93 bGVkZ2ViYXNlDQphbmQgQ2FzZSBUcmFja2VyLiZuYnNwOyAzQ29tIEtub3dsZWRnZWJhc2Ugd2hl cmUgeW91IGNhbiBlYXNpbHkgYW5kIHF1aWNrbHkNCmFjY2VzcyB0aGUgc2VsZi1zZXJ2aWNlIGRh dGFiYXNlIHRvIGZpbmQgc29sdXRpb25zIHRvIGhlbHAgZGlhZ25vc2UgYW5kDQpzb2x2ZSBpbnN0 YWxsYXRpb24sIGNvbmZpZ3VyYXRpb24sIGFuZCB1cGdyYWRlIGlzc3VlcyB3aXRoIDNDb20gcHJv ZHVjdHMuJm5ic3A7DQpJdCdzIGEgZnJlZSwgaW50ZXJhY3RpdmUgc2VsZi1zZXJ2aWNlIGRhdGFi YXNlIG9mJm5ic3A7IHRlY2huaWNhbCBpbmZvcm1hdGlvbg0KdG8gaGVscCB5b3UgbWF4aW1pemUg dGhlIHBlcmZvcm1hbmNlIG9mIHlvdXIgbmV0d29yayAyNC1ob3VycyBhIGRheSwgc2V2ZW4NCmRh eXMgYSB3ZWVrLg0KPGJyPklTUHMgd2l0aCAzQ29tIHNlcnZpY2UgY29udHJhY3RzIGNhbiBhY2Nl c3MgM0NvbSB0ZWNobmljYWwgc3VwcG9ydA0KY2FzZSBpbmZvcm1hdGlvbiB1c2luZyAzQ29tIENh c2UgVHJhY2tlci4NCjxwPlRoZSBJU1AgVGVjaG5pY2FsIFN1cHBvcnQgSG9tZSBQYWdlIGluY2x1 ZGVzIGRvY3VtZW50YXRpb24sIHJlbGVhc2UNCm5vdGVzIGFuZA0KPGJyPmNvbmZpZ3VyYXRpb24g cHJvY2VkdXJlcyBmb3IgdGhlIGZvbGxvd2luZyBwcm9kdWN0czoNCjxwPjxmb250IGNvbG9yPSIj RkYwMDAwIj5IaVBlciBBcmM8L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPkhpUGVy IERTUDwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+TmV0U2VydmVyPC9mb250Pg0K PGJyPjxmb250IGNvbG9yPSIjRkYwMDAwIj5SQURJVVM8L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiNGRjAwMDAiPlFVQUQ8L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPk5NQzwvZm9u dD4NCjxwPjxmb250IGNvbG9yPSIjMDAwMDY2Ij5Ob3RlOiBBIHNlcnZpY2UgY29udHJhY3QgaXMg cmVxdWlyZWQgZm9yIHNvbWUNCnNvZnR3YXJlIGFuZCB1dGlsaXRpZXMuPC9mb250Pg0KPHA+VG8g QWNjZXNzIHRoZSBJU1AgVGVjaG5pY2FsIFN1cHBvcnQgSG9tZSBQYWdlPw0KPHA+VmlzaXQgdGhl IHdlYnNpdGU6IDx1Pjxmb250IGNvbG9yPSIjMDAwMDY2Ij48QSBIUkVGPSJodHRwOi8vdG90YWxz ZXJ2aWNlLjNjb20uY29tLyI+aHR0cDovL3RvdGFsc2VydmljZS4zY29tLmNvbS88L0E+PC9mb250 PjwvdT4NCnRoZW4gY2xpY2sgb24gSVNQIEhvbWUgUGFnZQ0KPGJyPiZuYnNwOw0KPGJyPiZuYnNw Ow0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOzwvaHRtbD4N Cg0K --0__=3vWwQc5HmcamoCbusgT7iIR0fIMcqkk1JF2VjqbxQwhZ871Bftum8o5s--
Subject: (usr-tc) total control analog ninja needed
From: Chairman of the Borg <list-total-control@l7.org>
Date: 1999-04-26 17:53:34
Hey guys, I've got a total control chassis here with major angst. analog only .34 quad cards. the angst is cards with ports that won't pick up, respond with garbage, etc. no error lights, just borked communications. one card is perfect but won't connect to anything at over 14.4, misc crap like this. a couple people have said that most of this will sort itself out with a reflash, so i'm going to try that before i throw my hands up and ship it back. is there anyone on this list that lives and breathes these that would be willing to give me some pointers, etc? we sold off all our old pop equipment and the guy is showing up wed to pick it up, so if i don't get this sorted out by then i'm in deep doo doo :/ thanks, -dd \\\\\// \\|// _\\|//_ | | _\\|//_ \\|// (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ Plazma Networking Services / Level Seven inc. Connecting the World.... http://www.plazma.net http://www.L7.net http://www.L7.org /"\ Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
Subject: Re: (usr-tc) Short or long haul??
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-26 18:06:46
Brian writes... >On Mon, 26 Apr 1999, Jamie Orzechowski wrote: >> We are using PRI's and I was wondering which I should use?? Short or >> long haul and what DB should it be set to?? right now it's on DB26 >> and long haul ... are there any performance issues? > >I just select short haul nic, since its alot easier for me to think in >terms of feet than db :). And I just use CAT 1 in my network since its alot easier for me to have just one type of cable around! Doh! The reason you see some T1 settings in feet instead of dB is beacuse they are referring to a different types of interface. Feet are refering to a DSX-1 interface (ie, "short haul") and are a measure of the distance between you and the DSX-1 interface. For a T-1, ("long-haul") interface the number is in dB because thats how you measure the loss from you to the next repeater. The pulse masks and levels for DSX-1 and T-1 are different. The only reason they work at all when you mistakenly interconnect them or misconfigure your interface is because modern T-1 receivers are extremely wide range and can tolerate a lot of abuse. To be explcit, setting an interface to DSX-1 and measuring the distance in feet to the next repeater would not even come close to being even an approximation of a correct configuration. In case anyone was going to ask, the way you interconnect a DSX-1 device with a T-1 line is a box called a CSU. A CSU has two connectors, one is a T-1 interface, the other a DSX-1 interface. To answer Jamie's question, if you are connecting to a metallic T1 (PRI) that goes to a telco, select "long haul". Start with a TLBO of -7.5 if you can't get a craft person to measure the level for you. The only performance issue is the bulk error rate on the span. -- Aaron Nabil
Subject: Re: (usr-tc) HyperDSPs losing config
From: David Bachta <david_bachta@mw.3com.com>
Date: 1999-04-26 19:05:07
Hi Walt, It sounds like 'auto-config' might be causing your problem. To check if it is enabled/disabled select the NMC card in TCM and choose Programmed Settings. Choose 'Configuration Group' for the Parameter Group. Set 'Auto Config on Card Initialization' to disable. Hope this helps. Regards, David "Walt Gnann" <wgnann@islc.net> on 04/26/99 06:36:18 PM Please respond to usr-tc@lists.xmission.com Sent by: "Walt Gnann" <wgnann@islc.net> cc: (David Bachta/MW/US/3Com) NMC 5.5.5 HARC 4.1.59 HDSP 1.2.5 I've just added a few HyperDSPs (6 total) to a chasis and after the reboot the configs for the T1s and modems were goofed. They didn't go back to the default, but added weird settings. Reset modems and T1s to default, made my corrections, saved the T1s and Modems to NVRAM then rebooted the chasis. Same problem occurred. After I configure the T1s and modems it will hold those settings and operate properly until either the chasis is rebooted are the cards are hardware resetted. I don't think the DSPs are the problem...I've taken these DSPs and put them in another chasis and they worked normally. So I'm down to the HARC or NMC as the culprit. Any suggestions? Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) total control analog ninja needed
From: Chairman of the Borg <list-total-control@l7.org>
Date: 1999-04-26 19:10:49
>> total control chassis / major angst / analog only >> v.34 quad cards / ports that won't pick up >> / respond with garbage, etc. / no error lights, >Lot more information is required to find out what is the problem. >Are you using the Quads with NETServer/HiPer arc /Edgeserver ?? >Are you having packet bus problems or modem connection problems? >Do you have a NMC in the chassis ? >This minimal info will help in identifing the problem. >krish sorry krish, radius machine > cat5 > portmaster 2e-30 > serial cable > 4way cable > analog rs-232 nic chassis has 6 analog nics (with daughterboards) and 6 analog quadmodems in it. dialing in with terminate and a usr 33.6, i get the following port 01 : no answer / attach s0 (talk to modem directly) /atz <sits there> port 02 : clean 33.6 connect port 03 : clean 33.6 connect port 04 : connects, ton of upper ascii garbage port 05 : clean 14.4 connect port 06 : clean 14.4 connect port 07 : clean 14.4 connect port 08 : clean 14.4 connect port 09 : picks up and doesn't do anything else port 10 : clean 33.6 connect port 11 : connects, ton of upper ascii garbage port 12 : no answer / attach s11 / atz <sits there> port 13 : clean 33.6 connect port 14 : clean 33.6 connect port 15 : clean 33.6 connect port 16 : connects, ton of upper ascii garbage port 17 : no answer / attach s11 / atz <sits there> port 18 : clean 33.6 connect port 19 : clean 33.6 connect port 20 : connects, ton of upper ascii garbage port 21 : no answer / attach s11 / atz <sits there> port 22 : clean 33.6 connect port 23 : picks up and doesn't do anything else port 24 : clean 33.6 connect modem setup in portmaster is currently borgmatrix-001.L7.net>show modem tcr Short Name: tcr Long Name: totalcontrol Optimal Speed: 57600 Type: User Defined Init Script: Send Command Wait for Reply ------------------------------ ----------------------------- AT&B1&H1&R2X7&A3S0=1&N0&W OK <sigh> -dd \\\\\// \\|// _\\|//_ | | _\\|//_ \\|// (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ Plazma Networking Services / Level Seven inc. Connecting the World.... http://www.plazma.net http://www.L7.net http://www.L7.org /"\ Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
Subject: (usr-tc) HyperDSPs losing config
From: Walt Gnann <wgnann@islc.net>
Date: 1999-04-26 19:36:18
NMC 5.5.5 HARC 4.1.59 HDSP 1.2.5 I've just added a few HyperDSPs (6 total) to a chasis and after the reboot the configs for the T1s and modems were goofed. They didn't go back to the default, but added weird settings. Reset modems and T1s to default, made my corrections, saved the T1s and Modems to NVRAM then rebooted the chasis. Same problem occurred. After I configure the T1s and modems it will hold those settings and operate properly until either the chasis is rebooted are the cards are hardware resetted. I don't think the DSPs are the problem...I've taken these DSPs and put them in another chasis and they worked normally. So I'm down to the HARC or NMC as the culprit. Any suggestions? Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org
Subject: (usr-tc) Filters...
From: Rick <rickyz@mindspring.com>
Date: 1999-04-26 20:41:32
All, This filter thing is about confusing. I am just rying to create dynamic filters for people who have not paid up to restrict them from doing anything but access our Mail and authentication server, however, this doesn't appear to be working...the filters get applied, but they can still surf...what am I missing? HiPer>> sh filter bess.in RULES FOR FILTER /./bess.in SHOW PROTOCOLS: ALL #filter IP: 10 ACCEPT src-addr=0.0.0.0/0; 20 ACCEPT dst-addr=205.206.216.0/24; 30 ACCEPT dst-addr=209.167.188.0/24; 40 DENY; HiPer>> HiPer>> sh filter bess.out RULES FOR FILTER /./bess.out SHOW PROTOCOLS: ALL #filter IP: 10 ACCEPT src-addr=0.0.0.0/0; 20 ACCEPT dst-addr=209.167.188.0/24; 30 ACCEPT dst-addr=205.206.216.0/24; 40 ACCEPT protocol = tcp; 50 ACCEPT protocol = udp; 60 DENY; Also, What does the "AND" do here at the beginning of each line? mail.in: #filter IP: 010 AND dst-addr = 198.060.022.022/32; 020 ACCEPT tcp-dst-port = 106; 030 AND dst-addr = 198.060.022.022/32; 040 ACCEPT tcp-dst-port = 109; 050 AND dst-addr = 198.060.022.022/32; 060 ACCEPT tcp-dst-port = 110; 070 AND dst-addr = 198.060.022.022/32; 080 ACCEPT tcp-dst-port = 143; 090 AND dst-addr = 198.060.022.022/32; 100 ACCEPT tcp-dst-port = 25; 110 AND dst-addr = 198.060.022.022/32; 120 ACCEPT udp-dst-port = 53; 130 AND dst-addr = 198.060.022.002/32; 140 ACCEPT udp-dst-port = 53; 150 AND dst-addr = 198.060.022.000/26; 160 ACCEPT tcp-dst-port = 80; 170 AND dst-addr = 198.060.022.000/26; 180 ACCEPT tcp-dst-port = 8000; 190 AND dst-addr = 198.060.022.000/26; 200 ACCEPT tcp-dst-port = 443; 210 ACCEPT protocol = icmp; 220 DENY; mail.out: #filter IP: 010 AND src-addr = 198.060.022.0/26; 020 ACCEPT protocol = tcp; 030 AND src-addr = 198.060.022.002/32; 040 ACCEPT udp-src-port = 53; 050 AND src-addr = 198.060.022.022/32; 060 ACCEPT udp-src-port = 53; 070 ACCEPT protocol = icmp; 080 DENY; Thanks in Advance, RickyZ
Subject: (usr-tc) beating a dead horse
From: Brian <signal@shreve.net>
Date: 1999-04-26 20:43:32
I understand this question has been beaten to death here, but I am still a little vague. With regards to AUTHENTICATION, I understand that setting the Primary Server to your primary authentication server, and then setting the Primary First Backup to your "backup" authentication server, and then setting the RADIUS authentication algorithm to fallthrough, gives the effect that most people want: it uses the primary, and then if the primary fails, it goes to the secondary, and then if the primary comes back alive, it goes back to the primary. My question is, what about ACCOUNTING? I have set: The Primary Server Status is: ENABLED Primary Server is: 208.206.76.58 Primary First Backup Server is: 208.206.76.5 yet, if the primary should fail, and accounting goes to the "primary first backup", it wants to stay there. How do I tell it to go back to the primary if the primary goes back online? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) HyperDSPs losing config
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-26 21:01:04
> NMC 5.5.5 > HARC 4.1.59 > HDSP 1.2.5 > > I've just added a few HyperDSPs (6 total) to a chasis and after the reboot > the configs for the T1s and modems were goofed. They didn't go back to the > default, but added weird settings. Reset modems and T1s to default, made my > corrections, saved the T1s and Modems to NVRAM then rebooted the chasis. > Same problem occurred. After I configure the T1s and modems it will hold > those settings and operate properly until either the chasis is rebooted are > the cards are hardware resetted. I don't think the DSPs are the > problem...I've taken these DSPs and put them in another chasis and they > worked normally. So I'm down to the HARC or NMC as the culprit. Any > suggestions? When you plug in a DSP card in a chassis with HiPer arc and NMC - the NMC sends 'chassis awarness' which tells the ARC about the card and tells it to own/disown the same. When you put the DSP in a new/another chassis - the DSP worked good does not mean that the Problem is with the HiPer arc. You must see who own the cards/slots and also make sure that the DPS settings in the T1/PRI side is setup correctly. First here is what you need to do: 1. Take a look at the hiper arc interfaces List interface Make sure that the hiper arc owns the cards. 2. If the interfaces are 'up up' - no problems - but ifyou have interfaces 'up down' there is aa problem You must then check the interfaces - rebooting the hiper arc may clear the problem but the best bet would be to reboot the whole chassis or disable chassis awarness and start setting it up manually krish > > Walt > ----------------------------------------------------- > Walter N. Gnann > ISLC, President > 843.770.1000 > 843.770.1002 (fax) > wgnann@islc.net > http://www.islc.net > http://www.beaufortonline.com > http://www.beaufortcomputerclub.org > ----------------------------------------------------- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) total control analog ninja needed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-26 21:05:39
On Mon, 26 Apr 1999, Chairman of the Borg wrote: > > Hey guys, > > I've got a total control chassis here with major angst. > analog only .34 quad cards. the angst is cards with ports > that won't pick up, respond with garbage, etc. no error > lights, just borked communications. one card is perfect > but won't connect to anything at over 14.4, misc crap like > this. a couple people have said that most of this will sort Lot more information is required to find out what is the problem. Are you using the Quads with NETServer/HiPer arc /Edgeserver ?? Are you having packet bus problems or modem connection problems? Do you have a NMC in the chassis ? This minimal info will help in identifing the problem. krish > itself out with a reflash, so i'm going to try that before > i throw my hands up and ship it back. is there anyone on > this list that lives and breathes these that would be > willing to give me some pointers, etc? we sold off all > our old pop equipment and the guy is showing up wed to > pick it up, so if i don't get this sorted out by then > i'm in deep doo doo :/ > > thanks, > -dd > \\\\\// > \\|// _\\|//_ | | _\\|//_ \\|// > (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) > +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ > Plazma Networking Services / Level Seven inc. > Connecting the World.... > http://www.plazma.net http://www.L7.net http://www.L7.org /"\ > Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X > ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Re: cistron radius and VSA's
From: Mike Andrews <mandrews@termfrost.org>
Date: 1999-04-26 21:53:33
On Mon, 26 Apr 1999, Mike Andrews wrote: > I'm experimenting with the idea of switching to Cistron radius (beta16, > the latest), and I'm having problems with it not logging 3com VSA's > correctly. Ignore this, I figured it out. Cistron is *really* touchy about having ATTRIB_NMC lines in more than one file, it seems.... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."
Subject: (usr-tc) total control analog ninja needed
From: Chairman of the Borg <list-total-control@l7.org>
Date: 1999-04-26 23:02:11
okay, we're deep into flashing these modems now (the screwed up total control analog quadmodems) so far the first 3 ports on the first card are fine and do what they are supposed to. port 4 gives us garbage till we smack a key, and it seems to still be trying to handshake while the modem connecting to it is allready done. ideas? also, port 5, ati5 is giving me back this: borgmatrix-001.L7.net> attach s4 Trying 207.12.41.6 ... Connected - Escape character is '^]'. ati5 USRobotics Analog Quad NVRAM Settings... Copyright, 1988-97, U.S. Robotics. All rights reserved. DIAL=TONE B0 F1 X7 BAUD=115200 PARITY=N WORDLEN=8 &A3 &B1 &G0 &H1 &I0 &K1 &L0 &M4 &N0 &P0 &R2 &S0 &T4 &U0 &X0 &Y1 %N6 *U1=0 *U2=0 *U3=1 *V2=0 *X0=2048 *X1=2 S00=001 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S13=000 S15=000 S19=000 S21=010 S22=017 S23=019 S24=150 S25=005 S26=001 S27=000 S28=008 S29=020 S31=000 S32=009 S33=000 S34=000 S35=000 S36=000 S37=000 S38=000 S39=011 S40=000 S41=000 S42=126 S43=200 S44=015 S46=255 S47=000 S48=000 S49=016 S50=100 S51=000 S52=005 S53=000 S54=064 S55=000 S56=000 S57=000 S58=000 S60=000 S61=000 S62=000 S63=000 S64=000 S65=000 S66=000 S67=001 S68=000 S69=000 S70=000 S71=001 S72=000 S73=001 S74=000 S75=000 S76=000 S77=000 S78=000 S79=000 S80=000 S81=002 S82=012 STORED PHONE #0: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #1: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >< #2: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #3: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = OK now a) shouldn't the port speed be 57,600? and i'm not sure what the deal is wit the stored phone numbers, and i can't figure out how to set them to nothing. thanks to whomever sent me the faq's by the way :) -dd \\\\\// \\|// _\\|//_ | | _\\|//_ \\|// (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ Plazma Networking Services / Level Seven inc. Connecting the World.... http://www.plazma.net http://www.L7.net http://www.L7.org /"\ Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
Subject: Re: (usr-tc) total control analog ninja needed
From: Chairman of the Borg <list-total-control@l7.org>
Date: 1999-04-26 23:12:10
minor addendum port 8 for some reason gives me nothing but a repeating upper asci capital A with a tail thingy on top.. ideas? -dd \\\\\// \\|// _\\|//_ | | _\\|//_ \\|// (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ Plazma Networking Services / Level Seven inc. Connecting the World.... http://www.plazma.net http://www.L7.net http://www.L7.org /"\ Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
Subject: (usr-tc) DSP Code Version/File - Release Date
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-04-27 01:19:31
Webpage says: hd010243.zip 1041337 1.2.43 04/20/1999 ftp says: 04/20/99 09:05AM 1,041,337 hd010243.zip ... but my old zip of the same version is different. So how come it is a new date and file size but the version is the same?? All that is different is the modification of the PDF included in the zipfile. Seems as though this could be confusing to some. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
Subject: (usr-tc) required power supply
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-04-27 08:20:21
I have a chassis with 1 NMC, 1 ARC, 8 DSPs I am about to add another ARC and 2 more DSPs. I have a 70 amp AC power supply, a 3com tech told me I would need to go to the 130 amp supply in order to add these cards and others down the road. Anyone else had this type of problem? If so, can I just pull the existing 70a and put a 130a in place? Thanks, Scott Boggs United Bank - AccessUnited Internet
Subject: Re: (usr-tc) total control analog ninja needed
From: Chairman of the Borg <list-total-control@l7.org>
Date: 1999-04-27 09:22:41
ok, after flashng we still have 2 wonky ports on the first 3 cards. one of them sends back tons of upper ascii AAAAAA and the other with give a bit of garbage on connect, then will hand over a prompt. (win 95 dun gags on it though) i can see this is going to be a fun road.. -dd >On Mon, 26 Apr 1999, Chairman of the Borg wrote: >> >> radius machine > cat5 > portmaster 2e-30 > serial cable > 4way cable > >> analog rs-232 nic >> >> chassis has 6 analog nics (with daughterboards) and 6 analog quadmodems in it. >> >> dialing in with terminate and a usr 33.6, i get the following >> >> port 01 : no answer / attach s0 (talk to modem directly) /atz <sits there> >> port 02 : clean 33.6 connect >> port 03 : clean 33.6 connect >> port 04 : connects, ton of upper ascii garbage > > >Pull the modem and put dip switch 10 in the on position. This will set >the modem to factory default and cleary if there is any bad seetings. I >do see that you are sending the init string so the init string will set >the modem to proper setting that your portmaster requires. > >This should work > >krish > >> >> port 05 : clean 14.4 connect >> port 06 : clean 14.4 connect >> port 07 : clean 14.4 connect >> port 08 : clean 14.4 connect >> >> port 09 : picks up and doesn't do anything else >> port 10 : clean 33.6 connect >> port 11 : connects, ton of upper ascii garbage >> port 12 : no answer / attach s11 / atz <sits there> >> >> port 13 : clean 33.6 connect >> port 14 : clean 33.6 connect >> port 15 : clean 33.6 connect >> port 16 : connects, ton of upper ascii garbage >> >> port 17 : no answer / attach s11 / atz <sits there> >> port 18 : clean 33.6 connect >> port 19 : clean 33.6 connect >> port 20 : connects, ton of upper ascii garbage >> >> port 21 : no answer / attach s11 / atz <sits there> >> port 22 : clean 33.6 connect >> port 23 : picks up and doesn't do anything else >> port 24 : clean 33.6 connect >> >> modem setup in portmaster is currently >> >> borgmatrix-001.L7.net>show modem tcr >> >> Short Name: tcr >> Long Name: totalcontrol >> Optimal Speed: 57600 >> Type: User Defined >> Init Script: Send Command Wait for Reply >> ------------------------------ >> AT&B1&H1&R2X7&A3S0=1&N0&W OK >> >> >> <sigh> >> -dd >> >> \\\\\// >> \\|// _\\|//_ | | _\\|//_ \\|// >> (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) >> +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ >> Plazma Networking Services / Level Seven inc. >> Connecting the World.... >> http://www.plazma.net http://www.L7.net http://www.L7.org /"\ >> Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / >> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X >> ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \ >> > \\\\\// \\|// _\\|//_ | | _\\|//_ \\|// (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ Plazma Networking Services / Level Seven inc. Connecting the World.... http://www.plazma.net http://www.L7.net http://www.L7.org /"\ Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \
Subject: (usr-tc) stuck channels
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-27 09:23:51
I have two separate cards with two stuck channels (both of them are channel #8 coincidentally). I have repateadly reset them, flashed them, even swapped them, but I can't get the channel to come back to life. By "stuck" I mean that they generate fast-busies. Is this something that I should contact my telco on, or has anyone found a cure?
Subject: Re: (usr-tc) total control analog ninja needed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-27 09:30:34
On Mon, 26 Apr 1999, Chairman of the Borg wrote: > > radius machine > cat5 > portmaster 2e-30 > serial cable > 4way cable > > analog rs-232 nic > > chassis has 6 analog nics (with daughterboards) and 6 analog quadmodems in it. > > dialing in with terminate and a usr 33.6, i get the following > > port 01 : no answer / attach s0 (talk to modem directly) /atz <sits there> > port 02 : clean 33.6 connect > port 03 : clean 33.6 connect > port 04 : connects, ton of upper ascii garbage Pull the modem and put dip switch 10 in the on position. This will set the modem to factory default and cleary if there is any bad seetings. I do see that you are sending the init string so the init string will set the modem to proper setting that your portmaster requires. This should work krish > > port 05 : clean 14.4 connect > port 06 : clean 14.4 connect > port 07 : clean 14.4 connect > port 08 : clean 14.4 connect > > port 09 : picks up and doesn't do anything else > port 10 : clean 33.6 connect > port 11 : connects, ton of upper ascii garbage > port 12 : no answer / attach s11 / atz <sits there> > > port 13 : clean 33.6 connect > port 14 : clean 33.6 connect > port 15 : clean 33.6 connect > port 16 : connects, ton of upper ascii garbage > > port 17 : no answer / attach s11 / atz <sits there> > port 18 : clean 33.6 connect > port 19 : clean 33.6 connect > port 20 : connects, ton of upper ascii garbage > > port 21 : no answer / attach s11 / atz <sits there> > port 22 : clean 33.6 connect > port 23 : picks up and doesn't do anything else > port 24 : clean 33.6 connect > > modem setup in portmaster is currently > > borgmatrix-001.L7.net>show modem tcr > > Short Name: tcr > Long Name: totalcontrol > Optimal Speed: 57600 > Type: User Defined > Init Script: Send Command Wait for Reply > ------------------------------ ----------------------------- > AT&B1&H1&R2X7&A3S0=1&N0&W OK > > > <sigh> > -dd > > \\\\\// > \\|// _\\|//_ | | _\\|//_ \\|// > (@ @) (' 0-0 ') (.) (.) (' @-@ ') (o-o) > +-=oOOo-(_)-oOOo=oo0=(_)=0oo=oOO=-(_)-=OOo=oo0=(_)=0oo=oOOo-(_)-oOOo=-+ > Plazma Networking Services / Level Seven inc. > Connecting the World.... > http://www.plazma.net http://www.L7.net http://www.L7.org /"\ > Olympia's "one stop" InterNetworking Provider 1 (360) 357 - 7315 \ / > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ X > ASCII Ribbon campaign against HTML E-Mail >- - - - - - - - - - - - - -> / \ >
Subject: Re: (usr-tc) Filters...
From: Rommel Wladimir de Lima <rommel@server2.eol.com.br>
Date: 1999-04-27 09:48:20
Hi I saw a message about usr-tc Filters and I will take the chance to ask the solution to my problem as well. I work at an ISP and we have a usr-tc with 4 E1 cards hiper dsp and we would like to block attacks comming from dial in user. I've read the manual but it doesn't explain clearly the point. My questions are: 1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)? We've tried IP and IP-CALL and nothing worked 2) Is the filter input_filter or output_filter? This is a bit confusing because it may be an input filter for the trafic comming from a dial-in user, but may be also an output trafic leaving the card. I did all the "cake receipt" to set up the filter in the tc, but it didn't work. 1) add TFTP client <client IP> 2) tfpt <tc IP> 3) add filter <filter> 4) verify filter <filter> 5) set interface <slot:x/mod[1-30] input_filter|output_filter <filter> filter_access on Thank you in advance for the help.
Subject: RE: (usr-tc) Filters...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-27 10:14:55
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick |Sent: Monday, April 26, 1999 7:42 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Filters... | | |All, |This filter thing is about confusing. I am just rying to create dynamic |filters for people who have not paid up to restrict them from doing |anything but access our Mail and authentication server, however, this |doesn't appear to be working...the filters get applied, but they can still |surf...what am I missing? Filter access turned on?? |HiPer>> sh filter bess.in | |RULES FOR FILTER /./bess.in SHOW PROTOCOLS: ALL |#filter |IP: |10 ACCEPT src-addr=0.0.0.0/0; No need for the above line.. |20 ACCEPT dst-addr=205.206.216.0/24; |30 ACCEPT dst-addr=209.167.188.0/24; |40 DENY; |HiPer>> |HiPer>> sh filter bess.out | |RULES FOR FILTER /./bess.out SHOW PROTOCOLS: ALL |#filter |IP: |10 ACCEPT src-addr=0.0.0.0/0; No need for the above line. |20 ACCEPT dst-addr=209.167.188.0/24; |30 ACCEPT dst-addr=205.206.216.0/24; |40 ACCEPT protocol = tcp; |50 ACCEPT protocol = udp; |60 DENY; Since this is an "output" filter, meaning out of the HARC into the user, you should use src-addr not dst-addr here. |Also, What does the "AND" do here at the beginning of each line? The default filter action is to logic 'OR' the rules together. So in your above filters if the data satisfies any line it passes. So in your output filter (assuming you make it src and not dst) if the packet is tcp or udp it passes reguardless of what address it came from. Use of the "AND" construct is required there. In the example below the writter uses AND to indicate that the line with the AND and the following line are to be considered one rule. Both items must be matched to make the line "TRUE". From first looks your rules above will not work like you expect. The rules below seem to have the correct syntax and will work. Maybe changing them with your IP addresses is a better way to go.. The HARC manual covers the AND/OR idea and provides some sample filters. They are good examples to work from. -M |mail.in: | |#filter |IP: |010 AND dst-addr = 198.060.022.022/32; |020 ACCEPT tcp-dst-port = 106; |030 AND dst-addr = 198.060.022.022/32; |040 ACCEPT tcp-dst-port = 109; -[SNIP!]- -M
Subject: RE: (usr-tc) beating a dead horse
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-27 10:24:47
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Monday, April 26, 1999 8:44 PM |To: USRobotics TC Mailing List |Subject: (usr-tc) beating a dead horse | | | |I understand this question has been beaten to death here, but I am still a |little vague. | |With regards to AUTHENTICATION, I understand that setting the Primary |Server to your primary authentication server, and then setting the Primary |First Backup to your "backup" authentication server, and then setting the |RADIUS authentication algorithm to fallthrough, gives the effect that most |people want: it uses the primary, and then if the primary fails, it goes |to the secondary, and then if the primary comes back alive, it goes back |to the primary. | |My question is, what about ACCOUNTING? I have set: | |The Primary Server Status is: ENABLED |Primary Server is: 208.206.76.58 |Primary First Backup Server is: 208.206.76.5 | | |yet, if the primary should fail, and accounting goes to the "primary first |backup", it wants to stay there. How do I tell it to go back to the |primary if the primary goes back online? | Here is your answer, straight from the 3KB Knowledge Base. 3KB Solution: 1.0.21317967.2088893 Goal Total Control HiPer ARC - Making accounting fall back work just like authentication algorithm "FALL_THROUGH" Fact Total Control Chassis Fact Total Control HiPer ARC Fact Total Control HiPer ARC v 4.1.59-6 Fact Accounting Fact RADIUS Fact Engineering Release Code Symptom Accounting server is switching to first backup and not returning to primary server until backup goes down Fix From HiPer ARC console issue the command: HiPer>> "ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP" This will cause the accounting to return to the primary server when it becomes available. Fact Search group - Total Control Remote Access Concentrator
Subject: RE: (usr-tc) Filters...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-27 10:28:20
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rommel Wladimir de |Lima |Sent: Tuesday, April 27, 1999 7:48 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Filters... | | |Hi | | I saw a message about usr-tc Filters and I will take the chance to |ask the solution to my problem as well. | | I work at an ISP and we have a usr-tc with 4 E1 cards hiper dsp |and we would like to block attacks comming from dial in user. I've read |the manual but it doesn't explain clearly the point. My questions are: | | 1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)? | We've tried IP and IP-CALL and nothing worked IP: | 2) Is the filter input_filter or output_filter? | This is a bit confusing because it may be an input filter | for the trafic comming from a dial-in user, but may be | also an output trafic leaving the card. Filters on the HARC are always directional with respect to the interface. So data from a user is going "IN" to the modem interface. Data to the user is going "OUT" of the modem interface. From that you use an input filter to check data comming from a user. The same rule apples for ethernet interfaces. | I did all the "cake receipt" to set up the filter in the tc, but |it didn't work. | 1) add TFTP client <client IP> | 2) tfpt <tc IP> | 3) add filter <filter> | 4) verify filter <filter> | 5) set interface <slot:x/mod[1-30] input_filter|output_filter |<filter> filter_access on | It is possible your filter was applied, and was syntactically correct, but it didnt block anything. What was your exact filter? -M
Subject: RE: (usr-tc) beating a dead horse
From: Brian <signal@shreve.net>
Date: 1999-04-27 10:41:24
Thanks, I will learn to use 3kb first from now on, it seems like that knowledgbase is really getting alot of good tips in it. On Tue, 27 Apr 1999, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > |Sent: Monday, April 26, 1999 8:44 PM > |To: USRobotics TC Mailing List > |Subject: (usr-tc) beating a dead horse > | > | > | > |I understand this question has been beaten to death here, but I am still a > |little vague. > | > |With regards to AUTHENTICATION, I understand that setting the Primary > |Server to your primary authentication server, and then setting the Primary > |First Backup to your "backup" authentication server, and then setting the > |RADIUS authentication algorithm to fallthrough, gives the effect that most > |people want: it uses the primary, and then if the primary fails, it goes > |to the secondary, and then if the primary comes back alive, it goes back > |to the primary. > | > |My question is, what about ACCOUNTING? I have set: > | > |The Primary Server Status is: ENABLED > |Primary Server is: 208.206.76.58 > |Primary First Backup Server is: 208.206.76.5 > | > | > |yet, if the primary should fail, and accounting goes to the "primary first > |backup", it wants to stay there. How do I tell it to go back to the > |primary if the primary goes back online? > | > > Here is your answer, straight from the 3KB Knowledge Base. > > 3KB Solution: 1.0.21317967.2088893 > > Goal Total Control HiPer ARC - Making accounting fall back work just like > authentication algorithm "FALL_THROUGH" > Fact Total Control Chassis > Fact Total Control HiPer ARC > Fact Total Control HiPer ARC v 4.1.59-6 > Fact Accounting > Fact RADIUS > Fact Engineering Release Code > > Symptom Accounting server is switching to first backup and not returning to > primary server until backup goes down > > Fix From HiPer ARC console issue the command: > > HiPer>> "ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP" > > This will cause the accounting to return to the primary server when it becomes > available. > Fact Search group - Total Control Remote Access Concentrator > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: RE: (usr-tc) beating a dead horse
From: Brian <signal@shreve.net>
Date: 1999-04-27 10:56:56
> > Here is your answer, straight from the 3KB Knowledge Base. > > 3KB Solution: 1.0.21317967.2088893 > > Goal Total Control HiPer ARC - Making accounting fall back work just like > authentication algorithm "FALL_THROUGH" > Fact Total Control Chassis > Fact Total Control HiPer ARC > Fact Total Control HiPer ARC v 4.1.59-6 > Fact Accounting > Fact RADIUS > Fact Engineering Release Code > > Symptom Accounting server is switching to first backup and not returning to > primary server until backup goes down > > Fix From HiPer ARC console issue the command: > > HiPer>> "ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP" FYI, the HiperARC expects: ENABLE PRIORITISE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP and not ENABLE PRIORITIZE_FIRST_ACCOUNTING_SERVER_IN_A_GROUP probably a typo in the hiperarc code. > > This will cause the accounting to return to the primary server when it becomes > available. > Fact Search group - Total Control Remote Access Concentrator > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) Connecting to an NT Domain via TCHub
From: Marlo Montanaro <marlo@monmouth.com>
Date: 1999-04-27 10:59:40
Have a customer who wants his users to be able to click on one DUN = shortcut on their desktop and automatically dial in to a TC Hub and = authenticate into their NT domain. His users are running both old and = new versions of Win95 (a and b) as well as 98 and NT Workstation. We have him currently configured to dial in and route through a = proxy/firewall/router out to the Internet. He now needs NT = authentication also back to his local network as well. We can dial into the TC Hub and authenticate as a PPP user with no = problem. We can get to the Internet with no problem. The problem is NT = domain authentication. Can someone give us the TC Hub configuration as well as the config for = Windows DUN? Or at least a reference to the same. Thanks, MM=00=00
Subject: (usr-tc) RE: FS USR QUAD MODEM CARDS
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-04-27 11:19:09
For Sale: I have quantity (100) USR Quad Modem Cards in Stock These are the analog/digital cards for the USR total control chassis. USR part # 000793-04 $125 each min qty 5 Also: quantity (6) Netserver PRI T-1 card sets USR part# 69-001393-00 Rev.1 $800.00 each quantity (1) Dual T-1/E-1 NAC only $500.00 If interested, please contact me via private e-mail With Warmest Regards, Andrew Shlensky **************************** PC Global, Incorporated (305) 667-2111 TEL (305) 667-3636 FAX URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089
Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
From: Eric Forcey <eric@psnw.com>
Date: 1999-04-27 11:31:33
Same thing happened to us, and I think that is why 4.2.99 was written. I worked with support for well over 6 months on why the card was not accepting calls, or if it did it would only accept 1 or 2 calls then report busies. It was finally escalated to engineering to look at and at that time they wrote the 4.2.99. There is a way around flashing it to 4.2.99, as the problem is dealing with Jitter Attenuation. (this again is per the engineer that I dealt with). He was able to get the card working fine with existing code by changing the Jitter from TX to Recvr, saving the settings, resetting, then changing it back. I wasn't about to do that on a continual basis. After looking at the card again as I was writing this, are you positive on the numbering? I'm showing 4.3.99 is what was given to me and since that has happened (well over a year ago now) the card has performed without troubles. -Eric On Tue, 27 Apr 1999, Carl Litt wrote: > > We had a problem with span 1 of a Dual-T1/PRI card last year. When > I returned it for repair, it also came back with 4.2.99 and > a note that said "Reflashed with 4.2.99. Must be used for Channellized > T1 operation". > > I've mentioned this several times to 3Com tech support, but they > all think I'm stupid or something. > > On Mon, 19 Apr 1999, Mike McHenry wrote: > > > > > Hello all, > > > > I have a problem that is driving me crazy and I am leaning towards hardware > > failure. We have several TC chassis, each with one 386 T1 card, 12 Digital > > Quad modem cards, 1 HiperArc card, 1 16 meg NMC card. Several weeks ago one > > of the T1 cards starting acting up and would not accept incoming calls on > > the SPAN 1. The card was sent to USR for repair and was not-so-promptly > > returned to us with a note saying there was no problem found. There was also > > a note saying that the card was reflashed to version 4.2.99 and that this > > version was required for the card to function properly. > > > > <RANT ON> > > Now the first problem is 4.2.99 is not even available for download! 4.2.1 is > > the latest code for the Channelized T1 card and has been stable for over a > > year so I can't imagine why my card was reflashed to 4.2.99. This is not the > > first faulty card that has been sent in for a RMA and sent back to me with a > > note saying there was nothing wrong. My network of Total Control chassis is > > falling apart and it is not even being repaired when I send it in! > > <RANT OFF> > > > > I have seen this problem three times, each time after an unplanned power > > outage. About 20 modems on my chassis are not accepting any calls. The calls > > are being routed in across the T1, I can verify this by swapping T1s. The > > problem is definately NOT with the telco. The problem is also NOT with the > > quad modems as I can swap modems back and forth and the same 20 positions in > > the chassis will not take incoming calls. It is NOT a configuration issue > > such as the common t1tdm setting or the answer packet bus only setting. > > > > The Hiper ARC card is shown as the owner of all the cards in question when > > doing a list chassis. The T1 channels are active and are not OOS. The packet > > bus sessions appear to be up but I see no traffic on the affected channels, > > see below for a partial copy of a list pbus sessions: > > > > tc-2.minn.net> list pbus seSSIONS > > Interface Slot Channel Session Rpkts Spkts PktSize > > slot:2/mod:4 2 4 259 20575 18650 4096 > > slot:3/mod:1 3 1 512 62358 64852 4096 > > slot:3/mod:2 3 2 513 16674 14924 4096 > > slot:3/mod:3 3 3 514 0 0 4096 > > slot:3/mod:4 3 4 515 0 0 4096 > > slot:4/mod:1 4 1 768 0 0 4096 > > slot:4/mod:2 4 2 769 0 0 4096 > > slot:4/mod:3 4 3 770 0 0 4096 > > slot:4/mod:4 4 4 771 0 0 4096 > > > > I have tried power cycling the chassis, soft resets on the cards, hard > > resets on the cards, reflashing all of the cards, reseating the cards, > > checking the in house cabling, swapping cards with different chassis. In > > every case the problem seems to follow the T1 card. All of the cards are > > running the latest service patch code, 5.10.9 for the quads, 4.2.1 for the > > T1 card, 4.1.59 for the Hiper ARC, 5.5.5 for the 16meg NMC. The settings on > > the T1 card are correct, I have checked them about 30 times today and have > > also reset them a few times to make sure the settings were taking correctly. > > > > I have seen other people with very similar problems on this list, however I > > have yet to find a solution in the archives. Am I overlooking something > > here? I feel like I am bashing my head against a brick wall. > > > > Of course I do NOT want to ship this card back to USR/3com and let them look > > at it for another two weeks to tell me there is nothing wrong with it. I > > tried to call today and explain that this card was sent in for repair and > > was NOT repaired in the hopes that I could talk to an engineer to see why > > the card was sent back when it still appears to be faulty. No go, I was not > > allowed to talk to anyone as I do not have a service contract! Having a > > chassis down for two weeks in unacceptable, having it down for another two > > weeks because the problem wasn't fixed the first time is ludicrous! > > > > At this point I am about ready to ship the whole damn chassis in for repair > > and tell them the whole thing doesn't work! :) Either that or kick the thing > > a few times. I am entirely unhappy with these pieces of equipment and their > > reliability. I have probably spent 50-100 hours in the last year in dealing > > with problems that should have never existed. > > > > Any suggestions would be appreciated, sorry about the ranting :) > > > > Mike McHenry > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Accepting 2400bps modem connections on HDM
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-04-27 11:41:17
Robert von Bismarck said once upon a time: > >Hi, > >What do I need to set up in an HDM to accept a pure 2400 bps (V.22bis) >connection ? You need to turn on 2400 bps in the "signal converter" section of the modem settings via TCM.
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-27 13:32:41
On Tue, 20 Apr 1999, Rick wrote: > Krish, could you kindly add some well-deserved insight as to the > disable/disable topic regarding ppp offloading on the arc. I have been an > avid fan of yourself (without a doubt you devote more of your time and > effort then any other 3com employee) for the last few years and we have > experienced an increase in the amount ppp-negotiation failures in the last > month or two. We currently run 4.1.59-6 on the arc and 1.2.43 with the dsp > and your 3com literature expouses the use of 'enable ppp offloading' yet > the mailing list seems to suggest the opposite. I would appreciate any > thoughts yourself or Mike can add on this subject... 4.1.59 -6 is the hiper arc has lots of bug fixes and features. 1.2.43 DSP code also has the similar packet bus fixes to operate with the ARC. In our testing here 1.2.43 (1.2.59 also has this ) had a problem with ISDN calls. If ppp offloading was disabled then the DSP would present the call to the ARC as a analog call - not exactly like analog but would send async map information to the call. Thus when the ISDN sync call has async map info - ISDN calls would not go through. So in the release notes we had specified users to have the PPP offloading enabled to resolve the problem. Also when PPP offloading is enabled - the DSP takes care of the PPP framing - Meaning the DSP would receive the PPP packet and strip the PPP header and present the data to the ARC. This is done in the hardware level thus its fast and takes care of the ppp framing over head on the ARC. When you disable ppp offloading - the ppp framing is done by the hiper arc at a software layer. The net effect of ppp offloading enabled is that the users throughput is slightly higher. On a fully loaded chassis with 14 DSP and calls on all the DSP cards the throughput with PPP offloading is better. Now we received information from customers regarding users password getting corrupted. Some of you had radius logs which showed that the users password was getting corrupted. The users password from the showed that the last charecter of the password had some some control charecters like ]}# etc. This particular problem is not consistant and cannot be reproduced on demand. Its random and there is really no co-relation between the users-modems and connection type. There is a case when the DSP is actually corrupting the packet and sending it to the hiper arc which is forwarded to the ARC to the Radius server. Disabling ppp offloading on the ARC ( which means that the arc has to do the ppp framing ) does resolve the problem. So there is a know issue with the DSP corrupting random packets - Also by disabling ppp offloading ISDN calls may be affected. DSP now has a ER code that fixes the ISDN problem - when ppp offloading is disabled. However we are still debugging the problem with user password corruption. This is is the issue. regards krish > > thanks > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) ISDN call debug
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-27 13:35:09
On 22 Apr 1999 huix@990.net wrote: > Hi,=20 > > I monitor PPP call use ppp ficility, > > set ficility ppp loglevel verbose > > I get call information and find ISDN > canot build MP during LCP phase, > who can tell me it is which end canot > accept MP option? Send a mon ppp trace - that is easy to debug. krish > > > > > __________________________________________________ > =BB=B6=D3=AD=CA=B9=D3=C3=BD=F0=C1=EA=C8=C8=CF=DF=C3=E2=B7=D1=B5=E7=D7=D3=D3= > =CA=BC=FE=CF=B5=CD=B3http://www.990.net
Subject: RE: (usr-tc) Connecting to an NT Domain via TCHub
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-04-27 13:41:37
Need to have "Log onto network" checked in DUN.....
Subject: RE: (usr-tc) Filters...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-27 13:44:39
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rommel Wladimir de |Lima |Sent: Tuesday, April 27, 1999 1:43 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Filters... | | | | |On Tue, 27 Apr 1999, Mike Wronski wrote: | |Thank you for your message. | |> | |> | 1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)? |> | |> We've tried IP and IP-CALL and nothing worked |> IP: |> |> | I did all the "cake receipt" to set up the filter in the tc, but |> |it didn't work. |> | 1) add TFTP client <client IP> |> | 2) tfpt <tc IP> |> | 3) add filter <filter> |> | 4) verify filter <filter> |> | 5) set interface <slot:x/mod[1-30] input_filter|output_filter |> |<filter> filter_access on |> | |> |> It is possible your filter was applied, and was syntactically correct, but it |> didnt block anything. |> |> What was your exact filter? | |#filter |IP: |010 REJECT tcp-dst-port=12345; |020 REJECT tcp-dst-port=12346; |030 REJECT tcp-dst-port=31337; |... | The above is fine as an input filter.. Those tcp ports will be blocked. When you look at the individual interfaces with "sh interface slot:x/mod:y" do you see the filter name applied as an input filter? Also what version of HARC code are you using? BTW: BO can use any port.. Your not safe by blocking the default ports. -M
Subject: RE: (usr-tc) required power supply
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-04-27 13:46:15
Another possibility (please check this out before taking this advice) is putting another 70 in there. You lose redundancy, but gain the extra horsepower.... SMT > -----Original Message----- > From: Scott Boggs [mailto:sboggs@unitedbank.net] > Sent: Tuesday, April 27, 1999 7:20 AM > To: USR-TC Mail list > Subject: (usr-tc) required power supply > > > I have a chassis with 1 NMC, 1 ARC, 8 DSPs > I am about to add another ARC and 2 more DSPs. > I have a 70 amp AC power supply, a 3com tech told me > I would need to go to the 130 amp supply in order to > add these cards and others down the road. > Anyone else had this type of problem? > If so, can I just pull the existing 70a and put a 130a in place? > Thanks, > Scott Boggs > United Bank - AccessUnited Internet > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
From: Carl Litt <carl@execulink.com>
Date: 1999-04-27 14:00:20
We had a problem with span 1 of a Dual-T1/PRI card last year. When I returned it for repair, it also came back with 4.2.99 and a note that said "Reflashed with 4.2.99. Must be used for Channellized T1 operation". I've mentioned this several times to 3Com tech support, but they all think I'm stupid or something. On Mon, 19 Apr 1999, Mike McHenry wrote: > > Hello all, > > I have a problem that is driving me crazy and I am leaning towards hardware > failure. We have several TC chassis, each with one 386 T1 card, 12 Digital > Quad modem cards, 1 HiperArc card, 1 16 meg NMC card. Several weeks ago one > of the T1 cards starting acting up and would not accept incoming calls on > the SPAN 1. The card was sent to USR for repair and was not-so-promptly > returned to us with a note saying there was no problem found. There was also > a note saying that the card was reflashed to version 4.2.99 and that this > version was required for the card to function properly. > > <RANT ON> > Now the first problem is 4.2.99 is not even available for download! 4.2.1 is > the latest code for the Channelized T1 card and has been stable for over a > year so I can't imagine why my card was reflashed to 4.2.99. This is not the > first faulty card that has been sent in for a RMA and sent back to me with a > note saying there was nothing wrong. My network of Total Control chassis is > falling apart and it is not even being repaired when I send it in! > <RANT OFF> > > I have seen this problem three times, each time after an unplanned power > outage. About 20 modems on my chassis are not accepting any calls. The calls > are being routed in across the T1, I can verify this by swapping T1s. The > problem is definately NOT with the telco. The problem is also NOT with the > quad modems as I can swap modems back and forth and the same 20 positions in > the chassis will not take incoming calls. It is NOT a configuration issue > such as the common t1tdm setting or the answer packet bus only setting. > > The Hiper ARC card is shown as the owner of all the cards in question when > doing a list chassis. The T1 channels are active and are not OOS. The packet > bus sessions appear to be up but I see no traffic on the affected channels, > see below for a partial copy of a list pbus sessions: > > tc-2.minn.net> list pbus seSSIONS > Interface Slot Channel Session Rpkts Spkts PktSize > slot:2/mod:4 2 4 259 20575 18650 4096 > slot:3/mod:1 3 1 512 62358 64852 4096 > slot:3/mod:2 3 2 513 16674 14924 4096 > slot:3/mod:3 3 3 514 0 0 4096 > slot:3/mod:4 3 4 515 0 0 4096 > slot:4/mod:1 4 1 768 0 0 4096 > slot:4/mod:2 4 2 769 0 0 4096 > slot:4/mod:3 4 3 770 0 0 4096 > slot:4/mod:4 4 4 771 0 0 4096 > > I have tried power cycling the chassis, soft resets on the cards, hard > resets on the cards, reflashing all of the cards, reseating the cards, > checking the in house cabling, swapping cards with different chassis. In > every case the problem seems to follow the T1 card. All of the cards are > running the latest service patch code, 5.10.9 for the quads, 4.2.1 for the > T1 card, 4.1.59 for the Hiper ARC, 5.5.5 for the 16meg NMC. The settings on > the T1 card are correct, I have checked them about 30 times today and have > also reset them a few times to make sure the settings were taking correctly. > > I have seen other people with very similar problems on this list, however I > have yet to find a solution in the archives. Am I overlooking something > here? I feel like I am bashing my head against a brick wall. > > Of course I do NOT want to ship this card back to USR/3com and let them look > at it for another two weeks to tell me there is nothing wrong with it. I > tried to call today and explain that this card was sent in for repair and > was NOT repaired in the hopes that I could talk to an engineer to see why > the card was sent back when it still appears to be faulty. No go, I was not > allowed to talk to anyone as I do not have a service contract! Having a > chassis down for two weeks in unacceptable, having it down for another two > weeks because the problem wasn't fixed the first time is ludicrous! > > At this point I am about ready to ship the whole damn chassis in for repair > and tell them the whole thing doesn't work! :) Either that or kick the thing > a few times. I am entirely unhappy with these pieces of equipment and their > reliability. I have probably spent 50-100 hours in the last year in dealing > with problems that should have never existed. > > Any suggestions would be appreciated, sorry about the ranting :) > > Mike McHenry > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >
Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
From: David Bolen <db3l@ans.net>
Date: 1999-04-27 14:48:28
Eric Forcey <eric@psnw.com> writes: > There is a way around flashing it to 4.2.99, as the problem is dealing > with Jitter Attenuation. (this again is per the engineer that I dealt with). > > He was able to get the card working fine with existing code by changing > the Jitter from TX to Recvr, saving the settings, resetting, then > changing it back. I wasn't about to do that on a continual basis. Yes, there was a problem in this regard in the 4.2.x series that toggling the jitter attenuation could correct. The card would incorrectly latch AB bit patterns during a bootup (and or fall into that mode) which would affect its ability to process calls. The jitter attenuation toggling is just a workaround in that it gives the AB bits as perceived by the card a "kick", but the underlying problem isn't with the jitter attenuation itself. > After looking at the card again as I was writing this, are you positive > on the numbering? I'm showing 4.3.99 is what was given to me and since > that has happened (well over a year ago now) the card has performed > without troubles. I'm not sure about 4.3.99 but 4.2.99 was originally built for us back in 3/98 in response to this problem during TCS 3.1 testing (among other items) off of a 4.2.1 base, and it did address this sort of problem. Hope they didn't reintroduce the problem in the 4.3.x series :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: RE: (usr-tc) MPIP, RIP and ping/traceroute
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-27 14:58:54
Oooops... thanks for the tip... I forgot one of my ARC's in the server... and the MLPPP connection began on that one ... Now it works fine... I still have this memory leak/upgrade to take care of, but that'll be next Sunday morning... Robert -----Original Message----- From: Jeff Mcadams [SMTP:jeffm@iglou.com] Sent: vendredi, 23. avril 1999 20:02 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) MPIP, RIP and ping/traceroute >ARC3: >SET NTP PRIMARY_SERVER a.b.c.d >ENABLE NTP >ADD MPIP CLIENT a.r.c.1 SHAREDSECRET CRYPT TYPE HIPER >ADD MPIP CLIENT a.r.c.2 SHAREDSECRET CRYPT TYPE HIPER Add: set mpip server_state on add mpip client <mpip server's ip> sharedsecret crypt type hiper I *think* that should take care of it all. >The ARC's are all in different subnets, I don't know if that matters... Shouldn't. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Total Control Performance on a 100Mps Switch...
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-27 15:01:22
We use a cisco catalyst 2924XL (24 port 10/100 autosense) and it works beautifully with the HiPerARC's. It even detects the 100Mb Full-Duplex correctly... Catalyst 1900 also works fine, is only a 10Mb switch with two 100Base-TX ports though... Robert -----Original Message----- From: Ronald Kushner [SMTP:ron@glis.net] Sent: vendredi, 23. avril 1999 21:51 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) Total Control Performance on a 100Mps Switch... Dan Hollis wrote: > > On Fri, 23 Apr 1999, Robb Bryn wrote: > > I'll admit, I'm new to 10/100 switching technology and don't know if this is > > normal. It's definitely not what I was expecting. Anyone have similar > > setups with switches? > > The TC doesnt like certain hubs and switches. For example it completely > brainfarted on our SMC 3512TP hub -- wouldnt talk at all. No other > equipment has ever had problems with this hub, just the TC. I dont know > why the TC is so touchy although I suspect its buggy or completly broken > 10/100 autodetect. Has anyone compiled a list of known good or known bad auto-detecting 10/100 switching hubs when used with a Total Control? If not, readers can e-mail me off the list telling me about your experiences with different switching hubs connected to the Total Control chassis and I will post the results to the list. -Ron GLISnet, Inc. +1 810/939.9885 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) Filters...
From: Rommel Wladimir de Lima <rommel@server2.eol.com.br>
Date: 1999-04-27 15:43:21
On Tue, 27 Apr 1999, Mike Wronski wrote: Thank you for your message. > | > | 1) Which is the right filter (IP, IP-CALL, LOGIN-ACCESS)? > | > We've tried IP and IP-CALL and nothing worked > IP: > > | I did all the "cake receipt" to set up the filter in the tc, but > |it didn't work. > | 1) add TFTP client <client IP> > | 2) tfpt <tc IP> > | 3) add filter <filter> > | 4) verify filter <filter> > | 5) set interface <slot:x/mod[1-30] input_filter|output_filter > |<filter> filter_access on > | > > It is possible your filter was applied, and was syntactically correct, but it > didnt block anything. > > What was your exact filter? #filter IP: 010 REJECT tcp-dst-port=12345; 020 REJECT tcp-dst-port=12346; 030 REJECT tcp-dst-port=31337; ... What I've done is basicly: - deny netbus attack; - deny BO attack; - deny IP spoofing; Is it anything missing? Greetings
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-27 16:45:19
Tatai SV Krishnan writes... > . . . >Now we received information from customers regarding users password >getting corrupted. Some of you had radius logs which showed that the >users password was getting corrupted. > >The users password from the showed that the last charecter of the >password had some some control charecters like ]}# etc. This particular >problem is not consistant and cannot be reproduced on demand. I don't think *I* said that, and I'm the one who (re-)reported it recently and verified the workaround. I can gaurantee we have at _least_ one user who this occurs for on _every_ call. We used that particular user to troubleshoot with and to the try various possible fixes including disabling ppp offloading. We tried capturing the session using a syslog tap as described in the documentation. It didn't work, nothing was captured. -- Aaron Nabil
Subject: (usr-tc) Dedicated Dial-Up
From: Jason W. <jwatkins@iland.net>
Date: 1999-04-27 16:45:58
We have 2 dedicated dial-up customers that I'm having problems setting up properly. We are using a USRTC, Quad modem cards, and HiPer ARC. I'm having their IP addresses assigned to them via Radius, and 2 channels of that CT1 are pulled out of the hunt and have their own phone number. The problem is this. I have an IP address pool set to use 46 IP addresses, with a range of 123.123.123.1- 123.123.123.46 The static IP addresses our dedicated customers get are .47 and .48 With this configuration since the interfaces they connect to are in the modem_group all, the USRTC thinks that when our dedicated customer dials in that it uses 2 addresses from that IP pool. When that chassis is full users are unable to connect to two ports because it already thinks two addresses are being used..... confusing eh?? So my question is this, could I delete then re-create the modem_group all -those two interfaces, and assign those two interfaces their own IP address pool size (2), and create their own modem_group? Or am I making this WAY too hard on myself??? TIA \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ Jason Watkins, jwatkins@iland.net I-Land NOC Technician http://www.iland.net \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-04-27 16:56:13
David Bolen writes... >Eric Forcey <eric@psnw.com> writes: > >> There is a way around flashing it to 4.2.99, as the problem is dealing >> with Jitter Attenuation. (this again is per the engineer that I dealt with). >> >> He was able to get the card working fine with existing code by changing >> the Jitter from TX to Recvr, saving the settings, resetting, then >> changing it back. I wasn't about to do that on a continual basis. > >Yes, there was a problem in this regard in the 4.2.x series that >toggling the jitter attenuation could correct. The card would >incorrectly latch AB bit patterns during a bootup (and or fall into >that mode) which would affect its ability to process calls. > >The jitter attenuation toggling is just a workaround in that it gives >the AB bits as perceived by the card a "kick", but the underlying >problem isn't with the jitter attenuation itself. The jitter attenuartion default is also set wrong, you want jitter attenuation on the receiver, not the transmitter. So if you are going to "flip" it, leave it at the rx setting. -- Aaron Nabil
Subject: RE: (usr-tc) Dedicated Dial-Up
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-04-27 17:00:42
Way too hard. Assign them static addresses in Radius completely out of your pool. Pool is for random assignment only. You'll only give yourself grief trying to pick the pool. SMT > -----Original Message----- > From: Jason W. [mailto:jwatkins@iland.net] > Sent: Tuesday, April 27, 1999 4:46 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Dedicated Dial-Up > > > We have 2 dedicated dial-up customers that > I'm having problems setting up properly. > We are using a USRTC, Quad modem cards, > and HiPer ARC. I'm having their IP addresses > assigned to them via Radius, and 2 channels > of that CT1 are pulled out of the hunt and > have their own phone number. The problem is > this. I have an IP address pool set to use > 46 IP addresses, with a range of 123.123.123.1- > 123.123.123.46 The static IP addresses our > dedicated customers get are .47 and .48 With > this configuration since the interfaces they > connect to are in the modem_group all, the > USRTC thinks that when our dedicated customer > dials in that it uses 2 addresses from that IP > pool. When that chassis is full users are > unable to connect to two ports because it already > thinks two addresses are being used..... confusing > eh?? > > So my question is this, could I delete > then re-create the modem_group all -those two > interfaces, and assign those two interfaces > their own IP address pool size (2), and create > their own modem_group? Or am I making this > WAY too hard on myself??? > > TIA > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > Jason Watkins, jwatkins@iland.net > I-Land NOC Technician > http://www.iland.net > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Dedicated Dial-Up
From: Jason W. <jwatkins@iland.net>
Date: 1999-04-27 17:27:30
I'm actually assigning their IP addresses via Radius now. What happens is that even though I have the PI address set to 46 addresses, when the dedicated customer dials in they are basically a "default" user which is using the "modem_group all" So the PI pool thinks that the dedicated user is using a proper IP address and increments the number of addresses used by 2. So if our USRTC is almost full and 2 users try to dial into the last available ports they cannot because the PI pool thinks it has no more addresses to assign... Shouldn't the ARC be intuitive enough to know that those addresses are not part of the pool and thus not increment the size of the used IP pool??? \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ Jason Watkins, jwatkins@iland.net I-Land NOC Technician http://www.iland.net \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ ----- Original Message ----- Sent: Tuesday, April 27, 1999 5:00 PM > Way too hard. Assign them static addresses in Radius completely out of your > pool. > Pool is for random assignment only. You'll only give yourself grief trying > to pick the pool. > > SMT > > > -----Original Message----- > > From: Jason W. [mailto:jwatkins@iland.net] > > Sent: Tuesday, April 27, 1999 4:46 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Dedicated Dial-Up > > > > > > We have 2 dedicated dial-up customers that > > I'm having problems setting up properly. > > We are using a USRTC, Quad modem cards, > > and HiPer ARC. I'm having their IP addresses > > assigned to them via Radius, and 2 channels > > of that CT1 are pulled out of the hunt and > > have their own phone number. The problem is > > this. I have an IP address pool set to use > > 46 IP addresses, with a range of 123.123.123.1- > > 123.123.123.46 The static IP addresses our > > dedicated customers get are .47 and .48 With > > this configuration since the interfaces they > > connect to are in the modem_group all, the > > USRTC thinks that when our dedicated customer > > dials in that it uses 2 addresses from that IP > > pool. When that chassis is full users are > > unable to connect to two ports because it already > > thinks two addresses are being used..... confusing > > eh?? > > > > So my question is this, could I delete > > then re-create the modem_group all -those two > > interfaces, and assign those two interfaces > > their own IP address pool size (2), and create > > their own modem_group? Or am I making this > > WAY too hard on myself??? > > > > TIA > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > Jason Watkins, jwatkins@iland.net > > I-Land NOC Technician > > http://www.iland.net > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Dedicated Dial-Up
From: Jason W. <jwatkins@iland.net>
Date: 1999-04-27 17:38:42
Umm...Sorry about the PI instead of IP stupid spell checker... \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ Jason Watkins, jwatkins@iland.net I-Land NOC Technician http://www.iland.net \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ ----- Original Message ----- Sent: Tuesday, April 27, 1999 5:27 PM > I'm actually assigning their IP addresses via > Radius now. What happens is that even though > I have the PI address set to 46 addresses, > when the dedicated customer dials in they > are basically a "default" user which is using > the "modem_group all" So the PI pool thinks > that the dedicated user is using a proper > IP address and increments the number of > addresses used by 2. So if our USRTC is > almost full and 2 users try to dial into > the last available ports they cannot because > the PI pool thinks it has no more addresses > to assign... Shouldn't the ARC be intuitive > enough to know that those addresses are > not part of the pool and thus not increment > the size of the used IP pool??? > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > Jason Watkins, jwatkins@iland.net > I-Land NOC Technician > http://www.iland.net > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > ----- Original Message ----- > From: Scott Trautman <scottt@corp.gdinet.com> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, April 27, 1999 5:00 PM > Subject: RE: (usr-tc) Dedicated Dial-Up > > > > Way too hard. Assign them static addresses in Radius completely out of > your > > pool. > > Pool is for random assignment only. You'll only give yourself grief trying > > to pick the pool. > > > > SMT > > > > > -----Original Message----- > > > From: Jason W. [mailto:jwatkins@iland.net] > > > Sent: Tuesday, April 27, 1999 4:46 PM > > > To: usr-tc@lists.xmission.com > > > Subject: (usr-tc) Dedicated Dial-Up > > > > > > > > > We have 2 dedicated dial-up customers that > > > I'm having problems setting up properly. > > > We are using a USRTC, Quad modem cards, > > > and HiPer ARC. I'm having their IP addresses > > > assigned to them via Radius, and 2 channels > > > of that CT1 are pulled out of the hunt and > > > have their own phone number. The problem is > > > this. I have an IP address pool set to use > > > 46 IP addresses, with a range of 123.123.123.1- > > > 123.123.123.46 The static IP addresses our > > > dedicated customers get are .47 and .48 With > > > this configuration since the interfaces they > > > connect to are in the modem_group all, the > > > USRTC thinks that when our dedicated customer > > > dials in that it uses 2 addresses from that IP > > > pool. When that chassis is full users are > > > unable to connect to two ports because it already > > > thinks two addresses are being used..... confusing > > > eh?? > > > > > > So my question is this, could I delete > > > then re-create the modem_group all -those two > > > interfaces, and assign those two interfaces > > > their own IP address pool size (2), and create > > > their own modem_group? Or am I making this > > > WAY too hard on myself??? > > > > > > TIA > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > Jason Watkins, jwatkins@iland.net > > > I-Land NOC Technician > > > http://www.iland.net > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) TC chassis not taking incoming calls on part of T1 span
From: ispcnsl001@aol.com
Date: 1999-04-27 18:46:19
In a message dated 4/27/99 1:51:08 PM US Eastern Standard Time, db3l@ans.net writes: > Yes, there was a problem in this regard in the 4.2.x series that > toggling the jitter attenuation could correct. The card would > incorrectly latch AB bit patterns during a bootup (and or fall into > that mode) which would affect its ability to process calls. > > The jitter attenuation toggling is just a workaround in that it gives > the AB bits as perceived by the card a "kick", but the underlying > problem isn't with the jitter attenuation itself. The problem resides in the Hardware. The lucent framer to be exact. The ER code is a work around. > > > After looking at the card again as I was writing this, are you positive > > on the numbering? I'm showing 4.3.99 is what was given to me and since > > that has happened (well over a year ago now) the card has performed > > without troubles. > > I'm not sure about 4.3.99 but 4.2.99 was originally built for us back > in 3/98 in response to this problem during TCS 3.1 testing (among > other items) off of a 4.2.1 base, and it did address this sort of > problem. Hope they didn't reintroduce the problem in the 4.3.x series >
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-27 19:55:36
On Tue, 27 Apr 1999, Aaron Nabil wrote: > Tatai SV Krishnan writes... > > . . . > >Now we received information from customers regarding users password > >getting corrupted. Some of you had radius logs which showed that the > >users password was getting corrupted. > > > >The users password from the showed that the last charecter of the > >password had some some control charecters like ]}# etc. This particular > >problem is not consistant and cannot be reproduced on demand. > > I don't think *I* said that, and I'm the one who (re-)reported it recently > and verified the workaround. > > I can gaurantee we have at _least_ one user who this occurs for on > _every_ call. We used that particular user to troubleshoot with and > to the try various possible fixes including disabling ppp offloading. Here is my number 847-342-6345 - Call me when you have the user ready to dial. I would need access to your hiper arc / or your user should be able to dial long distance to our chassis. Call me when every you are ready, if you get to VM - you can call my cell (number is on the VM) else page me at pager@bubba.ae.usr.com Krish > > We tried capturing the session using a syslog tap as described in > the documentation. It didn't work, nothing was captured. > > -- > Aaron Nabil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Dedicated Dial-Up
From: Brian <signal@shreve.net>
Date: 1999-04-27 20:16:45
On Tue, 27 Apr 1999, Jason W. wrote: > I'm actually assigning their IP addresses via > Radius now. What happens is that even though > I have the PI address set to 46 addresses, > when the dedicated customer dials in they > are basically a "default" user which is using > the "modem_group all" So the PI pool thinks > that the dedicated user is using a proper > IP address and increments the number of > addresses used by 2. So if our USRTC is > almost full and 2 users try to dial into > the last available ports they cannot because > the PI pool thinks it has no more addresses > to assign... Shouldn't the ARC be intuitive > enough to know that those addresses are > not part of the pool and thus not increment > the size of the used IP pool??? show us the RADIUS config for the user. > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > Jason Watkins, jwatkins@iland.net > I-Land NOC Technician > http://www.iland.net > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > ----- Original Message ----- > From: Scott Trautman <scottt@corp.gdinet.com> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, April 27, 1999 5:00 PM > Subject: RE: (usr-tc) Dedicated Dial-Up > > > > Way too hard. Assign them static addresses in Radius completely out of > your > > pool. > > Pool is for random assignment only. You'll only give yourself grief trying > > to pick the pool. > > > > SMT > > > > > -----Original Message----- > > > From: Jason W. [mailto:jwatkins@iland.net] > > > Sent: Tuesday, April 27, 1999 4:46 PM > > > To: usr-tc@lists.xmission.com > > > Subject: (usr-tc) Dedicated Dial-Up > > > > > > > > > We have 2 dedicated dial-up customers that > > > I'm having problems setting up properly. > > > We are using a USRTC, Quad modem cards, > > > and HiPer ARC. I'm having their IP addresses > > > assigned to them via Radius, and 2 channels > > > of that CT1 are pulled out of the hunt and > > > have their own phone number. The problem is > > > this. I have an IP address pool set to use > > > 46 IP addresses, with a range of 123.123.123.1- > > > 123.123.123.46 The static IP addresses our > > > dedicated customers get are .47 and .48 With > > > this configuration since the interfaces they > > > connect to are in the modem_group all, the > > > USRTC thinks that when our dedicated customer > > > dials in that it uses 2 addresses from that IP > > > pool. When that chassis is full users are > > > unable to connect to two ports because it already > > > thinks two addresses are being used..... confusing > > > eh?? > > > > > > So my question is this, could I delete > > > then re-create the modem_group all -those two > > > interfaces, and assign those two interfaces > > > their own IP address pool size (2), and create > > > their own modem_group? Or am I making this > > > WAY too hard on myself??? > > > > > > TIA > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > Jason Watkins, jwatkins@iland.net > > > I-Land NOC Technician > > > http://www.iland.net > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) DI5601 Connect Problems
From: Beth Pullen <john1@execpc.com>
Date: 1999-04-27 20:16:55
Dear Jeff, I have had similar problems with my 5601 and my local ISP Execpc.com. They apparently use Us Robotics hardware and modems. Modem Blaster's Tech-people have suggested to try the following fixes which I have not had a chance to try myself yet. +MS=12,1,300,56000,0,0 or &F&C1&D2+MS=12,1,300,56000,0,0 good luck, Let me know if it helps. john1@execpc.com
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Brian <signal@shreve.net>
Date: 1999-04-27 20:18:22
> We tried capturing the session using a syslog tap as described in > the documentation. It didn't work, nothing was captured. It may have been captured. Check the facility that the ARC logs too, and it may have gone there. Thats what happens for me (TAP info is logged to the arc's facility rather than the tap users facility). I would say that this happens on the order of 100+ times a day, I don't see why its not reproducable. > > -- > Aaron Nabil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: Re: (usr-tc) Dedicated Dial-Up
From: Jason Watkins <jwatkins@iland.net>
Date: 1999-04-27 20:27:55
We are currently using ESVA (getting ready to implement Radiator) Below is a copy of the dedicated user's entry in the users file. user Password = "UNIX", Sessions = 1 User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 123.123.123.48, Framed-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1500 When he dials in he gets his static ip. But for some reason the HiPer ARC increments the ip pool by one when he connects. Thanks for all your help people! ----- Original Message ----- Sent: Tuesday, April 27, 1999 8:16 PM > On Tue, 27 Apr 1999, Jason W. wrote: > > > I'm actually assigning their IP addresses via > > Radius now. What happens is that even though > > I have the PI address set to 46 addresses, > > when the dedicated customer dials in they > > are basically a "default" user which is using > > the "modem_group all" So the PI pool thinks > > that the dedicated user is using a proper > > IP address and increments the number of > > addresses used by 2. So if our USRTC is > > almost full and 2 users try to dial into > > the last available ports they cannot because > > the PI pool thinks it has no more addresses > > to assign... Shouldn't the ARC be intuitive > > enough to know that those addresses are > > not part of the pool and thus not increment > > the size of the used IP pool??? > > > show us the RADIUS config for the user. > > > > > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > Jason Watkins, jwatkins@iland.net > > I-Land NOC Technician > > http://www.iland.net > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > ----- Original Message ----- > > From: Scott Trautman <scottt@corp.gdinet.com> > > To: <usr-tc@lists.xmission.com> > > Sent: Tuesday, April 27, 1999 5:00 PM > > Subject: RE: (usr-tc) Dedicated Dial-Up > > > > > > > Way too hard. Assign them static addresses in Radius completely out of > > your > > > pool. > > > Pool is for random assignment only. You'll only give yourself grief trying > > > to pick the pool. > > > > > > SMT > > > > > > > -----Original Message----- > > > > From: Jason W. [mailto:jwatkins@iland.net] > > > > Sent: Tuesday, April 27, 1999 4:46 PM > > > > To: usr-tc@lists.xmission.com > > > > Subject: (usr-tc) Dedicated Dial-Up > > > > > > > > > > > > We have 2 dedicated dial-up customers that > > > > I'm having problems setting up properly. > > > > We are using a USRTC, Quad modem cards, > > > > and HiPer ARC. I'm having their IP addresses > > > > assigned to them via Radius, and 2 channels > > > > of that CT1 are pulled out of the hunt and > > > > have their own phone number. The problem is > > > > this. I have an IP address pool set to use > > > > 46 IP addresses, with a range of 123.123.123.1- > > > > 123.123.123.46 The static IP addresses our > > > > dedicated customers get are .47 and .48 With > > > > this configuration since the interfaces they > > > > connect to are in the modem_group all, the > > > > USRTC thinks that when our dedicated customer > > > > dials in that it uses 2 addresses from that IP > > > > pool. When that chassis is full users are > > > > unable to connect to two ports because it already > > > > thinks two addresses are being used..... confusing > > > > eh?? > > > > > > > > So my question is this, could I delete > > > > then re-create the modem_group all -those two > > > > interfaces, and assign those two interfaces > > > > their own IP address pool size (2), and create > > > > their own modem_group? Or am I making this > > > > WAY too hard on myself??? > > > > > > > > TIA > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > Jason Watkins, jwatkins@iland.net > > > > I-Land NOC Technician > > > > http://www.iland.net > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Answer Supervision on DSPs - BUG
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-04-27 23:31:24
FYI for everyone... (Krish - when you see this - please check to make sure it's in the bug tracking system - worked with Fred Daneu, George Ebert, and Mohi in your dept.) After working with our local telco for three weeks, we found out that they turned on NMD in the 5E which requires answer supervision to be done properly. Extensive testing proved that the DSP's do not do answer supervision properly if DNIS is turned off. If DNIS is turned on, then answer supervision is done properly. In the very same trunk group with quads and dual t1 cards, we did not have this problem with DNIS turned off. This problem has already been reported to 3Com via two different fronts, though it has not yet (as we can tell) made it to the weekly field engineering reports. Answer supervision is what allows the switch to know that the CPE has received and accepted the call and is usually used for billing purposes. NMD is a feature which if the other end does not answer (or in our case do answer supervision), the switch takes the call back and then plays a recorded message to the customer asking them if they want to have the switch try to complete the call for them at a later time. We are *STILL* having other compatability problems with the DSP's that don't seem to be showing up in the quads. More on this later. Kevin Benton Sr. Network Engineer SOTA Technologies E-Mail: s1kevin@tims.net Web: http://www.users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice
Subject: Re: (usr-tc) Dedicated Dial-Up
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-28 07:22:31
On Tue, 27 Apr 1999, Jason Watkins wrote: > We are currently using ESVA (getting ready to > implement Radiator) Below is a copy of the dedicated > user's entry in the users file. > > user Password = "UNIX", > Sessions = 1 > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 123.123.123.48, > Framed-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-MTU = 1500 > > > When he dials in he gets his static ip. But for some > reason the HiPer ARC increments the ip pool by > one when he connects. Thanks for all your help > people! > Do you have hint assigned enabled? krish > > ----- Original Message ----- > From: Brian <signal@shreve.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, April 27, 1999 8:16 PM > Subject: Re: (usr-tc) Dedicated Dial-Up > > > > On Tue, 27 Apr 1999, Jason W. wrote: > > > > > I'm actually assigning their IP addresses via > > > Radius now. What happens is that even though > > > I have the PI address set to 46 addresses, > > > when the dedicated customer dials in they > > > are basically a "default" user which is using > > > the "modem_group all" So the PI pool thinks > > > that the dedicated user is using a proper > > > IP address and increments the number of > > > addresses used by 2. So if our USRTC is > > > almost full and 2 users try to dial into > > > the last available ports they cannot because > > > the PI pool thinks it has no more addresses > > > to assign... Shouldn't the ARC be intuitive > > > enough to know that those addresses are > > > not part of the pool and thus not increment > > > the size of the used IP pool??? > > > > > > show us the RADIUS config for the user. > > > > > > > > > > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > Jason Watkins, jwatkins@iland.net > > > I-Land NOC Technician > > > http://www.iland.net > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > > ----- Original Message ----- > > > From: Scott Trautman <scottt@corp.gdinet.com> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, April 27, 1999 5:00 PM > > > Subject: RE: (usr-tc) Dedicated Dial-Up > > > > > > > > > > Way too hard. Assign them static addresses in Radius completely out of > > > your > > > > pool. > > > > Pool is for random assignment only. You'll only give yourself grief > trying > > > > to pick the pool. > > > > > > > > SMT > > > > > > > > > -----Original Message----- > > > > > From: Jason W. [mailto:jwatkins@iland.net] > > > > > Sent: Tuesday, April 27, 1999 4:46 PM > > > > > To: usr-tc@lists.xmission.com > > > > > Subject: (usr-tc) Dedicated Dial-Up > > > > > > > > > > > > > > > We have 2 dedicated dial-up customers that > > > > > I'm having problems setting up properly. > > > > > We are using a USRTC, Quad modem cards, > > > > > and HiPer ARC. I'm having their IP addresses > > > > > assigned to them via Radius, and 2 channels > > > > > of that CT1 are pulled out of the hunt and > > > > > have their own phone number. The problem is > > > > > this. I have an IP address pool set to use > > > > > 46 IP addresses, with a range of 123.123.123.1- > > > > > 123.123.123.46 The static IP addresses our > > > > > dedicated customers get are .47 and .48 With > > > > > this configuration since the interfaces they > > > > > connect to are in the modem_group all, the > > > > > USRTC thinks that when our dedicated customer > > > > > dials in that it uses 2 addresses from that IP > > > > > pool. When that chassis is full users are > > > > > unable to connect to two ports because it already > > > > > thinks two addresses are being used..... confusing > > > > > eh?? > > > > > > > > > > So my question is this, could I delete > > > > > then re-create the modem_group all -those two > > > > > interfaces, and assign those two interfaces > > > > > their own IP address pool size (2), and create > > > > > their own modem_group? Or am I making this > > > > > WAY too hard on myself??? > > > > > > > > > > TIA > > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > Jason Watkins, jwatkins@iland.net > > > > > I-Land NOC Technician > > > > > http://www.iland.net > > > > > \\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\ > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages > send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Answer Supervision on DSPs - BUG
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-28 07:26:12
On Tue, 27 Apr 1999, Kevin Benton wrote: > FYI for everyone... > > (Krish - when you see this - please check to make sure it's in the bug > tracking system - worked with Fred Daneu, George Ebert, and Mohi in your > dept.) Mohi has to escalate the case (if its not already done) - then a NSE from the DSP group has to identify the bug - thats when a bug is entered. Send me the ticket number and will have a talk with Mohi - krish > > After working with our local telco for three weeks, we found out that they > turned on NMD in the 5E which requires answer supervision to be done > properly. Extensive testing proved that the DSP's do not do answer > supervision properly if DNIS is turned off. If DNIS is turned on, then > answer supervision is done properly. In the very same trunk group with > quads and dual t1 cards, we did not have this problem with DNIS turned > off. This problem has already been reported to 3Com via two different > fronts, though it has not yet (as we can tell) made it to the weekly field > engineering reports. > > Answer supervision is what allows the switch to know that the CPE has > received and accepted the call and is usually used for billing purposes. > NMD is a feature which if the other end does not answer (or in our case do > answer supervision), the switch takes the call back and then plays a > recorded message to the customer asking them if they want to have the > switch try to complete the call for them at a later time. > > We are *STILL* having other compatability problems with the DSP's that > don't seem to be showing up in the quads. More on this later. > > Kevin Benton > Sr. Network Engineer > SOTA Technologies > > E-Mail: s1kevin@tims.net > Web: http://www.users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) 4.1.59-6 hosing passwords
From: Andre Gustavo de Carvalho Albuquerque <gustavo@visualnet.com.br>
Date: 1999-04-28 10:09:38
----- Original Message -----=20 Sent: Wednesday, April 28, 1999 12:45 AM > Tatai SV Krishnan writes... ... > I can gaurantee we have at _least_ one user who this occurs for on > _every_ call. We used that particular user to troubleshoot with and > to the try various possible fixes including disabling ppp offloading. >=20 > We tried capturing the session using a syslog tap as described in=20 > the documentation. It didn't work, nothing was captured. >=20 I know it may seem quite obvious but have you started syslogd with -r option? Regards,=20 Gustavo Albuquerque
Subject: (usr-tc) cheat sheet for command line config
From: zip-usrtc@ran.zipcon.net
Date: 1999-04-28 13:53:57
Does anyone know of a cheat sheet for command line config of the Hiper ARC, DSP, and NMC? I'm just about to bring online my first USR-TC. Thanks for any info, Dan
Subject: (usr-tc) FS: TOTAL CONTROL CHASSIS
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-04-28 15:14:53
For Wednesday: Just received in (1) Total Control Unit (15) Quad Analog/Digital Modems with analog nic cards Netserver Card w/ token ring nic Net Management Card w/token ring nic (2) AC PSU45 Cards external fan tray chassis First $3,200 Please private e-mail if you are interested. Can ship immediately DOA Warranty Credit Cards accepted. With Warmest Regards, Andrew Shlensky **************************** PC Global, Incorporated (305) 667-2111 TEL (305) 667-3636 FAX URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089
Subject: (usr-tc) VPN's revisited
From: Brian <signal@shreve.net>
Date: 1999-04-28 15:43:22
I posted a while back asking if anyone had gotten VPN functionality between HiperARC->Linux, and it didn't seem anyone had tried it. I have tried, but have been unsuccessfull. The configuration I am using is: joeblow Auth-Type = "Unix-PW" Service-Type = "Framed-User", Framed-Protocol = "PPP", Framed-IP-Address = "255.255.255.254", Framed-Netmask = "255.255.255.255", Framed-MTU = "1500", Max-Channels = "1", Framed-Routing = "None", Framed-Compression = "Van-Jacobson-TCP-IP", Tunnel-Type = "PPTP", Tunnel-Server-Endpoint = "208.206.76.27" The Tunnel Server Endpoint, is the IP of a linux box, running PPTPD, as follows: pptpd --localip 208.206.76.27 --remoteip 208.206.76.71 (that remote ip, is the ip of the hiperarc the user is dialing into) This all seems like it *should* work, but it doesn't. I am going to try and gather some debug info, but wanted to know if anyone had success with this as of yet? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
Subject: (usr-tc) FS: TOTAL CONTROL CHASSIS
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-04-28 15:57:13
OK Ill meet or beat anyones price on these......... For Wednesday: Just received in (1) Total Control Unit (15) Quad Analog/Digital Modems with analog nic cards Netserver Card w/ token ring nic Net Management Card w/token ring nic (2) AC PSU45 Cards external fan tray chassis Please private e-mail if you are interested. Can ship immediately DOA Warranty Credit Cards accepted. With Warmest Regards, Andrew Shlensky **************************** PC Global, Incorporated (305) 667-2111 TEL (305) 667-3636 FAX URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 ____________ =95 The ISP-EQUIPMENT Discussion 4Sale/WTB List =95 ________= ____ To Remove, Send An Email To: mailto:remove-isp-equipment@isp-equipment.co= m To Join, Send An Email To: mailto:join-isp-equipment@isp-equipment.com Comdisco is a leading provider of equipment & services to emerging businesses. Secure new or used equipment from Comdisco via flexible leasing options or purchase. http://www.comdisco.com/promo/isp_equip.cfm
Subject: (usr-tc) Netserver64 failure codes
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-04-28 16:01:58
I get these messages in my syslog (sampling): Apr 28 15:52:06 xxxxx S61 didn't get online! status=-1, connect_fail=3, link_fail=3 Apr 28 15:53:45 xxxxx S7 didn't get online! status=-1, connect_fail=3, link_fail=3 Apr 28 15:54:10 xxxxx S7 didn't get online! status=-1, connect_fail=3, link_fail=3 Apr 28 15:54:17 xxxxx S9 didn't get online! status=-1, connect_fail=36, link_fail=31 Apr 28 15:54:21 xxxxx S23 didn't get online! status=-1, connect_fail=79, link_fail=31 Apr 28 15:55:32 xxxxx S32 didn't get online! status=-1, connect_fail=31, link_fail=25 Apr 28 15:56:25 xxxxx S23 didn't get online! status=-1, connect_fail=79, link_fail=31 Over time have figured out that connect_fail=3, link_fail=3 can either mean a user with a stinky modem, or our modem has gone mashuga. We basically look for a pattern of failures on a port over time to identify bad modems on our end. Anyone ever seen a listing of these different codes and what they might mean? I scoured 3Com's knowledgebase, the Netserver guide, nothing. SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718
Subject: (usr-tc) Pros and Cons
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-28 16:03:25
OK, folks...here we go... Let's here the pros and cons of event logging from NMC's via RADIUS, and via SNMP traps (or perhaps even both?) Let's start with general pros and cons of each... Also, if anyone is doing logging through these methods (either or both), and would like to contribute code, I'd be interested in looking through some of that and perhaps making use of some. :) Or perhaps I can contribute some expertise with other's in improving your code. Anyway...I'm looking at some of the logging stuff with the NMC's and it looks like there's quite a lot of information and I'm looking at trying to find the best way to make that information available to our tech support folks. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) stop acct. packets
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-28 16:08:21
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Angela A. Burford |Sent: Wednesday, April 28, 1999 3:59 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) stop acct. packets | | | | |My HARC is running code version 4.1.78 and still presents the problem of |not sending stop accounting packets once in a while. Has this been fixed |in version 4.1.59-6, or any other version? Yes.. Fixed since 4.1.72... -M
Subject: (usr-tc) stop acct. packets
From: Angela A. Burford <aratis@erie.net>
Date: 1999-04-28 16:58:30
My HARC is running code version 4.1.78 and still presents the problem of not sending stop accounting packets once in a while. Has this been fixed in version 4.1.59-6, or any other version? TIA Angela
Subject: Re: (usr-tc) cheat sheet for command line config
From: Ricky Beam <jfbeam@beaker.interpath.net>
Date: 1999-04-28 17:12:02
On 28 Apr 1999 zip-usrtc@ran.zipcon.net wrote: >Does anyone know of a cheat sheet for command line config of the Hiper >ARC, DSP, and NMC? I'm just about to bring online my first USR-TC. >Thanks for any info, Dan http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup (until they get around to reclaiming the drive space :-)) --Ricky
Subject: (usr-tc) 3- Netserver 16I Plus
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-28 17:15:24
3 units avilable now. In NEW condition, complete in original box, with all documentation. Including non-registered factroy warranty card. They are the PLUS Version :) Looking for buyers Steve Rivera - sales@wrca.net - 732-833-2111 http://www.wrca.net De-installed Net Hardware Wanted: WTB: Cisco 2501, 2511, Ascend Max4000 Chassis, MXSL-16MOD-L56, '''''''''''''''''''''''''''''''''''''''''''''''
Subject: RE: (usr-tc) stop acct. packets
From: vanhalen@coredcs.com
Date: 1999-04-29 08:23:18
On Thu, 29 Apr 1999, Angela A. Burford wrote: > Just got the explanation of why stop accounting packets are not > working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!) > Usr got the version numbers mixed up! > > Thanks for the help > Angela > Nope, that's their numbering scheme. Steve
Subject: RE: (usr-tc) stop acct. packets
From: Angela A. Burford <aratis@erie.net>
Date: 1999-04-29 09:09:34
Just got the explanation of why stop accounting packets are not working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!) Usr got the version numbers mixed up! Thanks for the help Angela On Wed, 28 Apr 1999, Mike Wronski wrote: > |My HARC is running code version 4.1.78 and still presents the problem of > |not sending stop accounting packets once in a while. Has this been fixed > |in version 4.1.59-6, or any other version? > > Yes.. Fixed since 4.1.72... > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) stop acct. packets
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-04-29 09:19:18
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Angela A. Burford |Sent: Thursday, April 29, 1999 8:10 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) stop acct. packets | | |Just got the explanation of why stop accounting packets are not |working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!) |Usr got the version numbers mixed up! Not mixed up.. But Im not going into it here.. Its been beaten down already :). If your still confused about the version numbers.. Search the archives.. -M
Subject: Re: (usr-tc) stop acct. packets
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-04-29 09:27:53
Thus spake Angela A. Burford >Just got the explanation of why stop accounting packets are not >working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!) >Usr got the version numbers mixed up! No, they're not mixed up...screwed up, yes, but not mixed up. Engineering Releases and Service Releases start at x.x.99 and count down rather than up. So, 4.1.78 is older than 4.1.72 which is itself older than 4.1.59. You *probably* should upgrade to 4.1.59 as there are quite a few fixes in there from 4.1.72. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) cheat sheet for command line config
From: John Schmerold <john@katy.com>
Date: 1999-04-29 10:47:37
Thanks. I sure wish 3COM would offer this information. At 04:12 PM 4/28/99 -0500, you wrote: >On 28 Apr 1999 zip-usrtc@ran.zipcon.net wrote: >>Does anyone know of a cheat sheet for command line config of the Hiper >>ARC, DSP, and NMC? I'm just about to bring online my first USR-TC. >>Thanks for any info, Dan > >http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup > >(until they get around to reclaiming the drive space :-)) > >--Ricky > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. John Schmerold Katy Computer Systems, Inc. 20 Meramec Station Rd Valley Park, MO 63088 314-316-9000 v 314-316-9200 f email: john@katy.com
Subject: Re: (usr-tc) stop acct. packets
From: Angela A. Burford <aratis@erie.net>
Date: 1999-04-29 11:13:09
I wish *all* their tech support people knew this! Good thing i have this list... angela On Thu, 29 Apr 1999, Jeff Mcadams wrote: > Thus spake Angela A. Burford > >Just got the explanation of why stop accounting packets are not > >working in 4.1.78... It came before 4.1.72, the 1st fixed version. (!!) > >Usr got the version numbers mixed up! > > No, they're not mixed up...screwed up, yes, but not mixed up. > Engineering Releases and Service Releases start at x.x.99 and count down > rather than up. So, 4.1.78 is older than 4.1.72 which is itself older > than 4.1.59. You *probably* should upgrade to 4.1.59 as there are quite > a few fixes in there from 4.1.72. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) WTB Total Control USR/3COM Server card EdgeServer Pro
From: access1 <access1@simplyweb.net>
Date: 1999-04-29 11:49:06
WTB USR/3COM's Server-on-a-card solution, the EdgeServer Pro for the Total Conrtol Chassis, with or without NT 4.0. Looking for surplus or used unit at good price. May consider older EdgeServer -non "Pro" model if set up with 3rd party software to accomodate RADIUS and NT 4.0
Subject: (usr-tc) Farewell
From: MegaZone <megazone@megazone.org>
Date: 1999-04-29 16:25:17
I've been a member of this list (aka a nuisance) for several years now - but I've decided to unsub. I don't work directly with NASen anymore, and I've been looking at my life and decided I'd rather do other things with my time than keep up with everything in the NAS world. Days pass fast enough as it is. :-) But I've enjoyed the exchanges here over these past years, and I wanted to thank everyone for their opinions, help, and kindness. Thanks, take care. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: (usr-tc) HDSP uptime in TCM ?
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-04-29 17:23:52
Is there a way to get the uptime of a HDSP in TCM ? I browsed through the MIB but didn't find anything... I can get it through the CLI though... Thanks Robert
Subject: Re: (usr-tc) WTB Total Control USR/3COM Server card EdgeServer
From: Steve Rivera <sales@wrca.net>
Date: 1999-04-30 10:10:09
I have a edgeserver acrd :) It is not a PRO series. Brand new in the box with NT4.0 Asking $3500 At 11:49 AM 4/29/99 -0700, you wrote: >WTB USR/3COM's Server-on-a-card solution, the EdgeServer Pro for the >Total Conrtol Chassis, with or without NT 4.0. Looking for surplus or >used unit at good price. May consider older EdgeServer -non "Pro" model >if set up with 3rd party software to accomodate RADIUS and NT 4.0 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) USR TC w/Hiper ARC
From: C Thompson <cthompson@wingnet.net>
Date: 1999-04-30 12:13:34
We are looking at the possiblity of selling one of our USR/3com Total Control racks. Specs are as follows: Rackmount chassis Integrated fan tray 1 70 amp PS 1 Network Management Card with memory upgrade 1 Dual PRI/T1 card 12 digital/analog quad modem cards (48 ports) X2/V.90 already in place and functional on hardware 1 Hiper ARC card (relatively NEW) Asking price = around $6995 Contact me if interested, or if you wish to register a bid. We will implement your IP address on the NMC and/or HARC to make configuration easier once you receive the unit. Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Thought for the day: Hope deferred maketh the heart sick, but when the desire cometh, it is a tree of life. (Prov. 13:12)
Subject: (usr-tc) Moving on
From: David Bolen <db3l@ans.net>
Date: 1999-04-30 14:27:09
Originally I figured this might be too presumptuous to send to the list at large, but then I figured it's been over three years of communicating with many of the folks here (4 if you count the older USRTC listserv list) so I figured a quick note couldn't hurt. And then MegaZone went and beat me to the punch by a few minutes. Sort of an interesting quirk of fate, although I guess Friday and end of month is just a nice day :-) For myself, I'm going to be moving on from ANS (never did get used to thinking of us as UUNET :-)) to new and bigger things, which as it happens won't involve NASen and dialup infrastructure, so I'll be unsubscribing from this list. I have to say that I think this list has shown itself to have one of the highest signal to noise ratios of the various forums that I follow, which has made it a pleasure to participate in as well as use as a resource over the years. And that's a credit to everyone participating on the list. So best of luck to everyone. I may be stepping away from building the dial infrastructure, but I'll likely be back on the consumer side, so keep those networks running at peak performance! -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) 3com VSA 0x9841
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-04-30 15:52:16
MP-EDO-HIPER 0x9841 string krish On Fri, 30 Apr 1999, Jesse Sipprell wrote: > Can anyone tell me what 3com/USR's 0x9841 VSA is? My radius server keeps > getting an attribute with this value, yet I don't have it in my dictionary. > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Does NOT support IP
From: John Mies <jmies@advancenet.net>
Date: 1999-04-30 16:16:42
--=====================_16259550==_.ALT Content-Type: text/plain; charset="us-ascii" Anyone know what this message means? New PPP Call received on interface slot:1/mod:10 PPP - Authentication Complete to spooky75. Peer PPP at spooky75 Does NOT support IP, DISABLING. (IPCP) Layer Down for Bundle 5885, Link 20829360, to spooky75. I walked the customer through her TCP/IP settings blah blah and everything should be OK on her side...she did have a weird external modem, tho... --=====================_16259550==_.ALT Content-Type: text/html; charset="us-ascii" <html> Anyone know what this message means?<br> <br> <font face="Helvetica, Helvetica">New PPP Call received on interface slot:1/mod:10<br> PPP - Authentication Complete to spooky75.<br> Peer PPP at spooky75 Does NOT support IP, DISABLING.<br> (IPCP) Layer Down for Bundle 5885, Link 20829360, to spooky75.<br> <br> </font>I walked the customer through her TCP/IP settings blah blah and everything should be OK on her side...she did have a weird external modem, tho...</html> --=====================_16259550==_.ALT--
Subject: (usr-tc) 3com VSA 0x9841
From: Jesse Sipprell <jss@evcom.net>
Date: 1999-04-30 16:19:19
Can anyone tell me what 3com/USR's 0x9841 VSA is? My radius server keeps getting an attribute with this value, yet I don't have it in my dictionary. Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *
Subject: Re: (usr-tc) Moving on
From: Al Huefner <al_huefner@mw.3com.com>
Date: 1999-04-30 16:23:49
David, on behalf of 3Com, we wish you the best of luck and thanks for your excellent support on this forum. You have always been very helpful and very professional. We wish you the best in whatever you choose to do. You will be missed. - Al Huefner VP Carrier Customer Services 3Com Corporation David Bolen <db3l@ans.net> on 04/30/99 01:27:09 PM Please respond to usr-tc@lists.xmission.com Sent by: David Bolen <db3l@ans.net> cc: (Al Huefner/MW/US/3Com) Originally I figured this might be too presumptuous to send to the list at large, but then I figured it's been over three years of communicating with many of the folks here (4 if you count the older USRTC listserv list) so I figured a quick note couldn't hurt. And then MegaZone went and beat me to the punch by a few minutes. Sort of an interesting quirk of fate, although I guess Friday and end of month is just a nice day :-) For myself, I'm going to be moving on from ANS (never did get used to thinking of us as UUNET :-)) to new and bigger things, which as it happens won't involve NASen and dialup infrastructure, so I'll be unsubscribing from this list. I have to say that I think this list has shown itself to have one of the highest signal to noise ratios of the various forums that I follow, which has made it a pleasure to participate in as well as use as a resource over the years. And that's a credit to everyone participating on the list. So best of luck to everyone. I may be stepping away from building the dial infrastructure, but I'll likely be back on the consumer side, so keep those networks running at peak performance! -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: Re: (usr-tc) Does NOT support IP
From: Frank Basso <frank@got.net>
Date: 1999-04-30 16:30:35
This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01BE9326.C6250DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks like a windows box sending you IPX or NetBEUI instead of TCP/IP ----- Original Message -----=20 From: John Mies=20 To: usr-tc@xmission.com=20 Sent: Friday, April 30, 1999 2:16 PM Subject: (usr-tc) Does NOT support IP Anyone know what this message means? New PPP Call received on interface slot:1/mod:10 PPP - Authentication Complete to spooky75. Peer PPP at spooky75 Does NOT support IP, DISABLING. (IPCP) Layer Down for Bundle 5885, Link 20829360, to spooky75. I walked the customer through her TCP/IP settings blah blah and = everything should be OK on her side...she did have a weird external = modem, tho...=20 ------=_NextPart_000_00CA_01BE9326.C6250DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>Looks like a windows box sending you&nbsp;IPX = or&nbsp;NetBEUI=20 instead&nbsp;of TCP/IP</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:jmies@advancenet.net" = title=3Djmies@advancenet.net>John Mies</A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = href=3D"mailto:usr-tc@xmission.com"=20 title=3Dusr-tc@xmission.com>usr-tc@xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 30, 1999 = 2:16=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) Does NOT = support=20 IP</DIV> <DIV><BR></DIV>Anyone know what this message means?<BR><BR><FONT=20 face=3D"Helvetica, Helvetica">New PPP Call received on interface=20 slot:1/mod:10<BR>PPP - Authentication Complete to spooky75.<BR>Peer = PPP at=20 spooky75 Does NOT support IP, DISABLING.<BR>(IPCP) Layer Down for = Bundle 5885,=20 Link 20829360, to spooky75.<BR><BR></FONT>I walked the customer = through her=20 TCP/IP settings blah blah and everything should be OK on her = side...she did=20 have a weird external modem, tho... </BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_00CA_01BE9326.C6250DB0--
« March 1999May 1999 »
USR Total Control Mailing List Archive · Messages from 1995–2001 · Generated from archived data