Subject:Re: (usr-tc) backing up Chassis files. From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-01-19 11:51:12
The "*.cfg" files contain configuration information for the router
application. In some cases, there are dependencies between the files, so
as a rule it is not safe to mix and match invididual config files. All of
the config files are created when you issue the "save all"
command. If you want to save your configuration off the box, I suggest
using the bulk configuration feature to package up the config
and then save it off. In general, you shouldn't need to save/restore
config files as they are modified only by doing a "save all".
NOTE: the "_quicksetup" command also issues a save all when complete.
Robo.stats - An internal statistics file generated by the system. Can be
safely removed, but will recreated on each save all.
app.ld - the compressed router application. Note that this MUST match the
installed kernel software on the card, or the image will
fail to load. In general, you should not save and restore
this file without doing a full software install.
atm.bin - executable for download the DS3 ATM NIC. Installed during
software install.
*.ind, *.str - Compressed strings and string index files files for the
router application, installed during software install.
-- Matt
Chris <helpchris@rconnect.com> on 01/19/99 08:47:21 AM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
Can anyone tell me what each of these files hold and which should be backed
up on a regular basis. Total Control Chassis. (You see them if you type:
list files).
Atmarp.cfg
CLI.cfg
CallInitProcess.cfg
Chassis.cfg
ConfigProcess.cfg
DNS.cfg
DialOutProcess.cfg
EventHandler.cfg
FilterMgr.cfg
IPForwarder.cfg
IpRterProcess.cfg
L2tpProcess.cfg
MPIPProcess.cfg
Ntp.cfg
PilgrimStrings.ind
PilgrimStrings.str
PingProcess.cfg
PppProcess.cfg
PptpProcess.cfg
QuickSetup.cfg
RemotePingProcess.cfg
Robo.stats
RoboExecNMProcess.cfg
RoboString.ind
RoboString.str
SlipProcess.cfg
SnmpProcess.cfg
TcpProcess.cfg
TermProt.cfg
TftpProcess.cfg
TracerouteProcess.cfg
app.ld
atm.bin
bspman.cfg
user_settings.cfg
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
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) HiperARC for Sale From: Bill Tidwell <bill@dscga.com> Date: 1999-01-19 19:08:13
Anyone need a 3com HiperARC card? Selling for $4k OBO or
trading 1-2 for HiperDSP! ;)
Bill Tidwell
770-455-9022
Digital Service Consultants, Inc. 770-455-9022
ISDN 64K-512K, Frame Relay, T1, ADSL, and Colocation.
QUALITY Internet SERVICE Provider http://www.dscga.com
Subject:(usr-tc) Help on upgrading token ring Net Server From: Mark Ross <mark@apu.ccis.com> Date: 1999-01-21 11:46:15
Does any one know of any problems upgrading to 3.7.4 Net server for token
ring ?
Is the 69-000209-00 TR NIC not compatable with newer software and the
69-001369-00 NAC ?
The release notes talk about using a 69-001827-00 TR NIC, does anyone know
if this is mandatory ?
thanks
Subject:(usr-tc) netserver ping problem From: Steve McConnell <stevem@emji.net> Date: 1999-01-25 16:53:51
We have a netserver chassis running 3.8.1 that I have recently moved to
another location.
People can dial in just fine, and surf fine as well. but now I can not
ping them from the network, nor can I ping them from the netserver itself.
This worked before, so it is obviously something that I did, but I am
unable to find it:
here is a sh glo (if that helps) Any ideas what I changed?
Telnet Access Port: 23 TCP Maximal Segment Size: 0
Assigned Address: 207.100.24.105 Reported Address: 0.0.0.0
Assigned Pool Size: 26 Periodic CHAP timeout: 5
PPP in modem: OFF SLIP in modem: OFF Packet bus clock:
SLAVE
ICMP error logging: OFF Connect message: OFF Dial !root access: OFF
Random hosts list: OFF SNMP: ON Proxy Arp: OFF
Response message: ON PPP message: ON Lan/Wan Routing: ON
RIP V2 Authen: OFF VPN Local Routing: OFF MPIP Server: OFF
Hint assigned: OFF Tap Login: OFF Syslog facility:
auth
Extd. IPXCP Opts: OFF Acct AuthChk: OFF/OFF Send DNS info: ON
DNS cache reset timeout: 0 days 0 hours 30 minutes (30 min)
Configured Ethernet media: Autodetect
Currently Active B-channels: 2 Maximum Active B-channels: 60
Command>
Thanks
steve
This is a multi-part message in MIME format.
------=_NextPart_000_0010_01BE4890.4550B440
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by vigil.pbmo.net id SAA07868
Scenerio:
Just installed a Netserver 16 running v4.1.7 (mar 16,98)
Some users dial into box and get authenticated (via Radius) and surf away
Other users get authenticated, get an IP address, but are dead in the wat=
er
-- If I try to ping the user, it times out on the Netserver BUT i see
traffic sent & received on both sides.
-- These "broken users" seem to be running either win98 or the updated DU=
N
driver on Win 95
Does anyone have a suggestion? I've got so many MAD users and I have no
ideas.
Thanks,
Brian Becker
=A0
Brian Becker
Poplar Bluff Internet, Inc.
=A0=A0=A0=A0 http://www.semo.net
Home of JP Bookstore
=A0=A0=A0=A0 http://www.JerusalemPerspective.com
And Webgabber Chat server
=A0=A0=A0=A0 http://www.webgabber.com
Personal Website
=A0=A0=A0=A0 http://www.Tonionio.com
=A0
------=_NextPart_000_0010_01BE4890.4550B440
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT size=3D2>
<P>Scenerio:</P>
<P>Just installed a Netserver 16 running v4.1.7 (mar 16,98)</P>
<P>Some users dial into box and get authenticated (via Radius) and surf =
away</P>
<P>Other users get authenticated, get an IP address, but are dead in the =
water</P>
<P>-- If I try to ping the user, it times out on the Netserver BUT i see =
traffic=20
sent & received on both sides.</P>
<P>-- These "broken users" seem to be running either win98 or =
the=20
updated DUN driver on Win 95</P>
<P>Does anyone have a suggestion? I've got so many MAD users and I have =
no=20
ideas.</P>
<P>Thanks,</P>
<P>Brian Becker</FONT></P></DIV></DIV>
<DIV> </DIV>
<P><FONT face=3DTahoma size=3D2>Brian Becker</FONT> <BR><FONT =
face=3DTahoma=20
size=3D2>Poplar Bluff Internet, Inc.</FONT> <BR><FONT face=3DTahoma=20
size=3D2> <A href=3D"http://www.semo.net/"=20
target=3D_blank>http://www.semo.net</A></FONT> <BR><FONT face=3DTahoma =
size=3D2>Home=20
of JP Bookstore</FONT> <BR><FONT face=3DTahoma =
size=3D2> <A=20
href=3D"http://www.jerusalemperspective.com/"=20
target=3D_blank>http://www.JerusalemPerspective.com</A></FONT> <BR><FONT =
face=3DTahoma size=3D2>And Webgabber Chat server</FONT> <BR><FONT =
face=3DTahoma=20
size=3D2> <A href=3D"http://www.webgabber.com/"=20
target=3D_blank>http://www.webgabber.com</A></FONT> <BR><FONT =
face=3DTahoma=20
size=3D2>Personal Website<BR> <A=20
href=3D"http://www.tonionio.com/" =
target=3D_blank>http://www.Tonionio.com</A></FONT>=20
</P>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0010_01BE4890.4550B440--
Everytime we attempt the comma trick the users can connect but no better
than a 1900 connection. Which is unaceptable. Anyother cures out there?
G. Owens
Magnolia Internet Services
-----Original Message-----
>One solution seems to be adding 2-3 commas after the phone # on the users
>dial-up adapter. Each comma represents a delay of .75 seconds, I think, and
>this gives the telecom switches time to react.
>
>At 02:34 PM 1/25/99 -0500, you wrote:
>> I've been running HiPer ARC 4.1.71/DSP 1.2.60 for about 5 weeks now with
>>no complaints from my users. Within the last few days I've started getting
>>complaints of "The modem you are dialing is not answering" problems
getting
>>connected. Nothing has changed at our end. Monitoring PPP on the ARC when
>>this occurs results in no information coming across, as if they've never
>>even hit a modem here, although the open modem does show up in <list
>>connections>. Could Bell Atlantic have changed anything with our PRI lines
>>that could be doing this?
>> I did have one customer that was able to get in fine after adding the
>>at&f init string, but it was a new customer so I'm not sure whether his
>>problem mirrored the others or not.
>>
>>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.
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
FYI -
I believe all the boards that come with twice the DRAM (128MB) also have
twice the flash (16Mb).
-- Matt
Robert von Bismarck <rvb@petrel.ch> on 01/27/99 02:58:45 AM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
Well, I'm perhaps a bit cisco-ish, but the first thing you run out of is
usually flash mem, as code, configs and filters get bigger and bigger,
and I personally like to have multiple code versions in my routers, in
case that I should downgrade in a hurry, (yeah tftp is cool, but if the
new code doesn't recognize your interfaces....) especially if they are
ER versions.
just my 0.02$
Robert
> -----Original Message-----
> From: Matt Harper [SMTP:Matt_Harper@mw.3com.com]
> Sent: mardi, 26. janvier 1999 22:49
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) HiperArc 128M vs 64M
>
> Currently, I don't think there are any limitations for 64Mb vs. 128Mb
> operation.
> In the future, certain service configurations may require the
> additional
> memory.
>
> If you have maxed out your chassis (15 spans), do a lot of PPP
> compression,
> have large OSPF routing tables,
> do a lot of IPX traffic, terminate large numbers of L2TP/PPTP sessions
> (>.5K), etc. the extra memory will help.
> Having the extra memory is really nice to protect you vs. ever
> increasing
> router code images & to eliminate costly on-site
> field upgrades.
>
> -- Matt
>
>
>
>
>
>
>
> "Randy Cosby" <dcosby@infowest.com> on 01/26/99 03:00:54 PM
>
> Please respond to usr-tc@lists.xmission.com
>
> To: usr-tc@lists.xmission.com
> cc: (Matt Harper/MW/US/3Com)
> Subject: (usr-tc) HiperArc 128M vs 64M
>
>
>
>
> I have a few HiperARC's, and some have 64Meg of RAM, some have 128.
> What
> limitations, if any, are there for the 64M version?
>
> Randy Cosby <dcosby@infowest.com>
> Vice President
> InfoWest Global Internet Services, Inc.
> (435)674-0165 http://www.infowest.com
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
>
>
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Is there a way to get a Cisco 1004 ISDN connection to a TC Hub using radius.
I can get it to connect only by defining the user on the chassis itself (a
pain since I have 12 chassis and have to add the user to each chassis)
If you have this working, please send me a copy of your Cisco/Radius
configs.
Thanks
John
Is there a way to get a Cisco 1004 ISDN connection to a TC Hub using radius.
I can get it to connect only by defining the user on the chassis itself (a
pain since I have 12 chassis and have to add the user to each chassis)
If you have this working, please send me a copy of your Cisco/Radius
configs.
Thanks
John
Subject:(usr-tc) ARC config From: Charles Sprickman <spork@inch.com> Date: 1999-01-27 14:48:08
Hi,
I finally did a capture of a config session on an arc so I can repeat at a
later date. After I trimmed it down, I think I have a fairly complete
config. Some things seem a little redundant (such as setting DNS servers
for ppp three times in three different places) but at least I can be sure
they are set.
Right now I am cutting and pasting line by line, has anyone successfully
used a term program to send a series of commands like this? I tried, and
it seems to overrun, and most of the commands get skipped. Is there a way
to turn this into a script like _quicksetup? If so, is there any way to
do get the file on the card via the console for pre-networked setup?
Any comments/corrections on this list of commands is welcome. I think I
nailed everything, but I'm not sure.
Thanks,
Charles
This is for a fairly simple setup, no RIP, two auth/acct servers, one user
for direct telnet access to a shell machine.
set system name "HiPer-x"
set system location "Oldslip/ACC"
set system contact "Charles Sprickman"
set command login_required yes
add user "foo" password "foo" type login,manage
delete user adm
add snmp community_pool secret address 207.240.xxx.xxx
add snmp community_pool secret address 207.240.xxx.xxx
add snmp community_pool secret address 207.240.xxx.xxx
add snmp community_pool secret address 207.240.xxx.xxx
add snmp community secret address 207.240.xxx.xxx access RW
add snmp community secret address 207.240.xxx.xxx access RO
set snmp community secret community_pool secret
set snmp community secret community_pool secret
list snmp communities
list snmp community_pools
enable security_option remote_user_administration telnet
add syslog 207.240.140.xxx facILITY log_local6 loglevel unusual
set accounting primary_server 207.240.140.xxx primary_secret "secret"
set authentication primary_server 207.240.140.xxx primary_secret "secret"
disable nmc chassis_awareness
set chassis slot 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 type static card_type empty
add ip network "lan-1" interface eth:1 address 207.240.xxx.xxx/C frame
ethernet_ii enable no
enable ip network "lan-1"
add ip defaultroute gateway 207.240.xxx.xxx metric 1
enable ip forwarding
add dns server 207.240.140.xxx preference 1
set dns domain_name "inch.com"
add ip pool "pool-1" initial_pool_address 207.240.xxx.xxx size 62
add tftp client 207.240.xxx.xxx
add dns serVER 207.240.140.xxx preFERENCE 2
disabLE secuRITY_OPTION remoTE_USER_ADMINISTRATION dialIN
set ppp autHENTICATION_PREFERENCE pap
set ppp dnS_USAGE ppp
set ppp pppdns_pRIMARY 207.240.140.xxx
set ppp pppdns_sECONDARY 207.240.140.xxx
set ppp ccp_MODEMTYPE_ACCEPT diGITAL
set user default poRT_LIMIT 1
set user default tyPE netWORK
set netWORK usER default ip rouTING none
set netwORK usER default ip rip ripv2
set netwoRK user default ppp maX_CHANNELS 1 primarY_DNS_SERVER
207.240.140.xxx secoNDARY_DNS_SERVER 207.240.140.xxx
set netWORK user default netWORK_SERVICE ppp
set accounting secondary_server 207.240.140.xxx
set accounting secondary_secret "secret"
set authENTICATION secondarY_serVER 207.240.140.xxx
set autHENTICATION secondary_secRET "secret"
set radIUS autHENTICATION_ALGORITHM fall_THROUGH
show authen
show account
set modEM_GROUP all messAGE "(HiPer- ) Welcome to Internet Channel. Enter
your username and password for PPP or enter 'foo' for shell access."
add user foo loGIN_SERVICE teLNET tyPE loGIN pasSWORD ""
set user foo poRT_LIMIT 0
set login usER foo login_host_iP_ADDRESS 207.240.140.xxx
set ip netWORK lan-1 routing_pROTOCOL none
set ntP priMARY_SERVER 207.240.140.xxx
set ntP secONDARY_SERVER 207.240.140.xxx
add loGIN_HOST shell addRESS 207.240.140.xxx prefERENCE 1
enaBLE ppp ofFLOADING
set ppp ccp_MODEMTYPE_ACCEPT digITAL
disabLE netWORK serVICE telnetd
set netwORK serVICE telnetd soCKET xxxx
enABLE netWORK serVICE telnetd
set command prompt "HiPer-x >"
# add when done
#set chassis slot 2,3,4,5,6,7,8,9,10,11,12 owner yes card_type quad_i_modem ports 4
#set chassis slot 13 owner yes card_type hdm_24 ports 24
save all
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Subject:RE: (usr-tc) IP-Input-Filter with Livingston RADIUS Server From: Ray Bellis <rpb@community.net.uk> Date: 1999-02-01 08:41:59
> I've got 3com VSA patches for Livingston Radius 2.0.1 on my usrtoys web
> page, based on the stuff Krish posted for 1.16 a long time ago. (And yes,
> we own 2 Portmasters.)
Where can I find documentation on the 3COM implementation of VSAs? I'm
writing my own RADIUS server and will probably need this information.
thanks,
Ray.
--
Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc
Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK
Telephone: +44-1865-856000 Fax: +44-1865-856001
Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/
Subject:RE: (usr-tc) Config needed - Cisco 1004 to Total Control with Hip From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-01 09:36:15
me too, but with a 1603 and HiPerARC 4.1.72-7. It connects,
authenticates, and times out in the IPCP configuration phase...
Robert
> -----Original Message-----
> From: John Verreault [SMTP:verreaul@aei.ca]
> Sent: lundi, 1. f=E9vrier 1999 07:14
> To: 'usr-tc@lists.xmission.com'
> Subject: (usr-tc) Config needed - Cisco 1004 to Total Control
> with HiperArc
>=20
> Can someone PLEASE post a lan to lan working config for a cisco 1004
> to a Total Control Chassis with a HiperArc.
> I would prefer a config that uses radius, but at this point I'll take
> anything
>=20
> I've got this working with a defined user on a Netserver but I cannot
> get this to work with a HiperArc.
>=20
> Thanks
>=20
> John Verreault
>=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.
Subject:RE: (usr-tc) IP-Input-Filter with Livingston RADIUS Server From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-01 09:50:13
It's in the NETserver manual somewhere near the end. If you can't
find it, drop me email and I'll try to write up my notes on the packet
format...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Mon, 1 Feb 1999, Ray Bellis wrote:
> > I've got 3com VSA patches for Livingston Radius 2.0.1 on my usrtoys web
> > page, based on the stuff Krish posted for 1.16 a long time ago. (And yes,
> > we own 2 Portmasters.)
>
> Where can I find documentation on the 3COM implementation of VSAs? I'm
> writing my own RADIUS server and will probably need this information.
>
> thanks,
>
> Ray.
>
> --
> Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc
> Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK
> Telephone: +44-1865-856000 Fax: +44-1865-856001
> Email: ray.bellis@community.net.uk URL: http://www.community.co.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) Oper Status Down and cant' get up! From: Wojciech Janiszewski <janisz@bydgoszcz.mtl.pl> Date: 1999-02-01 10:53:47
Walt Gnann wrote:
> Ownership doesn't seem to be the problem.
>
> tc5> sh chas sl 4
>
> CHASSIS SLOT 4 SETTINGS
> Owner: YES
> Description: Quad I-modem
> Number of Ports: 4
> Type: STATIC
>
> I tried the command you provided anyway and it still shows Oper Status Down:
> tc5> li inter
> ...
> slot:4/mod:1 Up Up
> slot:4/mod:2 Up Up
> slot:4/mod:3 Up Up
> slot:4/mod:4 Down Up
> ...
>
> Finally broke down and just powered down the chasis and powered it back up
> again. That fixed it. I'll have to keep my eye on it and see if it happens
> again.
Hi,
I don't know solution for that problem but you don't have to power down
chassis to make modems up. You can do "remove from service", "hardware
reset", "restore to service" under TCM. I know that quick fix because I
have the same problem with my modems and quads.
I discovered that this problem does not dependent on hardware revision of
quads (v2.0.0, v3.0.0) or they are set static or dynamic.
Wojciech
+-------------------------+-----------------+------------------------------+
> janisz@bydgoszcz.mtl.pl | WJ14-RIPE | Multinet - Bydgoszcz <
+-------------------------+-----------------+------------------------------+
Subject:(usr-tc) Eicon Deva ISDN From: Brian <signal@shreve.net> Date: 1999-02-01 14:22:44
Any known issues between Eicon Deva ISDN and hdm code 1.2.6/arc 4.1.11?
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) Motorola news From: K Mitchell <mitch@keyconn.net> Date: 1999-02-01 17:15:09
Found some interesting information on Motorola's website, they're
discontinuing support for their pc modems. This includes the various Surfr
lines. Opinions will vary on whether or not this is good news :)
http://www.mot.com/MIMS/ISG/Products/modems/retail.html
Kirk
Kirk Mitchell-General Manager sysadmin@keyconn.net
Keystone Connect http://www.keyconn.net
Altoona, PA 814-941-5000 We Unlock the World
At 05:15 PM 2/1/99 -0500, I wrote:
>Found some interesting information on Motorola's website, they're
>discontinuing support for their pc modems. This includes the various Surfr
>lines. Opinions will vary on whether or not this is good news :)
>http://www.mot.com/MIMS/ISG/Products/modems/retail.html
CORRECTION:
They don't say that they're discontinuing support, just the modems
themselves. But, it doesn't appear that they're putting much effort, if
any, in upgrading modem code as the newest drivers shown for many lines are
dated July of '98, with a few exceptions I found that were dated 08/12/99
03:43PM
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) Left-over telnet sessions From: Rick <rickyz@mindspring.com> Date: 1999-02-01 19:29:48
All 4.1.72-7 gurus:
What in the hell:; Keep getting "phantom" or "left-over" telnet sessions =
accumulating on the ARC card. At the 20 or so mark we rebooted, as 3Com =
had no clue. Now we have 4 admin users showing up in a li session, and =
one of them has the "mon ppp"/"monitor all packets" choice locked out. =
Now we can't debug.
Please. Isn't there a way to reset wan connections without rebooting? =
(equivelent to a "reset nxx" on the Netserver?). I realize this is =
probably due to an "un-clean" exit from telnet, but sometime remote =
telnet sessions are interupted beyond our control.
A show sessions looks like this:
li sessions
Name conn_type prot_type
admin wan Telnet
admin wan Telnet
admin wan Telnet
admin wan Telnet
admin wan Telnet
A "li tcp con" only shows the two we have active. How can we clear those =
sessions without rebooting? Is this a feature request? Hope not.
RickyZ@mindspring.com
Is The Truth Out There?
Hi All ... I am looking for a complete dictionary file with all the extended
3COM attributes ... anyone know where I might find one (Haven't checked the
SA package yet) ....
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
Subject:(usr-tc) V90analog vs. v90digital From: Brian Uechi <brianu@lava.net> Date: 1999-02-01 20:37:14
What's the difference between these modulation types? Is AllDigital
symmetric?
VALUE USR-Modulation-Type v90Analogue 33
VALUE USR-Modulation-Type v90Digital 34
VALUE USR-Modulation-Type v90AllDigital 35
I think the Netservers are reporting v90analogue but NMCs are
reporting v90digital.
Thanks,
---
Brian K. Uechi Email: brianu@lava.net
Technical Support Engineer Phone: 808-545-5282
LavaNet, Inc. FAX : 808-545-7020
Subject:Re: (usr-tc) Left-over telnet sessions From: Ronald E. Kushner <ron@glis.net> Date: 1999-02-01 20:37:19
Rick wrote:
>
> All 4.1.72-7 gurus:
>
> What in the hell:; Keep getting "phantom" or "left-over" telnet sessions accumulating on the ARC card. At the 20 or so mark we rebooted, as 3Com had no clue. Now we have 4 admin users showing up in a li session, and one of them has the "mon ppp"/"monitor all packets" choice locked out. Now we can't debug.
>
> Please. Isn't there a way to reset wan connections without rebooting? (equivelent to a "reset nxx" on the Netserver?). I realize this is probably due to an "un-clean" exit from telnet, but sometime remote telnet sessions are interupted beyond our control.
I'll tell you what I did. I implemented a 5 hour idle timeout for Admin
accounts. You could even add a maximum session time.
-Ron
--
Ronald Kushner
GLISnet, Inc.
+1 810/939.9885
I heard that the NetServer/I was discontinued. Does that mean that the
Modem Pool/Is were canned as well? Anyone know?
Thanks in advance,
Andy Sandoval
abs@nilenet.com
------ =_NextPart_000_01BE4E28.C6293400
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Ooooooh...! That's a great idea! Reminds me of that one about the =
problem of writing with ink in space; the americans poured millions into =
the development of the the Space Pen with a pressurized ink cartridge =
(works in zero gravity). The Rusians, faced with the same =
problem...decided to use a pencil.
Ronald 1; 3Com 0.
Rick
-> A show sessions looks like this:
->
-> li sessions
-> Name conn_type prot_type
-> admin wan Telnet
-> admin wan Telnet
-> admin wan Telnet
-> admin wan Telnet
-> admin wan Telnet
->
-> A "li tcp con" only shows the two we have active. How can we clear those =
-> sessions without rebooting? Is this a feature request? Hope not.
-> RickyZ@mindspring.com
-> Is The Truth Out There?
I'll go out on a limb here but will "disc user admin" work ?
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) MRTG and ESF stats From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-02 09:17:00
Is anyone using MRTG to collect the T-1 ESF stats off of either HDM or
Dual T-1/PRI cards ? If so, can you post your MRTG configuration file ?
Thanks,
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) V90analog vs. v90digital From: pferraro@wna-linknet.com Date: 1999-02-02 10:26:48
I also have a question about these... Our detail file will show
X2 but the rest of the entries, if they are v.90 only show the number (34)
How do we get it to record the v.90 in the detail log vice the 34?
Is this something specific to the radius itself? We current use Merit
3.6B
Thanks!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Mon, 1 Feb 1999, Brian Uechi wrote:
> What's the difference between these modulation types? Is AllDigital
> symmetric?
>
> VALUE USR-Modulation-Type v90Analogue 33
> VALUE USR-Modulation-Type v90Digital 34
> VALUE USR-Modulation-Type v90AllDigital 35
>
> I think the Netservers are reporting v90analogue but NMCs are
> reporting v90digital.
>
> Thanks,
> ---
> Brian K. Uechi Email: brianu@lava.net
> Technical Support Engineer Phone: 808-545-5282
> LavaNet, Inc. FAX : 808-545-7020
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
If it is a plain netserver 16 and not a plus or an i, 3.3 is the latest ver
that I know of that works on the box. We're running 8-10 of them around
the state with no problems.
At 06:24 PM 1/25/99 -0600, you wrote:
> Scenerio: Just installed a Netserver 16 running v4.1.7 (mar 16,98)
>Some users dial into box and get authenticated (via Radius) and surf away
>Other users get authenticated, get an IP address, but are dead in the
>water & received on both sides. "" seem to be running either win98 or the
>updated DUN driver on Win 95 Does anyone have a suggestion? I've got so
>many MAD users and I have no ideas. Thanks, Brian Becker Brian Becker
>Poplar Bluff Internet, Inc.
> http://www.semo.net
>Home of JP Bookstore
> http://www.JerusalemPerspective.com
>And Webgabber Chat server
> http://www.webgabber.com
>Personal Website
> http://www.Tonionio.com
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
I sent this earlier to you Guess you did not get it.
no service password-encryption
no service udp-small-servers
no service tcp-small-servers
!
hostname Cisco
!
!
username INTL_SE password 0 ppp
ip domain-name ae.usr.com
ip name-server 149.112.96.253
isdn switch-type basic-ni1
!
interface Ethernet0
ip address 172.24.1.254 255.255.255.0
!
interface BRI0
ip unnumbered Ethernet0
!
interface BRI0
ip unnumbered Ethernet0
encapsulation ppp
load-interval 30
dialer-group 1
isdn spid1 84722213920111 2221392
isdn spid2 84722213930111 2221393
no fair-queue
ppp multilink
!
no ip classless
ip route 0.0.0.0 0.0.0.0 207.24.79.202
ip route 0.0.0.0 0.0.0.0 207.24.79.202
ip route 149.112.96.0 255.255.255.0 207.24.79.202
ip route 207.24.79.202 255.255.255.255 BRI0
access-list 100 permit ip any any dialer-list 1 protocol ip
list 100
!
line con 0
exec-timeout 0 0
line vty 0 4
password temp
login
Here is the configuration for the HiPer arc
Here is the configuration for the HiPer arc
set systEM trANSMIT_AUTHENTICATION_NAME INTL_SE
adduser Cisco password ppp
----
If you are doing Radius then this user should have a plain text username
and password - you cannot user unix/etc password with chap so in radius
have a user set up like this
Cisco Password = ppp
User-Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 172.24.1.254,
Framed-Netmask = 255.255.255.0,
Framed-MTU = 1500
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 Wed, 27 Jan 1999, John Verreault wrote:
> Is there a way to get a Cisco 1004 ISDN connection to a TC Hub using radius.
> I can get it to connect only by defining the user on the chassis itself (a
> pain since I have 12 chassis and have to add the user to each chassis)
>
> If you have this working, please send me a copy of your Cisco/Radius
> configs.
>
> 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.
>
Did IP address or gateway also change and is that all setup properlly?
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, 25 Jan 1999, Steve McConnell wrote:
> We have a netserver chassis running 3.8.1 that I have recently moved to
> another location.
>
> People can dial in just fine, and surf fine as well. but now I can not
> ping them from the network, nor can I ping them from the netserver itself.
>
> This worked before, so it is obviously something that I did, but I am
> unable to find it:
>
> here is a sh glo (if that helps) Any ideas what I changed?
>
>
>
> Telnet Access Port: 23 TCP Maximal Segment Size: 0
> Assigned Address: 207.100.24.105 Reported Address: 0.0.0.0
> Assigned Pool Size: 26 Periodic CHAP timeout: 5
>
> PPP in modem: OFF SLIP in modem: OFF Packet bus clock:
> SLAVE
> ICMP error logging: OFF Connect message: OFF Dial !root access: OFF
> Random hosts list: OFF SNMP: ON Proxy Arp: OFF
> Response message: ON PPP message: ON Lan/Wan Routing: ON
> RIP V2 Authen: OFF VPN Local Routing: OFF MPIP Server: OFF
> Hint assigned: OFF Tap Login: OFF Syslog facility:
> auth
> Extd. IPXCP Opts: OFF Acct AuthChk: OFF/OFF Send DNS info: ON
> DNS cache reset timeout: 0 days 0 hours 30 minutes (30 min)
> Configured Ethernet media: Autodetect
> Currently Active B-channels: 2 Maximum Active B-channels: 60
> Command>
>
> Thanks
>
>
> steve
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) RIP updates with Cisco Router From: Ralph Helfenberger <rhelfenberger@comlight.ch> Date: 1999-02-02 14:50:33
Hi everyone
I should use RIP Updates betweeen a HiPer ARC and a Cisco 7500. After
the configuration has been done it looks like the Cisco is sending out
his updates but the HiPer ARC is not. I basically enabled Rip
set ip network ip routing_protocol ripv2
This is how my IP network looks like:
Interface: eth:1
Network Address: xxx.xxx.xxx.xxx/26
Frame Type: ETHERNET_II
Status: ENABLED
Reconfigure Needed: FALSE
Mask: 255.255.255.192
Station: xxx.xxx.xxx.xxx
Broadcast Algorithm: IETF
Max Reassembly Size: 3464
IP Routing Protocol: RIPV2
IP Routing Metric: 1
RIP Interface Export Metric: 0
IP RIP Routing Policies:
SEND_ROUTES
SPLIT_HORIZON
POISON_REVERSE
FLASH_UPDATE
SEND_COMPAT
RIPV1_RECEIVE
RIPV2_RECEIVE
IP RIP Authentication
Key:
Did I forgot something?
What tools are around to get more information (I'd like to see the RIP
packets arriving or been sent on the Ethernet interface).
Thanks for your comments
Ralph
Subject:(usr-tc) More DSPs From: Charles Sprickman <spork@inch.com> Date: 1999-02-02 15:31:53
Hi,
Anyone from 3com care to comment on any possible DSP promos? We're
looking to buy some, but we don't need any more ARC bundles. Any quad
trade-up programs?
And everyone else, how much are you paying for DSPs these days, and from
whom are you buying?
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Anyone else here going to ISPF II in San Diego next month?
<URL:http://www.ispf.com/>
I'll be there since I'm teaching a RADIUS class and speaking, but I was
thinking of trying to organize some kind of NAS BOF if there was interest.
Get people who use different things together to tell it how it is.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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) HELP ! Has anyone gotten a cisco BRI to connect to HARC / DSP From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-02 16:42:51
I don't know if this got through, so I'll just send it again....
After upgrading from 4.0.30 to 4.1.72-7, ciscoes will connect to the TC,
but IPCP times out.
Here's the config of the Cisco 2503 running IOS 11.3(T) versus a
HiPerARC 4.1.72-7, below is the config file for the HARC and the user
entry in RADIUS (passwords deleted of course)
USER = Username
PASS = Password
!
hostname USER
!
!
username HiPer
username USER password PASS
ip subnet-zero
no ip source-route
ip name-server xxx.xxx.xxx.xxx
isdn switch-type basic-net3
!
interface Ethernet0
ip address aaa.bbb.ccc.ddd 255.255.255.224
no ip redirects
no ip directed-broadcast
!
interface Serial0
no ip address
shutdown
!
interface Serial1
no ip address
shutdown
!
interface BRI0
ip address eee.fff.ggg.hhh 255.255.255.0
encapsulation ppp
dialer map ip GW-ADR name HiPer 5550051
dialer-group 1
ppp authentication pap chap
ppp chap hostname USER
ppp chap password PASS
ppp chap refuse
ppp pap sent-username USER password PASS
!
ip classless
ip route 0.0.0.0 0.0.0.0 GW-ADR
dialer-list 1 protocol ip permit
!
line con 0
line aux 0
line vty 0 4
login
!
end
$$$ Config of HiperARC
; Basic configuration of HiperARC in Petrel Network
;
; SNMP location and other info
;
set system name "SBL-TC1-ARC1"
set system location "SBL"
set system contact "rvb@petrel.ch"
set command login_required yes
set command prompt SBL-TC1-ARC1>
;
; enter some administrative stuff here like tftp, ntp, telnet and SNMP
;
add user "administrator" password "12345678" type login,manage
set user adm pass 12345678
enable security_option remote_user_administration telnet
add tftp client TFTP_PRIMARY_ADR
set ntp primary_SERVER NTP_PRIMARY_ADR
enable ntp
;
; Set up accounting and authentication
;
set accounting primary_server ACCT_PRIMARY_ADR primary_secret secret
set accounting secondary_servER ACCT_SEC_ADR secondary_secret secret
set authentication primary_server AUTH_PRIMARY_ADR primary_secret secret
set authentication secondary_server AUTH_SEC_SERVER secondary_secret
secret
set radiUS auTHENTICATION_ALGORITHM falL_THROUGH
;
; Set up the chassis
;
disable nmc chassis_awareness
set chassis slot 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 type static
card_type empty owner no
set chassIS slot 1,2,3,4,5,6 carD_TYPE hdm_30 ports 30 type stATIC ownER
yeS
;
; Set up IP networking and RIPV2
;
add ip network "ip" interface eth:1 address IP_OF_ETH/255.255.255.240
frame ethernet_ii enable no
enable ip network "ip"
add ip defaultroute gateway GW_OF_HARC metric 1
enable ip forwarding
add dns server 194.51.197.240 preference 1
add dns server 144.85.20.30 preference 2
set dns domain_name "span.ch"
set ip net ip routing_prOTOCOL ripv2
set ip net ip rip_pOLICIES_UPDATE no_poISON_REVERSE
set ip net ip rip_poLICIES_UPDATE no_send_comPAT
set ip net ip rip_pOLICIES_UPDATE no_ripV1_RECEIVE
enable ip secURITY_OPTION disallow_souRCE_ROUTE_OPTIONS
;
; Add an IP pool for dial-up
;
add ip pool "ippool" initial_pool_address IP_POOL_1 size 250 route
aggregate state public
set ppp pppdns_primary 194.51.197.240
set ppp pppdns_secondary 144.85.20.30
;
; Set up Multi-link PPP across multi-chassis
;
add mpip server MPIP_SERVER_ADR shaREDSECRET secret
set network user default ppp max_channels 1
set mpip client_sTATE on
;
; Save all configuration
;
save all
; Jan 1999 by rvb@petrel.ch
$$$ This is the RADIUS entry
USER Password = "PASS" , Expiration = "Dec 24 2040"
User-Service-Type = Framed-User,
Framed-Address = eee.fff.ggg.hhh,
Framed-Netmask = 255.255.255.255,
Framed-Route = "aaa.bbb.ccc.ddd/27 eee.fff.ggg.hhh 1",
Framed-Routing = None
--
Robert von Bismarck
Network Systems Engineer
Petrel Communications SA
Tel : +41 22 304 47 47
Fax : +41 22 300 48 43
WWW : http://www.petrel.ch
e-mail : rvb@petrel.ch
Subject:Re: (usr-tc) V90analog vs. v90digital From: Bruno Treguier <bruno.treguier@infini.fr> Date: 1999-02-02 17:05:31
Le Tue, Feb 02, 1999 at 10:26:48AM -0500, pferraro@wna-linknet.com �crivait:
>
> I also have a question about these... Our detail file will show
> X2 but the rest of the entries, if they are v.90 only show the number (34)
> How do we get it to record the v.90 in the detail log vice the 34?
>
> Is this something specific to the radius itself? We current use Merit
> 3.6B
Hello,
We're using the same version. All you have to do is update your dictionary
with the entries listed below (snipped from the first message of the thread).
> > VALUE USR-Modulation-Type v90Analogue 33
> > VALUE USR-Modulation-Type v90Digital 34
> > VALUE USR-Modulation-Type v90AllDigital 35
Bye,
Bruno
--
Bruno TREGUIER <treguier@infini.fr> | " Il y a 3 sortes de personnes:
FreeBSD 2.2.5, XFree86 3.3.1 | celles qui savent compter,
Association INFINI, Brest, FRANCE | et celles qui ne savent pas..."
------ =_NextPart_000_01BE4EEF.BC013AA0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Jeff, tried that...it no worky. Guess I'l go with the session timer....thanks though.
Rick
Once upon a time Brian Elfert shaped the electrons to say...
>Were there any real BOFs at the last ISPF?
Nothing 'official' but anyone can organize a gathering after hours, and
I can probably get a room if needed - being on the BoD and all. :-)
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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:Re: (usr-tc) Heading to ISPF II? From: Brian Elfert <brian@citilink.com> Date: 1999-02-02 21:30:43
On Tue, 2 Feb 1999, MegaZone wrote:
> Anyone else here going to ISPF II in San Diego next month?
> <URL:http://www.ispf.com/>
I'm going, and I posted a list of cheap hotels to the inet-access mailing
list a few days ago.
> thinking of trying to organize some kind of NAS BOF if there was interest.
Were there any real BOFs at the last ISPF?
Brian
Subject:(usr-tc) Is there a way to turn off --More-- prompts? From: vanhalen@coredcs.com Date: 1999-02-03 02:59:33
Is there a way to turn off the --More-- prompt that comes up when one does
a list conn on a HiperArc and just dump it all at once to the screen?
Thanks,
Steve
On Wed, 3 Feb 1999, Robert von Bismarck wrote:
> I found the bug... it's the way Cisco and HARC handle PAP. It seems
> broken on the cisco, when you do CHAP it works fine.
>=20
If you are doing PAP with cisco your dialer config should be like this
dialer map ip xx.xx.xx.xx <phone number>=20
dialer load-threshold 100 outbound
dialer-group 1
isdn spid1 84722213920111 2221392
isdn spid2 84722213930111 2221393
no fair-queue
ppp pap sent-username username password 7 09464101175547425B =20
Now notice here
this will connect only one channel. Cisco expects to do reverse pap=20
authentication on pap connection on the second channel.
> I have one last question concerning ciscoes :
>=20
> I have a hunt group with one single number and 24 DSP's. For load
> sharing, I put 5 ARC's on it.=20
>=20
> This is the addressing scheme :
>=20
> HARC1 : IP address on eth:1 is 10.0.0.1/24 and has pool 192.168.1.0/24
> HARC2 : IP address on eth:1 is 10.0.0.2/24 and has pool 192.168.2.0/24
> HARC3 : IP address on eth:1 is 10.0.0.3/24 and has pool 192.168.3.0/24
> and so on for HARC4 and HARC5
> Default GW for all the HARC's is 10.0.0.254 which is the primary IP of
> the Cisco Ethernet.
> The HARC's talk RIP with the CISCO
>=20
> There is one special pool for Fixed IP dial-up connections, this is
> 172.16.1.0/24
> the pool is routed into the ethernet 0 of the cisco so that those guys
> can log into any TC.
>=20
> Now my question is :
>=20
> What is the default gateway on the dial-up cisco 1603 ???? the address
> of one of the HARCS, the address of the cisco ? something different ?
>=20
> for now I have one IP that is not used (172.16.1.254) which acts as
> default, but this setup sucks...
> in the cisco it gives :
>=20
> ip route 0.0.0.0 0.0.0.0 172.16.1.254
> ip route 172.16.254 255.255.255.255 bri0
>=20
If you are using a single hiper arc=20
then the default gateway for the cisco would be that hiper arc
ip route 0.0.0.0 0.0.0.0 <ip of hiper >
now if you are not sure which hiper arc you are connecting then you can=20
set the default gateway as the core cisco router, but you will have some=20
icmp redirects.
krish
> Is there a way to hand the default route to the cisco via PPP, RADIUS or
> by smoke signals ?
>=20
> I hope this is clear enough ;-)
>=20
> Robert
>=20
> --
> Robert von Bismarck
> Network Systems Engineer
> Petrel Communications SA
> Tel : +41 22 304 47 47
> Fax : +41 22 300 48 43
> WWW : http://www.petrel.ch
> e-mail : rvb@petrel.ch
>=20
>=20
> > -----Original Message-----
> > From:=09Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com]
> > Sent:=09mardi, 2. f=E9vrier 1999 20:48
> > To:=09John Verreault
> > Cc:=09usr-tc@lists.xmission.com
> > Subject:=09Re: (usr-tc) Cisco 1004 ISDN Connection
> >=20
> > I sent this earlier to you Guess you did not get it.
> >=20
> >=20
> > no service password-encryption
> > no service udp-small-servers
> > no service tcp-small-servers
> > !
> > hostname Cisco
> > !
> > !
> > username INTL_SE password 0 ppp
> > ip domain-name ae.usr.com
> > ip name-server 149.112.96.253
> > isdn switch-type basic-ni1
> > !
> > interface Ethernet0
> > ip address 172.24.1.254 255.255.255.0
> > !
> > interface BRI0
> > ip unnumbered Ethernet0
> > !
> > interface BRI0
> > ip unnumbered Ethernet0
> > encapsulation ppp
> > load-interval 30 =20
> > dialer-group 1
> > isdn spid1 84722213920111 2221392
> > isdn spid2 84722213930111 2221393
> > no fair-queue
> > ppp multilink
> > !
> > no ip classless
> > ip route 0.0.0.0 0.0.0.0 207.24.79.202 =20
> > ip route 0.0.0.0 0.0.0.0 207.24.79.202
> > ip route 149.112.96.0 255.255.255.0 207.24.79.202
> > ip route 207.24.79.202 255.255.255.255 BRI0
> > access-list 100 permit ip any any dialer-list 1 protocol ip
> >=20
> > list 100
> > !
> > line con 0
> > exec-timeout 0 0
> > line vty 0 4
> > password temp
> > login=20
> >=20
> >=20
> >=20
> > Here is the configuration for the HiPer arc
> >=20
> > Here is the configuration for the HiPer arc
> >=20
> >=20
> >=20
> >=20
> > set systEM trANSMIT_AUTHENTICATION_NAME INTL_SE
> >=20
> >=20
> > adduser Cisco password ppp
> >=20
> >=20
> >=20
> >=20
> > ----
> >=20
> > If you are doing Radius then this user should have a plain text
> > username
> > and password - you cannot user unix/etc password with chap so in
> > radius
> > have a user set up like this
> > Cisco Password =3D ppp
> > User-Service-Type =3D Framed-User,
> > Framed-Protocol =3D PPP,
> > Framed-IP-Address =3D 172.24.1.254,
> > Framed-Netmask =3D 255.255.255.0,
> > Framed-MTU =3D 1500
> >=20
> >=20
> >=20
> > regards
> >=20
> > krish =20
> >=20
> > -----------------------------------------
> > =09=09\=09T.S.V. Krishnan \
> > =09=09 \ Network System Engineer \ ( : - : )
> > =09=09 \ 3Com ............ \
> > =09=09----------------------------------------------/
> > tkrishna@bubba.ae.usr.com =20
> > ----------------------------/ http://interproc.ae.usr.com ----/
> > The Yadda Yadda Search - for simple anwers -
> > http://interproc.ae.usr.com/tkb.html
> > ----------------------------------------------------------------------
> > ---\
> > =09Any Sufficiently advanced bug is indistinguishable for a
> > feature.
> > =09=09=09=09=09=09- Rick Kulawiec
> > ----------------------------------------------------------------------
> > ---/
> >=20
> > On Wed, 27 Jan 1999, John Verreault wrote:
> >=20
> > > Is there a way to get a Cisco 1004 ISDN connection to a TC Hub using
> > radius.
> > > I can get it to connect only by defining the user on the chassis
> > itself (a
> > > pain since I have 12 chassis and have to add the user to each
> > chassis)
> > >=20
> > > If you have this working, please send me a copy of your Cisco/Radius
> > > configs.
> > >=20
> > > Thanks
> > > John
> > >=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
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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
Here's an interesting scenario:
User dials in using a 2 channel MPP call.
list ip networks shows:
nndsb1-ip-I2026 IP slot:4/mod:2 ENA DYN
209.91.145.121/29
(this is good)
list ip routes shows:
209.91.145.120/29 LOCAL 209.91.145.121 1 slot:4/mod:2
I cannot find an entry for 209.91.145.121/32 anywhere in this list.
The next hop (default) Cisco 4700 shows a static:
S 209.91.145.120/29 [1/0] via 204.187.89.5
(ripv2 isn't running between the two - I haven't been able to get it
working at all with this #@$(* box - probably because it at 4.0.29 before
I flashed up to 4.1.72) .. thing is, there's a static entry there,
pointing to the NAS. If I trace from an outside unix host, it gets as far
as the NAS and then dies. I can ping the IP (209.91.145.121/32) locally
on the NAS, but not from the unix host.
It's definitely a routing issue, but what the hell? 209.91.145.121/32 is
directly connected to the NAS via MPP but I cannot ping it remotely.
I'm going to see if the remote user (an NT4 box) has a default gateway
set; that's the only possible explanation I can come up with at the
moment.
Any insight would be appreciated. Normally, I have a clue, but this just
baffles me.
Thnx.
--
Gilles Melanson ViaNet Internet Solutions
System Administrator 128 Larch St. Suite 301
gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
There isn't any reason why Linux can't be implemented as an enterprise
computing solution. Find out what you've been missing while you've
been rebooting Windows NT. -- Eric Hammond
Here's an interesting scenario:
User dials in using a 2 channel MPP call.
list ip networks shows:
nndsb1-ip-I2026 IP slot:4/mod:2 ENA DYN
209.91.145.121/29
(this is good)
list ip routes shows:
209.91.145.120/29 LOCAL 209.91.145.121 1 slot:4/mod:2
I cannot find an entry for 209.91.145.121/32 anywhere in this list.
The next hop (default) Cisco 4700 shows a static:
S 209.91.145.120/29 [1/0] via 204.187.89.5
(ripv2 isn't running between the two - I haven't been able to get it
working at all with this #@$(* box - probably because it at 4.0.29 before
I flashed up to 4.1.72) .. thing is, there's a static entry there,
pointing to the NAS. If I trace from an outside unix host, it gets as far
as the NAS and then dies. I can ping the IP (209.91.145.121/32) locally
on the NAS, but not from the unix host.
It's definitely a routing issue, but what the hell? 209.91.145.121/32 is
directly connected to the NAS via MPP but I cannot ping it remotely.
I'm going to see if the remote user (an NT4 box) has a default gateway
set; that's the only possible explanation I can come up with at the
moment.
Any insight would be appreciated. Normally, I have a clue, but this just
baffles me.
Thnx.
--
Gilles Melanson ViaNet Internet Solutions
System Administrator 128 Larch St. Suite 301
gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
There isn't any reason why Linux can't be implemented as an enterprise
computing solution. Find out what you've been missing while you've
been rebooting Windows NT. -- Eric Hammond
Subject:RE: (usr-tc) Routing issues with ARCs From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-03 10:06:22
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Gilles Melanson
|Sent: Wednesday, February 03, 1999 9:04 AM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Routing issues with ARCs
|
|
|Here's an interesting scenario:
|
|User dials in using a 2 channel MPP call.
|
|list ip networks shows:
|
|nndsb1-ip-I2026 IP slot:4/mod:2 ENA DYN
|209.91.145.121/29
|
|(this is good)
|
What netmask are you assinging this user?
|list ip routes shows:
|
|209.91.145.120/29 LOCAL 209.91.145.121 1 slot:4/mod:2
|
|I cannot find an entry for 209.91.145.121/32 anywhere in this list.
|
|The next hop (default) Cisco 4700 shows a static:
|S 209.91.145.120/29 [1/0] via 204.187.89.5
|
|(ripv2 isn't running between the two - I haven't been able to get it
|working at all with this #@$(* box - probably because it at 4.0.29 before
|I flashed up to 4.1.72) .. thing is, there's a static entry there,
|pointing to the NAS. If I trace from an outside unix host, it gets as far
|as the NAS and then dies. I can ping the IP (209.91.145.121/32) locally
|on the NAS, but not from the unix host.
|
|It's definitely a routing issue, but what the hell? 209.91.145.121/32 is
|directly connected to the NAS via MPP but I cannot ping it remotely.
|
|I'm going to see if the remote user (an NT4 box) has a default gateway
|set; that's the only possible explanation I can come up with at the
|moment.
|
|Any insight would be appreciated. Normally, I have a clue, but this just
|baffles me.
I just had this problem. Was banging my head against a wall thinking it was
a routing problem. I had him turn off software compression and it worked.
Wish I would have thought of that 3 hours earlier.
-----Original Message-----
>Here's an interesting scenario:
>
>User dials in using a 2 channel MPP call.
>
>list ip networks shows:
>
>nndsb1-ip-I2026 IP slot:4/mod:2 ENA DYN
>209.91.145.121/29
>
>(this is good)
>
>list ip routes shows:
>
>209.91.145.120/29 LOCAL 209.91.145.121 1 slot:4/mod:2
>
>I cannot find an entry for 209.91.145.121/32 anywhere in this list.
>
>The next hop (default) Cisco 4700 shows a static:
>S 209.91.145.120/29 [1/0] via 204.187.89.5
>
>(ripv2 isn't running between the two - I haven't been able to get it
>working at all with this #@$(* box - probably because it at 4.0.29 before
>I flashed up to 4.1.72) .. thing is, there's a static entry there,
>pointing to the NAS. If I trace from an outside unix host, it gets as far
>as the NAS and then dies. I can ping the IP (209.91.145.121/32) locally
>on the NAS, but not from the unix host.
>
>It's definitely a routing issue, but what the hell? 209.91.145.121/32 is
>directly connected to the NAS via MPP but I cannot ping it remotely.
>
>I'm going to see if the remote user (an NT4 box) has a default gateway
>set; that's the only possible explanation I can come up with at the
>moment.
>
>Any insight would be appreciated. Normally, I have a clue, but this just
>baffles me.
>
>Thnx.
>
>--
>Gilles Melanson ViaNet Internet Solutions
>System Administrator 128 Larch St. Suite 301
>gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
>
> There isn't any reason why Linux can't be implemented as an enterprise
> computing solution. Find out what you've been missing while you've
> been rebooting Windows NT. -- Eric Hammond
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) possible dual pri card problem From: matthew de Jongh <matthew.de.jongh@the-spa.com> Date: 1999-02-03 10:52:43
we are having an occasional problem that we think is related to a dual pri
card in an older chassis.
the symptom is that there are a bunch of "older" chassis with dual pri
cards and two hiper dsp cards.
they are all in one large hunt group with uniform call distribution.
normally all the chassis' fill in almost exactly evenly.
now all of a sudden just this one chassis will have like 15-20 users and
the other chassis will all have 40 users. i.e. all of the other traffic is
evenly distributed between all of the pri's in the hunt group.
the double up cards in the chassis in question are evenly loaded as the
others in the group.
the telco has checked the circuit, we also swapped both pri's from this
chassis to another and the problem stayed with the chassis and did not
follow the pri.
we have reflashed the card and such. what else should i do?
matthew
I have tried a diamond and kept getting disconnect problems with 1.2.6 ...
try http://beta.supra.com for the latest beta code ... it fixed the diamond
I was working on ...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
-----Original Message-----
>
>Any known issues with Diamond SupraMax HCF and 1.2.6 hdm code?
>
>
>-----------------------------------------------------
>Brian Feeny (BF304) signal@shreve.net
>318-222-26318 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) possible dual pri card problem From: Brian K McIntire <bmcintire@commnet.com> Date: 1999-02-03 12:30:28
check the dso modem configuration. make sure everything is mapped properly.
make sure the corresponding ports are active on he netserver
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of matthew de Jongh
> Sent: Wednesday, February 03, 1999 10:53 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) possible dual pri card problem
>
>
>
> we are having an occasional problem that we think is related to
> a dual pri
> card in an older chassis.
>
> the symptom is that there are a bunch of "older" chassis with dual pri
> cards and two hiper dsp cards.
>
> they are all in one large hunt group with uniform call distribution.
>
> normally all the chassis' fill in almost exactly evenly.
>
> now all of a sudden just this one chassis will have like 15-20 users and
> the other chassis will all have 40 users. i.e. all of the other traffic is
> evenly distributed between all of the pri's in the hunt group.
>
> the double up cards in the chassis in question are evenly loaded as the
> others in the group.
>
> the telco has checked the circuit, we also swapped both pri's from this
> chassis to another and the problem stayed with the chassis and did not
> follow the pri.
>
> we have reflashed the card and such. what else should i do?
>
> matthew
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Cisco 1004 ISDN Connection From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-03 13:11:08
I found the bug... it's the way Cisco and HARC handle PAP. It seems
broken on the cisco, when you do CHAP it works fine.
I have one last question concerning ciscoes :
I have a hunt group with one single number and 24 DSP's. For load
sharing, I put 5 ARC's on it.=20
This is the addressing scheme :
HARC1 : IP address on eth:1 is 10.0.0.1/24 and has pool 192.168.1.0/24
HARC2 : IP address on eth:1 is 10.0.0.2/24 and has pool 192.168.2.0/24
HARC3 : IP address on eth:1 is 10.0.0.3/24 and has pool 192.168.3.0/24
and so on for HARC4 and HARC5
Default GW for all the HARC's is 10.0.0.254 which is the primary IP of
the Cisco Ethernet.
The HARC's talk RIP with the CISCO
There is one special pool for Fixed IP dial-up connections, this is
172.16.1.0/24
the pool is routed into the ethernet 0 of the cisco so that those guys
can log into any TC.
Now my question is :
What is the default gateway on the dial-up cisco 1603 ???? the address
of one of the HARCS, the address of the cisco ? something different ?
for now I have one IP that is not used (172.16.1.254) which acts as
default, but this setup sucks...
in the cisco it gives :
ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 172.16.254 255.255.255.255 bri0
Is there a way to hand the default route to the cisco via PPP, RADIUS =
or
by smoke signals ?
I hope this is clear enough ;-)
Robert
--
Robert von Bismarck
Network Systems Engineer
Petrel Communications SA
Tel : +41 22 304 47 47
Fax : +41 22 300 48 43
WWW : http://www.petrel.ch
e-mail : rvb@petrel.ch
> -----Original Message-----
> From: Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com]
> Sent: mardi, 2. f=E9vrier 1999 20:48
> To: John Verreault
> Cc: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Cisco 1004 ISDN Connection
>=20
> I sent this earlier to you Guess you did not get it.
>=20
>=20
> no service password-encryption
> no service udp-small-servers
> no service tcp-small-servers
> !
> hostname Cisco
> !
> !
> username INTL_SE password 0 ppp
> ip domain-name ae.usr.com
> ip name-server 149.112.96.253
> isdn switch-type basic-ni1
> !
> interface Ethernet0
> ip address 172.24.1.254 255.255.255.0
> !
> interface BRI0
> ip unnumbered Ethernet0
> !
> interface BRI0
> ip unnumbered Ethernet0
> encapsulation ppp
> load-interval 30 =20
> dialer-group 1
> isdn spid1 84722213920111 2221392
> isdn spid2 84722213930111 2221393
> no fair-queue
> ppp multilink
> !
> no ip classless
> ip route 0.0.0.0 0.0.0.0 207.24.79.202 =20
> ip route 0.0.0.0 0.0.0.0 207.24.79.202
> ip route 149.112.96.0 255.255.255.0 207.24.79.202
> ip route 207.24.79.202 255.255.255.255 BRI0
> access-list 100 permit ip any any dialer-list 1 protocol =
ip
>=20
> list 100
> !
> line con 0
> exec-timeout 0 0
> line vty 0 4
> password temp
> login=20
>=20
>=20
>=20
> Here is the configuration for the HiPer arc
>=20
> Here is the configuration for the HiPer arc
>=20
>=20
>=20
>=20
> set systEM trANSMIT_AUTHENTICATION_NAME INTL_SE
>=20
>=20
> adduser Cisco password ppp
>=20
>=20
>=20
>=20
> ----
>=20
> If you are doing Radius then this user should have a plain text
> username
> and password - you cannot user unix/etc password with chap so in
> radius
> have a user set up like this
> Cisco Password =3D ppp
> User-Service-Type =3D Framed-User,
> Framed-Protocol =3D PPP,
> Framed-IP-Address =3D 172.24.1.254,
> Framed-Netmask =3D 255.255.255.0,
> Framed-MTU =3D 1500
>=20
>=20
>=20
> regards
>=20
> krish =20
>=20
> -----------------------------------------
> \ T.S.V. Krishnan \
> \ Network System Engineer \ ( : - : )
> \ 3Com ............ \
> ----------------------------------------------/
> tkrishna@bubba.ae.usr.com =20
> ----------------------------/ 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
> =
> ---/
>=20
> On Wed, 27 Jan 1999, John Verreault wrote:
>=20
> > Is there a way to get a Cisco 1004 ISDN connection to a TC Hub =
using
> radius.
> > I can get it to connect only by defining the user on the chassis
> itself (a
> > pain since I have 12 chassis and have to add the user to each
> chassis)
> >=20
> > If you have this working, please send me a copy of your =
Cisco/Radius
> > configs.
> >=20
> > Thanks
> > John
> >=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.
Thus spake Robert von Bismarck
>What is the default gateway on the dial-up cisco 1603 ???? the address
>of one of the HARCS, the address of the cisco ? something different ?
Unless the 1603 is broken, it should be able to take the remote IP
address (negotiated through IPCP) and use it as a default gateway.
>Is there a way to hand the default route to the cisco via PPP, RADIUS =
>or
>by smoke signals ?
You can hand the cisco the remote IP address through PPP (IPCP
specifically), but not a route. It's incumbent upon the cisco to take
that remote IP and use it as the gateway for a default route if it feels
it needs to.
Another alternative, at least with the NETServers, I assume the Arc's
have similar functionality, is to use the "reported address" setting in
the NETServer. Basically, this is an address that all the NETServers
can use, but they don't actively use it. Meaning, that you can set the
reported address on all your access servers and have the same IP
address, and they'll use this IP address in the IPCP negotiation, so
remote dial-in systems that are too brain-dead to install a default
route dynamically, ie, you can set the default route statically, and all
the access servers will use that address in the IPCP negotiation, so the
route will always have something to point to no matter which access
server it hits on the dial-in.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
The solution was actually much simpler than that.
I forgot the cardinal rule of NT4 (piece of #@$(*): Use numbered PPP
interfaces.
It didn't like having the same network for both PPP and local interfaces.
I still have a ripv2 issue between my Cisco 4700 and one of my RAS boxes,
but I'll have to play with it some more. Maybe I'll give up and wait for
OSPF support *grin* .. I'm allowed to dream, aren't I?
/gm
On Wed, 3 Feb 1999, Russ Miescke wrote:
> I just had this problem. Was banging my head against a wall thinking it was
> a routing problem. I had him turn off software compression and it worked.
> Wish I would have thought of that 3 hours earlier.
> -----Original Message-----
> From: Gilles Melanson <gilles@vianet.on.ca>
> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
> Date: Wednesday, February 03, 1999 9:51 AM
> Subject: (usr-tc) Routing issues with ARCs
>
>
> >Here's an interesting scenario:
> >
> >User dials in using a 2 channel MPP call.
> >
> >list ip networks shows:
> >
> >nndsb1-ip-I2026 IP slot:4/mod:2 ENA DYN
> >209.91.145.121/29
> >
> >(this is good)
> >
> >list ip routes shows:
> >
> >209.91.145.120/29 LOCAL 209.91.145.121 1 slot:4/mod:2
> >
> >I cannot find an entry for 209.91.145.121/32 anywhere in this list.
> >
> >The next hop (default) Cisco 4700 shows a static:
> >S 209.91.145.120/29 [1/0] via 204.187.89.5
> >
> >(ripv2 isn't running between the two - I haven't been able to get it
> >working at all with this #@$(* box - probably because it at 4.0.29 before
> >I flashed up to 4.1.72) .. thing is, there's a static entry there,
> >pointing to the NAS. If I trace from an outside unix host, it gets as far
> >as the NAS and then dies. I can ping the IP (209.91.145.121/32) locally
> >on the NAS, but not from the unix host.
> >
> >It's definitely a routing issue, but what the hell? 209.91.145.121/32 is
> >directly connected to the NAS via MPP but I cannot ping it remotely.
> >
> >I'm going to see if the remote user (an NT4 box) has a default gateway
> >set; that's the only possible explanation I can come up with at the
> >moment.
> >
> >Any insight would be appreciated. Normally, I have a clue, but this just
> >baffles me.
> >
> >Thnx.
> >
> >--
> >Gilles Melanson ViaNet Internet Solutions
> >System Administrator 128 Larch St. Suite 301
> >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
> >
> > There isn't any reason why Linux can't be implemented as an enterprise
> > computing solution. Find out what you've been missing while you've
> > been rebooting Windows NT. -- Eric Hammond
> >
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
--
Gilles Melanson ViaNet Internet Solutions
System Administrator 128 Larch St. Suite 301
gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
There isn't any reason why Linux can't be implemented as an enterprise
computing solution. Find out what you've been missing while you've
been rebooting Windows NT. -- Eric Hammond
Subject:(usr-tc) Diamond SupraMax HCF From: Brian <signal@shreve.net> Date: 1999-02-03 21:35:56
Any known issues with Diamond SupraMax HCF and 1.2.6 hdm code?
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Is there a way to turn a MONITOR PPP Hex trace into more readable
english ? We have a user with a LAN behind their Ascend pipeline
and one of the users has something running which is keeping
there connection up. We see the packets every 30-45 seconds on
a monitor PPP command on the HiPerArc but the decode isn't
sufficient enough to tell him where to start looking. Any thoughts ?
Jeff Binkley
ASA Network Computing
On Wed, 3 Feb 1999, Jamie Orzechowski wrote:
> I have tried a diamond and kept getting disconnect problems with 1.2.6 ...
>
> try http://beta.supra.com for the latest beta code ... it fixed the diamond
> I was working on ...
Any idea if that code will work on other Rockwell HCF modems (like the
ones in some Compaqs)? Those modems have always been problematic... at
least the LT Winmodems can be fixed with an update...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:Re: (usr-tc) Is there a way to turn off --More-- prompts? From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-04 10:56:22
Try:
disaBLE coMMAND glOBAL_TERMINAL_SETTINGS_PAGE_BREAKS
Disables more for all sessions on box
OR
disaBLE coMMAND LOCAL_TERMINAL_SETTINGS_PAGE_BREAKS
Disables more for current session
Also see:
show command settings
HiPer>> show comMAND seTTINGS
COMMAND SETTINGS
History Depth: 10
Global Prompt: HiPer>>
Local Prompt: HiPer>>
Console Login Required: NO
Console Idle Timeout: 5
Current Idle Timeout: 0
Global Terminal Settings Page-break: ENABLED
Global Terminal Settings Rows: 23
Local Terminal Settings Page-break: ENABLED
Local Terminal Settings Rows: 23
-- Matt
vanhalen@coredcs.com on 02/03/99 02:59:33 AM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
Is there a way to turn off the --More-- prompt that comes up when one does
a list conn on a HiperArc and just dump it all at once to the screen?
Thanks,
Steve
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) Problem with Quad modems and HyperARC From: Mark Lemmert <cto@athenet.net> Date: 1999-02-04 11:48:41
I have a chassis that has 12 quad modems 5.10.9, 2 HyperDSPs (1.2.5), a
netserver card (3.8.71) and
I'm trying to install a HyperARC (4.1.63).
People are able to connect fine to the HyperDSPs but there seems to be trouble
when connecting to the quad modems. I am able to conenct to them with my
courier v.90 modem but when I route public calls onto them about 90% drop off
and don't succussfully log in.
I still have the netserver card in the chassis but my understanding is that
shouldn't be a problem.
Has anybody run into this?
-Mark Lemmert AthEnet Data Exchange
Chief Technical Officer 888-919-8700
Subject:(usr-tc) Session Timers From: Paul M. Oster <devious@minot.com> Date: 1999-02-04 13:11:08
Anyone know how to set session timeouts in the HARC's and NetServers?
3Com tech support is less than helpfull in these regards.
Paul M. Oster <devious@minot.com> http://www.minot.com/
Magic Internet Services (701) 838-1265
Minots FIRST Internet Connection
-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire
Subject:Re: (usr-tc) Windows NT users can't browse From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-04 13:13:12
Thus spake Ralph Helfenberger
>If I connect to the same system, same username/password I also get
>connected, I can ping everything (including ping www.xxxx.xx). But if I
>open a Browser I just can't get any data from the WWW. It happens with
>different NT Systems.
Turn off software compression.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
There is a new code 4.1.59 - the new service release on totalservice.usr.com
This does fix your issue. Also included are release notes.
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, 25 Jan 1999, Aaron Nabil wrote:
>
> System Version: V4.1.63
>
> Here's what I send...
>
> Framed-Routing = None
> Framed-IP-Netmask = 255.255.255.255
> Service-Type = Framed-User
> Idle-Timeout = 3600
> Session-Timeout = 43200
> USR-Max-Channels = 1
> Framed-Protocol = PPP
> USR-Log-Filter-Packet = Log-Disable
> USR-IP-Input-Filter = "1 REJECT dst-addr = 192.168.0.0/16"
>
> This is what I get in the syslog with every login...
>
> Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL"::
> Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL":: invalid token near line 1 (text was '=')
> Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL"::
> Jan 25 11:08:29 us4b last message repeated 2 times
> Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL":: line 1: syntax error near or at "REJECT"
>
> This must have started very recently, I'm guessing with this version.
>
> Can anyone suggest anything?
>
> --
> 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.
>
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul M. Oster
|Sent: Thursday, February 04, 1999 1:11 PM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Session Timers
|
|
|
|
|Anyone know how to set session timeouts in the HARC's and NetServers?
|3Com tech support is less than helpfull in these regards.
|
|
In netservers its a RADIUS attribute.. For HARC just set it on the default user
or you can also use RADIUS.
Attrbute 27 BTW.
-M
Subject:Re: (usr-tc) Yikes, filters broken in arc V4.1.63? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-04 14:20:19
Thus spake Tatai SV Krishnan
>There is a new code 4.1.59 - the new service release on totalservice.usr.com
>This does fix your issue. Also included are release notes.
Ooh... .59 is an SR now? Cool. Nice to know that I won't have to
upgrade again on it. :)
BTW, .59 has the "set modem_group all prompt_delay <n>" command that
will enable us to start moving our hunt group over to HiPer Arcs from
NETServers.
Finally! :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
|Sent: Thursday, February 04, 1999 6:03 AM
|To: USR-TC@lists.xmission.com
|Subject: (usr-tc) Monitor Hex Decode
|
|
|
|Is there a way to turn a MONITOR PPP Hex trace into more readable
|english ? We have a user with a LAN behind their Ascend pipeline
|and one of the users has something running which is keeping
|there connection up. We see the packets every 30-45 seconds on
|a monitor PPP command on the HiPerArc but the decode isn't
|sufficient enough to tell him where to start looking. Any thoughts ?
|
Grab the packet from the screen.. The the PPP and TCP/IP RFC's and a pencil and
start decoding the header. From the header you should be abel to tell protocol,
port, and dest address. And thats usually enough. Or place a sniffer etc on the
wire on your site and see if that will tell you more.. You cant expect the HARC
to be a full featured packet sniffer, can you :)?
-M
Jeff,
We are aware of the issue. We're currently testing a version of HARM that
corrects the issue. I will post to the list when this code is made
availble.
Vito Maselli
Jeff Mcadams <jeffm@iglou.com> on 02/04/99 01:49:04 PM
Please respond to usr-tc@lists.xmission.com
cc: (Vito Maselli/MW/US/3Com)
Fired up HARM to see about the possibility of giving it to the tech
support dudes with a read only SNMP string. Started looking through
it...played with various of the windows, and what to my wondering eyes
did appear (to borrow a phrase from the night before Xmas), but a tab
labeled SNMP. Well...being the explorer that I am, I clicked it...and
what did I see? Oh my, but if it isn't *ALL* my SNMP community strings,
including the one's set up as ADM!
Wups. 3Com goofed.
--
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) Oh fun, joy...3Com hoses up security issues again. From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-04 14:49:04
Fired up HARM to see about the possibility of giving it to the tech
support dudes with a read only SNMP string. Started looking through
it...played with various of the windows, and what to my wondering eyes
did appear (to borrow a phrase from the night before Xmas), but a tab
labeled SNMP. Well...being the explorer that I am, I clicked it...and
what did I see? Oh my, but if it isn't *ALL* my SNMP community strings,
including the one's set up as ADM!
Wups. 3Com goofed.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Jeff,
Thanks for pointing out it's not a HARM issue. We know it's a HiperArc
issue and we are taking steps to correct it.
Vito
Jeff Mcadams <jeffm@iglou.com> on 02/04/99 02:27:21 PM
Please respond to usr-tc@lists.xmission.com
cc: (Vito Maselli/MW/US/3Com)
Thus spake Vito Maselli
>We are aware of the issue. We're currently testing a version of HARM that
>corrects the issue. I will post to the list when this code is made
>availble.
Uhm...its not a HARM issue.
--
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) Oh fun, joy...3Com hoses up security issues again. From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-04 15:27:21
Thus spake Vito Maselli
>We are aware of the issue. We're currently testing a version of HARM that
>corrects the issue. I will post to the list when this code is made
>availble.
Uhm...its not a HARM issue.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) WebTV revisited From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-04 16:42:59
I'm still getting no satisifaction for many of my WebTV users. I'm running
both quads and DSP's (1.2.6), all on HiperARC's (4.1.72-7). I'm planning
on upgrading to 4.1.59-1. I'm running a pretty generic config. Any config
tips you can share?
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Subject:(usr-tc) WebTV Correction.. From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-04 16:45:46
Actually, I'm running a different version of HiperARC code with the DSPs, so
I can get IEA. I'll take that up with the appropriate engineers. Any tips
for the Quads? Will 4.1.59 help?
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Vito Maselli was heard to say:
>We are aware of the issue. We're currently testing a version of HARM that
>corrects the issue. I will post to the list when this code is made
>availble.
Excuss me? HARM is not the problem... If the community strings are
available via READ-ONLY SNMP, then what's the point in HARM not showing
them???
<grin> How drunk were you guy when you wrote this stuff :-)
--Ricky
Subject:(usr-tc) zmodem for FreeBSD From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-04 17:51:53
Does anyone know of a decent terminal program that will do Zmodem on
FreeBSD? cu with lsz hurts my head ;)
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Subject:Re: (usr-tc) Oh fun, joy...3Com hoses up security issues again. From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-04 18:31:12
Thus spake Ricky Beam
>If the community strings are available via READ-ONLY SNMP
Incidentally...the strings aren't as immediately obvious via ro SNMP as
I first thought, but they definitely are there.
snmpwalk enterprises.usRobotics.common.usrSnmp.usrSnmpCommTable
You'll see entries of the format:
usrSnmpCommTable.usrSnmpCommEntry.usrSnmpCommxxxxx.<a>.<b>.<c>.<d>.<e> = blah
The xxxxx is the SNMP oid for whichever value in the table you're trying
to get (IpAddr, Access, Status, LastError, etc.)
<a> is the length of the community string
<b>,<c>,<d>,<e>, etc. are the ASCII character codes (my snmpwalk that
I'm using displays them in decimal FWIW) of the community string.
So, anyway...its not like you can just scan down through and see the
string, it takes a slight amount of interpretation, but that's pretty
trivial in the overall scheme of things...
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:RE: (usr-tc) Session Timers From: Paul M. Oster <devious@minot.com> Date: 1999-02-04 19:08:09
Yes, Session-Timeout=18000, is what I have been using, however, the Hiper
Arc's are not listening tothe attribute, which is causing some problems.
If 3com had been able to answer that1 question, I would have renewed my
support contracts, but having a feature missing that was readily available
in the NetServers, that unacceptable.
Paul M. Oster <devious@minot.com> http://www.minot.com/
Magic Internet Services (701) 838-1265
Minots FIRST Internet Connection
-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire
On Thu, 4 Feb 1999, Mike Wronski wrote:
>
>
> |-----Original Message-----
> |From: owner-usr-tc@lists.xmission.com
> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul M. Oster
> |Sent: Thursday, February 04, 1999 1:11 PM
> |To: usr-tc@lists.xmission.com
> |Subject: (usr-tc) Session Timers
> |
> |
> |
> |
> |Anyone know how to set session timeouts in the HARC's and NetServers?
> |3Com tech support is less than helpfull in these regards.
> |
> |
>
> In netservers its a RADIUS attribute.. For HARC just set it on the default user
> or you can also use RADIUS.
>
> Attrbute 27 BTW.
>
>
> -M
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) Windows NT users can't browse From: Ralph Helfenberger <rhelfenberger@comlight.ch> Date: 1999-02-04 19:12:06
Hi
I have a problem wich looks a bit strange to me.
Netserver 3.8.1/Quadmodems 5.9.9 based system.
Users with Windows 95 can connect to the system without any problems.
They can use Netscape or whatever they want.
If I connect to the same system, same username/password I also get
connected, I can ping everything (including ping www.xxxx.xx). But if I
open a Browser I just can't get any data from the WWW. It happens with
different NT Systems.
Anybody any idea where to debug such a problem ?
Thanks
Ralph
Subject:Re: (usr-tc) zmodem for FreeBSD From: Allen Marsalis <am@shreve.net> Date: 1999-02-04 19:18:04
At 05:51 PM 2/4/99 -0700, Randy Cosby wrote:
>Does anyone know of a decent terminal program that will do Zmodem on
>FreeBSD? cu with lsz hurts my head ;)
Doesn't minicom do zmodem?
http://btp1da.phy.uni-bayreuth.de/~werner/FreeBSD/fbsd_pub_ftp/ports/comms/m
inicom/
Allen
>
>
>Randy Cosby <dcosby@infowest.com>
>Vice President
>InfoWest Global Internet Services, Inc.
>(435)674-0165 http://www.infowest.com
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
-> X-MSMail-Priority: Normal
-> X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
-> Importance: Normal
-> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
-> In-Reply-To: <35.386856.7@asacomp.com>
-> Sender: owner-usr-tc@lists.xmission.com
-> Precedence: bulk
-> Reply-To: usr-tc@lists.xmission.com
->
-> |-----Original Message-----
-> |From: owner-usr-tc@lists.xmission.com
-> |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley |Sent:
-> Thursday, February 04, 1999 6:03 AM
-> |To: USR-TC@lists.xmission.com
-> |Subject: (usr-tc) Monitor Hex Decode
-> |
-> |
-> |
-> |Is there a way to turn a MONITOR PPP Hex trace into more readable |english
-> ? We have a user with a LAN behind their Ascend pipeline |and one of the
-> users has something running which is keeping
-> |there connection up. We see the packets every 30-45 seconds on |a monitor
-> PPP command on the HiPerArc but the decode isn't
-> |sufficient enough to tell him where to start looking. Any thoughts ? |
->
-> Grab the packet from the screen.. The the PPP and TCP/IP RFC's and a pencil
-> and
-> start decoding the header. From the header you should be abel to tell
-> protocol,
-> port, and dest address. And thats usually enough. Or place a sniffer etc on
-> the
-> wire on your site and see if that will tell you more.. You cant expect the
-> HARC
-> to be a full featured packet sniffer, can you :)?
No, I wasn't asking for a pull packet sniffer but if someone had a
debug utility to run against it, that might be nice.
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) Accounting From: Paul M. Oster <devious@minot.com> Date: 1999-02-04 21:04:22
Umm... I've got a hyperarc which is mis-sending some accounting stuff,
every botched packet (Radius STOP) lists the user as being on 62 million,
2 hundred thousand and some odd seconds... or over 17 thousand hours (708
days or almost 2 YEARS).... I dont even have a chassis thats been IN
production that long :) Hyper Arc, just upgraded from a NetServer... any
suggestions as to whats wrong, and how to fix?
Paul M. Oster <devious@minot.com> http://www.minot.com/
Magic Internet Services (701) 838-1265
Minots FIRST Internet Connection
-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire
Subject:Re: (usr-tc) Problem with Quad modems and HyperARC From: Russ Miescke <russm@powerweb.net> Date: 1999-02-04 21:21:48
Do not use the automatic program from 3Com to do the upgrade. It does not
recognize the quads. I even tried to add them later but had the same
problem as you. Delete the config in the HyperArc (del config) and do it
manually. Make sure you answer yes to the enable chassis awareness
question.
Russ Miescke
Power Web Connect
russm@powerweb.net
http://www.powerweb.net
----- Original Message -----
Sent: Thursday, February 04, 1999 11:48 AM
>I have a chassis that has 12 quad modems 5.10.9, 2 HyperDSPs (1.2.5), a
>netserver card (3.8.71) and
>I'm trying to install a HyperARC (4.1.63).
>
>People are able to connect fine to the HyperDSPs but there seems to be
trouble
>when connecting to the quad modems. I am able to conenct to them with my
>courier v.90 modem but when I route public calls onto them about 90% drop
off
>and don't succussfully log in.
>
>I still have the netserver card in the chassis but my understanding is that
>shouldn't be a problem.
>
>Has anybody run into this?
>
>
>
>-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) Is there a way to turn off --More-- prompts? From: K Mitchell <mitch@keyconn.net> Date: 1999-02-04 23:01:23
At 10:56 AM 2/4/99 -0600, "Matt Harper" <Matt_Harper@mw.3com.com> wrote:
>HiPer>> show comMAND seTTINGS
>
>COMMAND SETTINGS
>History Depth: 10
>Global Prompt: HiPer>>
>Local Prompt: HiPer>>
>Console Login Required: NO
>Console Idle Timeout: 5
>Current Idle Timeout: 0
>Global Terminal Settings Page-break: ENABLED
>Global Terminal Settings Rows: 23
>Local Terminal Settings Page-break: ENABLED
>Local Terminal Settings Rows: 23
Can the number of rows displayed be changed?
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) zmodem for FreeBSD From: Charles Sprickman <spork@inch.com> Date: 1999-02-04 23:43:25
Yep, minicom works, just make sure you have lrzsz installed and have
minicom configured to know where to find it.
Anyone know of any other good term progs (for uxix)?
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
On Thu, 4 Feb 1999, Allen Marsalis wrote:
> At 05:51 PM 2/4/99 -0700, Randy Cosby wrote:
> >Does anyone know of a decent terminal program that will do Zmodem on
> >FreeBSD? cu with lsz hurts my head ;)
>
> Doesn't minicom do zmodem?
>
> http://btp1da.phy.uni-bayreuth.de/~werner/FreeBSD/fbsd_pub_ftp/ports/comms/m
> inicom/
>
> Allen
>
> >
> >
> >Randy Cosby <dcosby@infowest.com>
> >Vice President
> >InfoWest Global Internet Services, Inc.
> >(435)674-0165 http://www.infowest.com
> >
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) Accounting From: Charles Hill <chill@ionet.net> Date: 1999-02-05 00:32:41
I got those, too. I did a "set accounting log_UNAUTHENTICATED_CALLS
false" to and they stopped.
-CH
On Thu, 4 Feb 1999, Paul M. Oster wrote:
>
>
> Umm... I've got a hyperarc which is mis-sending some accounting stuff,
> every botched packet (Radius STOP) lists the user as being on 62 million,
> 2 hundred thousand and some odd seconds... or over 17 thousand hours (708
> days or almost 2 YEARS).... I dont even have a chassis thats been IN
> production that long :) Hyper Arc, just upgraded from a NetServer... any
> suggestions as to whats wrong, and how to fix?
>
> Paul M. Oster <devious@minot.com> http://www.minot.com/
> Magic Internet Services (701) 838-1265
> Minots FIRST Internet Connection
>
> -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
>
> "I might not agree with what you have to say but I will defend, to
> my death, your right to say it." - Voltaire
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) problem with chassis everytime power is lost From: eric@dol.net Date: 1999-02-05 01:22:40
Everytime power is lost on one of my total control boxes
with netserver cards I have to manually go in and do a
soft reset on modems 20-48 and my pri card has to be reset
for first available from round robin. I have gone to configure
and saved all this to nvram but there must be some chassis
setting that I am missing. From the tcm main menu I click on
file , save nvram and i get a tcmramsr has performed an illegal
operation. Is this what is giving me a problem? I know
I have saved it months before I upgraded the chassis to v.90.
After upgrading is when I began getting the illegal message but I
always had a problem when the power went out. All help is appreciated.
thanks
eric
Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems
Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...
Jeff Mcadams writes...
>BTW, .59 has the "set modem_group all prompt_delay <n>" command that
>will enable us to start moving our hunt group over to HiPer Arcs from
>NETServers.
It doesn't work for me.
usr2> _show ver
V4.1.59 - 1
usr2> set modem_group all prompt_delay 5
CLI - Invalid Argument: prompt_delay
--
Aaron Nabil
Subject:(usr-tc) 56k=v.Unreliable From: Richard Gamberg <richard@808hi.com> Date: 1999-02-05 08:03:26
New pages & recent updates at the 56k=v.Unreliable website
http://808hi.com/56k/
[Alternate mirror: http://808news.com/56k/ ]
Flashback a 3Com/USR/Sportster - http://808hi.com/56k/flashback.htm
Who Manufactured Your Modem - now uses a database I'm maintaining
(based upon FCC Part68 registration data) -
http://808hi.com/56k/whomadeit.htm
The latest Lucent-Apollo/Mars "LT Win Modem" code - version 5.39 &
extensive info on the modem - http://808hi.com/56k/x2-lucent.htm
NEWS & LATEST UPDATES - http://808hi.com/56k/latest.htm
TROUBLESHOOTING - http://808hi.com/56k/r-rnut-x2-3.htm
Throughput - http://808hi.com/56k/x2-thru.htm
A/D Conversion check - http://808hi.com/56k/x2-adconversion.htm
Limiting Connect speed- http://808hi.com/56k/x2-linklimit.htm
HyperTerminal - http://808hi.com/56k/x2-hyperterm.htm
Port (115.2k) connects - http://808hi.com/56k/x2-inf1.htm
3Com diagnostic info - http://808hi.com/56k/diag3com.htm
Your telephone wiring - http://808hi.com/56k/cat5.htm
Note - my site is copyrighted; many ISP help pages link to one or more of my
pages - no permission is needed to do this; however, if you want to COPY
info & place on your site, you need to get my permission. Thanks.
Aloha,
Richard
Subject:Re: (usr-tc) Accounting From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-05 08:28:00
The downside is you can track folks trying to hack their way in.
Jeff Binkley
ASA Network Computing
u>I got those, too. I did a "set accounting log_UNAUTHENTICATED_CALLS
u>false" to and they stopped.
u>-CH
u>On Thu, 4 Feb 1999, Paul M. Oster wrote:
u>> Umm... I've got a hyperarc which is mis-sending some accounting
u>> stuff, every botched packet (Radius STOP) lists the user as being on
u>> 62 million, 2 hundred thousand and some odd seconds... or over 17
u>> thousand hours (708 days or almost 2 YEARS).... I dont even have a
u>> chassis thats been IN production that long :) Hyper Arc, just
u>> upgraded from a NetServer... any suggestions as to whats wrong, and
u>> how to fix?
u>> Paul M. Oster <devious@minot.com>
u>> http://www.minot.com/ Magic Internet Services
u>> (701) 838-1265 Minots FIRST Internet Connection
u>> -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
u>> "I might not agree with what you have to say but I will defend, to
u>> my death, your right to say it." - Voltaire
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> 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.
CMPQwk 1.42 9999
Subject:Re: (usr-tc) Accounting From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-05 09:19:08
Krish mentioned a 4.1.59 service release yesterday... This bug is listed
as one of the fixes in its release notes. I've only been running it for
15 minutes so I can't tell for sure yet. :)
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Fri, 5 Feb 1999, Charles Hill wrote:
>
> I got those, too. I did a "set accounting log_UNAUTHENTICATED_CALLS
> false" to and they stopped.
>
> -CH
>
> On Thu, 4 Feb 1999, Paul M. Oster wrote:
>
> >
> >
> > Umm... I've got a hyperarc which is mis-sending some accounting stuff,
> > every botched packet (Radius STOP) lists the user as being on 62 million,
> > 2 hundred thousand and some odd seconds... or over 17 thousand hours (708
> > days or almost 2 YEARS).... I dont even have a chassis thats been IN
> > production that long :) Hyper Arc, just upgraded from a NetServer... any
> > suggestions as to whats wrong, and how to fix?
> >
> > Paul M. Oster <devious@minot.com> http://www.minot.com/
> > Magic Internet Services (701) 838-1265
> > Minots FIRST Internet Connection
> >
> > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
> >
> > "I might not agree with what you have to say but I will defend, to
> > my death, your right to say it." - Voltaire
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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) Eicon Diva TA From: Brian <signal@shreve.net> Date: 1999-02-05 09:21:41
I know I have asked this many times, but I promise this will be my last :)
Is anyone having problems with Eicon Diva TA? If so, please let me know,
we run HDM 1.2.6 code. Either way, I am going to open a trouble ticket
with 3Com, becuase I really believe their is an issue with that particular
modem. FYI, Eicon is the modem that Bellsouth pushes its customers to buy
when they subscribe to ISDN.
Brian
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) Offload or not offload From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-05 09:39:47
Using the latest released software on both DSP and Quads, with HiperARC's,
is PPP offloading currently recommended or not? Any issues with any
particular combination we should be aware of?
thanks,
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Subject:Re: (usr-tc) Is there a way to turn off --More-- prompts? From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-05 09:51:19
Yes - there is such a command...
HiPer>> set comMAND local_tERMINAL_SETTINGS_ROWS
This field is a Decimal Number within a Range
The valid range is 1-256
HiPer>> set comMAND local_tERMINAL_SETTINGS_ROWS 80
-- Matt
K Mitchell <mitch@keyconn.net> on 02/04/99 10:01:23 PM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
At 10:56 AM 2/4/99 -0600, "Matt Harper" <Matt_Harper@mw.3com.com> wrote:
>HiPer>> show comMAND seTTINGS
>
>COMMAND SETTINGS
>History Depth: 10
>Global Prompt: HiPer>>
>Local Prompt: HiPer>>
>Console Login Required: NO
>Console Idle Timeout: 5
>Current Idle Timeout: 0
>Global Terminal Settings Page-break: ENABLED
>Global Terminal Settings Rows: 23
>Local Terminal Settings Page-break: ENABLED
>Local Terminal Settings Rows: 23
Can the number of rows displayed be changed?
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) pri busy signals From: Jolliffe, Anu <ajolliffe@imagen.net> Date: 1999-02-05 10:18:20
I'm in the process of setting up an Enterprise Hub with a Dual Pri
interface. When I dial the number assigned to the PRI I get a busy signal.
I've been browsing through the messages from the last 3 months and have
found quite a number of different reasons for the busy signal. I've tried
most of the suggestions, but am still getting that damn busy signal. Anyone
have any bright ideas?
Thanx.
Subject:Re: (usr-tc) Yikes, filters broken in arc V4.1.63? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-05 10:30:06
Thus spake Aaron Nabil
>Jeff Mcadams writes...
>>BTW, .59 has the "set modem_group all prompt_delay <n>" command that
>>will enable us to start moving our hunt group over to HiPer Arcs from
>>NETServers.
>It doesn't work for me.
>usr2> _show ver
>V4.1.59 - 1
>usr2> set modem_group all prompt_delay 5
>CLI - Invalid Argument: prompt_delay
Hrmm...mine is -2. Can 3Com's release numbering get any more confusing?
Sorry about that.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) DSP problems From: Charles Sprickman <spork@inch.com> Date: 1999-02-05 11:27:32
Hi,
Yesterday I finally installed our ARC/DSP updgrades. We're now about 50%
DSP for dialin. Today, we're getting a ton of calls about disconnects and
problems with handshaking.
Is this normal? I always assumed the quads would be less compatible as
they run much older code, but that doesn't seem to be the case...
Also, if we just have to live with it, can anyone recommend the best sites
for our support people to visit to familiarize themselves with client
modem issues?
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Charles,
We are in the same situation
50% converted
Latest Code running
I would estimate about 5-10% of our user base is having problems (> 1000
people) with handshaking & disconnects. With many modems that do not
handshake.
I am seriously thinking of putting the Quad's/Netserver's back in
production.
John
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman
> Sent: Friday, February 05, 1999 11:28 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) DSP problems
>
>
> Hi,
>
> Yesterday I finally installed our ARC/DSP updgrades. We're now about 50%
> DSP for dialin. Today, we're getting a ton of calls about disconnects and
> problems with handshaking.
>
> Is this normal? I always assumed the quads would be less compatible as
> they run much older code, but that doesn't seem to be the case...
>
> Also, if we just have to live with it, can anyone recommend the best sites
> for our support people to visit to familiarize themselves with client
> modem issues?
>
> Thanks,
>
> Charles
>
> --
> =-----------------= =
> | Charles Sprickman Internet Channel |
> | INCH System Administration Team (212)243-5200 |
> | spork@inch.com access@inch.com |
> = =----------------=
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Wayne Barber said once upon a time:
>
>I just noticed there is new code on the totalservice web page for the DSP
>cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
>
>Documentation says it has a partial fix for Rockwell v.90 disconnection
>problem. Has anyone tried it yet?
I'm going to throw it on next Tuesday morning. I'll report back on it if
anything is noticeable.
Let me be the first to applaud 3com in making this code freely available,
even for a limited time.
Subject:RE: (usr-tc) Windows NT users can't browse From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-05 12:07:45
Disable LCP extensions on the NT client
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 Ralph Helfenberger
Sent: Friday, February 05, 1999 11:22 AM
I tried to turn off software compression on the netserver
set ccp off
and to turn compression off also on the NT client. Still the problem
is here. I reset the card with Dipswitch 5, no change.
Interesting: if I turn debug on I get an error message as soon as I
start the Browser on the client. The message reads:
net: Bad wanted 54679, got 171
Has anybody any clues what this message means?
Thanks
Ralph
Jeff Mcadams wrote:
>
> Thus spake Ralph Helfenberger
> >If I connect to the same system, same username/password I also get
> >connected, I can ping everything (including ping www.xxxx.xx). But if I
> >open a Browser I just can't get any data from the WWW. It happens with
> >different NT Systems.
>
> Turn off software compression.
> --
> Jeff McAdams Email: jeffm@iglou.com
> Head Network Administrator Voice: (502) 966-3848
> IgLou Internet Services (800) 436-4456
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Charles Sprickman said once upon a time:
>In unresolved issues, I still see #MR 1829 that states "selective reject
>is disabled by default". What's the net effect of that setting?
That was an aspect of v.42, that just makes for smoother connections if you
shut it off.
I just noticed there is new code on the totalservice web page for the DSP
cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
Documentation says it has a partial fix for Rockwell v.90 disconnection
problem. Has anyone tried it yet?
For modem issues, try http://www.56k.com which has a lot of information
about modems. They have init strings you can try with Rockwell modems that
tells them to connect at v.34 rather than 56k. I've "cured" a lot of
problems with that. Another good site is http://www.808hi.com/56k which has
the latest drivers for LT winmodems, which works quite well with the TC hub.
Wayne Barber
Coastal Telco Services
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman
> Sent: Friday, February 05, 1999 11:28 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) DSP problems
>
>
> Hi,
>
> Yesterday I finally installed our ARC/DSP updgrades. We're now about 50%
> DSP for dialin. Today, we're getting a ton of calls about disconnects and
> problems with handshaking.
>
> Is this normal? I always assumed the quads would be less compatible as
> they run much older code, but that doesn't seem to be the case...
>
> Also, if we just have to live with it, can anyone recommend the best sites
> for our support people to visit to familiarize themselves with client
> modem issues?
>
> Thanks,
>
> Charles
>
> --
> =-----------------= =
> | Charles Sprickman Internet Channel |
> | INCH System Administration Team (212)243-5200 |
> | spork@inch.com access@inch.com |
> = =----------------=
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:RE: (usr-tc) pri busy signals From: Jolliffe, Anu <ajolliffe@imagen.net> Date: 1999-02-05 13:47:56
I found a solution.
Thanx.
-----Original Message-----
Sent: Friday, February 05, 1999 10:18 AM
I'm in the process of setting up an Enterprise Hub with a Dual Pri
interface. When I dial the number assigned to the PRI I get a busy signal.
I've been browsing through the messages from the last 3 months and have
found quite a number of different reasons for the busy signal. I've tried
most of the suggestions, but am still getting that damn busy signal. Anyone
have any bright ideas?
Thanx.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
On Fri, 5 Feb 1999, Wayne Barber wrote:
> I just noticed there is new code on the totalservice web page for the DSP
> cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
>
> Documentation says it has a partial fix for Rockwell v.90 disconnection
> problem. Has anyone tried it yet?
That's interesting... Can anyone share their experiences with this code?
Especially someone with some "test cases".
In unresolved issues, I still see #MR 1829 that states "selective reject
is disabled by default". What's the net effect of that setting?
Thanks,
Charles
>
> For modem issues, try http://www.56k.com which has a lot of information
> about modems. They have init strings you can try with Rockwell modems that
> tells them to connect at v.34 rather than 56k. I've "cured" a lot of
> problems with that. Another good site is http://www.808hi.com/56k which has
> the latest drivers for LT winmodems, which works quite well with the TC hub.
>
> Wayne Barber
> Coastal Telco Services
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman
> > Sent: Friday, February 05, 1999 11:28 AM
> > To: usr-tc@lists.xmission.com
> > Subject: (usr-tc) DSP problems
> >
> >
> > Hi,
> >
> > Yesterday I finally installed our ARC/DSP updgrades. We're now about 50%
> > DSP for dialin. Today, we're getting a ton of calls about disconnects and
> > problems with handshaking.
> >
> > Is this normal? I always assumed the quads would be less compatible as
> > they run much older code, but that doesn't seem to be the case...
> >
> > Also, if we just have to live with it, can anyone recommend the best sites
> > for our support people to visit to familiarize themselves with client
> > modem issues?
> >
> > Thanks,
> >
> > Charles
> >
> > --
> > =-----------------= =
> > | Charles Sprickman Internet Channel |
> > | INCH System Administration Team (212)243-5200 |
> > | spork@inch.com access@inch.com |
> > = =----------------=
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Windows NT users can't browse From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-05 14:21:35
Thus spake Ralph Helfenberger
>I tried to turn off software compression on the netserver
>set ccp off
Ack...I mis-spoke earlier...not software compression...VJ header
compression. Basically, VJ is a TCP header compression, so only TCP
packets will get messed up, so you were seeing UDP (DNS requests and
replies), and ICMP (ping and ping replies) were going through correctly,
but when it came time to actually load pages and stuff, the TCP
connections (http/web requests and replies) got messed up by the
header compression.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) pri busy signals From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-05 14:22:12
Thus spake Jolliffe, Anu
>I'm in the process of setting up an Enterprise Hub with a Dual Pri
>interface. When I dial the number assigned to the PRI I get a busy signal.
>I've been browsing through the messages from the last 3 months and have
>found quite a number of different reasons for the busy signal. I've tried
>most of the suggestions, but am still getting that damn busy signal. Anyone
>have any bright ideas?
Are you getting a fast busy signal or a normal busy signal?
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Stacking for MPP From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-05 14:25:58
Thus spake King Wee
>Has anybody tried stacking USR TC using HiperDSPs for MPP ISDN calls? Any
>idea what is the maximum number that we can stack before the whole system
>becomes unstable?
Don't have too many of the DSP's, but have quite a few of the older
quads that I'm running via MPIP on NETServers by and large. I've got 17
NETServers and 1 Arc now pointing MPIP service at a single Arc as an
MPIP server. (the MPIP server arc is a different arc from the arc
taking calls)
MPIP is not particularly reliable, but I don't think that's particularly
an issue of the number of chassis involved in the hunt group and more a
matter that MPIP is still just a bit buggy. It's gotten a *whole* lot
better over the past 6 months or so with a *ton* of hounding from me and
probably others about it, but its still not perfect on the
NETServers...I can't comment too much on MPIP on the Arc's yet.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
I've just flashed 10 DSP's and put them into production with 1.2.59
I'll report on success (note positive attitude) next week.
John
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown
> Sent: Friday, February 05, 1999 2:09 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) DSP problems
>
>
> Charles Sprickman said once upon a time:
>
> >In unresolved issues, I still see #MR 1829 that states "selective reject
> >is disabled by default". What's the net effect of that setting?
>
> That was an aspect of v.42, that just makes for smoother
> connections if you
> shut it off.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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 problems From: Brian <signal@shreve.net> Date: 1999-02-05 14:45:47
On Fri, 5 Feb 1999, Wayne Barber wrote:
> I just noticed there is new code on the totalservice web page for the DSP
> cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
>
> Documentation says it has a partial fix for Rockwell v.90 disconnection
> problem. Has anyone tried it yet?
>
Id be very interested in hearing reports good or bad about
1.2.59.......anyone?
> For modem issues, try http://www.56k.com which has a lot of information
> about modems. They have init strings you can try with Rockwell modems that
> tells them to connect at v.34 rather than 56k. I've "cured" a lot of
> problems with that. Another good site is http://www.808hi.com/56k which has
> the latest drivers for LT winmodems, which works quite well with the TC hub.
>
> Wayne Barber
> Coastal Telco Services
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman
> > Sent: Friday, February 05, 1999 11:28 AM
> > To: usr-tc@lists.xmission.com
> > Subject: (usr-tc) DSP problems
> >
> >
> > Hi,
> >
> > Yesterday I finally installed our ARC/DSP updgrades. We're now about 50%
> > DSP for dialin. Today, we're getting a ton of calls about disconnects and
> > problems with handshaking.
> >
> > Is this normal? I always assumed the quads would be less compatible as
> > they run much older code, but that doesn't seem to be the case...
> >
> > Also, if we just have to live with it, can anyone recommend the best sites
> > for our support people to visit to familiarize themselves with client
> > modem issues?
> >
> > Thanks,
> >
> > Charles
> >
> > --
> > =-----------------= =
> > | Charles Sprickman Internet Channel |
> > | INCH System Administration Team (212)243-5200 |
> > | spork@inch.com access@inch.com |
> > = =----------------=
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:RE: (usr-tc) DSP problems From: Brian <signal@shreve.net> Date: 1999-02-05 14:48:36
On Fri, 5 Feb 1999, Charles Sprickman wrote:
> On Fri, 5 Feb 1999, Wayne Barber wrote:
>
> > I just noticed there is new code on the totalservice web page for the DSP
> > cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
> >
> > Documentation says it has a partial fix for Rockwell v.90 disconnection
> > problem. Has anyone tried it yet?
>
> That's interesting... Can anyone share their experiences with this code?
> Especially someone with some "test cases".
>
> In unresolved issues, I still see #MR 1829 that states "selective reject
> is disabled by default". What's the net effect of that setting?
I am sure I'll be corrected, but basically the modems send big chunks of
data back and forth, and as you know, for clean lines, bigger chunks work
better, and for problematic lines, smaller chunks work better. If a CRC
error is found on a large chunk, the entire chunk is resent. With
selective reject, its my understanding that only the bad part of the chunk
is rejected, and thus resent, and the rest of it is processed/used.
>
> Thanks,
>
> Charles
>
> >
> > For modem issues, try http://www.56k.com which has a lot of information
> > about modems. They have init strings you can try with Rockwell modems that
> > tells them to connect at v.34 rather than 56k. I've "cured" a lot of
> > problems with that. Another good site is http://www.808hi.com/56k which has
> > the latest drivers for LT winmodems, which works quite well with the TC hub.
> >
> > Wayne Barber
> > Coastal Telco Services
> >
> > > -----Original Message-----
> > > From: owner-usr-tc@lists.xmission.com
> > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman
> > > Sent: Friday, February 05, 1999 11:28 AM
> > > To: usr-tc@lists.xmission.com
> > > Subject: (usr-tc) DSP problems
> > >
> > >
> > > Hi,
> > >
> > > Yesterday I finally installed our ARC/DSP updgrades. We're now about 50%
> > > DSP for dialin. Today, we're getting a ton of calls about disconnects and
> > > problems with handshaking.
> > >
> > > Is this normal? I always assumed the quads would be less compatible as
> > > they run much older code, but that doesn't seem to be the case...
> > >
> > > Also, if we just have to live with it, can anyone recommend the best sites
> > > for our support people to visit to familiarize themselves with client
> > > modem issues?
> > >
> > > Thanks,
> > >
> > > Charles
> > >
> > > --
> > > =-----------------= =
> > > | Charles Sprickman Internet Channel |
> > > | INCH System Administration Team (212)243-5200 |
> > > | spork@inch.com access@inch.com |
> > > = =----------------=
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the message.
> > > For information on digests or retrieving files and old messages send
> > > "help" to the same address. Do not use quotes in your message.
> > >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) DSP problems From: Brian <signal@shreve.net> Date: 1999-02-05 14:49:13
On Fri, 5 Feb 1999, Pete Ashdown wrote:
> Wayne Barber said once upon a time:
> >
> >I just noticed there is new code on the totalservice web page for the DSP
> >cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
> >
> >Documentation says it has a partial fix for Rockwell v.90 disconnection
> >problem. Has anyone tried it yet?
>
> I'm going to throw it on next Tuesday morning. I'll report back on it if
> anything is noticeable.
>
> Let me be the first to applaud 3com in making this code freely available,
> even for a limited time.
I agree, making the service releases freely available is much appreciated.
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-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Hiper Arc? From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-05 15:08:19
When I reboot the Hiper Arc it knocks all connections off of my Single sided
Quad modem cards but my 2 DSP cards in this chassis seem to be not effected.
Is this normal behavior? Should my connections not be lost when I reboot or
should they all drop?
I am running the Latest code on the Hiper Arc. 4.1.59-1 and also the latest
on my DSP and Quads.
Thanks
Paul JR.
AlaWeb Support
1800-427-8896
http://www.alaweb.com/support.html
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Jr. (AlaWeb
|Support)
|Sent: Friday, February 05, 1999 3:08 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Hiper Arc?
|
|
|When I reboot the Hiper Arc it knocks all connections off of my Single sided
|Quad modem cards but my 2 DSP cards in this chassis seem to be not effected.
|Is this normal behavior? Should my connections not be lost when I reboot or
|should they all drop?
|
|I am running the Latest code on the Hiper Arc. 4.1.59-1 and also the latest
|on my DSP and Quads.
|
It knocks them all off. It just takes the DSP a little longer to realize it has
lost its connection to the HARC.
-M
anyone have a reference for the _ commands? IOW I know
_auth and _show. any others?
thanks, blake
-----Original Message-----
Sent: Friday, February 05, 1999 9:19 AM
Jeff Mcadams writes...
>BTW, .59 has the "set modem_group all prompt_delay <n>" command that
>will enable us to start moving our hunt group over to HiPer Arcs from
>NETServers.
It doesn't work for me.
usr2> _show ver
V4.1.59 - 1
usr2> set modem_group all prompt_delay 5
CLI - Invalid Argument: prompt_delay
--
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.
Installing it now ... I'll report back if I have problems ...
-----Original Message-----
>On Fri, 5 Feb 1999, Wayne Barber wrote:
>
>> I just noticed there is new code on the totalservice web page for the DSP
>> cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
>>
>> Documentation says it has a partial fix for Rockwell v.90 disconnection
>> problem. Has anyone tried it yet?
>>
>
>
>Id be very interested in hearing reports good or bad about
>1.2.59.......anyone?
>
>
>> For modem issues, try http://www.56k.com which has a lot of information
>> about modems. They have init strings you can try with Rockwell modems
that
>> tells them to connect at v.34 rather than 56k. I've "cured" a lot of
>> problems with that. Another good site is http://www.808hi.com/56k which
has
>> the latest drivers for LT winmodems, which works quite well with the TC
hub.
>>
>> Wayne Barber
>> Coastal Telco Services
>>
>> > -----Original Message-----
>> > From: owner-usr-tc@lists.xmission.com
>> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman
>> > Sent: Friday, February 05, 1999 11:28 AM
>> > To: usr-tc@lists.xmission.com
>> > Subject: (usr-tc) DSP problems
>> >
>> >
>> > Hi,
>> >
>> > Yesterday I finally installed our ARC/DSP updgrades. We're now about
50%
>> > DSP for dialin. Today, we're getting a ton of calls about disconnects
and
>> > problems with handshaking.
>> >
>> > Is this normal? I always assumed the quads would be less compatible as
>> > they run much older code, but that doesn't seem to be the case...
>> >
>> > Also, if we just have to live with it, can anyone recommend the best
sites
>> > for our support people to visit to familiarize themselves with client
>> > modem issues?
>> >
>> > Thanks,
>> >
>> > Charles
>> >
>> > --
>> > =-----------------= =
>> > | Charles Sprickman Internet Channel |
>> > | INCH System Administration Team (212)243-5200 |
>> > | spork@inch.com access@inch.com |
>> > = =----------------=
>> >
>> >
>> > -
>> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> > with "unsubscribe usr-tc" in the body of the message.
>> > For information on digests or retrieving files and old messages send
>> > "help" to the same address. Do not use quotes in your message.
>> >
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the 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-26318 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) Strange bug: HARC not logging over long periods of time From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-05 16:05:01
Bruno Treguier said once upon a time:
>We just had, yesterday, a very very strange thing with our HARC running
>4.1.72-7: it simply stopped sending RADIUS accounting information, as well
>as any other syslog logging packets, for several hours. This happened, for
>example, from Feb 4 16:46 to Feb 5 3:02, and several other times after
>that...
>
>I checked many things on the servers, like disk space, other logs and all,
>and the only possible culprit is the HiperARC.
>
>Apart from that, everything seemed to run fine, connections were still
>possible... The strangest thing being that we use RADIUS for authentication
>as well ! So it seems that only the logging facility was affected,
>during several hours...
What did the memory usage on your ARC look like? Is your ARC firewalled
from the outside?
Subject:(usr-tc) Netserver 3.8.1 rejecting MLPPP connects. From: Charles Hill <chill@ionet.net> Date: 1999-02-05 16:32:21
I have an Ascend Pipeline 75 running 6.1.7 trying to connect to a
Netserver v.3.8.1 and I'm getting NAKs on the MRRU of 1524. I was able to
get it to connect when I set the MRU on the Pipeline to 1500, but I'm
still curious about why it was necessary. Why, technically, won't the
Netserver accept 1524?
-CH
Sending LCP_CONFIGURE_REQUEST to port I34 of 33 bytes containing:
01 0A 00 21 01 04 05 DC 11 04 05 DC 13 07 04 52 DA C8 B9
05 06 BC 32 3A 33 07 02 08 02 03 04 C0 23
Packet Info: Code: 0x01, ID: 0x0A, 33 bytes.
Maximum-Receive-Unit [0x01], length: (4 bytes) 1500 bytes [0x05DC]
Multilink-MRRU [0x11], length: (4 bytes), [0x05DC]
Max-Receive-Reconstructed-Unit (MRRU): 1500 bytes.
Multilink-Endpoint-Discriminator [0x13], length: (7 bytes),
[0x0452DAC8B9]
Class [0x04]: PPP Magic-Number Block 52 DA C8 B9
Magic-Number [0x05], length: (6 bytes), [0xBC323A33]
Protocol-Field-Compression [0x07], length: (2 bytes)
Address-and-Control-Field-Compression [0x08], length: (2 bytes)
Authentication-Protocol [0x03], length: (4 bytes), Password
Authentication Protocol [0xC023]
Received LCP_CONFIGURE_REQUEST on port I34 of 21 bytes containing:
01 01 00 19 00 04 00 00 01 04 05 F4 11 04 05 F4 13 09 03
00 C0 7B 80 D0 5A
Packet Info: Code: 0x01, ID: 0x01, 25 bytes.
Maximum-Receive-Unit [0x01], length: (4 bytes) 1524 bytes [0x05F4]
Multilink-MRRU [0x11], length: (4 bytes), [0x05F4]
Max-Receive-Reconstructed-Unit (MRRU): 1524 bytes.
Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
[0x0300C07B80D05A]
Class [0x03]: IEEE 802.1 MAC Address 00 C0 7B 80 D0 5A
Sending LCP_CONFIGURE_REJECT to port I34 of 8 bytes containing:
04 01 00 08 00 04 00 00
Packet Info: Code: 0x04, ID: 0x01, 8 bytes.
Connection Failed
On Fri, 5 Feb 1999, Brian wrote:
> On Fri, 5 Feb 1999, Charles Sprickman wrote:
>
> > On Fri, 5 Feb 1999, Wayne Barber wrote:
> >
> > > I just noticed there is new code on the totalservice web page for the DSP
> > > cards. It is 1.2.59 service release, which I assume is newer than 1.2.60?
> > >
> > > Documentation says it has a partial fix for Rockwell v.90 disconnection
> > > problem. Has anyone tried it yet?
> >
> > That's interesting... Can anyone share their experiences with this code?
> > Especially someone with some "test cases".
> >
> > In unresolved issues, I still see #MR 1829 that states "selective reject
> > is disabled by default". What's the net effect of that setting?
>
> I am sure I'll be corrected, but basically the modems send big chunks of
> data back and forth, and as you know, for clean lines, bigger chunks work
> better, and for problematic lines, smaller chunks work better. If a CRC
> error is found on a large chunk, the entire chunk is resent. With
> selective reject, its my understanding that only the bad part of the chunk
> is rejected, and thus resent, and the rest of it is processed/used.
Why is SREJ default ON on the quads but default off on the HDMs? Is
SREJ broken on the HDMs? SREJ sounds like a big advantage on noisy
lines with lots of retransmissions.
Subject:Re: (usr-tc) Stacking for MPP From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-05 17:19:26
Jeff Mcadams said once upon a time:
>probably others about it, but its still not perfect on the
>NETServers...I can't comment too much on MPIP on the Arc's yet.
It isn't perfect on the ARC yet either.
Subject:Re: (usr-tc) Yikes, filters broken in arc V4.1.63? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-05 17:28:00
Thus spake Blake Fithen
>anyone have a reference for the _ commands? IOW I know
>_auth and _show. any others?
Well...last time I mentioned any unsupported stuff I had a 3Com person
write me about the existence of the "_" commands in the Harc, so I guess
they're really not keeping them secret.
Most significant is the "_reveal commands" command. :)
After that, if you just type "?" at the command line, all the "_"
commands are in there as well.
Some really useful commands in there...some that are really dangerous,
some that aren't so dangerous...so be careful.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake Charles Hill
>I have an Ascend Pipeline 75 running 6.1.7 trying to connect to a
>Netserver v.3.8.1 and I'm getting NAKs on the MRRU of 1524. I was able to
>get it to connect when I set the MRU on the Pipeline to 1500, but I'm
>still curious about why it was necessary. Why, technically, won't the
>Netserver accept 1524?
I guess they're just statically carving up some memory expecting to
handle 1500 byte packets at most, so it can't handle 1524.
Given that the PPP RFC doesn't require them to accept more than 1500,
the pipe really should back down to that.
>Sending LCP_CONFIGURE_REQUEST to port I34 of 33 bytes containing:
^^^
Ew...still using the Munich card? Might want to switch you ISDN gateway
setting to use the quad I-modems....much better performance from what
I've seen...particularly when dealing with a full chassis.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Is there a way to turn off --More-- prompts? From: K Mitchell <mitch@keyconn.net> Date: 1999-02-05 17:59:41
At 09:51 AM 2/5/99 -0600, Matt Harper wrote:
>Yes - there is such a command...
>
>HiPer>> set comMAND local_tERMINAL_SETTINGS_ROWS
>This field is a Decimal Number within a Range
> The valid range is 1-256
>HiPer>> set comMAND local_tERMINAL_SETTINGS_ROWS 80
Thanks, I was omitting <command>
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) Windows NT users can't browse From: Ralph Helfenberger <rhelfenberger@comlight.ch> Date: 1999-02-05 19:22:14
I tried to turn off software compression on the netserver
set ccp off
and to turn compression off also on the NT client. Still the problem
is here. I reset the card with Dipswitch 5, no change.
Interesting: if I turn debug on I get an error message as soon as I
start the Browser on the client. The message reads:
net: Bad wanted 54679, got 171
Has anybody any clues what this message means?
Thanks
Ralph
Jeff Mcadams wrote:
>
> Thus spake Ralph Helfenberger
> >If I connect to the same system, same username/password I also get
> >connected, I can ping everything (including ping www.xxxx.xx). But if I
> >open a Browser I just can't get any data from the WWW. It happens with
> >different NT Systems.
>
> Turn off software compression.
> --
> 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) Stacking for MPP From: King Wee <kingwee@pacific.net.sg> Date: 1999-02-05 19:27:43
Hi,
Has anybody tried stacking USR TC using HiperDSPs for MPP ISDN calls? Any
idea what is the maximum number that we can stack before the whole system
becomes unstable?
Thank you and regards,
Matthias
"He is no fool,
who gives what he cannot keep,
to gain what he cannot lose."
Subject:(usr-tc) pri busy signals From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-05 19:34:00
-> I'm in the process of setting up an Enterprise Hub with a Dual Pri
-> interface. When I dial the number assigned to the PRI I get a busy signal.
-> I've been browsing through the messages from the last 3 months and have
-> found quite a number of different reasons for the busy signal. I've tried
-> most of the suggestions, but am still getting that damn busy signal. Anyone
-> have any bright ideas?
The #1 cause is to go to the TCM and issue an "IN SERVICE" command against the
PRIs and that generally fixes it as long as you have the quads pointing to the
correct line interface. I have always wished 3Com would add this as an option
for Auto Response for when a T-1 drops and recovers.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) Stacking for MPP From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-05 20:22:15
Thus spake Pete Ashdown
>Jeff Mcadams said once upon a time:
>>probably others about it, but its still not perfect on the
>>NETServers...I can't comment too much on MPIP on the Arc's yet.
>It isn't perfect on the ARC yet either.
So I can look forward to my trouble ticket having a birthday
then...lovely.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Once upon a time Brian Uechi shaped the electrons to say...
>Why is SREJ default ON on the quads but default off on the HDMs? Is
>SREJ broken on the HDMs? SREJ sounds like a big advantage on noisy
>lines with lots of retransmissions.
I know that while at Livingston/Lucent they complete removed support for
SREJ from the modems - because way too many client mdoems have buggy SREJ
code, and if you actually try to use it it just FUBARS the whole deal.
Since it really doesn't provide a noticable advantage it was better not
to try it than try to explain to clients that their $29 modem is crap.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
Once upon a time David Bolen shaped the electrons to say...
>I'd hate to penalize everyone because some client modems get it wrong
>though, since you can always disable it in the client.
True - but it seems like not many clients use it. And it seems like most
ISPs would rather not have to work with each customer on modem init strings.
That much is evidenced by the threads on having to do so with various PCM
modems.
Of course, in a perfect world there would be no bugs and everything would
talk happily. :-)
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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) Strange bug: HARC not logging over long periods of time From: Bruno Treguier <bruno.treguier@infini.fr> Date: 1999-02-05 22:16:28
Hello all,
We just had, yesterday, a very very strange thing with our HARC running
4.1.72-7: it simply stopped sending RADIUS accounting information, as well
as any other syslog logging packets, for several hours. This happened, for
example, from Feb 4 16:46 to Feb 5 3:02, and several other times after
that...
I checked many things on the servers, like disk space, other logs and all,
and the only possible culprit is the HiperARC.
Apart from that, everything seemed to run fine, connections were still
possible... The strangest thing being that we use RADIUS for authentication
as well ! So it seems that only the logging facility was affected,
during several hours...
Has anyone seen that before ?
Thanks,
Bruno
Pete Ashdown <pashdown@xmission.com> writes:
> That was an aspect of v.42, that just makes for smoother connections if you
> shut it off.
Hmm, barring implementation bugs, the smoother connections should be
if V.42 selective reject is enabled and negotiated by the modems. I
don't think too many client modems aside from 3Com implement it, but
it's definitely a good thing. My understanding is that it is an
optional part of the V.42 standard.
Depending on the particular modems in use, and especially during the
early x2 days, using selective reject did cause some problems in the
past due to bugs in the implementation (either on client or server),
generally resulting in either a hung session (often eventually
disconnected by the server due to a retransmit limit error) or a quick
disconnect.
Without selective reject, V.42 must retransmit all blocks from a
failed block onwards (e.g., generally retransmitting a bunch of good
information) within its window of data sent to the remote modem. With
selective reject, only the failed block is retransmitted, even if in
the middle of other data that got through successfully. If you have
perfect lines with no block errors or retransmissions, there is no
difference with or without selective reject but only any lines with
errors it will be a higher performance session since you aren't double
transmitting data.
The original HDM code (not sure if only beta or the first production
round) had some issues with selective reject and it got disabled by
default in the configuration - not sure why that hasn't been changed,
but maybe its only to stay compatible with earlier releases.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| UUNET Technologies, Inc. \ Phone: (914) 701-5327 |
/ 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \
\-----------------------------------------------------------------------/
MegaZone <megazone@megazone.org> writes:
> Since it really doesn't provide a noticable advantage it was better not
> to try it than try to explain to clients that their $29 modem is crap.
I don't know about noticeable, but it's certainly a measurable
advantage (I would find at times 6-10%) over not having it if you have
any decent level of errors (which can happen under normal
circumstances even on fairly good lines).
I do agree, however, that you're certainly not going to get a
noticeable advantage if the implementation is broken :-)
I'd hate to penalize everyone because some client modems get it wrong
though, since you can always disable it in the client.
-- 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) pri busy signals From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)"> Date: 1999-02-06 00:13:26
Bear in mind that I've only set up maybe a dozen of these from scratch but
the biggest cause of a busy signal I've seen when trying to set up is just
plain misconfiguration between the PRI card and whatever the telco has the
PRI set at. One such session I chuckle about now (mind you, I was quite
irritated at the time it was happening) I had spent several hours on site at
the remote POP getting the equipment in place, setting up the frame relay
interface on the netserver, getting everythign routing right, etc, spent 2
hours driving back to the office and began to play with the span settings a
bit to see if I could get some calls up. After verifying that all settings
were the same as one of my other PRI cards, and spending two bloody hours on
the phone with the telco trying this and that I was ready to give up. Then
(and this is the funny part) the guy at the switch says, "oh, wait a
minute"...puts me on hold for about 5 minutes...meanwhile I'm staring at TCM
and I all of a sudden see calls up on the quads. The guy comes back on the
phone and says "hey, there are calls up...WHAT DID YOU DO???"
heh...that's telco for ya...
Matthew Stainforth
Technical Services Manager
BrunNet Inc.
-----Original Message-----
Sent: 2/5/99 8:34 PM
-> I'm in the process of setting up an Enterprise Hub with a Dual Pri
-> interface. When I dial the number assigned to the PRI I get a busy
signal.
-> I've been browsing through the messages from the last 3 months and
have
-> found quite a number of different reasons for the busy signal. I've
tried
-> most of the suggestions, but am still getting that damn busy signal.
Anyone
-> have any bright ideas?
The #1 cause is to go to the TCM and issue an "IN SERVICE" command
against the
PRIs and that generally fixes it as long as you have the quads pointing
to the
correct line interface. I have always wished 3Com would add this as an
option
for Auto Response for when a T-1 drops and recovers.
Jeff Binkley
ASA Network Computing
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
David Bolen writes...
> . . .
>The original HDM code (not sure if only beta or the first production
>round) had some issues with selective reject and it got disabled by
>default in the configuration - not sure why that hasn't been changed,
>but maybe its only to stay compatible with earlier releases.
The hiperdsp jitter attenuation default is also wrong, 3com knows
this, but hasn't fixed it. So I'm guessing that it's something more
substantial than just a minor tweak to fix. Maybe something to do
with compatibility with the stored configuration.
--
Aaron Nabil
Subject:RE: (usr-tc) pri busy signals From: Dwight G. Jones <djones@imagen.net> Date: 1999-02-06 12:13:40
That was our problem. The Telco said they had turned it up, when they
hadn't.
Seems it's never enough to do your own job, you have to do the next guy's as
well...
Dwight
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew
(Sys Mgr - BrunNet)
Sent: Friday, February 05, 1999 8:13 PM
Bear in mind that I've only set up maybe a dozen of these from scratch but
the biggest cause of a busy signal I've seen when trying to set up is just
plain misconfiguration between the PRI card and whatever the telco has the
PRI set at. One such session I chuckle about now (mind you, I was quite
irritated at the time it was happening) I had spent several hours on site at
the remote POP getting the equipment in place, setting up the frame relay
interface on the netserver, getting everythign routing right, etc, spent 2
hours driving back to the office and began to play with the span settings a
bit to see if I could get some calls up. After verifying that all settings
were the same as one of my other PRI cards, and spending two bloody hours on
the phone with the telco trying this and that I was ready to give up. Then
(and this is the funny part) the guy at the switch says, "oh, wait a
minute"...puts me on hold for about 5 minutes...meanwhile I'm staring at TCM
and I all of a sudden see calls up on the quads. The guy comes back on the
phone and says "hey, there are calls up...WHAT DID YOU DO???"
heh...that's telco for ya...
Matthew Stainforth
Technical Services Manager
BrunNet Inc.
-----Original Message-----
Sent: 2/5/99 8:34 PM
-> I'm in the process of setting up an Enterprise Hub with a Dual Pri
-> interface. When I dial the number assigned to the PRI I get a busy
signal.
-> I've been browsing through the messages from the last 3 months and
have
-> found quite a number of different reasons for the busy signal. I've
tried
-> most of the suggestions, but am still getting that damn busy signal.
Anyone
-> have any bright ideas?
The #1 cause is to go to the TCM and issue an "IN SERVICE" command
against the
PRIs and that generally fixes it as long as you have the quads pointing
to the
correct line interface. I have always wished 3Com would add this as an
option
for Auto Response for when a T-1 drops and recovers.
Jeff Binkley
ASA Network Computing
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
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) Version numbers From: Bryan Wann <bwann@cwis.net> Date: 1999-02-06 15:38:46
Okay, let me get this straight, HiPer DSP 1.2.59 service release is newer
code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
I was talking to 3com support yesterday about an ARC card completely
going bezerk and losing its flash, first they said 4.1.72 was latest, then
later into the call he said 4.1.59-1 was the latest version.
Are there any additional strangeness about numbering schemes I should be
aware of, or am I just thinking too linear?
---
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
On Sat, 6 Feb 1999, Bryan Wann wrote:
>
> Okay, let me get this straight, HiPer DSP 1.2.59 service release is newer
> code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
The numbering scheme is like that. The GA release of 4.1 code was 4.1.11
The first ER release of this code was 4.1.99 ...
The First service release of this case was 4.1.72 - 7
The second service release of this code is 4.1.59 -1
>
> I was talking to 3com support yesterday about an ARC card completely
> going bezerk and losing its flash, first they said 4.1.72 was latest, then
> later into the call he said 4.1.59-1 was the latest version.
It all depends when you were talking the code was posted 2 days ago and
the tech may not realized or be aware of this posting when he was talking
to you.
You say here that the ARC card is losing its flash ? Could you explain
what exactly is happening?
krish
>
> Are there any additional strangeness about numbering schemes I should be
> aware of, or am I just thinking too linear?
>
>
>
> ---
> 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
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Version numbers From: Bryan Wann <bwann@cwis.net> Date: 1999-02-06 16:49:37
On Sat, 6 Feb 1999, Tatai SV Krishnan wrote:
> The numbering scheme is like that. The GA release of 4.1 code was 4.1.11
>
> The first ER release of this code was 4.1.99 ...
>
> The First service release of this case was 4.1.72 - 7
> The second service release of this code is 4.1.59 -1
Ah, okay, thanks!
> It all depends when you were talking the code was posted 2 days ago and
> the tech may not realized or be aware of this posting when he was talking
> to you.
>
> You say here that the ARC card is losing its flash ? Could you explain
> what exactly is happening?
I am not exactly sure what caused the problem, can only explain what I
saw... Yesterday morning I went to get on the ARC to look at something,
and noticed that telnet and pings timed out. I could still hop on the
chassis with TCM, and it showed the ARC as yellow, could not reboot it. I
went on site, hooked my console to it, and saw the ARC was rebooting
itself, each time it reported:
Starting up the HiPer system Executive...
RoboExec couldn't open a string index file
Filename = PilgrimStrings.ind, error = -142 (0)
EXCEPTION 0000 CRASH DUMP:
<registers (?) dump followed, then reboot>
I tried power cycling the chassis, same problem. I pulled the NAC card
out, reseated it, same problem, kept rebooting. By that time the office
where the equipment was closing, so I hooked the console to a Portmaster
serial port so I could access it from remote later.
I got back to the office about 30 minutes later, hopped on the console of
the ARC, then it started reporting "Auto-load failed." and said it needed
software download.
That was when I called 3com. First suggested reseating NIC/NAC cards, and
swapping slots. When I mentioned the software download error, he faxed me
instructions on how to upload code via hyperterminal/console, and said I
might as well get 4.1.59-2 while I was doing it. I put 4.1.72 back on the
chassis for the time being, reconfigured it, everything is working
normally, I have been dialed up all day to it today with no problems.
The only thing "out of the ordinary" I remember doing the night before was
playing with MPPP and compression over dialups. Until then, this box has
been in service for two weeks with light load without any other problems.
I can provide captured dumps if this will help.
---
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
Is there a way to setup an admin/telnet user for the ARC via RADIUS? I
just setup an ARC in a remote POP, and now that I'm back home, I found out
that I didn't setup an administrative/telnet user on the card (argh!!).
ask them about 4.1.59-9
-----Original Message-----
>
>Okay, let me get this straight, HiPer DSP 1.2.59 service release is newer
>code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
>
>I was talking to 3com support yesterday about an ARC card completely
>going bezerk and losing its flash, first they said 4.1.72 was latest, then
>later into the call he said 4.1.59-1 was the latest version.
>
>Are there any additional strangeness about numbering schemes I should be
>aware of, or am I just thinking too linear?
>
>
>
>---
>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
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) NMC problems and questions From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-06 19:30:20
1) What do dip switches 7 thru 10 on an NMC do? Switch 10 appears to dump
Phoenix BIOS output to the serial port. What about the others?
2) (Related to the above) Why would a serial cable with only tx+rx+ground
(3 wire), hooked up an NMC's serial port, work on a 4 meg NMC running
5.4.95, but once that NMC's upgraded to 14 meg running 5.5.5, it stops
working? The supplied USR cable hooked to a laptop will work in both
cases. A similar thing happens with newer ARC releases, but flipping dip
switch 5 up makes it work again.
3) I have an NMC card that doesn't like to boot. Most of the time, it
just puts the Run/Fail and Hub Status lights in red and leaves them there.
Sometimes, though, it will boot fine. I've tried swapping RAM and flash
(both with the 4 meg and the 16 meg code) with another good NMC and the
good NMC will boot OK. The times it boots fine are almost always with the
4 meg flash, almost never with the 16 meg. (With dip switch 10 on, the
Phoenix BIOS stuff shows up immediately if it's going to work, and never
if it isn't.)
Unfortunately this is only one of two NMC's I have with an x2 feature key
on it, or else I'd just use the other NMC. This was a 4 meg NMC that I'm
trying to get upgraded to 16 meg so I can swap my last NETserver out for
an ARC.
Any ideas how to revive this thing so it boots more consistently? I've
tried putting dip switches 5 and 6 up, tried putting the CMOS Clear jumper
(JP4/JP5) on clear for a few minutes, swapped flash simms, swapped ram
simms, all to no avail.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:RE: (usr-tc) Radius telnet/admin user? From: Brian K McIntire <bmcintire@commnet.com> Date: 1999-02-07 01:42:07
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown
> Sent: Saturday, February 06, 1999 6:51 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Radius telnet/admin user?
>
>
> Is there a way to setup an admin/telnet user for the ARC via RADIUS?
Yes, Service type administrative
I
> just setup an ARC in a remote POP, and now that I'm back home, I found out
> that I didn't setup an administrative/telnet user on the card (argh!!).
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) Quick question(s) about 4.1.59 From: vanhalen@coredcs.com Date: 1999-02-07 03:24:25
Hello,
I'm going to be upgrading our HiperArcs to 4.1.59 early next week, but in
the meantime can anyone who's running the code answer this quick question
about it:
Does the 'show connection <interface_name>' command show session stats
like characters sent/received? Does 'show all connections' do that?
I'm in the middle of writing a program to walk the boxes looking for
linecampers and I'd like to know if those new commands gimme the byte
transfers or if I have to do it via SNMP. Hey while I'm at it, if the new
'show conn' commands don't work, anyone know the SNMP oid's for characters
sent/received?
Thanks all!
Steve
Subject:(usr-tc) Sniffer software From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-07 07:51:00
I was wondering if anyone had some recommendations for either NT based or
Unix/Linux based packet sniffer type of software ? We don't have a great
need for it but occasionally it would be nice to trace things coming off
of our TC boxes.
Thanks,
Jeff Binkley
ASA Network Computing
We use EtherPeek on an NT machine.
http://www.aggroup.com/
Russ Miescke
Power Web Connect
russm@powerweb.net
http://www.powerweb.net
----- Original Message -----
Sent: Sunday, February 07, 1999 6:51 AM
>
>I was wondering if anyone had some recommendations for either NT based or
>Unix/Linux based packet sniffer type of software ? We don't have a great
>need for it but occasionally it would be nice to trace things coming off
>of our TC boxes.
>
> Thanks,
> Jeff Binkley
> ASA Network Computing
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) Sniffer software From: Mark R. Lindsey <mark@vielle.datasys.net> Date: 1999-02-07 14:40:49
: I was wondering if anyone had some recommendations for either NT based or
: Unix/Linux based packet sniffer type of software ? We don't have a great
: need for it but occasionally it would be nice to trace things coming off
: of our TC boxes.
tcpdump is the standard packet sniffer, and it's free. The book `TCP/IP
Illustrated' (W. Richard Stevens) uses tcpdump to illustrate the
operation of the protocols.
On Sat, 6 Feb 1999, Bryan Wann wrote:
> On Sat, 6 Feb 1999, Tatai SV Krishnan wrote:
>
> > The numbering scheme is like that. The GA release of 4.1 code was 4.1.11
> >
> > The first ER release of this code was 4.1.99 ...
> >
> > The First service release of this case was 4.1.72 - 7
> > The second service release of this code is 4.1.59 -1
>
> Ah, okay, thanks!
>
> > It all depends when you were talking the code was posted 2 days ago and
> > the tech may not realized or be aware of this posting when he was talking
> > to you.
> >
> > You say here that the ARC card is losing its flash ? Could you explain
> > what exactly is happening?
>
> I am not exactly sure what caused the problem, can only explain what I
> saw... Yesterday morning I went to get on the ARC to look at something,
> and noticed that telnet and pings timed out. I could still hop on the
> chassis with TCM, and it showed the ARC as yellow, could not reboot it. I
> went on site, hooked my console to it, and saw the ARC was rebooting
> itself, each time it reported:
>
The reason I can best think here is that the arc is is a download state.
There was an attept to download and that either failed or cause flash
corruption.
> Starting up the HiPer system Executive...
> RoboExec couldn't open a string index file
> Filename = PilgrimStrings.ind, error = -142 (0)
>
> EXCEPTION 0000 CRASH DUMP:
>
> <registers (?) dump followed, then reboot>
>
Need to get the registers to find out what the problem was.
>
> I tried power cycling the chassis, same problem. I pulled the NAC card
> out, reseated it, same problem, kept rebooting. By that time the office
> where the equipment was closing, so I hooked the console to a Portmaster
> serial port so I could access it from remote later.
>
> I got back to the office about 30 minutes later, hopped on the console of
> the ARC, then it started reporting "Auto-load failed." and said it needed
> software download.
>
As I said above there ARC has lost its router config and the flash is not
good. There was some type of flash upload intervention or something that
was corrupted in the flash that is causing this.
> That was when I called 3com. First suggested reseating NIC/NAC cards, and
> swapping slots. When I mentioned the software download error, he faxed me
> instructions on how to upload code via hyperterminal/console, and said I
> might as well get 4.1.59-2 while I was doing it. I put 4.1.72 back on the
> chassis for the time being, reconfigured it, everything is working
> normally, I have been dialed up all day to it today with no problems.
>
>
> The only thing "out of the ordinary" I remember doing the night before was
> playing with MPPP and compression over dialups. Until then, this box has
> been in service for two weeks with light load without any other problems.
> I can provide captured dumps if this will help.
>
>
Sure go ahead send the dumps to me - I will take a look and see what the
problem is. MPIP should not cause flash corruptions.
krish
>
>
> ---
> 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
>
On Sat, 6 Feb 1999, Mike Andrews wrote:
> 1) What do dip switches 7 thru 10 on an NMC do? Switch 10 appears to dump
> Phoenix BIOS output to the serial port. What about the others?
>
These I have to check some of them are reserved.
>
> 2) (Related to the above) Why would a serial cable with only tx+rx+ground
> (3 wire), hooked up an NMC's serial port, work on a 4 meg NMC running
> 5.4.95, but once that NMC's upgraded to 14 meg running 5.5.5, it stops
> working? The supplied USR cable hooked to a laptop will work in both
> cases. A similar thing happens with newer ARC releases, but flipping dip
> switch 5 up makes it work again.
>
>
DTE/RTS..
> 3) I have an NMC card that doesn't like to boot. Most of the time, it
> just puts the Run/Fail and Hub Status lights in red and leaves them there.
> Sometimes, though, it will boot fine. I've tried swapping RAM and flash
> (both with the 4 meg and the 16 meg code) with another good NMC and the
> good NMC will boot OK. The times it boots fine are almost always with the
> 4 meg flash, almost never with the 16 meg. (With dip switch 10 on, the
> Phoenix BIOS stuff shows up immediately if it's going to work, and never
> if it isn't.)
>
> Unfortunately this is only one of two NMC's I have with an x2 feature key
> on it, or else I'd just use the other NMC. This was a 4 meg NMC that I'm
> trying to get upgraded to 16 meg so I can swap my last NETserver out for
> an ARC.
>
> Any ideas how to revive this thing so it boots more consistently? I've
> tried putting dip switches 5 and 6 up, tried putting the CMOS Clear jumper
> (JP4/JP5) on clear for a few minutes, swapped flash simms, swapped ram
> simms, all to no avail.
>
I would basically suggest that you put dip 5 and 6 in the on position and
download the code again. Download 4.3.x code via pcsdl and then upgrade
it to 5.x
krish
>
> Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
> getting beaten by the police, put down the video camera and come help me!"
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Is there a way to turn off --More-- prompts? From: David OBrien <growler@ac.net> Date: 1999-02-07 22:39:31
Is there a similar command for a netserver?
-Dave
Subject:Re: (usr-tc) NMC problems and questions From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-08 00:13:22
On Sun, 7 Feb 1999, Tatai SV Krishnan wrote:
> On Sat, 6 Feb 1999, Mike Andrews wrote:
>
> > 1) What do dip switches 7 thru 10 on an NMC do? Switch 10 appears to dump
> > Phoenix BIOS output to the serial port. What about the others?
> >
>
> These I have to check some of them are reserved.
I think they're all listed as reserved.
> > 2) (Related to the above) Why would a serial cable with only tx+rx+ground
> > (3 wire), hooked up an NMC's serial port, work on a 4 meg NMC running
> > 5.4.95, but once that NMC's upgraded to 14 meg running 5.5.5, it stops
> > working? The supplied USR cable hooked to a laptop will work in both
> > cases. A similar thing happens with newer ARC releases, but flipping dip
> > switch 5 up makes it work again.
> >
> >
> DTE/RTS..
Any of those reserved dipswitches override this?
> > 3) I have an NMC card that doesn't like to boot. Most of the time, it
> > just puts the Run/Fail and Hub Status lights in red and leaves them there.
> > Sometimes, though, it will boot fine. I've tried swapping RAM and flash
> > (both with the 4 meg and the 16 meg code) with another good NMC and the
> > good NMC will boot OK. The times it boots fine are almost always with the
> > 4 meg flash, almost never with the 16 meg. (With dip switch 10 on, the
> > Phoenix BIOS stuff shows up immediately if it's going to work, and never
> > if it isn't.)
[munch]
> > Any ideas how to revive this thing so it boots more consistently? I've
> > tried putting dip switches 5 and 6 up, tried putting the CMOS Clear jumper
> > (JP4/JP5) on clear for a few minutes, swapped flash simms, swapped ram
> > simms, all to no avail.
> >
>
> I would basically suggest that you put dip 5 and 6 in the on position and
> download the code again. Download 4.3.x code via pcsdl and then upgrade
> it to 5.x
When it decides it doesn't want to boot, I mean it doesn't even get to the
point where it would start SDL. The run/fail light never goes to the
blinking-green stage. If I can get it to that point, I'll try putting
4.3.x on it and see if it makes any difference...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:(usr-tc) Packet bus status change From: Cassandra M. Perkins <cassy@loop.com> Date: 1999-02-08 06:35:47
I have two USRTC in the same hunt group. I started getting busy signals
when there were plenty of ports available. No visable alarms showed up
but on one of the Netservers, the packet bus options changed from ARP to
AIP for most of the modems. A "reset all" cleared up the problem.
What could cause the change in status for the packet bus? Why can't the
PRI card detect a problem and hunt over?
Thank you.
Cassandra
| Cassandra M. Perkins | People usually get what's coming to |
| Network Operations | them... unless it's been mailed. |
| The Loop Internet Switch Co., LLC | -fortune |
Subject:Re: (usr-tc) Packet bus status change From: Cassandra M. Perkins <cassy@loop.com> Date: 1999-02-08 07:08:12
Jeff,
I could have a program telnet to the Netserver to check the packet bus
status, but I would think that the NMC card should have a better way to
report pb connection problems.
Thanks for the reply.
Cassandra
| Cassandra M. Perkins | People usually get what's coming to |
| Network Operations | them... unless it's been mailed. |
| The Loop Internet Switch Co., LLC | -fortune |
On Mon, 8 Feb 1999, Jeff Mcadams wrote:
> Thus spake Cassandra M. Perkins
> >What could cause the change in status for the packet bus?
>
> For some reason the modems were unable to continue communicating with
> the NETServer...don't know why...happens with us too occasionally.
>
> >Why can't the PRI card detect a problem and hunt over?
>
> Because the communications problem is between the modems and the
> NETServer, not between the modems and the PRI card. The PRI card
> doesn't communication with the NETServer at all (assuming you aren't
> using the Munich card), so the NETServer can't inform the PRI card that
> it has some ports that it can't use...and the modems don't have the
> intelligence to know to inform the PRI card (or any mechanism to that
> I'm aware of) when it looses pb communication with the NETServer.
> --
> 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) Windows NT users can't browse From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-08 08:04:50
Thus spake Ralph Helfenberger
>Thanks for this information. This solved the problem. I wasn't aware
>that the Netserver had a problem with Header compression...
Actually, I tend to blame NT for it as NT is the only system that has a
problem with it dialing up to the NETServers. I also believe I've heard
other people talk about the same problem with NT dialing up to other
types of NASen, but don't quote me on that.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Sniffer software From: Brian <signal@shreve.net> Date: 1999-02-08 09:11:25
On Sun, 7 Feb 1999, Jeff Binkley wrote:
>
> I was wondering if anyone had some recommendations for either NT based or
> Unix/Linux based packet sniffer type of software ? We don't have a great
> need for it but occasionally it would be nice to trace things coming off
> of our TC boxes.
>
I use sniffit, and it works pretty good.
> Thanks,
> Jeff Binkley
> ASA Network Computing
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Packet bus status change From: Brian <signal@shreve.net> Date: 1999-02-08 09:14:19
On Mon, 8 Feb 1999, Cassandra M. Perkins wrote:
> I have two USRTC in the same hunt group. I started getting busy signals
> when there were plenty of ports available. No visable alarms showed up
> but on one of the Netservers, the packet bus options changed from ARP to
> AIP for most of the modems. A "reset all" cleared up the problem.
>
This is what you call, USR Totally Out of Control :)
> What could cause the change in status for the packet bus? Why can't the
> PRI card detect a problem and hunt over?
Well, I use to see interfaces on netservers go from ARP to AIP, and
couldn't explain it. In the earlier days of ARC code, I would do a "list
interfaces" and see interfaces marked "down", when they should have been
"Up". Alot of times this would happen just after a reboot.
Things are better now on ARC's, but I can't comment on the netserver.
When an arc shows an interface(s) down, I usually try "enable interface
slot:x/mod:y", however, this rarly works, and I am not sure what else to
try, and usually end up rebooting the entire card (yikes!). I wish their
was something else to try.
Brian
> > Thank you.
>
> Cassandra
>
> ----------------------------------------------------------------------------
> | Cassandra M. Perkins | People usually get what's coming to |
> | Network Operations | them... unless it's been mailed. |
> | The Loop Internet Switch Co., LLC | -fortune |
> ----------------------------------------------------------------------------
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) Packet bus status change From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-08 09:57:21
Thus spake Cassandra M. Perkins
>What could cause the change in status for the packet bus?
For some reason the modems were unable to continue communicating with
the NETServer...don't know why...happens with us too occasionally.
>Why can't the PRI card detect a problem and hunt over?
Because the communications problem is between the modems and the
NETServer, not between the modems and the PRI card. The PRI card
doesn't communication with the NETServer at all (assuming you aren't
using the Munich card), so the NETServer can't inform the PRI card that
it has some ports that it can't use...and the modems don't have the
intelligence to know to inform the PRI card (or any mechanism to that
I'm aware of) when it looses pb communication with the NETServer.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Supra 56K Sp From: pferraro@wna-linknet.com Date: 1999-02-08 10:15:38
Has anyone seen problems with this particular modem? THis is a
strange one: User is running a MAC with OS 8.05 and this modem. Calls in
gets 45,000 connect and then gets dumped! Radius verifies writes both the
Start and the Stop. Just wondering if there is a "trick" or is it the
modem itself? Don't know enough about the Macs to give any guidance!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
Subject:RE: (usr-tc) Windows NT users can't browse From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-08 10:29:33
Its NT's PPP stack not the Netserver.
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ralph Helfenberger
|Sent: Monday, February 08, 1999 4:58 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Windows NT users can't browse
|
|
|Thanks for this information. This solved the problem. I wasn't aware
|that the Netserver had a problem with Header compression...
|Ralph
|
|Jeff Mcadams wrote:
|>
|> Thus spake Ralph Helfenberger
|> >I tried to turn off software compression on the netserver
|>
|> >set ccp off
|>
|> Ack...I mis-spoke earlier...not software compression...VJ header
|> compression. Basically, VJ is a TCP header compression, so only TCP
|> packets will get messed up, so you were seeing UDP (DNS requests and
|> replies), and ICMP (ping and ping replies) were going through correctly,
|> but when it came time to actually load pages and stuff, the TCP
|> connections (http/web requests and replies) got messed up by the
|> header compression.
|> --
|> Jeff McAdams Email: jeffm@iglou.com
|> Head Network Administrator Voice: (502) 966-3848
|> IgLou Internet Services (800) 436-4456
|>
|> -
|> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
|> with "unsubscribe usr-tc" in the body of the message.
|> For information on digests or retrieving files and old messages send
|> "help" to the same address. Do not use quotes in your message.
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| with "unsubscribe usr-tc" in the body of the message.
| For information on digests or retrieving files and old messages send
| "help" to the same address. Do not use quotes in your message.
|
Subject:Re: (usr-tc) Windows NT users can't browse From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-08 10:36:30
Jeff Mcadams was heard to say:
>Thus spake Ralph Helfenberger
>>Thanks for this information. This solved the problem. I wasn't aware
>>that the Netserver had a problem with Header compression...
>
>Actually, I tend to blame NT for it as NT is the only system that has a
>problem with it dialing up to the NETServers. I also believe I've heard
>other people talk about the same problem with NT dialing up to other
>types of NASen, but don't quote me on that.
That's odd... as I recall, updating the modem code fixed alot of my original
VJ problems. But, yes, the netserver has a few problems with VJ compression
under load (it reassembles the header with the wrong payload -- usually
two packets out of sequence.) FWIW, the hiper hardware has the same problem,
but oddly, it's easier to trip up.
(I'll add, just about every network stack has or did have some kind of problem
with VJ compression at some point. Many of them still have problems.)
--Ricky
We will beginning HARC 4.2 BETA soon. If you are interested, please go to
totalservice and fill out the BETA application. Once received, we will be sending
you a brief survey to be used in the selection process.
http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+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) Packet bus status change From: David Bolen <db3l@ans.net> Date: 1999-02-08 11:14:34
Jeff Mcadams <jeffm@iglou.com> writes:
...and the modems don't have the
> intelligence to know to inform the PRI card (or any mechanism to that
> I'm aware of) when it looses pb communication with the NETServer.
Actually, there's a setting in the call-control table for the quads to
tell them to busy themselves out (places a busy pattern on the TDM bus
for CT1 cases, or rejects attempts by the circuit card to accept a
call in PRI cases) if they lose the packet bus link. This can
propagate failures on the packet bus side of the modem back out to the
circuit card.
I'm not sure what it might be called in TCM, but the MIB object is
mdmCcNoPbNoConnEna. It's disabled by default.
You do sometimes still lose an initial call depending on how the
packet bus fails (sometimes the modem has to try to deliver a call to
the NETServer before it notices it is down).
In a CT1 case, you'll want to have auto-busy enabled so that the CT1
card can automatically busy the DS0 in response to the modem's busy.
If you have circuits where the busy operation doesn't work, you
probably shouldn't use this setting since it won't help much anyway.
In a PRI case, if you have too many modems do this, you'll end up with
more input B channels than available modems, which can "absorb"
inbound calls (rejecting them so the user gets a busy) very quickly -
depending on your situation it can almost sometimes be better to have
the slow failure that a down packet bus link can cause, since that
helps "throttle" the inbound failing call load. (In theory, using the
PRI in fixed mode (B channel to modem) with auto-busy enabled should
work much like the CT1 case - presuming service messages work on your
span to take a B channel out of service - but we don't typically run
that way).
We run with this setting enabled on all quad modems, but we also have
a 5 minute monitoring task to notify us of any down packet bus links
as viewed from the NETServer/ARC.
-- 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) Supra 56K Sp From: Paul M. Oster <devious@minot.com> Date: 1999-02-08 11:14:53
Kill those supra modems, the modem is bad... if you question the customer,
you will find the modem is between 6 and 18 months old, once they start
doing that, their toast... I've seen this issue with Supra modems from the
28.8 on up (didn't have the pleasure of working with anything earlier) and
I tried EVERYTHING to resolve it, flash upgrades, driver updates, even
(on my own machine) fdisk/format/reinstall the OS... nothing helped.
Paul M. Oster <devious@minot.com> http://www.minot.com/
Magic Internet Services (701) 838-1265
Minots FIRST Internet Connection
-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire
On Mon, 8 Feb 1999 pferraro@wna-linknet.com wrote:
>
> Has anyone seen problems with this particular modem? THis is a
> strange one: User is running a MAC with OS 8.05 and this modem. Calls in
> gets 45,000 connect and then gets dumped! Radius verifies writes both the
> Start and the Stop. Just wondering if there is a "trick" or is it the
> modem itself? Don't know enough about the Macs to give any guidance!
>
> ==============================================================================
> Phillip Ferraro WorldNet Access, Inc
> pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
> Voice (910) 346-0835 824 Gumbranch Square, Suite R3
> FAX (910) 455-1933 Jacksonville, Nc 28540-6269
> ==============================================================================
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Upgrade the drivers to at leat 5.32. The latest version is 5.39, which also
works. You can find the drivers at http://www.808hi.com/56k. Look for the LT
Winmodem page.
Wayne Barber
Coastal Telco Services
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza
> Sent: Monday, February 08, 1999 10:39 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Modems w/ Lucent Chipset
>
>
>
> Does anybody has problems with modems 56k with Lucent chipset?
> Some users with such modems doesn't connect to my TC even at
> 33.6kbps.
> The chip shows:
>
> Lucent
> 1646100
> REA12
> 983622782540
>
> My TC is HARC (4.1.29) / DSP (1.1.91 - E1R2 Trunks).
>
> - 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.
>
Thus spake Mike Wronski
>We will beginning HARC 4.2 BETA soon. If you are interested, please go to
>totalservice and fill out the BETA application. Once received, we will be sending
>you a brief survey to be used in the selection process.
>http://totalservice.usr.com/cgi-bin/w3com/start?totalservice+beta
Did they get the prompt_delay command rolled into 4.2 yet? If so, I'll
go sign up for it officially.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Windows NT users can't browse From: Ralph Helfenberger <rhelfenberger@comlight.ch> Date: 1999-02-08 11:58:19
Thanks for this information. This solved the problem. I wasn't aware
that the Netserver had a problem with Header compression...
Ralph
Jeff Mcadams wrote:
>
> Thus spake Ralph Helfenberger
> >I tried to turn off software compression on the netserver
>
> >set ccp off
>
> Ack...I mis-spoke earlier...not software compression...VJ header
> compression. Basically, VJ is a TCP header compression, so only TCP
> packets will get messed up, so you were seeing UDP (DNS requests and
> replies), and ICMP (ping and ping replies) were going through correctly,
> but when it came time to actually load pages and stuff, the TCP
> connections (http/web requests and replies) got messed up by the
> header compression.
> --
> 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) IEA and DNIS From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-08 12:28:16
Question for those who may know more than I do about IEA and DNIS:
We currently use IEA on a HDM based box for a filtering service called
Xstop. All we have to do is send a reply from radius that says VPN-Neighbor
= w.x.y.z for accounts that have Xstop enabled. I'm toying with the idea of
taking this a step further and adding dnis-based authentication to this. In
other words, if a someone logs on from a particular location, regardless of
the account username/password they use, we'd still send the VPN-Neighbor
reply. I know this is not foolproof, but I'm just wondering if it's
possible, and how. I'm using Radiator for the radius.
The process should look something like this:
Does DNIS=Xstop-enabled phone #? Yes: add VPN-Neighbor then continue
No: just continue
Does Username=Xstop-enabled Username? Yes: add VPN-Neighbor, continue
No: add nothing, continue
thanks,
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Having a problem with ISDN calls terminating on HiperDSPs/HiperARC, and it
seems intermittant (w/ imodem). On some ports, no problem, on others no data
is transferred (no radius authentication happens). When customers "open
terminal window after dialing" on the "bad" ports, they simply see no
banner/login transmitted and are dropped after a few seconds (as opposed to
the normal behavior of tapping CR and seeing a login prompt). Rechecked the
HDSP template numerous times and all settings seem correct. However, I'm
concerned that the modem may not actually be picking up the template correctly
(for one thing, when I look at the modem directly, it's ISDN settings
*definitely* differ from the template's settings). What is the procedure to
completely reconfig from the template? I've been using "Save template 1 to
NVRAM", followed by "Refresh template 1 config channels".
Thanks!
--
Jesse Sipprell
Technical Operations Director
Evolution Communications, Inc.
800-496-4736 (ext 106)
* Finger jss@evcom.net for my PGP Public Key *
I have a few modems on HDSPs that report "Operational Status: Down". The
modems look fine in TCM. Any clues on how to reset this? I've tried reset
interface, reset modems and reset modem_group, all to no avail.
Thanks!
--
Jesse Sipprell
Technical Operations Director
Evolution Communications, Inc.
800-496-4736 (ext 106)
* Finger jss@evcom.net for my PGP Public Key *
Does anybody has problems with modems 56k with Lucent chipset?
Some users with such modems doesn't connect to my TC even at
33.6kbps.
The chip shows:
Lucent
1646100
REA12
983622782540
My TC is HARC (4.1.29) / DSP (1.1.91 - E1R2 Trunks).
- Marcelo
krish,
Does the .out filter have the same permit rules?
Curt
On Mon, 8 Feb 1999, Tatai SV Krishnan wrote:
> you need to have another filter on the netserver called mailin.out
>
> basically you need two filters
>
> 1. mailin.in
> 2. mailin.out
> 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, 8 Feb 1999, Netlink Hardware admin wrote:
>
> >
> > mailonly filter not working on Netserver...works fine on PM2
> >
> > info:
> >
> > -------------
> > xx>ver
> >
> > U.S. Robotics
> > Total Control (tm) NETServer 8/16 version 3.3.0
> >
> > Build date: Nov 14 1997
> > Build time: 10:04:31
> >
> > xx>sho filer mailonly.in
> > - IP rules -
> > 1 permit 0.0.0.0/0 my.target.ip.here/32 tcp dst eq 80
> > 2 permit 0.0.0.0/0 0.0.0.0/0 udp dst eq 53
> > 3 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 25
> > 4 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 110
> >
> > --------------
> >
> > Using Livingston Radius_2.01 (yes, I also use the same radius auth server
> > for Pormasters)
> >
> > Radius entry in user database:
> > --------------
> > joeuser Password = "UNIX"
> > User-Service-Type = Framed-User,
> > Session-Timeout = 1800,
> > Framed-Protocol = PPP,
> > Framed-Address = 255.255.255.254,
> > Framed-Netmask = 255.255.255.255,
> > Framed-Routing = None,
> > Framed-Compression = Van-Jacobsen-TCP-IP,
> > Filter-Id = "mailonly",
> > Framed-MTU = 1500
> >
> > --------------
> >
> > This filter works fine for the PM2s. It allows the user to dial in and
> > establish a PPP session.
> >
> > They can then send and receive e-mail and can surf only on our server.
> >
> > When I set this up on the Netserver, the user gets authenticated and
> > connected, but then disconnected immediately. (Acct-Session-Time = 0,
> > Acct-Terminate-Cause = 0).
> >
> > Any ideas??
> >
> > Thanks,
> >
> > Curt
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
>
you need to have another filter on the netserver called mailin.out
basically you need two filters
1. mailin.in
2. mailin.out
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, 8 Feb 1999, Netlink Hardware admin wrote:
>
> mailonly filter not working on Netserver...works fine on PM2
>
> info:
>
> -------------
> xx>ver
>
> U.S. Robotics
> Total Control (tm) NETServer 8/16 version 3.3.0
>
> Build date: Nov 14 1997
> Build time: 10:04:31
>
> xx>sho filer mailonly.in
> - IP rules -
> 1 permit 0.0.0.0/0 my.target.ip.here/32 tcp dst eq 80
> 2 permit 0.0.0.0/0 0.0.0.0/0 udp dst eq 53
> 3 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 25
> 4 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 110
>
> --------------
>
> Using Livingston Radius_2.01 (yes, I also use the same radius auth server
> for Pormasters)
>
> Radius entry in user database:
> --------------
> joeuser Password = "UNIX"
> User-Service-Type = Framed-User,
> Session-Timeout = 1800,
> Framed-Protocol = PPP,
> Framed-Address = 255.255.255.254,
> Framed-Netmask = 255.255.255.255,
> Framed-Routing = None,
> Framed-Compression = Van-Jacobsen-TCP-IP,
> Filter-Id = "mailonly",
> Framed-MTU = 1500
>
> --------------
>
> This filter works fine for the PM2s. It allows the user to dial in and
> establish a PPP session.
>
> They can then send and receive e-mail and can surf only on our server.
>
> When I set this up on the Netserver, the user gets authenticated and
> connected, but then disconnected immediately. (Acct-Session-Time = 0,
> Acct-Terminate-Cause = 0).
>
> Any ideas??
>
> Thanks,
>
> Curt
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
On Mon, 8 Feb 1999, Netlink Hardware admin wrote:
> krish,
>
> Does the .out filter have the same permit rules?
No - it can be empty
krish
>
> Curt
>
> On Mon, 8 Feb 1999, Tatai SV Krishnan wrote:
>
> > you need to have another filter on the netserver called mailin.out
> >
> > basically you need two filters
> >
> > 1. mailin.in
> > 2. mailin.out
> > 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, 8 Feb 1999, Netlink Hardware admin wrote:
> >
> > >
> > > mailonly filter not working on Netserver...works fine on PM2
> > >
> > > info:
> > >
> > > -------------
> > > xx>ver
> > >
> > > U.S. Robotics
> > > Total Control (tm) NETServer 8/16 version 3.3.0
> > >
> > > Build date: Nov 14 1997
> > > Build time: 10:04:31
> > >
> > > xx>sho filer mailonly.in
> > > - IP rules -
> > > 1 permit 0.0.0.0/0 my.target.ip.here/32 tcp dst eq 80
> > > 2 permit 0.0.0.0/0 0.0.0.0/0 udp dst eq 53
> > > 3 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 25
> > > 4 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 110
> > >
> > > --------------
> > >
> > > Using Livingston Radius_2.01 (yes, I also use the same radius auth server
> > > for Pormasters)
> > >
> > > Radius entry in user database:
> > > --------------
> > > joeuser Password = "UNIX"
> > > User-Service-Type = Framed-User,
> > > Session-Timeout = 1800,
> > > Framed-Protocol = PPP,
> > > Framed-Address = 255.255.255.254,
> > > Framed-Netmask = 255.255.255.255,
> > > Framed-Routing = None,
> > > Framed-Compression = Van-Jacobsen-TCP-IP,
> > > Filter-Id = "mailonly",
> > > Framed-MTU = 1500
> > >
> > > --------------
> > >
> > > This filter works fine for the PM2s. It allows the user to dial in and
> > > establish a PPP session.
> > >
> > > They can then send and receive e-mail and can surf only on our server.
> > >
> > > When I set this up on the Netserver, the user gets authenticated and
> > > connected, but then disconnected immediately. (Acct-Session-Time = 0,
> > > Acct-Terminate-Cause = 0).
> > >
> > > Any ideas??
> > >
> > > Thanks,
> > >
> > > Curt
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the message.
> > > 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) ACCT_TERM_NAS_ERROR From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-08 14:33:59
I have a few Hiper/Quad based NAS's that are really giving me some
headaches. I'v gotten complaints from people who connect, authenticate,
then soon get disconnected again. When I look up their disconnect in the
detail file, I see:
Acct-Terminate-Cause = ACCT_TERM_NAS_ERROR
I currently am duplicating this problem on 3 different NASes, dialing in
with a USR Courier 33.6 on Windows 95. It doesn't happen every time, and
happens at different intervals. I'm running all the latest release code on
these boxes.
I had this happening the other day, and a reboot seemed to solve the
problem. I need a better answer than that. Anyone offer any clues?
Please...
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Subject:(usr-tc) ACCT_TERM_NAS_ERROR continued From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-08 14:49:32
Looking at syslog for one of the boxes in question:
Feb 8 14:49:15 nas.ip.address At 14:47:53, Facility "IP", Level
"CRITICAL":: ip_fwd_get_opt: no IP address available for dynamic address
assignment
Feb 8 14:49:15 nas.ip.address At 14:47:53, Facility "PPP", Level
"UNUSUAL":: ../../src/ppp_main.c: PPP Get Option Rejected, (bad status).
What the ?@?! is this! I though we weren't having problems running out of
IP's on the hiperarcs.
Randy Cosby <dcosby@infowest.com>
Vice President
InfoWest Global Internet Services, Inc.
(435)674-0165 http://www.infowest.com
Hi all,
Can anyone recommend a few good ISDN modems (not routers) that:
-interoperate well with HiperARC/DSP
-work well in general
-are easy to setup and support
-are economical
From what I understand, the 3com ImpactIQ doesn't even work with the TC
stuff, is that correct? I've used a Bitsurfr, and hated it...
And on the router side, what do you all think of the Netgear product?
Seems very nice for the $$.
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Subject:Re: (usr-tc) Windows NT users can't browse From: Ralph Helfenberger <rhelfenberger@comlight.ch> Date: 1999-02-08 15:00:42
Now I changed the VJ setting on my RADIUS server (SAWIN 6.0.8). I see
that
the VJ is set to none. But somehow the Netserver isn't eating this
setting. Any idea why? I wouldn't like to inform every NT user about
this
change. I'd rather set all users on the RADIUS to not use it. But... as
I
wrote the Netserver doesn't seem to react to it.
Ralph
Jeff Mcadams wrote:
>
> Thus spake Ralph Helfenberger
> >Thanks for this information. This solved the problem. I wasn't aware
> >that the Netserver had a problem with Header compression...
>
> Actually, I tend to blame NT for it as NT is the only system that has a
> problem with it dialing up to the NETServers. I also believe I've heard
> other people talk about the same problem with NT dialing up to other
> types of NASen, but don't quote me on that.
> --
> 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) Version numbers From: Carl Litt <carl@cca1.execulink.net> Date: 1999-02-08 15:29:32
No, I think that 1.2.60 is the newest for those of us who have support
contracts, and 1.2.59 is the newest for all the rest.
If you go to the support page and go directly to "Latest Code" without
logging in with your Member Login, you have access to DSP 1.2.59 and
ARC 4.1.59-1, but not DSP 1.2.60 or ARC 4.1.78.
On Sat, 6 Feb 1999, Bryan Wann wrote:
>
> Okay, let me get this straight, HiPer DSP 1.2.59 service release is newer
> code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
>
> I was talking to 3com support yesterday about an ARC card completely
> going bezerk and losing its flash, first they said 4.1.72 was latest, then
> later into the call he said 4.1.59-1 was the latest version.
>
> Are there any additional strangeness about numbering schemes I should be
> aware of, or am I just thinking too linear?
>
>
>
> ---
> 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
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
the 3com impactiq is the best one i have used
-----Original Message-----
>Hi all,
>
>Can anyone recommend a few good ISDN modems (not routers) that:
>
>-interoperate well with HiperARC/DSP
>-work well in general
>-are easy to setup and support
>-are economical
>
>>From what I understand, the 3com ImpactIQ doesn't even work with the TC
>stuff, is that correct? I've used a Bitsurfr, and hated it...
>
>And on the router side, what do you all think of the Netgear product?
>Seems very nice for the $$.
>
>Thanks,
>
>Charles
>
>--
>=-----------------= =
>| Charles Sprickman Internet Channel |
>| INCH System Administration Team (212)243-5200 |
>| spork@inch.com access@inch.com |
>= =----------------=
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
This is still happening is V4.1.59 - 1, although the release notes led
me to believe it might be fixed.
Aaron Nabil writes...
>Subject: (usr-tc) Yikes, filters broken in arc V4.1.63?
>To: usr-tc@lists.xmission.com
>Date: Mon, 25 Jan 1999 11:12:28 -0800 (PST)
>
>System Version: V4.1.63
>
>Here's what I send...
>
>Framed-Routing = None
>Framed-IP-Netmask = 255.255.255.255
>Service-Type = Framed-User
>Idle-Timeout = 3600
>Session-Timeout = 43200
>USR-Max-Channels = 1
>Framed-Protocol = PPP
>USR-Log-Filter-Packet = Log-Disable
>USR-IP-Input-Filter = "1 REJECT dst-addr = 192.168.0.0/16"
>
>This is what I get in the syslog with every login...
>
>Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL"::
>Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL":: invalid token near line 1 (text was '=')
>Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL"::
>Jan 25 11:08:29 us4b last message repeated 2 times
>Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL":: line 1: syntax error near or at "REJECT"
>
--
Aaron Nabil
On Mon, 8 Feb 1999, Randy Cosby wrote:
> Looking at syslog for one of the boxes in question:
>
> Feb 8 14:49:15 nas.ip.address At 14:47:53, Facility "IP", Level
> "CRITICAL":: ip_fwd_get_opt: no IP address available for dynamic address
> assignment
I have not seen this before. Now the two questions
1. What version of Hiper arc code did you see this on.
2. Do you have hint assigned enabled on the hiper arc?
3. Does the user disconnect due to IPCP - no ip address? - for all its
worth syslog may report this but may not mean the same.
get me the info.
krish
> Feb 8 14:49:15 nas.ip.address At 14:47:53, Facility "PPP", Level
> "UNUSUAL":: ../../src/ppp_main.c: PPP Get Option Rejected, (bad status).
>
> What the ?@?! is this! I though we weren't having problems running out of
> IP's on the hiperarcs.
>
> Randy Cosby <dcosby@infowest.com>
> Vice President
> InfoWest Global Internet Services, Inc.
> (435)674-0165 http://www.infowest.com
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Do the DSP cards log any kind of information, as far as why they
crash/reboot?
I just went into my back room, and noticed that one of my DSPs was in the
middle of a reboot. Strange coincidence - another card required a reboot
over the weekend to wake up. This has been happening since I've added DSP
#6 to a brand new chassis (dual 70A) - I had blown the other chassis'
management bus, and this thing replaced it.
Very, very odd. All the cards are running 1.2.60/4.1.72/5.5.5.
Any input would be appreciated.. at least it'd be a first step in the
right direction.
--
Gilles Melanson ViaNet Internet Solutions
System Administrator 128 Larch St. Suite 301
gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
There isn't any reason why Linux can't be implemented as an enterprise
computing solution. Find out what you've been missing while you've
been rebooting Windows NT. -- Eric Hammond
This is not a bug. This is intensional. The SBUS messages are generated when the HARC does Netserver to HARC
filter conversion. Since the filter is not Netserver syle the messages are generated. If you dont want the
messages in your syslog adjust your syslog level to critial for SBUS instead of UNUSUAL.
Aaron Nabil wrote:
> This is still happening is V4.1.59 - 1, although the release notes led
> me to believe it might be fixed.
>
> Aaron Nabil writes...
> >Subject: (usr-tc) Yikes, filters broken in arc V4.1.63?
> >To: usr-tc@lists.xmission.com
> >Date: Mon, 25 Jan 1999 11:12:28 -0800 (PST)
> >
> >System Version: V4.1.63
> >
> >Here's what I send...
> >
> >Framed-Routing = None
> >Framed-IP-Netmask = 255.255.255.255
> >Service-Type = Framed-User
> >Idle-Timeout = 3600
> >Session-Timeout = 43200
> >USR-Max-Channels = 1
> >Framed-Protocol = PPP
> >USR-Log-Filter-Packet = Log-Disable
> >USR-IP-Input-Filter = "1 REJECT dst-addr = 192.168.0.0/16"
> >
> >This is what I get in the syslog with every login...
> >
> >Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL"::
> >Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL":: invalid token near line 1 (text was '=')
> >Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL"::
> >Jan 25 11:08:29 us4b last message repeated 2 times
> >Jan 25 11:08:29 us4b At 11:05:28, Facility "SBUS", Level "UNUSUAL":: line 1: syntax error near or at "REJECT"
> >
>
> --
> 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.
I have had DSP's caught in reboots also.
I had to take outthe DSP (and NIC) and put them into another chassis and
they would come up fine. Flash them in the other chassis and put them back
to the original chassis and everythign was fine . Strange ...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
-----Original Message-----
>Do the DSP cards log any kind of information, as far as why they
>crash/reboot?
>
>I just went into my back room, and noticed that one of my DSPs was in the
>middle of a reboot. Strange coincidence - another card required a reboot
>over the weekend to wake up. This has been happening since I've added DSP
>#6 to a brand new chassis (dual 70A) - I had blown the other chassis'
>management bus, and this thing replaced it.
>
>Very, very odd. All the cards are running 1.2.60/4.1.72/5.5.5.
>
>Any input would be appreciated.. at least it'd be a first step in the
>right direction.
>
>--
>Gilles Melanson ViaNet Internet Solutions
>System Administrator 128 Larch St. Suite 301
>gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
>
> There isn't any reason why Linux can't be implemented as an enterprise
> computing solution. Find out what you've been missing while you've
> been rebooting Windows NT. -- Eric Hammond
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01BE53B3.679F5820
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I am just looking at some commands and a SHOW NMC give me the following
HiPer>> show nmc
NMC SETTINGS
Chassis Awareness: ENABLED
Dynamic Slot Assignment: DISABLED
DSA Idle Rebalancing: DISABLED =20
Just wondering what Dynamic Slot Assignment is?
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
------=_NextPart_000_0006_01BE53B3.679F5820
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.3612.1700"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>I am just looking at some commands =
and a SHOW=20
NMC give me the following</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>HiPer>> show nmc</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>NMC SETTINGS<BR>Chassis=20
Awareness: ENABLED<BR>Dynamic =
Slot=20
Assignment: DISABLED<BR>DSA Idle =
Rebalancing: =20
DISABLED </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Just wondering what Dynamic Slot =
Assignment=20
is?</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2><BR>---------------------------------------------------<BR>Have =
a Great=20
Day!</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Jamie Orzechowski<BR>RipNET System=20
Admin</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Tel.: 613-342-3946 ext 293<BR>Tel.: =
800-267-4434=20
ext 293<BR>Page.: 613-341-0883<BR>EMail.: <A=20
href=3D"mailto:mhz@ripnet.com">mhz@ripnet.com</A><BR>Web.: <A=20
href=3D"http://www.ripnet.com">http://www.ripnet.com</A><BR>Personal.: =
<A=20
href=3D"http://www.moonchilli.com">http://www.moonchilli.com</A><BR>-----=
TML>
------=_NextPart_000_0006_01BE53B3.679F5820--
Subject:RE: (usr-tc) Sniffer software From: Mario M. Bustamante <mario@accesspro.net> Date: 1999-02-08 22:46:07
OK, so where do we get sniffit?
Thanks,
_______________________________________________
Mario M. Bustamante, President
AccessPro Communications Inc.
Miami, Florida
Internet Service Providers, Web Hosting & Design
Microsoft Certified Web Presence Providers
Wide Area Networks, Security, Intranets.
http://www.AccessPro.net mario@accesspro.net
_______________________________________________
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian
> Sent: Monday, February 08, 1999 10:11 AM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Sniffer software
>
>
> On Sun, 7 Feb 1999, Jeff Binkley wrote:
>
> >
> > I was wondering if anyone had some recommendations
> for either NT based or
> > Unix/Linux based packet sniffer type of software ?
> We don't have a great
> > need for it but occasionally it would be nice to
> trace things coming off
> > of our TC boxes.
> >
>
> I use sniffit, and it works pretty good.
>
> > Thanks,
> > Jeff Binkley
> > ASA Network Computing
> >
> > -
> > To unsubscribe to usr-tc, send an email to
> "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and
> old messages send
> > "help" to the same address. Do not use quotes in
> your message.
> >
>
> -----------------------------------------------------
> Brian Feeny (BF304) signal@shreve.net
> 318-222-26318 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.
>
latest version is always here
http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
-----Original Message-----
>OK, so where do we get sniffit?
>
>
>Thanks,
Subject:(usr-tc) HARC vs. NMC radius accounting From: Brian Uechi <brianu@lava.net> Date: 1999-02-08 23:34:31
I noticed several radius accounting discrepancies in a chassis with
NMC running 5.5.5, HiPer ARC running 4.1.59, and HiPer DSP running
1.2.59. The HARC output looks a lot saner but does not have as much
detail so I'm trying to get the NMC working. The radius daemon is
Cistron with an updated 3Com/USR dictionary. BTW, a chassis with dual
pri, quads, netserver, and NMC 5.5.5 is producing reasonable results
sending to the same Cistron daemon.
It appears the NMC is not getting the correct info from the HDM. Is
there an HDM option which affects this? I poked around the dictionary
values and found many of the NMC values are off by 1 compared to the
HARC.
Thanks,
Brian
NMC USR-Initial-Tx-Link-Data-Rate = 49333-BPS
USR-Final-Tx-Link-Data-Rate = 49333-BPS
USR-Sync-Async-Mode = Synchronous
USR-Modulation-Type = v90AllDigital
USR-Simplified-MNP-Levels = piafs
USR-Simplified-V42bis-Usage = mnpLevel5
USR-Connect-Term-Reason = tokenPassingTimeout
USR-Initial-Rx-Link-Data-Rate = 110-BPS
USR-Final-Rx-Link-Data-Rate = 110-BPS
NAS-Port-Id = 1
HARC USR-Connect-Speed = 48000-BPS
NAS-Port-Type = Async
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42SREJ
USR-Simplified-V42bis-Usage = ccittV42bis
Acct-Terminate-Cause = Idle-Timeout
NAS-Port-Id = 3337
RADIUS accounting record from NMC 5.5.5
Mon Feb 8 01:13:28 1999
NAS-IP-Address = xxx.xxx.xxx.xxx
NAS-Port-Id = 1
Acct-Delay-Time = 0
Acct-Session-Id = "218628220"
USR-Event-Id = In-Connection-Term
USR-Chassis-Slot = 14
USR-Channel = 9
Acct-Status-Type = Stop
Acct-Session-Time = 1383
USR-Connect-Term-Reason = tokenPassingTimeout
USR-Characters-Sent = 91880
USR-Characters-Received = 26215
Acct-Output-Octets = 72420
Acct-Input-Octets = 12741
USR-Blocks-Sent = 679
USR-Blocks-Received = 697
USR-Blocks-Resent = 74
USR-Number-Of-Characters-Lost = 0
USR-Number-of-Blers = 31
USR-Number-of-Link-NAKs = 131
USR-Number-of-Fallbacks = 0
USR-Number-of-Link-Timeouts = 1
USR-Initial-Tx-Link-Data-Rate = 49333-BPS
USR-Final-Tx-Link-Data-Rate = 49333-BPS
USR-Retrains-Requested = 0
USR-Retrains-Granted = 0
USR-Sync-Async-Mode = Synchronous
USR-Modulation-Type = v90AllDigital
USR-Simplified-MNP-Levels = piafs
USR-Simplified-V42bis-Usage = mnpLevel5
USR-Fallback-Enabled = Enabled
USR-Equalization-Type = Short
USR-Last-Number-Dialed-In-DNIS = "xxxxxxx"
USR-Last-Callers-Number-ANI = "xxxxxxxxxx"
Timestamp = 918472408
Request-Authenticator = Verified
RADIUS accounting record from HiPer ARC 4.1.59
Mon Feb 8 01:13:28 1999
User-Name = "xxxx"
NAS-IP-Address = xxx.xxx.xxx.xxx
Acct-Status-Type = Stop
Acct-Session-Id = "218628220"
Acct-Delay-Time = 0
Acct-Authentic = RADIUS
Service-Type = Framed-User
NAS-Port-Type = Async
NAS-Port-Id = 3337
USR-Modem-Training-Time = 16
USR-Interface-Index = 4593
USR-Chassis-Call-Slot = 14
USR-Chassis-Call-Span = 1
USR-Chassis-Call-Channel = 9
USR-Unauthenticated-Time = 8
Calling-Station-Id = "xxxxxxxxx"
Called-Station-Id = "xxxxxxx"
USR-Modulation-Type = v90Digital
USR-Simplified-MNP-Levels = ccittV42SREJ
USR-Simplified-V42bis-Usage = ccittV42bis
USR-Connect-Speed = 48000-BPS
Framed-Protocol = PPP
Framed-IP-Address = xxx.xxx.xxx.xxx
Acct-Session-Time = 1382
Acct-Terminate-Cause = Idle-Timeout
Acct-Input-Octets = 26215
Acct-Output-Octets = 91879
Acct-Input-Packets = 207
Acct-Output-Packets = 203
Timestamp = 918472408
Request-Authenticator = Verified
---
Brian K. Uechi Email: brianu@lava.net
Technical Support Engineer Phone: 808-545-5282
LavaNet, Inc. FAX : 808-545-7020
Subject:(usr-tc) Showing errors on DS1 span From: Brian Elfert <brian@citilink.com> Date: 1999-02-09 08:34:49
I have PRI NACs with CT1s into them.
How can I display a listing of errors like CRC error, Bipolar Violations,
and other alarms over time?
The perf monitor in TCM only seems to show alarms that are current or
errors since I started perf monitor.
Brian
On Mon, 8 Feb 1999, Thomas Suiter wrote:
> I'm receiving loads of LCP protocl rejection codes in my ppp session.
> Anybody know what all it's trying to do here? My connection will be
> cooking along just fine and then (for lack of a better word) freeze up,
> and a couple of seconds later start going again. This doesn't happen on
> our total-control units, so I'm guessing that it's something that needs
> to be turned off (or at least tuned).
>
> Anybody have any ideas on this I'd greatly appreciate it.
>
What version of code on the Hiper arc?
and also do you have stac compression enabled for this link on the client
side.
krish
> Thomas
>
> Boring ppp output -------------------------------------------
>
>
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xf5
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xef
> ppp[126669]: Static LCP: receive mysterious Protocol-Reject for
> protocol 0x67
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x14ca
> ppp[126669]: Static LCP: receive mysterious Protocol-Reject for
> protocol 0x17
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x487f
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x9ee0
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x85
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xd2e2
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xed
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x14de
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x1000
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xd4e0
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xd47a
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xfe96
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x3b
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x4d6
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x74ac
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x17
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x746d
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x3e4a
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x5272
> ppp[126669]: Static LCP: receive mysterious Protocol-Reject for
> protocol 0xfb
> ppp[126669]: Static LCP: receive mysterious Protocol-Reject for
> protocol 0x1
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xc08b
> ppp[126669]: Static LCP: receive mysterious Protocol-Reject for
> protocol 0x35
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x77
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x1c0e
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x8004
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x5455
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x1b
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xd3
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xbf
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x12ca
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x56de
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xc4a7
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x3e9d
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x66ff
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xa7
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x180b
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x9b
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0xe6b1
> ppp[126669]: Static: Protocol-Rejecting unrecognized protocol 0x14d0
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Show idle time on HiperArc? From: David Swearingin <david@carolnet.com> Date: 1999-02-09 09:36:30
Netserver's 'show sessions' would show each user's session time and idle
time - Is there a command in HiperArc to show the same?
David
__________________________________________________
David Swearingin (david@carolnet.com)
CARROLLTON INTERNET SERVICE (www.carolnet.com)
First Financial Group, Inc.
11 N. Folger, Carrollton, MO 64633
816-542-3002 Fax 816-542-3003
Subject:(usr-tc) WWW.V90STUFF.COM From: Brian Gordon <administrator@westelcom.com> Date: 1999-02-09 09:45:49
http://www.v90stuff.com
This is for all you ISP's that have the Total Control Hiper Solution.
We have used these strings to get our customers online when there modems
seemed incompatable.
We will be updating this to add new strings daily.
Feedback and submissions are welcome.
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: (usr-tc) WWW.V90STUFF.COM From: Wayne Barber <barberw@tidewater.net> Date: 1999-02-09 10:08:35
Is this serious? I'd have to disagree that these are solutions for making
these modems work with the TC hub. On the Rockwell HCF modems, you are
turning k56 on; the string for Rockwell based ITU modems is wrong; the
Gateway PCI Lucent modems (LT winmodems)will work as long as you have the
latest drivers, currently 5.39. If you want to turn v.90 off, the string is
ATS38=0. All your USR common strings turn off v.90. Why would we want that?
Maybe I'm reading your intent wrong, but this seems like total
disinformation.
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 Gordon
> Sent: Tuesday, February 09, 1999 9:46 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) WWW.V90STUFF.COM
>
>
> http://www.v90stuff.com
>
> This is for all you ISP's that have the Total Control Hiper Solution.
>
> We have used these strings to get our customers online when there modems
> seemed incompatable.
>
> We will be updating this to add new strings daily.
>
> Feedback and submissions are welcome.
>
> 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.
>
On Mon, 8 Feb 1999, Jamie Orzechowski wrote:
> I am just looking at some commands and a SHOW NMC give me the following
>
> HiPer>> show nmc
>
> NMC SETTINGS
> Chassis Awareness: ENABLED
> Dynamic Slot Assignment: DISABLED
> DSA Idle Rebalancing: DISABLED
>
> Just wondering what Dynamic Slot Assignment is?
>
is not available without the 2.x HDM code and 6.x NMC code. Do yourself a
favor and DONT enable them unless your involved in the BETA. As for what
it is.. Its the methed that will be used when you place two harcs in a
chassis and you turn on Chassis Awarenss which is a bad thing now.
-M
Subject:Re: (usr-tc) Show idle time on HiperArc? From: vanhalen@coredcs.com Date: 1999-02-09 10:14:55
list conn will show you the session time(the start time of the session).
It's my understanding that idle time is not yet in a release but is in the
works.
Steve
On Tue, 9 Feb 1999, David Swearingin wrote:
> Netserver's 'show sessions' would show each user's session time and idle
> time - Is there a command in HiperArc to show the same?
>
> David
> __________________________________________________
> David Swearingin (david@carolnet.com)
> CARROLLTON INTERNET SERVICE (www.carolnet.com)
> First Financial Group, Inc.
> 11 N. Folger, Carrollton, MO 64633
> 816-542-3002 Fax 816-542-3003
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Show idle time on HiperArc? From: Mike Wronski <mwronski@coredump.ae.usr.com> Date: 1999-02-09 10:15:21
Not at this time..
-m
On Tue, 9 Feb 1999, David Swearingin wrote:
> Netserver's 'show sessions' would show each user's session time and idle
> time - Is there a command in HiperArc to show the same?
>
> David
> __________________________________________________
> David Swearingin (david@carolnet.com)
> CARROLLTON INTERNET SERVICE (www.carolnet.com)
> First Financial Group, Inc.
> 11 N. Folger, Carrollton, MO 64633
> 816-542-3002 Fax 816-542-3003
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) HARC & Mac Problems From: Dale Hege <fhege@sover.net> Date: 1999-02-09 10:45:40
Has anyone been having trouble with macintosh users connecting to a harc
running 4.1.59-1? They connect but ppp never starts up.
-Dale
Subject:Re: (usr-tc) Show idle time on HiperArc? From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-09 10:58:27
No... not unless they added something in 4.1.59.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Tue, 9 Feb 1999, David Swearingin wrote:
> Netserver's 'show sessions' would show each user's session time and idle
> time - Is there a command in HiperArc to show the same?
Subject:Re: (usr-tc) Show idle time on HiperArc? From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-09 11:00:22
(Oops, must engage brain and read whole message before responding).
The "no" was for idle time -- no way to get that on an ARC, unless
something has changed recently.
You CAN get the time of day (in GMT) the session started... "list
connections" will tell you... and from that you can get the length by
subtracting the start time from the current time.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Tue, 9 Feb 1999, David Swearingin wrote:
> Netserver's 'show sessions' would show each user's session time and idle
> time - Is there a command in HiperArc to show the same?
Subject:(usr-tc) Switch to ELI From: Brian A. Burgmeier <brianb@ntwrld.com> Date: 1999-02-09 12:17:04
We have had the USR 48 port Total control chassis for just over a year
without any problems (not 1 call to tech support). We recently switched
from USWest to ELI going from 1 channelized T-1 to 2 so we now have all 48
ports active. We switched a week ago and everything seemed to be O.K. until
today when 20 people were disconnected and then received a busy signal. I
called ELI and was told their end was fine it was a problem with our
equipment. I shut off and turned back on the Hub. This fixed the
problem. I'm concerned that this may happen again. My tech support
contract ran out with USR. Should I renew it? $200/hour seems a little
steep for tech support. Could this be a problem with the new T-1 from ELI?
Has anyone switched from USWest to ELI and experienced similar problems? Is
there something I need to change on the Chassis?
Thanks-Brian
has anyone experienced problems with this code? as soon
as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
customers had problems. The pipline customers sould not
connect until i downgraded the DSP code to 1.2.5. the
webramp customers are still SOL.
any advice would be greatly appreciated.
blake
Subject:(usr-tc) Service contract. Was: Switch to ELI From: Ronald E. Kushner <ron@glis.net> Date: 1999-02-09 15:00:11
"Brian A. Burgmeier" wrote:
>
> $200/hour seems a little steep for tech support.
>
> Thanks-Brian
Brian, if this is the only call you expect to make to USR this year, pay
the $200. It's alot less expensive than the service contract. You can
make 10 calls before it's more expensive than a contract.
I only had to pay USR once for a support call. I saved $5,800 instead of
buying a contract over 2 years.
-Ron
--
Ronald Kushner
GLISnet, Inc.
+1 810/939.9885
On Tue, 9 Feb 1999, Blake Fithen wrote:
>
> has anyone experienced problems with this code? as soon
> as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
> customers had problems. The pipline customers sould not
> connect until i downgraded the DSP code to 1.2.5. the
> webramp customers are still SOL.
>
> any advice would be greatly appreciated.
>
> blake
>
Can you take a "mon PPP" trace for the failed calls on each respective TA
and send them to me directly?
+--------------------------------------+
Mike Wronski (mike@coredump.ae.usr.com)
3Com Network Systems Engineer
Subject:(usr-tc) MP/16 and Leased Lines From: Jose Roberto Bulcao <bulcao@rio.com.br> Date: 1999-02-09 19:22:26
We have a Managed MP/16 V34 with the latest modem firmware version
(v.2.0.8) but when we try to connect any of its ports to a Courier
V.34 in Leased Line mode (AT&L1) the modems only connect at V32 Terbo
protocol giving a maximum speed of 21.6Kbps.
Note that this is not a distance problem as we tested using a 5 feet cable
and the results was the same.
Someone told me that some USR firmware versions doesn't support V34
protocol in Leased Line mode.
Is this the case? If yes, is there something we can do to upgrade the
MP/16 to support V34 protocol handshaking in Leased Line mode?
tks,
Jose Roberto Bulcao - RioLink Internet
Tel : (021) 577-8899
e-mail : bulcao@rio.com.br
same problem here. WebRAMP customer cannot connect and ACER Open Modems will
not connect either. If they dial a Quad modem running latest v.90 code they
have no problems.
-----Original Message-----
>On Tue, 9 Feb 1999, Blake Fithen wrote:
>
>>
>> has anyone experienced problems with this code? as soon
>> as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
>> customers had problems. The pipline customers sould not
>> connect until i downgraded the DSP code to 1.2.5. the
>> webramp customers are still SOL.
>>
>> any advice would be greatly appreciated.
>>
>> blake
>>
>
>Can you take a "mon PPP" trace for the failed calls on each respective TA
>and send them to me directly?
>
>+--------------------------------------+
>Mike Wronski (mike@coredump.ae.usr.com)
>3Com Network Systems Engineer
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
There really isn't much to the "mon ppp" output for either
case the Ascends do not produce any mon ppp traffic but you
can see them trying to grab a modem if you "li co". The
Webramp M3 (has 56k Sportster plugged in on the back)
produces a "New call received..." message and then after 20
seconds or so gives the "LCP timeout..." message. As soon
as i downgraded to 1.2.5 while keeping 4.1.59, the Ascends
connected and started passing traffic. Also, I pointed the
webramp to a ARC chassis running 4.1.72/1.2.5 in another
city and they logged in immediately and pointed them to a
chassis running 4.1.72/1.2.59, again logged right in.
blake
-----Original Message-----
Sent: Tuesday, February 09, 1999 5:48 PM
On Tue, 9 Feb 1999, Blake Fithen wrote:
>
> has anyone experienced problems with this code? as soon
> as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
> customers had problems. The pipline customers sould not
> connect until i downgraded the DSP code to 1.2.5. the
> webramp customers are still SOL.
>
> any advice would be greatly appreciated.
>
> blake
>
Can you take a "mon PPP" trace for the failed calls on each respective TA
and send them to me directly?
+--------------------------------------+
Mike Wronski (mike@coredump.ae.usr.com)
3Com Network Systems Engineer
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
On Tue, 9 Feb 1999, Tatai SV Krishnan wrote:
> Date: Tue, 9 Feb 1999 09:32:40 -0600 (CST)
> From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
> To: Thomas Suiter <tsuiter@midusa.net>
> Cc: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Hiper arc protocol rejects
>
> On Mon, 8 Feb 1999, Thomas Suiter wrote:
>
> > I'm receiving loads of LCP protocl rejection codes in my ppp session.
> > Anybody know what all it's trying to do here? My connection will be
> > cooking along just fine and then (for lack of a better word) freeze up,
> > and a couple of seconds later start going again. This doesn't happen on
> > our total-control units, so I'm guessing that it's something that needs
> > to be turned off (or at least tuned).
> >
> > Anybody have any ideas on this I'd greatly appreciate it.
> >
> What version of code on the Hiper arc?
> and also do you have stac compression enabled for this link on the client
> side.
HiPer ARC V4.1.72
On the client (Sgi Irix ppp dialer) I've gotten just about everything
turned off that I can.
No: ccp, tx/rx predictor1 link compression, tx/rx bsd link compression,
PPP LCP address & control compression or PPP LCP protocol field
compression.
At one point I had all of these turned on, turning them off has seemed to
shore it up a small bit.
On a secondary note, anybody know what password this box sends back on pap
authentication (after I've authenticated to it, it trys to authen back to
me). I thought it was supposed to be my login username and password, but
it's sending back the username of HiPer. I've turned off recv_pap
requests, but would be nice to know how to fix it.
Thanks
Thomas Suiter
____________________________________________________________________________
Thomas P. Suiter | Systems Administrator
tsuiter@midusa.net | NetSpace Internet Service
Fax: (785) 825-5873 | (785) 823-3565
____________________________________________________________________________
Subject:Re: (usr-tc) Showing errors on DS1 span From: David Bolen <db3l@ans.net> Date: 1999-02-09 21:42:53
Brian Elfert <brian@citilink.com> writes:
> How can I display a listing of errors like CRC error, Bipolar Violations,
> and other alarms over time?
Hopefully someone more familiar with TCM can be more specific about
how this works in TCM, but I can say that the NMC does manage a full
24 hours of statistics (or since the last NMC or CT1/PRI card reset if
more recent) for all of the stats.
They are located in the "ds1IntervalTable" in the MIB for a standard
set of stats (SES, UAS etc..) defined in the older experimental DS1
MIB (RFC 1232) and in the "uds1IntervalTable" in the MIB for 3Com/USR
extensions to that MIB (e.g., FBE, ECRC).
I don't know if TCM can poll older tables, but if it can't you can
certainly query them yourself via any SNMP tool. The table objects
are indexed with an interval number (from 1-96) representing 15 minute
"buckets" for the stats.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| UUNET Technologies, Inc. \ Phone: (914) 701-5327 |
/ 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \
\-----------------------------------------------------------------------/
Worked fine with our P75. But no one with Rockwell HCF's could connect,
which were connecting fine before the upgrade. Other strange problems
were happening as well thus I went back to 1.2.60 and 4.1.79.
On Tue, 9 Feb 1999, Blake Fithen wrote:
>
> has anyone experienced problems with this code? as soon
> as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
> customers had problems. The pipline customers sould not
> connect until i downgraded the DSP code to 1.2.5. the
> webramp customers are still SOL.
>
> any advice would be greatly appreciated.
>
> blake
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) Show idle time on HiperArc? From: Paul M. Oster <devious@minot.com> Date: 1999-02-10 10:31:10
You know, I've confronted 3com about this, and keep getting the "this is a
feature request not a bug" line... BULLSHIT, those idiots charge me 6500
bucks to "upgrade" to a hyperarc, and that thing is BROKEN. (No 3com I
dont buy that what I want is a "feature request"... it worked before, and
you broke it, fix it and dont make me buy a damned worthless contract to
get the code update.)
Its times like this I wonder if a PM3 or a MAX TNT would be easier to work
with.
Paul M. Oster <devious@minot.com> http://www.minot.com/
Magic Internet Services (701) 838-1265
Minots FIRST Internet Connection
-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire
On Tue, 9 Feb 1999, David Swearingin wrote:
> Netserver's 'show sessions' would show each user's session time and idle
> time - Is there a command in HiperArc to show the same?
>
> David
> __________________________________________________
> David Swearingin (david@carolnet.com)
> CARROLLTON INTERNET SERVICE (www.carolnet.com)
> First Financial Group, Inc.
> 11 N. Folger, Carrollton, MO 64633
> 816-542-3002 Fax 816-542-3003
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Fixing an aborted software download From: Brian Elfert <brian@citilink.com> Date: 1999-02-10 10:46:41
I'm not sure if this message went to the list, so I'm reposting it.
I did something stupid, and I had to cancel a software download to a quad
modem card from TCM.
Now, the card is unresponsive, and the status LED just blinks. TCM won't
load code into it.
How can I resurrect this modem card?
Brian
Subject:(usr-tc) Boy, this is certainly my week. From: Jesse Sipprell <jss@evcom.net> Date: 1999-02-10 10:52:01
I have a single local user on a netserver card, "shell":
Username: shell Type: Login User
Host: default Login Service: telnet (23)
Now, normally, this appears to work perfectly. Customers who type "shell" at
the login prompt are telnet'd to the default host with no password requested
by the tc.
*However*, we have recently had reports that the netserver is occasionally
asking for a password when the user sends "shell" as a user. In this case, no
password actually works. We can't reproduce it, but we've checked all port
configurations, and everything appears exactly the same. Anyone seen anything
like this before (running 3.8.1).
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) Show idle time on HiperArc? From: David Swearingin <david@carolnet.com> Date: 1999-02-10 11:34:38
At 12:24 PM 2/10/99 -0500, you wrote:
>What hiperARC have you ever used that reported an idle time? The HARC has
>_never_ reported an idle time; therefore 3com didn't break it -- it never
>existed in the first place. Personally, I'd be more inclined to beleive
>the HARC isn't keeping an idle timer and that's why it's never displayed.
>(Assume it does have an idle timer, then it would take about 2 minutes for
> someone familiar with the code to make it print it out.)
>
I assume an idle timer is working since you can 'set user idle_timeout' as
well as a 'set user session_timeout'
David
__________________________________________________
David Swearingin (david@carolnet.com)
CARROLLTON INTERNET SERVICE (www.carolnet.com)
First Financial Group, Inc.
11 N. Folger, Carrollton, MO 64633
816-542-3002 Fax 816-542-3003
Subject:RE: (usr-tc) Show idle time on HiperArc? From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-10 12:01:30
I understand your frustration. But Its not broken if it was never there.. And it
is comming..Soon..
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul M. Oster
|Sent: Wednesday, February 10, 1999 10:31 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Show idle time on HiperArc?
|
|
|
|
|You know, I've confronted 3com about this, and keep getting the "this is a
|feature request not a bug" line... BULLSHIT, those idiots charge me 6500
|bucks to "upgrade" to a hyperarc, and that thing is BROKEN. (No 3com I
|dont buy that what I want is a "feature request"... it worked before, and
|you broke it, fix it and dont make me buy a damned worthless contract to
|get the code update.)
|
|Its times like this I wonder if a PM3 or a MAX TNT would be easier to work
|with.
|
|Paul M. Oster <devious@minot.com> http://www.minot.com/
|Magic Internet Services (701) 838-1265
|Minots FIRST Internet Connection
|
|-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
|
|"I might not agree with what you have to say but I will defend, to
|my death, your right to say it." - Voltaire
|
|On Tue, 9 Feb 1999, David Swearingin wrote:
|
|> Netserver's 'show sessions' would show each user's session time and idle
|> time - Is there a command in HiperArc to show the same?
|>
|> David
|> __________________________________________________
|> David Swearingin (david@carolnet.com)
|> CARROLLTON INTERNET SERVICE (www.carolnet.com)
|> First Financial Group, Inc.
|> 11 N. Folger, Carrollton, MO 64633
|> 816-542-3002 Fax 816-542-3003
|>
|> -
|> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
|> with "unsubscribe usr-tc" in the body of the 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) Show idle time on HiperArc? From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-10 12:01:31
Idle timer works... Lets not start any ugly rumors :)...
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Swearingin
|Sent: Wednesday, February 10, 1999 11:35 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Show idle time on HiperArc?
|
|
|At 12:24 PM 2/10/99 -0500, you wrote:
|>What hiperARC have you ever used that reported an idle time? The HARC has
|>_never_ reported an idle time; therefore 3com didn't break it -- it never
|>existed in the first place. Personally, I'd be more inclined to beleive
|>the HARC isn't keeping an idle timer and that's why it's never displayed.
|>(Assume it does have an idle timer, then it would take about 2 minutes for
|> someone familiar with the code to make it print it out.)
|>
|I assume an idle timer is working since you can 'set user idle_timeout' as
|well as a 'set user session_timeout'
|
|David
On Wed, 10 Feb 1999, Gilles Melanson wrote:
> > I have had DSP's caught in reboots also.
> >
> > I had to take outthe DSP (and NIC) and put them into another chassis and
> > they would come up fine. Flash them in the other chassis and put them back
> > to the original chassis and everythign was fine . Strange ...
What version of code on the DSP.
>
> That's just slightly strange.
>
> Krish, any input on this one?
>
> Does the HiperDSP have some kind of 'history' that says what happened to
> it, and why it rebooted last (similar to the way Cisco boxes do)
>
No at this point the only option is to have a console attached. However
the next 2.0 code should have a way to store the crash.
krish
> ie:
>
> System restarted by reload at 14:52:04 est Fri Jan 29 1999
>
> Knowing WHY a card crashes is a good way to figure out a way of fixing it.
>
> /gm
>
> --
>
> > From: Gilles Melanson <gilles@vianet.on.ca>
> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
> > Date: Monday, February 08, 1999 7:32 PM
> > Subject: (usr-tc) DSP cards spontaneously rebooting
> >
> >
> > >Do the DSP cards log any kind of information, as far as why they
> > >crash/reboot?
> > >
> > >I just went into my back room, and noticed that one of my DSPs was in the
> > >middle of a reboot. Strange coincidence - another card required a reboot
> > >over the weekend to wake up. This has been happening since I've added DSP
> > >#6 to a brand new chassis (dual 70A) - I had blown the other chassis'
> > >management bus, and this thing replaced it.
> > >
> > >Very, very odd. All the cards are running 1.2.60/4.1.72/5.5.5.
> > >
> > >Any input would be appreciated.. at least it'd be a first step in the
> > >right direction.
> > >
> > >--
> > >Gilles Melanson ViaNet Internet Solutions
> > >System Administrator 128 Larch St. Suite 301
> > >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
> > >
> > > There isn't any reason why Linux can't be implemented as an enterprise
> > > computing solution. Find out what you've been missing while you've
> > > been rebooting Windows NT. -- Eric Hammond
> > >
> > >
> > >-
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the message.
> > > For information on digests or retrieving files and old messages send
> > > "help" to the same address. Do not use quotes in your message.
> > >
> > >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
>
> --
> Gilles Melanson ViaNet Internet Solutions
> System Administrator 128 Larch St. Suite 301
> gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
>
> There isn't any reason why Linux can't be implemented as an enterprise
> computing solution. Find out what you've been missing while you've
> been rebooting Windows NT. -- Eric Hammond
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
> I have had DSP's caught in reboots also.
>
> I had to take outthe DSP (and NIC) and put them into another chassis and
> they would come up fine. Flash them in the other chassis and put them back
> to the original chassis and everythign was fine . Strange ...
That's just slightly strange.
Krish, any input on this one?
Does the HiperDSP have some kind of 'history' that says what happened to
it, and why it rebooted last (similar to the way Cisco boxes do)
ie:
System restarted by reload at 14:52:04 est Fri Jan 29 1999
Knowing WHY a card crashes is a good way to figure out a way of fixing it.
/gm
--
> From: Gilles Melanson <gilles@vianet.on.ca>
> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
> Date: Monday, February 08, 1999 7:32 PM
> Subject: (usr-tc) DSP cards spontaneously rebooting
>
>
> >Do the DSP cards log any kind of information, as far as why they
> >crash/reboot?
> >
> >I just went into my back room, and noticed that one of my DSPs was in the
> >middle of a reboot. Strange coincidence - another card required a reboot
> >over the weekend to wake up. This has been happening since I've added DSP
> >#6 to a brand new chassis (dual 70A) - I had blown the other chassis'
> >management bus, and this thing replaced it.
> >
> >Very, very odd. All the cards are running 1.2.60/4.1.72/5.5.5.
> >
> >Any input would be appreciated.. at least it'd be a first step in the
> >right direction.
> >
> >--
> >Gilles Melanson ViaNet Internet Solutions
> >System Administrator 128 Larch St. Suite 301
> >gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
> >
> > There isn't any reason why Linux can't be implemented as an enterprise
> > computing solution. Find out what you've been missing while you've
> > been rebooting Windows NT. -- Eric Hammond
> >
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
--
Gilles Melanson ViaNet Internet Solutions
System Administrator 128 Larch St. Suite 301
gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8
There isn't any reason why Linux can't be implemented as an enterprise
computing solution. Find out what you've been missing while you've
been rebooting Windows NT. -- Eric Hammond
Subject:Re: (usr-tc) Show idle time on HiperArc? From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-10 12:24:23
Paul M. Oster was heard to say:
>(No 3com I
>dont buy that what I want is a "feature request"... it worked before, and
>you broke it...
What hiperARC have you ever used that reported an idle time? The HARC has
_never_ reported an idle time; therefore 3com didn't break it -- it never
existed in the first place. Personally, I'd be more inclined to beleive
the HARC isn't keeping an idle timer and that's why it's never displayed.
(Assume it does have an idle timer, then it would take about 2 minutes for
someone familiar with the code to make it print it out.)
>Its times like this I wonder if a PM3 or a MAX TNT would be easier to work
>with.
No. However, you might like the interface better.
--Ricky
Subject:Re: (usr-tc) NFAS Support across DSPs From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-10 14:44:05
Thus spake matthews
>Is there any word if or when NFAS will be supported on HiPerDSPs?
The "if" was answered in the past in the affirmative. No answer for
"when" though. (hoping this doesn't turn into another OSPF)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Blake Fithen said once upon a time:
>
>
>has anyone experienced problems with this code? as soon
>as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
>customers had problems. The pipline customers sould not
>connect until i downgraded the DSP code to 1.2.5. the
>webramp customers are still SOL.
Our Pipeline customers connect fine under the new code. Webramp had some
problems, but those customers had some sort of MPPP configuration turned
on. Once they shut it off, they were able to connect.
Subject:Re: (usr-tc) Netserver and mailonly filter?! From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-10 15:06:29
I think in this case, the filter names should be
1. mailonly.in
2. mailonly.out
Tatai SV Krishnan said once upon a time:
>
>you need to have another filter on the netserver called mailin.out
>
>basically you need two filters
>
>1. mailin.in
>2. mailin.out
>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, 8 Feb 1999, Netlink Hardware admin wrote:
>
>>
>> mailonly filter not working on Netserver...works fine on PM2
>>
>> info:
>>
>> -------------
>> xx>ver
>>
>> U.S. Robotics
>> Total Control (tm) NETServer 8/16 version 3.3.0
>>
>> Build date: Nov 14 1997
>> Build time: 10:04:31
>>
>> xx>sho filer mailonly.in
>> - IP rules -
>> 1 permit 0.0.0.0/0 my.target.ip.here/32 tcp dst eq 80
>> 2 permit 0.0.0.0/0 0.0.0.0/0 udp dst eq 53
>> 3 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 25
>> 4 permit 0.0.0.0/0 0.0.0.0/0 tcp dst eq 110
>>
>> --------------
>>
>> Using Livingston Radius_2.01 (yes, I also use the same radius auth server
>> for Pormasters)
>>
>> Radius entry in user database:
>> --------------
>> joeuser Password = "UNIX"
>> User-Service-Type = Framed-User,
>> Session-Timeout = 1800,
>> Framed-Protocol = PPP,
>> Framed-Address = 255.255.255.254,
>> Framed-Netmask = 255.255.255.255,
>> Framed-Routing = None,
>> Framed-Compression = Van-Jacobsen-TCP-IP,
>> Filter-Id = "mailonly",
>> Framed-MTU = 1500
>>
>> --------------
>>
>> This filter works fine for the PM2s. It allows the user to dial in and
>> establish a PPP session.
>>
>> They can then send and receive e-mail and can surf only on our server.
>>
>> When I set this up on the Netserver, the user gets authenticated and
>> connected, but then disconnected immediately. (Acct-Session-Time = 0,
>> Acct-Terminate-Cause = 0).
>>
>> Any ideas??
>>
>> Thanks,
>>
>> Curt
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the 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.
>
Aaron Nabil said once upon a time:
>
>David Bolen writes...
>> . . .
>>The original HDM code (not sure if only beta or the first production
>>round) had some issues with selective reject and it got disabled by
>>default in the configuration - not sure why that hasn't been changed,
>>but maybe its only to stay compatible with earlier releases.
>
>The hiperdsp jitter attenuation default is also wrong, 3com knows
>this, but hasn't fixed it. So I'm guessing that it's something more
>substantial than just a minor tweak to fix. Maybe something to do
>with compatibility with the stored configuration.
What should this be set to?
Subject:(usr-tc) NFAS Support across DSPs From: matthews <matthews@brunnet.net> Date: 1999-02-10 15:22:45
Is there any word if or when NFAS will be supported on HiPerDSPs? We pay
$170 a month here for a D channel and if we could reduce the number of
required D channels it would represent substantial savings.
Be Seeing You...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562
Don't rush me, sonny. You rush a miracle maker and you get rotten
miracles.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject:RE: (usr-tc) Version numbers From: Randy Cosby <dcosby@infowest.com> Date: 1999-02-10 15:43:56
Nope. The numbering goes backwards. 1.2.59 is newer than 1.2.60. 1.2.59-1
is also newer than 1.2.72-4. If you're still confused, check the dates :)
Randy
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Carl Litt
> Sent: Monday, February 08, 1999 1:30 PM
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Version numbers
>
>
>
> No, I think that 1.2.60 is the newest for those of us who have support
> contracts, and 1.2.59 is the newest for all the rest.
>
> If you go to the support page and go directly to "Latest Code" without
> logging in with your Member Login, you have access to DSP 1.2.59 and
> ARC 4.1.59-1, but not DSP 1.2.60 or ARC 4.1.78.
>
>
>
> On Sat, 6 Feb 1999, Bryan Wann wrote:
>
> >
> > Okay, let me get this straight, HiPer DSP 1.2.59 service
> release is newer
> > code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
> >
> > I was talking to 3com support yesterday about an ARC card completely
> > going bezerk and losing its flash, first they said 4.1.72 was
> latest, then
> > later into the call he said 4.1.59-1 was the latest version.
> >
> > Are there any additional strangeness about numbering schemes I should be
> > aware of, or am I just thinking too linear?
> >
> >
> >
> > ---
> > 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
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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) Version numbers From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-10 16:30:44
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Carl Litt
|Sent: Monday, February 08, 1999 2:30 PM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Version numbers
|
|
|
|No, I think that 1.2.60 is the newest for those of us who have support
|contracts, and 1.2.59 is the newest for all the rest.
|
|If you go to the support page and go directly to "Latest Code" without
|logging in with your Member Login, you have access to DSP 1.2.59 and
|ARC 4.1.59-1, but not DSP 1.2.60 or ARC 4.1.78.
|
Let me guide you in the right direction. 1.2.59 is newer than 1.2.60
4.1.59-1 is newer than 4.1.78..
These releases are free and do not require a service contract to get them.
-M
Subject:Re: (usr-tc) NFAS Support across DSPs From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-10 16:37:49
Jeff Mcadams was heard to say:
>Thus spake matthews
>>Is there any word if or when NFAS will be supported on HiPerDSPs?
>
>The "if" was answered in the past in the affirmative. No answer for
>"when" though. (hoping this doesn't turn into another OSPF)
The "if" was yes, and the "when" was in the current beta.
--Ricky
Subject:Re: (usr-tc) NFAS Support across DSPs From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-10 16:54:05
Thus spake Ricky Beam
>Jeff Mcadams was heard to say:
>>Thus spake matthews
>>>Is there any word if or when NFAS will be supported on HiPerDSPs?
>>
>>The "if" was answered in the past in the affirmative. No answer for
>>"when" though. (hoping this doesn't turn into another OSPF)
>The "if" was yes, and the "when" was in the current beta.
Oh, wups...I misremembered then...I didn't think "when" was answered at
all. Sorry.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) MIBS / OIDS From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-10 19:35:39
I have had a problem since I upgraded to the DSP with my MRTG software not
recognizing the ports that are in use on the DSP's.
I have been useing OID '1.3.6.1.4.1.429.1.5.2.1.3' to gather information on
port utilization. i.e. when I am haveing busy signals. This oid is only
recognizeing the Quad modem utilization. Has anyone else had this problem?
Can someone point me to some detail docs on OID's/ Mibs for these DSP's?
Here is the Graphs that I am haveing problems with.
http://netman.alaweb.com/mrtg/all-andalusia.html
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
l
Subject:RE: (usr-tc) NFAS Support across DSPs From: matthews <matthews@brunnet.net> Date: 1999-02-10 19:43:10
On Wednesday, February 10, 1999 5:38 PM, Ricky Beam
[SMTP:jfbeam@enterprise.interpath.net] wrote:
> Jeff Mcadams was heard to say:
> >Thus spake matthews
> >>Is there any word if or when NFAS will be supported on HiPerDSPs?
> >
> >The "if" was answered in the past in the affirmative. No answer for
> >"when" though. (hoping this doesn't turn into another OSPF)
>
> The "if" was yes, and the "when" was in the current beta.
>
Well that's very good to hear. I have another NFAS question though. Our
phone company (also a competing ISP) claims that they're using USR
NETServer/Quad racks and are sharing one D channel among 19 spans. Is that
even possible? My knowledge of how PRI signalling works is somewhat
limited but I was under the impression that the minimum was one D channel
per PRI card.
Be Seeing You...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562
Don't rush me, sonny. You rush a miracle maker and you get rotten
miracles.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pete Ashdown writes...
>Aaron Nabil said once upon a time:
>>
>>David Bolen writes...
>>> . . .
>>>The original HDM code (not sure if only beta or the first production
>>>round) had some issues with selective reject and it got disabled by
>>>default in the configuration - not sure why that hasn't been changed,
>>>but maybe its only to stay compatible with earlier releases.
>>
>>The hiperdsp jitter attenuation default is also wrong, 3com knows
>>this, but hasn't fixed it. So I'm guessing that it's something more
>>substantial than just a minor tweak to fix. Maybe something to do
>>with compatibility with the stored configuration.
>
>What should this be set to?
AttenJitterOnRcvr for loop-timed applications.
--
Aaron Nabil
And I thought MS was stupid with renaming NT5 to Windows 2000... what
happens when you get to 0.0.0?
-----Original Message-----
>Nope. The numbering goes backwards. 1.2.59 is newer than 1.2.60.
1.2.59-1
>is also newer than 1.2.72-4. If you're still confused, check the dates :)
>
>Randy
>
>> -----Original Message-----
>> From: owner-usr-tc@lists.xmission.com
>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Carl Litt
>> Sent: Monday, February 08, 1999 1:30 PM
>> To: usr-tc@lists.xmission.com
>> Subject: Re: (usr-tc) Version numbers
>>
>>
>>
>> No, I think that 1.2.60 is the newest for those of us who have support
>> contracts, and 1.2.59 is the newest for all the rest.
>>
>> If you go to the support page and go directly to "Latest Code" without
>> logging in with your Member Login, you have access to DSP 1.2.59 and
>> ARC 4.1.59-1, but not DSP 1.2.60 or ARC 4.1.78.
>>
>>
>>
>> On Sat, 6 Feb 1999, Bryan Wann wrote:
>>
>> >
>> > Okay, let me get this straight, HiPer DSP 1.2.59 service
>> release is newer
>> > code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
>> >
>> > I was talking to 3com support yesterday about an ARC card completely
>> > going bezerk and losing its flash, first they said 4.1.72 was
>> latest, then
>> > later into the call he said 4.1.59-1 was the latest version.
>> >
>> > Are there any additional strangeness about numbering schemes I should
be
>> > aware of, or am I just thinking too linear?
>> >
>> >
>> >
>> > ---
>> > 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
>> >
>> >
>> > -
>> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> > with "unsubscribe usr-tc" in the body of the message.
>> > For information on digests or retrieving files and old messages send
>> > "help" to the same address. Do not use quotes in your message.
>> >
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the message.
>> For information on digests or retrieving files and old messages send
>> "help" to the same address. Do not use quotes in your message.
>>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) DSP upgrades From: Terry Kennedy <terry@olypen.com> Date: 1999-02-11 10:37:42
Does the hyperarc limit of seven DSP's per still apply?
Been hearing quite a bit of how you don't want to apply the upgrade
with TCM. Is this still true?
I am running 4.0.30 on the HyperArc and 1.2.68 on the dsp's.
Is there any problem with going on to 1.2.59 on the dspand 4.1.59-1
on the HyperArc?
Subject:RE: (usr-tc) Version numbers From: Paul M. Oster <devious@minot.com> Date: 1999-02-11 10:55:59
Maybe someone from 3com can spell this out in REALLY simple english for
those of us that still dont see it... I've always been confused by this
numbering, but just went by the dates... now I'm curious :)
Paul M. Oster <devious@minot.com> http://www.minot.com/
Magic Internet Services (701) 838-1265
Minots FIRST Internet Connection
-=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
"I might not agree with what you have to say but I will defend, to
my death, your right to say it." - Voltaire
On Wed, 10 Feb 1999, Randy Cosby wrote:
> Nope. The numbering goes backwards. 1.2.59 is newer than 1.2.60. 1.2.59-1
> is also newer than 1.2.72-4. If you're still confused, check the dates :)
>
> Randy
>
> > -----Original Message-----
> > From: owner-usr-tc@lists.xmission.com
> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Carl Litt
> > Sent: Monday, February 08, 1999 1:30 PM
> > To: usr-tc@lists.xmission.com
> > Subject: Re: (usr-tc) Version numbers
> >
> >
> >
> > No, I think that 1.2.60 is the newest for those of us who have support
> > contracts, and 1.2.59 is the newest for all the rest.
> >
> > If you go to the support page and go directly to "Latest Code" without
> > logging in with your Member Login, you have access to DSP 1.2.59 and
> > ARC 4.1.59-1, but not DSP 1.2.60 or ARC 4.1.78.
> >
> >
> >
> > On Sat, 6 Feb 1999, Bryan Wann wrote:
> >
> > >
> > > Okay, let me get this straight, HiPer DSP 1.2.59 service
> > release is newer
> > > code than 1.2.60 was, likewise, 4.1.59-1 is newer than 4.1.72-x ?
> > >
> > > I was talking to 3com support yesterday about an ARC card completely
> > > going bezerk and losing its flash, first they said 4.1.72 was
> > latest, then
> > > later into the call he said 4.1.59-1 was the latest version.
> > >
> > > Are there any additional strangeness about numbering schemes I should be
> > > aware of, or am I just thinking too linear?
> > >
> > >
> > >
> > > ---
> > > 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
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the 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) Version numbers From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-11 11:32:34
And god forbid we converge in the middle.. :)..
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams
|Sent: Thursday, February 11, 1999 11:09 AM
|To: usr-tc@lists.xmission.com
|Subject: Re: (usr-tc) Version numbers
|
|
|Thus spake Paul M. Oster
|> Maybe someone from 3com can spell this out in REALLY simple english for
|>those of us that still dont see it... I've always been confused by this
|>numbering, but just went by the dates... now I'm curious :)
|
|For basic releases, the third number goes up, but emergency and service
|releases number them down from the top.
|
|So, you'll have the regular release (using the HiPer Arc's as an
|example) that start with 4.1.1, 4.1.2, 4.1.3, and eventually in this
|series, got released as 4.1.11. ER's and SR's start with 4.1.99,
|4.1.98, 4.1.97, etc. Having SR's come out in this case at 4.1.72 and
|4.1.59.
Subject:Re: (usr-tc) Version numbers From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-11 12:09:25
Thus spake Paul M. Oster
> Maybe someone from 3com can spell this out in REALLY simple english for
>those of us that still dont see it... I've always been confused by this
>numbering, but just went by the dates... now I'm curious :)
For basic releases, the third number goes up, but emergency and service
releases number them down from the top.
So, you'll have the regular release (using the HiPer Arc's as an
example) that start with 4.1.1, 4.1.2, 4.1.3, and eventually in this
series, got released as 4.1.11. ER's and SR's start with 4.1.99,
4.1.98, 4.1.97, etc. Having SR's come out in this case at 4.1.72 and
4.1.59.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) Busy signals on PRI+HiPerDSP From: Joe Konopka <jkonopka@itol.com> Date: 1999-02-11 12:23:53
Greetings.
I've been following the list for awhile, and did some searching through
the archives, and haven't found anything that quite matches my problem.
We have a pool of PRIs coming into HiPerDSP cards. The PRIs are arranged
in a round robin hunt, which seems to be working correctly. Under normal
circumstances, all the DSPs take load approximately evenly.
Once in a while, one or more of the DSPs decides to start rejecting calls.
I have a trace dump that was sent to me by the telco showing that they
delivered a call setup message, and the DSP responded with "Network
congestion, no channel/modem available." Of course, the telco switch has
already decided where it wants to put the call, and when it gets rejected,
the customer gets a busy signal.
I've checked the "di spnstat" counters, and observed that the "no modem
available" counter shows a small number consistently, despite the fact
that busy signals are being handed out quite rapidly. The other counters
all show 0.
The telco switch is a Siemens EWSD, switch type is set as NI-2. The
inbound call routing on the DSPs is set as "Fixed Assignment" which
according to what I've seen on the archives is correct, provided the telco
is doing round-robin.
So far, the solution to this seems to be locating the offending card(s)
and physically removing them from the chassis, waiting a minute or so, and
putting them back in. A "hardware reset" via TCM doesn't always seem to
do it.
This is of course pretty difficult to debug when it's not actually
happening, but it's been fairly consistent every night lately. I'd like
to do some debugging on the D-chan activity at the DSP, and found a link
to a program to decode the trace output:
http://reverb.ae.usr.com/tools/pri_dump.zip
However, this link appears to be dead (404), and some other links that
point to the same server are .htaccess protected. Can anyone tell me where
to get this utility?
Thanks...
Subject:Re: (usr-tc) NFAS Support across DSPs From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-11 13:39:58
matthews was heard to say:
>Well that's very good to hear. I have another NFAS question though. Our
>phone company (also a competing ISP) claims that they're using USR
>NETServer/Quad racks and are sharing one D channel among 19 spans. Is that
>even possible? My knowledge of how PRI signalling works is somewhat
>limited but I was under the impression that the minimum was one D channel
>per PRI card.
Correct. Even with the hiperDSP NFAS, you still cannot have a D channel
span multiple chassis'. (Of course, I don't use NFAS at all so I've not
followed its development in the DSP code other than, "Neato, there's NFAS
settings now.")
--Ricky
I would be interested in hearing from the group on this, but with the ISPs
I have been working with, it is almost all positive. Performance with
Rockwells is up (there was a patch in there for a Rockwell bug that would
affect connect speeds and performance), disconnects and failure to
connects are down, in addition to the benefits of some big bug fixes that
were also in 1.2.60 (mostly system oriented, and improvements with
Lucents).
You do need to remember, a forum like this tends to get mostly problems
reported, so the impression one gets tends to be a bit skewed.
Regards,
JP
On Thu, 11 Feb 1999, Charles Sprickman wrote:
> On Thu, 11 Feb 1999, Terry Kennedy wrote:
>
> > I am running 4.0.30 on the HyperArc and 1.2.68 on the dsp's.
> > Is there any problem with going on to 1.2.59 on the dspand 4.1.59-1
> > on the HyperArc?
>
> Some folks asked this last week, does anyone have field reports on how
> well the SR code is working? So far I've seen two negative comments, one
> stating that webramps stopped working and another stating that all
> 'Rockwell HFC(?)' modems could not connect...
>
> Charles
Greetings.
I first sent this from an address that's not subscribed to the list, so
I'm not sure if it made it. Pardon me if this gets duplicated...
I've been following the list for awhile, and did some searching through
the archives, and haven't found anything that quite matches my problem.
We have a pool of PRIs coming into HiPerDSP cards. The PRIs are arranged
in a round robin hunt, which seems to be working correctly. Under normal
circumstances, all the DSPs take load approximately evenly.
Once in a while, one or more of the DSPs decides to start rejecting calls.
I have a trace dump that was sent to me by the telco showing that they
delivered a call setup message, and the DSP responded with "Network
congestion, no channel/modem available." Of course, the telco switch has
already decided where it wants to put the call, and when it gets rejected,
the customer gets a busy signal.
I've checked the "di spnstat" counters, and observed that the "no modem
available" counter shows a small number consistently, despite the fact
that busy signals are being handed out quite rapidly. The other counters
all show 0.
The telco switch is a Siemens EWSD, switch type is set as NI-2. The
inbound call routing on the DSPs is set as "Fixed Assignment" which
according to what I've seen on the archives is correct, provided the telco
is doing round-robin.
So far, the solution to this seems to be locating the offending card(s)
and physically removing them from the chassis, waiting a minute or so, and
putting them back in. A "hardware reset" via TCM doesn't always seem to
do it.
This is of course pretty difficult to debug when it's not actually
happening, but it's been fairly consistent every night lately. I'd like
to do some debugging on the D-chan activity at the DSP, and found a link
to a program to decode the trace output:
http://reverb.ae.usr.com/tools/pri_dump.zip
However, this link appears to be dead (404), and some other links that
point to the same server are .htaccess protected. Can anyone tell me where
to get this utility?
Thanks...
On Thu, 11 Feb 1999, Terry Kennedy wrote:
> I am running 4.0.30 on the HyperArc and 1.2.68 on the dsp's.
> Is there any problem with going on to 1.2.59 on the dspand 4.1.59-1
> on the HyperArc?
Some folks asked this last week, does anyone have field reports on how
well the SR code is working? So far I've seen two negative comments, one
stating that webramps stopped working and another stating that all
'Rockwell HFC(?)' modems could not connect...
Charles
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
We're running 4.1.59 and 1.2.60 and truthfully I haven't noticed a big
change in the number of calls either way. Still the same people calling
with the same low quality modems with problems I can never seem to
reproduce.
Steve
On Thu, 11 Feb 1999, John Powell wrote:
> I would be interested in hearing from the group on this, but with the ISPs
> I have been working with, it is almost all positive. Performance with
> Rockwells is up (there was a patch in there for a Rockwell bug that would
> affect connect speeds and performance), disconnects and failure to
> connects are down, in addition to the benefits of some big bug fixes that
> were also in 1.2.60 (mostly system oriented, and improvements with
> Lucents).
>
> You do need to remember, a forum like this tends to get mostly problems
> reported, so the impression one gets tends to be a bit skewed.
>
> Regards,
>
> JP
>
> On Thu, 11 Feb 1999, Charles Sprickman wrote:
>
> > On Thu, 11 Feb 1999, Terry Kennedy wrote:
> >
> > > I am running 4.0.30 on the HyperArc and 1.2.68 on the dsp's.
> > > Is there any problem with going on to 1.2.59 on the dspand 4.1.59-1
> > > on the HyperArc?
> >
> > Some folks asked this last week, does anyone have field reports on how
> > well the SR code is working? So far I've seen two negative comments, one
> > stating that webramps stopped working and another stating that all
> > 'Rockwell HFC(?)' modems could not connect...
> >
> > Charles
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Version numbers From: vanhalen@coredcs.com Date: 1999-02-11 14:17:44
That all seems kind of cute, but what I haven't heard yet is why they just
can't number all releases by incrementing. I personally don't care to
know if it's an SR and ER or RR as long as whatever it is fixes some
problems. Why not put 4.1.73(SR) to denote the Service Release status?
Just mho, I'm not really going to lose sleep on it either way. :)
Steve
On Thu, 11 Feb 1999, Jeff Mcadams wrote:
> Thus spake Paul M. Oster
> > Maybe someone from 3com can spell this out in REALLY simple english for
> >those of us that still dont see it... I've always been confused by this
> >numbering, but just went by the dates... now I'm curious :)
>
> For basic releases, the third number goes up, but emergency and service
> releases number them down from the top.
>
> So, you'll have the regular release (using the HiPer Arc's as an
> example) that start with 4.1.1, 4.1.2, 4.1.3, and eventually in this
> series, got released as 4.1.11. ER's and SR's start with 4.1.99,
> 4.1.98, 4.1.97, etc. Having SR's come out in this case at 4.1.72 and
> 4.1.59.
> --
> 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) Hiper Arc routing?? From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-11 14:25:59
Can anyone give any info on this. I have a POP site we are considering
adding DCS 56K. This pop would only have one chassis. Can the Hiper Arc
support this pops routing without me haveing to purchase a router? This pop
would be getting it's internet connections across frame relay from our Main
Core Router. This pop has a PM3 Er in place now and is routing fine. We
have found that the Cisco 5200's do not have to have a router in this
situation but we wanted to use USR.
Thanks
Paul JR.
AlaWeb Network Admin.
Subject:RE: (usr-tc) Busy signals on PRI+HiPerDSP From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-11 14:29:16
You neglected to tell us what code versions you are running on your DSP's and if
you are using HARC or Netserver as the NAS.. Code versions for those would also
be helpfull.
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of ROC Services
|Sent: Thursday, February 11, 1999 2:03 PM
|To: usr-tc@lists.xmission.com
|Subject: (usr-tc) Busy signals on PRI+HiPerDSP
|
|
|Greetings.
|
|I first sent this from an address that's not subscribed to the list, so
|I'm not sure if it made it. Pardon me if this gets duplicated...
|
|I've been following the list for awhile, and did some searching through
|the archives, and haven't found anything that quite matches my problem.
|
|We have a pool of PRIs coming into HiPerDSP cards. The PRIs are arranged
|in a round robin hunt, which seems to be working correctly. Under normal
|circumstances, all the DSPs take load approximately evenly.
|
|Once in a while, one or more of the DSPs decides to start rejecting calls.
|I have a trace dump that was sent to me by the telco showing that they
|delivered a call setup message, and the DSP responded with "Network
|congestion, no channel/modem available." Of course, the telco switch has
|already decided where it wants to put the call, and when it gets rejected,
|the customer gets a busy signal.
|
|I've checked the "di spnstat" counters, and observed that the "no modem
|available" counter shows a small number consistently, despite the fact
|that busy signals are being handed out quite rapidly. The other counters
|all show 0.
|
|The telco switch is a Siemens EWSD, switch type is set as NI-2. The
|inbound call routing on the DSPs is set as "Fixed Assignment" which
|according to what I've seen on the archives is correct, provided the telco
|is doing round-robin.
|
|So far, the solution to this seems to be locating the offending card(s)
|and physically removing them from the chassis, waiting a minute or so, and
|putting them back in. A "hardware reset" via TCM doesn't always seem to
|do it.
|
|This is of course pretty difficult to debug when it's not actually
|happening, but it's been fairly consistent every night lately. I'd like
|to do some debugging on the D-chan activity at the DSP, and found a link
|to a program to decode the trace output:
|
|http://reverb.ae.usr.com/tools/pri_dump.zip
|
|However, this link appears to be dead (404), and some other links that
|point to the same server are .htaccess protected. Can anyone tell me where
|to get this utility?
|
|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.
|
I reported the following earlier this week:
>has anyone experienced problems with this code? as soon
>as i upgraded our ARC chassis, our Pipeline 75 and WebRamp
>customers had problems. The pipline customers sould not
>connect until i downgraded the DSP code to 1.2.5. the
>webramp customers are still SOL.
>
>any advice would be greatly appreciated.
>
>blake
So far the pipline customers are working (my error) but I still
get the following error for the webramp m3 running v1.01 firmware:
New PPP Call received on interface slot:13/mod:1
Connection Establish Timeout (LCP), PPP link down to .
PPP connection down to .
the newer webramps (300e) connect just fine. I've tried 1.2.6, 1.2.5,
and 1.2.59 with no luck.
blake
-----Original Message-----
Sent: Thursday, February 11, 1999 1:44 PM
I would be interested in hearing from the group on this, but with the ISPs
I have been working with, it is almost all positive. Performance with
Rockwells is up (there was a patch in there for a Rockwell bug that would
affect connect speeds and performance), disconnects and failure to
connects are down, in addition to the benefits of some big bug fixes that
were also in 1.2.60 (mostly system oriented, and improvements with
Lucents).
You do need to remember, a forum like this tends to get mostly problems
reported, so the impression one gets tends to be a bit skewed.
Regards,
JP
On Thu, 11 Feb 1999, Charles Sprickman wrote:
> On Thu, 11 Feb 1999, Terry Kennedy wrote:
>
> > I am running 4.0.30 on the HyperArc and 1.2.68 on the dsp's.
> > Is there any problem with going on to 1.2.59 on the dspand 4.1.59-1
> > on the HyperArc?
>
> Some folks asked this last week, does anyone have field reports on how
> well the SR code is working? So far I've seen two negative comments, one
> stating that webramps stopped working and another stating that all
> 'Rockwell HFC(?)' modems could not connect...
>
> Charles
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) HiPER ARC Trade Up From: Brian A. Burgmeier <brianb@ntwrld.com> Date: 1999-02-11 14:40:04
We have the 48 Port USRobotics Chassis. We are about 9 months away from needing and
more ports. USR is having a promo that expires at the end of Feb where we can
upgrade to the new HiPer ARC for $6,555 with a $3200 Rebate when we send in our
Netserver Card set. So for $3,350 we could go from 48 ports to 72 port with the
HiPer ARC. Should we take advantage of this promo or should we wait until we
actually need the extra ports to make a purchase? Any comments or suggestions would
be appreciated.
Thanks-Brian
Subject:Re: (usr-tc) Version numbers From: MegaZone <megazone@megazone.org> Date: 1999-02-11 15:01:44
Once upon a time vanhalen@coredcs.com shaped the electrons to say...
>That all seems kind of cute, but what I haven't heard yet is why they just
>can't number all releases by incrementing. I personally don't care to
>know if it's an SR and ER or RR as long as whatever it is fixes some
>problems. Why not put 4.1.73(SR) to denote the Service Release status?
It is pretty damn confusing... There are a few systems I liked:
Linux -
X.even.Y = production - such as 2.0.24
X.odd.Y = development - such as 2.1.17
And now 2.2.x and 2.3.x, etc
Xylogics-
Rx.x - Release - R8.0.8
Xx.x - eXperimental/development - X8.0.24
If an experimental build proved solid, it turned R - X9.2.7 -> R9.2.7
Livingston-
X - Release - 3.8.2
XbY - Beta - 3.9b5
XcY - Patch - 3.7.2c3
All sequential and ascending.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
On Thu, 11 Feb 1999, Mike Wronski wrote:
Indeed they would. It's been somewhat hectic around here today.
DSP v1.2.59 (latest from totalservice.3com.com)
HARC V4.1.72 - 7
The problem is occurring right now. We have 7 PRIs terminating on this
chassis, in two separate hunt pools. Cards 1-4 and 7 are in one hunt
group, cards 5 and 6 are in another. When the first pool is full, it's
supposed to hunt to the second.
When the busy signals are being returned, 1-4 are completely full, 7 is
full except for one timeslot (#20) and it's not hunting to the next group.
'di atstat' shows the timeslot in-service and idle. 'di spnstat' shows 0
for all the call-rejection counters.
> You neglected to tell us what code versions you are running on your DSP's and if
> you are using HARC or Netserver as the NAS.. Code versions for those would also
> be helpfull.
Subject:Re: (usr-tc) Fixing an aborted software download From: David Bolen <db3l@ans.net> Date: 1999-02-11 15:30:48
Brian Elfert <brian@citilink.com> writes:
> I did something stupid, and I had to cancel a software download to a quad
> modem card from TCM.
Normally I haven't found that to necessarily cause a problem - the
card is definitely stuck in a download state at that point (the RN/FL
LED will have a slow green blink) but you can normally just start
downloading again once the NMC has timed out the aborted process.
> Now, the card is unresponsive, and the status LED just blinks. TCM won't
> load code into it.
What sort of error does TCM give?
> How can I resurrect this modem card?
If you've waited long enough that the command table for that slot
indicates an SDL timeout, you ought to be able to restart it. If not,
you might try resetting the slot through the NMC, waiting for it to be
in an operational state of "loading" and then try again.
If none of that works, then you're pretty much stuck with a PCSDL
download over one of the console ports, but I'm not sure I've ever
actually ended up that way just by aborting a download.
I suppose it's also possible that TCM itself is complaining rather
than the NMC if TCM no longer detects the proper card type or
something (sometimes the slot will become an unknown card in such a
case, particularly if the NMC resets while the card is in this state).
If so, then you should still be able to download via the NMC, but will
need to use some direct SNMP tools and a tftp utility to actually
issue the commands and tftp the SDL/NAC files down.
-- 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) Version numbers From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-11 15:43:10
Thus spake vanhalen@coredcs.com
>That all seems kind of cute, but what I haven't heard yet is why they just
>can't number all releases by incrementing. I personally don't care to
>know if it's an SR and ER or RR as long as whatever it is fixes some
>problems. Why not put 4.1.73(SR) to denote the Service Release status?
>Just mho, I'm not really going to lose sleep on it either way. :)
Agreed...if you look back in the archives you'll see where I've ranted
about that before. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) problem with cli on HARC after flashing to 4.1.59 From: Chris Peltier <cpeltier@netcarrier.net> Date: 1999-02-11 15:46:48
I just reflashed a Hiper Arc to 4.1.59 from
4.1.72 and am having problems with the CLI.
When ever I type a command i get:
HiPer>>
HiPer>> list
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> help
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> jjjj
CLI - Invalid Argument: jjjj
This field is a KEYWORD. The possi`le talues ape:
ADD EXIT REBOOT
ARP HANGUP RECONFIGURE
AND SO ON....
Notice the possi`le talues above. It seems that something is
corrupted. The rack runs fine and I can access it via HARM
and TCM normally. Any ideas on how to fix this? It is in
another POP 50 miles away.
-Chris
Subject:Archives: was(usr-tc) Version numbers From: Brian A. Burgmeier <brianb@ntwrld.com> Date: 1999-02-11 15:49:26
Where are the archives located? Thanks-Brian
Ricky Beam wrote:
> Jeff Mcadams was heard to say:
> >Agreed...if you look back in the archives you'll see where I've ranted
> >about that before. :)
>
> Everyone rants about their (lack of a) versioning system. On the otherhand,
> I don't want to see 3Com version numbers looking like Cisco... I never can
> keep up with what's what.
>
> --Ricky
Thus spake Paul Jr.
>Can anyone give any info on this. I have a POP site we are considering
>adding DCS 56K. This pop would only have one chassis. Can the Hiper Arc
>support this pops routing without me haveing to purchase a router? This pop
>would be getting it's internet connections across frame relay from our Main
>Core Router. This pop has a PM3 Er in place now and is routing fine. We
>have found that the Cisco 5200's do not have to have a router in this
>situation but we wanted to use USR.
Not currently that I'm aware of...not that the Arc is software incapable
of it, but because they don't (I believe) have the NIC's available that
will do WAN connections for the Arc yet. My understanding is that this
is coming. Current NICs for the Arc's only have 2 FE ports I believe.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
> We have the 48 Port USRobotics Chassis. We are about 9 months away from needing and
> more ports. USR is having a promo that expires at the end of Feb where we can
> upgrade to the new HiPer ARC for $6,555 with a $3200 Rebate when we send in our
> Netserver Card set. So for $3,350 we could go from 48 ports to 72 port with the
> HiPer ARC. Should we take advantage of this promo or should we wait until we
> actually need the extra ports to make a purchase? Any comments or suggestions would
> be appreciated.
TAKE IT! You'll want the ARC anyway, and the HDM added to the deal is the
sweet part. Think of how much it will cost later if you don't.
| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt |
| Senior Vice President - Exec-PC, Inc. |
Jeff Mcadams was heard to say:
>Agreed...if you look back in the archives you'll see where I've ranted
>about that before. :)
Everyone rants about their (lack of a) versioning system. On the otherhand,
I don't want to see 3Com version numbers looking like Cisco... I never can
keep up with what's what.
--Ricky
Subject:Re: (usr-tc) problem with cli on HARC after flashing to 4.1.59 From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-11 17:04:14
Hi Chris,
I just verified a 4.1.59 over 4.1.72 - seemed to work fine.
Somehow one or more of the string files for the router application got
corrupted or failed to update on your HARC when installing 4.1.59.
Try downloading 4.1.59 again and that should correct the problem.
-- Matt
Chris Peltier <CPELTIER@iectech.com> on 02/11/99 04:13:21 PM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
I just reflashed a Hiper Arc to 4.1.59 from
4.1.72 and am having problems with the CLI.
When ever I type a command i get:
HiPer>>
HiPer>> list
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> help
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> jjjj
CLI - Invalid Argument: jjjj
This field is a KEYWORD. The possi`le talues ape:
ADD EXIT REBOOT
ARP HANGUP RECONFIGURE
AND SO ON....
Notice the possi`le talues above. It seems that something is
corrupted. The rack runs fine and I can access it via HARM
and TCM normally. Any ideas on how to fix this? It is in
another POP 50 miles away.
-Chris
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) problem with cli on HARC after flashing to 4.1.59 From: Chris Peltier <cpeltier@iectech.com> Date: 1999-02-11 17:13:21
I just reflashed a Hiper Arc to 4.1.59 from
4.1.72 and am having problems with the CLI.
When ever I type a command i get:
HiPer>>
HiPer>> list
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> help
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> jjjj
CLI - Invalid Argument: jjjj
This field is a KEYWORD. The possi`le talues ape:
ADD EXIT REBOOT
ARP HANGUP RECONFIGURE
AND SO ON....
Notice the possi`le talues above. It seems that something is
corrupted. The rack runs fine and I can access it via HARM
and TCM normally. Any ideas on how to fix this? It is in
another POP 50 miles away.
-Chris
Subject:RE: (usr-tc) HARC & Mac Problems From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-11 19:27:40
what DSP code are you using?
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, 11 Feb 1999, Rick wrote:
> 3Commer's,
> Sho nuff...this was the case...we were able to get the MAC user to =
> connect by disabling ppp offloading, but now isdn customers cannot =
> connect.
> Is there a setting we might try as a happy medium?=20
> Enable ppp offloading; isdn can connect, disable ppp offloading; MAC can =
> connect. What's up with that?
> Any idea of a setting we can try next to allow both to connect?
> RickyZ
>
> ----------
> From: Dale Hege[SMTP:fhege@sover.net]
> Sent: Tuesday, February 09, 1999 10:45 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) HARC & Mac Problems
>
>
> Has anyone been having trouble with macintosh users connecting to a harc
> running 4.1.59-1? They connect but ppp never starts up.
>
> -Dale
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:RE: (usr-tc) HARC & Mac Problems From: Rick <rickyz@mindspring.com> Date: 1999-02-11 19:39:01
------ =_NextPart_000_01BE55F6.2F8650C0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
3Commer's,
Sho nuff...this was the case...we were able to get the MAC user to =
connect by disabling ppp offloading, but now isdn customers cannot =
connect.
Is there a setting we might try as a happy medium?=20
Enable ppp offloading; isdn can connect, disable ppp offloading; MAC can =
connect. What's up with that?
Any idea of a setting we can try next to allow both to connect?
RickyZ
Subject:RE: (usr-tc) HARC & Mac Problems From: Charles Sprickman <spork@inch.com> Date: 1999-02-11 22:15:00
We had problems with older mac users. Replacing their configPPP with
FreePPP fixed it all up. I think some of the closed issues in the latest
code regarding "illegal LCP requests" may have fixed this. We are running
1.2.60...
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
On Thu, 11 Feb 1999, Rick wrote:
> 3Commer's,
> Sho nuff...this was the case...we were able to get the MAC user to connect by disabling ppp offloading, but now isdn customers cannot connect.
> Is there a setting we might try as a happy medium?
> Enable ppp offloading; isdn can connect, disable ppp offloading; MAC can connect. What's up with that?
> Any idea of a setting we can try next to allow both to connect?
> RickyZ
>
> ----------
> From: Dale Hege[SMTP:fhege@sover.net]
> Sent: Tuesday, February 09, 1999 10:45 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) HARC & Mac Problems
>
>
> Has anyone been having trouble with macintosh users connecting to a harc
> running 4.1.59-1? They connect but ppp never starts up.
>
> -Dale
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Some Motorola v.90 will not connect any more with the new code 1.2.59.
Charles Sprickman wrote:
>
> On Thu, 11 Feb 1999, Terry Kennedy wrote:
>
> > I am running 4.0.30 on the HyperArc and 1.2.68 on the dsp's.
> > Is there any problem with going on to 1.2.59 on the dspand 4.1.59-1
> > on the HyperArc?
>
> Some folks asked this last week, does anyone have field reports on how
> well the SR code is working? So far I've seen two negative comments, one
> stating that webramps stopped working and another stating that all
> 'Rockwell HFC(?)' modems could not connect...
>
> Charles
>
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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) Gateway modem From: Matthew Opoka <phantom@magnolia.net> Date: 1999-02-12 01:21:24
Anyone have problems with the Gateway modems on the DSPs?
I think the Gateway model number is ???767.
Yes, and re-flashing the Telepath modem fixed the problem.
Matthew Opoka wrote:
>
> Anyone have problems with the Gateway modems on the DSPs?
> I think the Gateway model number is ???767.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) HARC & Mac Problems From: Rick <rickyz@mindspring.com> Date: 1999-02-12 06:25:08
------ =_NextPart_000_01BE5650.7611C100
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Krish,
We are latest; 1.2.59 on the DSP's, and 4.1.59 on the ARC.
Had a customer yesterday with a NEW gateway. I had him get rid of ALL
compression through dialup-networking. He was able to logon after
that...
~~~~~~~~~~~~~~~~~~~~~~~
Cindy Smith
SysAdmin - KTC I-Net
www.ktc.net
~~~~~~~~~~~~~~~~~~~~~~~
On Fri, 12 Feb 1999, you wrote:
>Anyone have problems with the Gateway modems on the DSPs?
>I think the Gateway model number is ???767.
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
--
Gateway modems are usually Winmodems of one type or another. If they are USR
winmodems, they shouldn't have a problem connecting. If they are LT
Winmodems, they need a driver upgrade to 5.39. To tell the difference, go to
Control Panel/Modems/Diagnostics and highlight the Com port that relates to
the modem. Click on More Info and check the ati3 response. If it's an LT, it
will say so there. You can get the drivers from http://www.808hi.com/56k on
the LT Winmodem page.
Wayne Barber
Coastal Telco Services
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Matthew Opoka
> Sent: Friday, February 12, 1999 2:21 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Gateway modem
>
>
> Anyone have problems with the Gateway modems on the DSPs?
> I think the Gateway model number is ???767.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) HARC & Mac Problems From: pferraro@wna-linknet.com Date: 1999-02-12 08:19:11
I too would like to know about this! We have several MAC users
that have upgraded their modems... Get connected (verified in Radius) on a
couple of minutes then disconnected (4.1.72-7/quads with v.90)
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Thu, 11 Feb 1999, Rick wrote:
> 3Commer's,
> Sho nuff...this was the case...we were able to get the MAC user to connect by disabling ppp offloading, but now isdn customers cannot connect.
> Is there a setting we might try as a happy medium?
> Enable ppp offloading; isdn can connect, disable ppp offloading; MAC can connect. What's up with that?
> Any idea of a setting we can try next to allow both to connect?
> RickyZ
>
> ----------
> From: Dale Hege[SMTP:fhege@sover.net]
> Sent: Tuesday, February 09, 1999 10:45 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) HARC & Mac Problems
>
>
> Has anyone been having trouble with macintosh users connecting to a harc
> running 4.1.59-1? They connect but ppp never starts up.
>
> -Dale
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:RE: (usr-tc) HARC & Mac Problems From: pferraro@wna-linknet.com Date: 1999-02-12 08:22:24
What about those MAC user that have os v8.0x They do not have
the old configppp??? Also, the problem we have also exist on the quads
with HiperArc... This is ONLY 56K connections! The only modem type I can
identify is a SUPRA 56k sp! Any ideas on how to fix this?
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Thu, 11 Feb 1999, Charles Sprickman wrote:
> We had problems with older mac users. Replacing their configPPP with
> FreePPP fixed it all up. I think some of the closed issues in the latest
> code regarding "illegal LCP requests" may have fixed this. We are running
> 1.2.60...
>
> Charles
>
> --
> =-----------------= =
> | Charles Sprickman Internet Channel |
> | INCH System Administration Team (212)243-5200 |
> | spork@inch.com access@inch.com |
> = =----------------=
>
> On Thu, 11 Feb 1999, Rick wrote:
>
> > 3Commer's,
> > Sho nuff...this was the case...we were able to get the MAC user to connect by disabling ppp offloading, but now isdn customers cannot connect.
> > Is there a setting we might try as a happy medium?
> > Enable ppp offloading; isdn can connect, disable ppp offloading; MAC can connect. What's up with that?
> > Any idea of a setting we can try next to allow both to connect?
> > RickyZ
> >
> > ----------
> > From: Dale Hege[SMTP:fhege@sover.net]
> > Sent: Tuesday, February 09, 1999 10:45 AM
> > To: usr-tc@lists.xmission.com
> > Subject: (usr-tc) HARC & Mac Problems
> >
> >
> > Has anyone been having trouble with macintosh users connecting to a harc
> > running 4.1.59-1? They connect but ppp never starts up.
> >
> > -Dale
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) What does prompt_delay buy me? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-12 10:29:45
Even though I don't have 4.1.59-2, I would like to know what prompt_delay
does and why some people are so desperate for it.
We tracked down the Macintosh connection problem to the PAP
authentication. This may be what is screwing up *some* models of Webramps
as well. Does prompt_delay help with PAP?
Subject:Re: (usr-tc) problem with cli on HARC after flashing to 4.1.59 From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-12 12:02:53
Did the flash go through - the error looks like some type of corruption.
krish
On Thu, 11 Feb 1999, Chris Peltier wrote:
>
> I just reflashed a Hiper Arc to 4.1.59 from
> 4.1.72 and am having problems with the CLI.
> When ever I type a command i get:
>
> HiPer>>
> HiPer>> list
> CLI - Software Error - Attempt to retrieve string failed: 2178
> HiPer>> help
> CLI - Software Error - Attempt to retrieve string failed: 2178
> HiPer>> jjjj
> CLI - Invalid Argument: jjjj
>
> This field is a KEYWORD. The possi`le talues ape:
> ADD EXIT REBOOT
> ARP HANGUP RECONFIGURE
> AND SO ON....
>
> Notice the possi`le talues above. It seems that something is
> corrupted. The rack runs fine and I can access it via HARM
> and TCM normally. Any ideas on how to fix this? It is in
> another POP 50 miles away.
>
> -Chris
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:Re: (usr-tc) problem with cli on HARC after flashing to 4.1.59 From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-12 12:22:03
Hum, if reflashing the card again with 4.1.59 didn't clear the problem, then
there must be something messed up with the
flash file system that is stopping the software install.
I suggest doing the following (which will def. clear the problem, but will
result in loss of all configuration).
reset card
quickly after reset, on console, type: AT{ZF}
after a bit, you should see the Zmodem download start
serial download the card with 4.1.59 dmf file
This will re-format the flash before doing the download.
You will have to reconfigure the card from scratch.
-- Matt
Chris Peltier <cpeltier@NetCarrier.net> on 02/11/99 02:46:48 PM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
I just reflashed a Hiper Arc to 4.1.59 from
4.1.72 and am having problems with the CLI.
When ever I type a command i get:
HiPer>>
HiPer>> list
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> help
CLI - Software Error - Attempt to retrieve string failed: 2178
HiPer>> jjjj
CLI - Invalid Argument: jjjj
This field is a KEYWORD. The possi`le talues ape:
ADD EXIT REBOOT
ARP HANGUP RECONFIGURE
AND SO ON....
Notice the possi`le talues above. It seems that something is
corrupted. The rack runs fine and I can access it via HARM
and TCM normally. Any ideas on how to fix this? It is in
another POP 50 miles away.
-Chris
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
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) What does prompt_delay buy me? From: Aaron Nabil <nabil@spiritone.com> Date: 1999-02-12 12:28:57
Pete Ashdown writes...
>We tracked down the Macintosh connection problem to the PAP
>authentication.
What did you do to fix it?
--
Aaron Nabil
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-12 13:45:20
Thus spake Pete Ashdown
>Even though I don't have 4.1.59-2, I would like to know what prompt_delay
>does and why some people are so desperate for it.
Heh...its something funky with our setup here. We still support shell
logins (ie, user using PCPlus or Telix or the like), so we needed a way
to easily get to a shell server.
What we do is when the modem connects, a banner message is printed up,
and a timer starts...the timer is defined by the prompt_delay
command...basically, during that time period defined by the
prompt_delay, the user can start up PPP and use PAP to authenticate. If
they don't do anything during that time period, then the access server
(NETServer's have supported this for quite some time, and Harc's do as
of 4.1.59-2) will automatically send in a RADIUS request with a default
userid (also configurable) with no password (or possibly with a default
password configured in the access server), we then, in our RADIUS
server, define that userid (USR_NETS is what we use...was the default in
the NETServers) to be a login user using rlogin, which then causes the
access server to connect the user to the shell server and be presented a
login prompt. (We use a hacked version of rlogind that *always*
presents a login prompt.)
We needed the timeout because we still have many user using scripted
logins for various reasons that after the connect message, waited for
"ogin:", so we needed to have the access server eventually go ahead and
telnet/rlogin to the shell server so they would get the ogin: and the
scripts would continue processing. Having it wait at the access server
indefinitely would break those login scripts.
>We tracked down the Macintosh connection problem to the PAP
>authentication. This may be what is screwing up *some* models of Webramps
>as well. Does prompt_delay help with PAP?
I would think that would be unlikely. If you're doing PAP, PPP has
already started and completely LCP, and prompt_delay has long ago ceased
to be significant (ie, once the first PPP frame is received).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Fixing an aborted software download From: Brian Elfert <brian@citilink.com> Date: 1999-02-12 13:59:09
On Thu, 11 Feb 1999, David Bolen wrote:
> Brian Elfert <brian@citilink.com> writes:
>
> > I did something stupid, and I had to cancel a software download to a quad
> > modem card from TCM.
>
> Normally I haven't found that to necessarily cause a problem - the
> card is definitely stuck in a download state at that point (the RN/FL
> LED will have a slow green blink) but you can normally just start
> downloading again once the NMC has timed out the aborted process.
Actually, I needed working modems, so I swapped cards with another
chassis. Later, I was able to get the card reflashed in the new chassis.
> > Now, the card is unresponsive, and the status LED just blinks. TCM won't
> > load code into it.
>
> What sort of error does TCM give?
Something about device failed or device not ready.
> If none of that works, then you're pretty much stuck with a PCSDL
> download over one of the console ports, but I'm not sure I've ever
> actually ended up that way just by aborting a download.
Apparently, the copy of PCSDL I had doesn't like the quad modem DSL files.
When I told it the prefix was qr, it complained about a unknown prefix.
Brian
I need to know what i need to do to eraset he netserver's configuration
back to factory settings?
Subject:(usr-tc) Hiper Arc? From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-12 19:55:03
Can the Hiper Arc Support 12 DSp cards in one Chassis? I would be only
useing DCS T1's with no static addresses.
If anyone has a chassis in production with this many DSP's please let me
know if I would see any performance differances.
Thanks
Paul Jr.
AlaWeb Network Admin
1800-427-8896
Subject:Re: (usr-tc) Hiper Arc? From: Victor J. Velazquez <victorv@infi.net> Date: 1999-02-12 23:08:03
I am currently using 12 HiperDSP cards with 12 PRIs terminated at each
HiperDSP
and one HiperARC. Be sure to use the latest code for the HiperDSPs and
HiperARC.
At 07:55 PM 2/12/99 -0600, you wrote:
>Can the Hiper Arc Support 12 DSp cards in one Chassis? I would be only
>useing DCS T1's with no static addresses.
>If anyone has a chassis in production with this many DSP's please let me
>know if I would see any performance differances.
>
>
>Thanks
>Paul Jr.
>AlaWeb Network Admin
>1800-427-8896
>
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Rlogin problem with ARC 1.1.59-1 From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-13 09:42:52
On Sat, 13 Feb 1999, King Ho wrote:
>
> Hi,
>
> We are having problem with the ARC dropping packet when users are
> connected using the rlogin login service in the ARC. This problem
> also exists in ARC 1.1.72-7.
>
> Basically, our UUCP users are connected to our server using the rlogin
> service. Downloading files is OK. The problem appears when
> users try to upload large files (>1M) where errors were reported and most
> of the time the uucico program were not able to recover and resulted
> in a time-out. Anyone is using the ARC with UUCP connections.
>
> There is no problem if a netserver (which we replaced with the ARC) or a
> portmaster is used.
>
> I don't know if this problem is related to the fix 8063 given in the
> 1.1.59-1 release note. Below is a quote of the fix:
>
> 8063 Rlogin Client drops data when connected some Unix machines
> Nile UNIX client send unknown control signals causing HARC to drop
> date packets while handling unknown condition
>
This fix was for Rlogin clients that connect to some old unix Servers
which did not understand or did not send the correct control charecters.
Nile Unix client is used in Korea and did not do Rlogin properlly. Your
problem is something different. You are saying that the HiPer arc is
droping a packet - Can you get a trace on the wire?
krish
>
> Could it be that the fix is not complete and some packet drops still
> happen?
>
>
> Thanks.
>
> Best regards,
>
> King Ho
> Global Link Information Services Ltd.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) Rlogin problem with ARC 1.1.59-1 From: King Ho <ml@glink.net.hk> Date: 1999-02-13 11:44:39
Hi,
We are having problem with the ARC dropping packet when users are
connected using the rlogin login service in the ARC. This problem
also exists in ARC 1.1.72-7.
Basically, our UUCP users are connected to our server using the rlogin
service. Downloading files is OK. The problem appears when
users try to upload large files (>1M) where errors were reported and most
of the time the uucico program were not able to recover and resulted
in a time-out. Anyone is using the ARC with UUCP connections.
There is no problem if a netserver (which we replaced with the ARC) or a
portmaster is used.
I don't know if this problem is related to the fix 8063 given in the
1.1.59-1 release note. Below is a quote of the fix:
8063 Rlogin Client drops data when connected some Unix machines
Nile UNIX client send unknown control signals causing HARC to drop
date packets while handling unknown condition
Could it be that the fix is not complete and some packet drops still
happen?
Thanks.
Best regards,
King Ho
Global Link Information Services Ltd.
Subject:Re: (usr-tc) Rlogin problem with ARC 1.1.59-1 From: King Ho <ml@glink.net.hk> Date: 1999-02-13 13:08:29
Forgot to mention that the server is Solaris 2.5.1 running the
uucp package that came with it.
Best regards,
King Ho
Global Link Information Services Ltd.
On Sat, 13 Feb 1999, King Ho wrote:
>
> Hi,
>
> We are having problem with the ARC dropping packet when users are
> connected using the rlogin login service in the ARC. This problem
> also exists in ARC 1.1.72-7.
>
> Basically, our UUCP users are connected to our server using the rlogin
> service. Downloading files is OK. The problem appears when
> users try to upload large files (>1M) where errors were reported and most
> of the time the uucico program were not able to recover and resulted
> in a time-out. Anyone is using the ARC with UUCP connections.
>
> There is no problem if a netserver (which we replaced with the ARC) or a
> portmaster is used.
>
> I don't know if this problem is related to the fix 8063 given in the
> 1.1.59-1 release note. Below is a quote of the fix:
>
> 8063 Rlogin Client drops data when connected some Unix machines
> Nile UNIX client send unknown control signals causing HARC to drop
> date packets while handling unknown condition
>
>
> Could it be that the fix is not complete and some packet drops still
> happen?
>
>
> Thanks.
>
> Best regards,
>
> King Ho
> Global Link Information Services Ltd.
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) Show Session From: Nader Kheyrdan <nader@ccinet.com> Date: 1999-02-14 00:30:40
Hi all
Does any body know why in the NETServer Card V.34/ISDN with Frame Relay
V3.8.1 version when you try to display show sessions, it shows connection
users as well as none connection. In older version it was working OK.
Command> show sessions
Port User Host/Inet/Dest Type Dir Status Start
Idle
---- --------------- ---------------- ------- --- ------------- ------ -----
-
S0 - - Log/Net In USERNAME -
1days
S1 - - Log/Net In IDLE 0
0
S2 - - Log/Net In IDLE 0
0
S3 - - Log/Net In IDLE 0
0
S4 - - Log/Net In IDLE 0
0
S5 - - Log/Net In IDLE 51
0
S6 - - Log/Net In IDLE 2
1
S7 shannon 207.168.4.180 Netwrk In ESTABLISHED 2:21
0
S8 mjwolf 207.168.6.171 Netwrk In ESTABLISHED 41
11
S9 cyvex 207.168.6.202 Netwrk In ESTABLISHED 40
1
S10 leblonk 207.168.4.187 Netwrk In ESTABLISHED 2:12
0
S11 - - Log/Net In IDLE 1:06
0
S12 amptron 207.168.6.193 Netwrk In ESTABLISHED 48
4
S13 - - Log/Net In IDLE 15
15
S14 - - Log/Net In IDLE 26
0
S15 - - Log/Net In IDLE 5
0
S16 - - Log/Net In IDLE 5
0
Nader
Subject:Re: (usr-tc) Rlogin problem with ARC 1.1.59-1 From: King Ho <ml@glink.net.hk> Date: 1999-02-14 04:54:17
Krish,
I captured the data transfer between the ARC and the UUCP server. To save
space, I only present the portion where the problem occurs and please let
me know if you need the whole tcpdump output file.
Below is the portion of data which UUCP is trying to upload to the server
and has data being dropped:
M '4>]T0$ 0!U!_=$!$ =!!1'O]V!%&:_@!C!5D+P'0@@\8*03M-'';2B\3)
MP@0 :@ .:#8 :@!J &H0FO$# SP.OG4U%J FH : <FH4$ +P'12HQ@,
M4%8N_QXD +@ H*,3#&H":@!0FL % +P'0THQP,HQ$,4%8N_QXD +C__Z,-
Below is the output of tcpshow of the packets captured related to
the above data transfer:
Packet 188
Timestamp: 03:24:42.021401
Source Ethernet Address: 00:C0:49:12:E9:EA
Destination Ethernet Address: 08:00:20:22:93:9F
Encapsulated Protocol: IP
IP Header
Version: 4
Header Length: 20 bytes
Service Type: 0x00
Datagram Length: 137 bytes
Identification: 0x6356
Flags: MF=off, DF=off
Fragment Offset: 0
TTL: 255
Encapsulated Protocol: TCP
Header Checksum: 0xC32A
Source IP Address: 202.72.0.49
Destination IP Address: 202.72.0.44
TCP Header
Source Port: 842 (<unknown>)
Destination Port: 513 (login)
Sequence Number: 2859324673
Acknowledgement Number: 2084063307
Header Length: 20 bytes (data=97)
Flags: URG=off, ACK=on, PSH=on
RST=off, SYN=off, FIN=off
Window Advertisement: 3578 bytes
Checksum: 0x4C05
Urgent Pointer: 0
TCP Data
M '4>]T0$ 0!U!_=$!$ =!!1'......O]V!%&:_@!C!5D+P'0@@\8*03M-'';2B\3)
MP@0 :@ .:#8 :@!J &H0FO$#
** Please note that the 6 bytes denoted as "......" above is the checksum
** of the previous 64 bytes of data generated by UUCP. The following
** packets from the ARC should begins with 6 bytes of checksum and then
** the data beginning with "SP.OG".
Packet 189
Timestamp: 03:24:42.022902
Source Ethernet Address: 08:00:20:22:93:9F
Destination Ethernet Address: 00:C0:49:12:E9:EA
Encapsulated Protocol: IP
IP Header
Version: 4
Header Length: 20 bytes
Service Type: 0x00
Datagram Length: 46 bytes
Identification: 0xCDF2
Flags: MF=off, DF=on
Fragment Offset: 0
TTL: 255
Encapsulated Protocol: TCP
Header Checksum: 0x18E9
Source IP Address: 202.72.0.44
Destination IP Address: 202.72.0.49
TCP Header
Source Port: 513 (login)
Destination Port: 842 (<unknown>)
Sequence Number: 2084063307
Acknowledgement Number: 2859324770
Header Length: 20 bytes (data=6)
Flags: URG=off, ACK=on, PSH=on
RST=off, SYN=off, FIN=off
Window Advertisement: 8760 bytes
Checksum: 0xF44C
Urgent Pointer: 0
TCP Data
. ..$.
Packet 190
Timestamp: 03:24:42.024140
Source Ethernet Address: 00:C0:49:12:E9:EA
Destination Ethernet Address: 08:00:20:22:93:9F
Encapsulated Protocol: IP
IP Header
Version: 4
Header Length: 20 bytes
Service Type: 0x00
Datagram Length: 42 bytes
Identification: 0x6357
Flags: MF=off, DF=off
Fragment Offset: 0
TTL: 255
Encapsulated Protocol: TCP
Header Checksum: 0xC388
Source IP Address: 202.72.0.49
Destination IP Address: 202.72.0.44
TCP Header
Source Port: 842 (<unknown>)
Destination Port: 513 (login)
Sequence Number: 2859324770
Acknowledgement Number: 2084063313
Header Length: 20 bytes (data=2)
Flags: URG=off, ACK=on, PSH=on
RST=off, SYN=off, FIN=off
Window Advertisement: 3572 bytes
Checksum: 0xB341
Urgent Pointer: 0
TCP Data
..
** The above packet contains 2 bytes of checksum only so the next
** packets coming from the ARC should contains the remaining 4 bytes of
** checksum and the data begining with "SP.OG".
Packet 191
Timestamp: 03:24:42.024242
Source Ethernet Address: 08:00:20:22:93:9F
Destination Ethernet Address: 00:C0:49:12:E9:EA
Encapsulated Protocol: IP
IP Header
Version: 4
Header Length: 20 bytes
Service Type: 0x00
Datagram Length: 46 bytes
Identification: 0xCDF3
Flags: MF=off, DF=on
Fragment Offset: 0
TTL: 255
Encapsulated Protocol: TCP
Header Checksum: 0x18E8
Source IP Address: 202.72.0.44
Destination IP Address: 202.72.0.49
TCP Header
Source Port: 513 (login)
Destination Port: 842 (<unknown>)
Sequence Number: 2084063313
Acknowledgement Number: 2859324772
Header Length: 20 bytes (data=6)
Flags: URG=off, ACK=on, PSH=on
RST=off, SYN=off, FIN=off
Window Advertisement: 8760 bytes
Checksum: 0xF442
Urgent Pointer: 0
TCP Data
. ..%.
Packet 192
Timestamp: 03:24:42.024909
Source Ethernet Address: 00:C0:49:12:E9:EA
Destination Ethernet Address: 08:00:20:22:93:9F
Encapsulated Protocol: IP
IP Header
Version: 4
Header Length: 20 bytes
Service Type: 0x00
Datagram Length: 40 bytes
Identification: 0x6358
Flags: MF=off, DF=off
Fragment Offset: 0
TTL: 255
Encapsulated Protocol: TCP
Header Checksum: 0xC389
Source IP Address: 202.72.0.49
Destination IP Address: 202.72.0.44
TCP Header
Source Port: 842 (<unknown>)
Destination Port: 513 (login)
Sequence Number: 2859324772
Acknowledgement Number: 2084063319
Header Length: 20 bytes (data=0)
Flags: URG=off, ACK=on, PSH=off
RST=off, SYN=off, FIN=off
Window Advertisement: 3566 bytes
Checksum: 0xC34B
Urgent Pointer: 0
TCP Data
<No data>
Packet 193
Timestamp: 03:24:42.039797
Source Ethernet Address: 00:C0:49:12:E9:EA
Destination Ethernet Address: 08:00:20:22:93:9F
Encapsulated Protocol: IP
IP Header
Version: 4
Header Length: 20 bytes
Service Type: 0x00
Datagram Length: 74 bytes
Identification: 0x6359
Flags: MF=off, DF=off
Fragment Offset: 0
TTL: 255
Encapsulated Protocol: TCP
Header Checksum: 0xC366
Source IP Address: 202.72.0.49
Destination IP Address: 202.72.0.44
TCP Header
Source Port: 842 (<unknown>)
Destination Port: 513 (login)
Sequence Number: 2859324772
Acknowledgement Number: 2084063319
Header Length: 20 bytes (data=34)
Flags: URG=off, ACK=on, PSH=on
RST=off, SYN=off, FIN=off
Window Advertisement: 3566 bytes
Checksum: 0x18CA
Urgent Pointer: 0
TCP Data
G4U%J FH : <FH4$ +P'12HQ@,
M4%8
** This packet begins with "G4U" and we have lost 8 bytes of data!
** Please let me know if there is any other test or data that you want.
Another thing is that if I try to upload the same data file again the
problem will occur at a different part of the data file so I don't think
it is data specific.
By the way, I have tried using different UUCP clients (Unix and DOS and
WinNT) on different computers with different modems and they all have
problem uploading large files when the ARC is used. And they all don't
have problem when the term server is a portmaster 2E.
Best regards,
King Ho
Global Link Information Services Ltd.
On Sat, 13 Feb 1999, Tatai SV Krishnan wrote:
> On Sat, 13 Feb 1999, King Ho wrote:
>
> >
> > Hi,
> >
> > We are having problem with the ARC dropping packet when users are
> > connected using the rlogin login service in the ARC. This problem
> > also exists in ARC 1.1.72-7.
> >
> > Basically, our UUCP users are connected to our server using the rlogin
> > service. Downloading files is OK. The problem appears when
> > users try to upload large files (>1M) where errors were reported and most
> > of the time the uucico program were not able to recover and resulted
> > in a time-out. Anyone is using the ARC with UUCP connections.
> >
> > There is no problem if a netserver (which we replaced with the ARC) or a
> > portmaster is used.
> >
> > I don't know if this problem is related to the fix 8063 given in the
> > 1.1.59-1 release note. Below is a quote of the fix:
> >
> > 8063 Rlogin Client drops data when connected some Unix machines
> > Nile UNIX client send unknown control signals causing HARC to drop
> > date packets while handling unknown condition
> >
>
>
> This fix was for Rlogin clients that connect to some old unix Servers
> which did not understand or did not send the correct control charecters.
> Nile Unix client is used in Korea and did not do Rlogin properlly. Your
> problem is something different. You are saying that the HiPer arc is
> droping a packet - Can you get a trace on the wire?
>
> krish
>
> >
> > Could it be that the fix is not complete and some packet drops still
> > happen?
> >
> >
> > Thanks.
> >
> > Best regards,
> >
> > King Ho
> > Global Link Information Services Ltd.
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Rlogin problem with ARC 1.1.59-1 From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-15 11:06:03
On Sun, 14 Feb 1999, King Ho wrote:
>
> Krish,
>
> I captured the data transfer between the ARC and the UUCP server. To save
> space, I only present the portion where the problem occurs and please let
> me know if you need the whole tcpdump output file.
>
This trace does not tell me much. I do need the whole tcpdump output.
I guess you are using a Sun box here right? In that it should be very
easy to duplicate and get a snoop - tell me your exact config - I will
try to duplicate the same.
regards
krish
> Below is the portion of data which UUCP is trying to upload to the server
> and has data being dropped:
>
> M '4>]T0$ 0!U!_=$!$ =!!1'O]V!%&:_@!C!5D+P'0@@\8*03M-'';2B\3)
> MP@0 :@ .:#8 :@!J &H0FO$# SP.OG4U%J FH : <FH4$ +P'12HQ@,
> M4%8N_QXD +@ H*,3#&H":@!0FL % +P'0THQP,HQ$,4%8N_QXD +C__Z,-
>
> Below is the output of tcpshow of the packets captured related to
> the above data transfer:
>
> Packet 188
> Timestamp: 03:24:42.021401
> Source Ethernet Address: 00:C0:49:12:E9:EA
> Destination Ethernet Address: 08:00:20:22:93:9F
> Encapsulated Protocol: IP
> IP Header
> Version: 4
> Header Length: 20 bytes
> Service Type: 0x00
> Datagram Length: 137 bytes
> Identification: 0x6356
> Flags: MF=off, DF=off
> Fragment Offset: 0
> TTL: 255
> Encapsulated Protocol: TCP
> Header Checksum: 0xC32A
> Source IP Address: 202.72.0.49
> Destination IP Address: 202.72.0.44
> TCP Header
> Source Port: 842 (<unknown>)
> Destination Port: 513 (login)
> Sequence Number: 2859324673
> Acknowledgement Number: 2084063307
> Header Length: 20 bytes (data=97)
> Flags: URG=off, ACK=on, PSH=on
> RST=off, SYN=off, FIN=off
> Window Advertisement: 3578 bytes
> Checksum: 0x4C05
> Urgent Pointer: 0
> TCP Data
>
> M '4>]T0$ 0!U!_=$!$ =!!1'......O]V!%&:_@!C!5D+P'0@@\8*03M-'';2B\3)
> MP@0 :@ .:#8 :@!J &H0FO$#
>
>
> ** Please note that the 6 bytes denoted as "......" above is the checksum
> ** of the previous 64 bytes of data generated by UUCP. The following
> ** packets from the ARC should begins with 6 bytes of checksum and then
> ** the data beginning with "SP.OG".
>
> Packet 189
> Timestamp: 03:24:42.022902
> Source Ethernet Address: 08:00:20:22:93:9F
> Destination Ethernet Address: 00:C0:49:12:E9:EA
> Encapsulated Protocol: IP
> IP Header
> Version: 4
> Header Length: 20 bytes
> Service Type: 0x00
> Datagram Length: 46 bytes
> Identification: 0xCDF2
> Flags: MF=off, DF=on
> Fragment Offset: 0
> TTL: 255
> Encapsulated Protocol: TCP
> Header Checksum: 0x18E9
> Source IP Address: 202.72.0.44
> Destination IP Address: 202.72.0.49
> TCP Header
> Source Port: 513 (login)
> Destination Port: 842 (<unknown>)
> Sequence Number: 2084063307
> Acknowledgement Number: 2859324770
> Header Length: 20 bytes (data=6)
> Flags: URG=off, ACK=on, PSH=on
> RST=off, SYN=off, FIN=off
> Window Advertisement: 8760 bytes
> Checksum: 0xF44C
> Urgent Pointer: 0
> TCP Data
> . ..$.
> -----------------------------------------------------------------
> Packet 190
> Timestamp: 03:24:42.024140
> Source Ethernet Address: 00:C0:49:12:E9:EA
> Destination Ethernet Address: 08:00:20:22:93:9F
> Encapsulated Protocol: IP
> IP Header
> Version: 4
> Header Length: 20 bytes
> Service Type: 0x00
> Datagram Length: 42 bytes
> Identification: 0x6357
> Flags: MF=off, DF=off
> Fragment Offset: 0
> TTL: 255
> Encapsulated Protocol: TCP
> Header Checksum: 0xC388
> Source IP Address: 202.72.0.49
> Destination IP Address: 202.72.0.44
> TCP Header
> Source Port: 842 (<unknown>)
> Destination Port: 513 (login)
> Sequence Number: 2859324770
> Acknowledgement Number: 2084063313
> Header Length: 20 bytes (data=2)
> Flags: URG=off, ACK=on, PSH=on
> RST=off, SYN=off, FIN=off
> Window Advertisement: 3572 bytes
> Checksum: 0xB341
> Urgent Pointer: 0
> TCP Data
> ..
>
> ** The above packet contains 2 bytes of checksum only so the next
> ** packets coming from the ARC should contains the remaining 4 bytes of
> ** checksum and the data begining with "SP.OG".
>
> -----------------------------------------------------------------
> Packet 191
> Timestamp: 03:24:42.024242
> Source Ethernet Address: 08:00:20:22:93:9F
> Destination Ethernet Address: 00:C0:49:12:E9:EA
> Encapsulated Protocol: IP
> IP Header
> Version: 4
> Header Length: 20 bytes
> Service Type: 0x00
> Datagram Length: 46 bytes
> Identification: 0xCDF3
> Flags: MF=off, DF=on
> Fragment Offset: 0
> TTL: 255
> Encapsulated Protocol: TCP
> Header Checksum: 0x18E8
> Source IP Address: 202.72.0.44
> Destination IP Address: 202.72.0.49
> TCP Header
> Source Port: 513 (login)
> Destination Port: 842 (<unknown>)
> Sequence Number: 2084063313
> Acknowledgement Number: 2859324772
> Header Length: 20 bytes (data=6)
> Flags: URG=off, ACK=on, PSH=on
> RST=off, SYN=off, FIN=off
> Window Advertisement: 8760 bytes
> Checksum: 0xF442
> Urgent Pointer: 0
> TCP Data
> . ..%.
> -----------------------------------------------------------------
> Packet 192
> Timestamp: 03:24:42.024909
> Source Ethernet Address: 00:C0:49:12:E9:EA
> Destination Ethernet Address: 08:00:20:22:93:9F
> Encapsulated Protocol: IP
> IP Header
> Version: 4
> Header Length: 20 bytes
> Service Type: 0x00
> Datagram Length: 40 bytes
> Identification: 0x6358
> Flags: MF=off, DF=off
> Fragment Offset: 0
> TTL: 255
> Encapsulated Protocol: TCP
> Header Checksum: 0xC389
> Source IP Address: 202.72.0.49
> Destination IP Address: 202.72.0.44
> TCP Header
> Source Port: 842 (<unknown>)
> Destination Port: 513 (login)
> Sequence Number: 2859324772
> Acknowledgement Number: 2084063319
> Header Length: 20 bytes (data=0)
> Flags: URG=off, ACK=on, PSH=off
> RST=off, SYN=off, FIN=off
> Window Advertisement: 3566 bytes
> Checksum: 0xC34B
> Urgent Pointer: 0
> TCP Data
> <No data>
> -----------------------------------------------------------------
> Packet 193
> Timestamp: 03:24:42.039797
> Source Ethernet Address: 00:C0:49:12:E9:EA
> Destination Ethernet Address: 08:00:20:22:93:9F
> Encapsulated Protocol: IP
> IP Header
> Version: 4
> Header Length: 20 bytes
> Service Type: 0x00
> Datagram Length: 74 bytes
> Identification: 0x6359
> Flags: MF=off, DF=off
> Fragment Offset: 0
> TTL: 255
> Encapsulated Protocol: TCP
> Header Checksum: 0xC366
> Source IP Address: 202.72.0.49
> Destination IP Address: 202.72.0.44
> TCP Header
> Source Port: 842 (<unknown>)
> Destination Port: 513 (login)
> Sequence Number: 2859324772
> Acknowledgement Number: 2084063319
> Header Length: 20 bytes (data=34)
> Flags: URG=off, ACK=on, PSH=on
> RST=off, SYN=off, FIN=off
> Window Advertisement: 3566 bytes
> Checksum: 0x18CA
> Urgent Pointer: 0
> TCP Data
> G4U%J FH : <FH4$ +P'12HQ@,
> M4%8
>
> ** This packet begins with "G4U" and we have lost 8 bytes of data!
> ** Please let me know if there is any other test or data that you want.
>
> Another thing is that if I try to upload the same data file again the
> problem will occur at a different part of the data file so I don't think
> it is data specific.
>
> By the way, I have tried using different UUCP clients (Unix and DOS and
> WinNT) on different computers with different modems and they all have
> problem uploading large files when the ARC is used. And they all don't
> have problem when the term server is a portmaster 2E.
>
> Best regards,
>
> King Ho
> Global Link Information Services Ltd.
>
>
> On Sat, 13 Feb 1999, Tatai SV Krishnan wrote:
>
> > On Sat, 13 Feb 1999, King Ho wrote:
> >
> > >
> > > Hi,
> > >
> > > We are having problem with the ARC dropping packet when users are
> > > connected using the rlogin login service in the ARC. This problem
> > > also exists in ARC 1.1.72-7.
> > >
> > > Basically, our UUCP users are connected to our server using the rlogin
> > > service. Downloading files is OK. The problem appears when
> > > users try to upload large files (>1M) where errors were reported and most
> > > of the time the uucico program were not able to recover and resulted
> > > in a time-out. Anyone is using the ARC with UUCP connections.
> > >
> > > There is no problem if a netserver (which we replaced with the ARC) or a
> > > portmaster is used.
> > >
> > > I don't know if this problem is related to the fix 8063 given in the
> > > 1.1.59-1 release note. Below is a quote of the fix:
> > >
> > > 8063 Rlogin Client drops data when connected some Unix machines
> > > Nile UNIX client send unknown control signals causing HARC to drop
> > > date packets while handling unknown condition
> > >
> >
> >
> > This fix was for Rlogin clients that connect to some old unix Servers
> > which did not understand or did not send the correct control charecters.
> > Nile Unix client is used in Korea and did not do Rlogin properlly. Your
> > problem is something different. You are saying that the HiPer arc is
> > droping a packet - Can you get a trace on the wire?
> >
> > krish
> >
> > >
> > > Could it be that the fix is not complete and some packet drops still
> > > happen?
> > >
> > >
> > > Thanks.
> > >
> > > Best regards,
> > >
> > > King Ho
> > > Global Link Information Services Ltd.
> > >
> > >
> > > -
> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > > with "unsubscribe usr-tc" in the body of the message.
> > > For information on digests or retrieving files and old messages send
> > > "help" to the same address. Do not use quotes in your message.
> > >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > 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) MRTG Solutions From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-15 16:08:01
I modified my hiperdsp.pl script to monitor the utilization of the modems.
It now grabs the DS0 status in bulk and performs much much faster. You
can get it at http://www.cableone.net/ebilleter/hiperdsp.pl
I also have scripts that will work with the Dual PRI and Dual T1 cards.
You will need MRTG 2.5.3 running ( I will not help you troubleshoot that
part )
IMPORTANT: The IP address you are polling is the NMC, not the HiperArc.
I also have scripts that will work with the Dual PRI and Dual T1 cards.
Thanks
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
Use something similar to the following in your mrtg.cfg file
Replace public with your community name (of course you don't use public)
Replace 127.0.0.1 with the ip address of the network management card.
Replace Maxbytes value with the modem capacity of the chassis.
Target[MYTCH1]: `perl c:\perl\lib\tch-pri.pl public@127.0.0.1`
MaxBytes[MYTCH1]: 46
Unscaled[MYTCH1]:ymwd
Title[MYTCH1]: My Total Control Hub
PageTop[MYTCH1]: <H1>My TCH Modem Utilization </H1>
YLegend[MYTCH1]:Modem Capacity
Options[MYTCH1]:gauge,growright
ShortLegend[MYTCH1]:Modems
Legend1[MYTCH1]:  Utilization  
Legend2[MYTCH1]:  Capacity  
Legend3[MYTCH1]:  Connections  
Legend4[MYTCH1]:  Capacity  
LegendI[MYTCH1]:  Utilization  
LegendO[MYTCH1]:  Capacity  
Thanks
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Billy Huddleston
Sent: Monday, February 15, 1999 4:47 PM
How do you integrate this scrip into MRTG?
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter
> Sent: Monday, February 15, 1999 6:08 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) MRTG Solutions
>
>
> I modified my hiperdsp.pl script to monitor the utilization
> of the modems.
> It now grabs the DS0 status in bulk and performs much much
> faster. You
> can get it at http://www.cableone.net/ebilleter/hiperdsp.pl
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> You will need MRTG 2.5.3 running ( I will not help you
> troubleshoot that
> part )
> IMPORTANT: The IP address you are polling is the NMC, not
> the HiperArc.
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> Thanks
> Eric T. Billeter Cable One
> Internet Engineer 1314 North 3rd Street
> ebilleter@cableone.net Phoenix, AZ 85004
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
How do you integrate this scrip into MRTG?
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter
> Sent: Monday, February 15, 1999 6:08 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) MRTG Solutions
>
>
> I modified my hiperdsp.pl script to monitor the utilization
> of the modems.
> It now grabs the DS0 status in bulk and performs much much
> faster. You
> can get it at http://www.cableone.net/ebilleter/hiperdsp.pl
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> You will need MRTG 2.5.3 running ( I will not help you
> troubleshoot that
> part )
> IMPORTANT: The IP address you are polling is the NMC, not
> the HiperArc.
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> Thanks
> Eric T. Billeter Cable One
> Internet Engineer 1314 North 3rd Street
> ebilleter@cableone.net Phoenix, AZ 85004
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
OK, I'm convinced that my NMC is dead. Run/fail and Status lights just
stay red forever... can't flash it, can't do anything with it.
We don't have a hardware support contract on it, so I'm looking to buy a
used NMC from someone. 486sx/33, 4 meg is fine (will upgrade it to 16
when I get my last NETserver trade-in kit), but it MUST have an x2/v.90
feature enable key for Quad modems on it.
We have only 2 racks of Quads, and so only two NMC's with the keys -- as
luck would have it, it's one of those two NMC's that's dead. I've got a
spare 16 meg NMC in there now, but that NMC came from a DSP bundle and it
doesn't have the x2 key for the quads, and they'll be kinda unhappy about
that if we have a power outage...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:Re: (usr-tc) MRTG Solutions From: John C Hill II <carroll@netexas.net> Date: 1999-02-15 19:28:06
Could you post the website of this graph?
John C Hill II
North East Texas Internet
-----Original Message-----
Use something similar to the following in your mrtg.cfg file
Replace public with your community name (of course you don't use public)
Replace 127.0.0.1 with the ip address of the network management card.
Replace Maxbytes value with the modem capacity of the chassis.
Target[MYTCH1]: `perl c:\perl\lib\tch-pri.pl public@127.0.0.1`
MaxBytes[MYTCH1]: 46
Unscaled[MYTCH1]:ymwd
Title[MYTCH1]: My Total Control Hub
PageTop[MYTCH1]: <H1>My TCH Modem Utilization </H1>
YLegend[MYTCH1]:Modem Capacity
Options[MYTCH1]:gauge,growright
ShortLegend[MYTCH1]:Modems
Legend1[MYTCH1]:  Utilization  
Legend2[MYTCH1]:  Capacity  
Legend3[MYTCH1]:  Connections  
Legend4[MYTCH1]:  Capacity  
LegendI[MYTCH1]:  Utilization  
LegendO[MYTCH1]:  Capacity  
Thanks
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Billy Huddleston
Sent: Monday, February 15, 1999 4:47 PM
How do you integrate this scrip into MRTG?
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter
> Sent: Monday, February 15, 1999 6:08 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) MRTG Solutions
>
>
> I modified my hiperdsp.pl script to monitor the utilization
> of the modems.
> It now grabs the DS0 status in bulk and performs much much
> faster. You
> can get it at http://www.cableone.net/ebilleter/hiperdsp.pl
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> You will need MRTG 2.5.3 running ( I will not help you
> troubleshoot that
> part )
> IMPORTANT: The IP address you are polling is the NMC, not
> the HiperArc.
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> Thanks
> Eric T. Billeter Cable One
> Internet Engineer 1314 North 3rd Street
> ebilleter@cableone.net Phoenix, AZ 85004
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
Looking at the PORT's "Session Performance".
There is a column named "Reason for Call Termination"
What does these words means
(1) v42DisconnectCMD(26)
(2) none(32)
(3) rcvdGatewayDiscCmd(62)
(4) ds0Teardown(37)
And how many other reasons that could be possible shown in
this field and how do I know what they means ?
Thanks for help.
Meng Tsai
tsaim@mft.com
Subject:Re: (usr-tc) TCM's "Reason for call termination" From: Ray Whelan <ray_whelan@3com.com> Date: 1999-02-16 08:47:55
--0__=aaxfZp9asd3FZbwtWtjunhuIwsnrwvmRP8D4ywWHtf7sW3VCGSs1eCC4
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
Disconnect/Failure to Connect Reasons
v42DisconnectCmd(26) =BE 'DISC Received'
The remote modem sent a V.42 error control Disconnect request. This is=
a normal
disconnect procedure under V.42 error control when the remote modem is=
the
initiator of the disconnect. This would occur if the user or applicati=
on sent
+++, ATH, or dropped DTR on the remote modem.
none(32) =BE 'No Connection' or 'Online'
This is the value reported to the NMC on a query of disconnect reason d=
uring
modem training or while connected, or a query of the call fail reason w=
hen the
call did not fail. In the I6 screen, the modem will report No Connecti=
on after
being reset or on powerup. From online command mode, it will display ?=
Online?
instead of a disconnect reason.
ds0Teardown(37) =BE 'Call Teardown'
The T1 or PRI Card initiated the disconnect. This usually occurs becaus=
e the
remote modem has hung up: the central office signals to the T1 or PRI c=
ard when
there is a disconnect at the other end of a call. This reason only app=
lies to
T1 or PRI calls, not to POTS calls.
Note to tech support: This reason is a catch-all on T1 and PRI calls. =
It can
mean the remote modem went on hook abruptly without sending a V.42 Disc=
, MNP LD,
or GSTN Cleardown. Even if the remote modem sends these before going =
on-hook,
there is a race condition over whether it will be received locally befo=
re the
ds0Teardown is received. As a failure to connect reason, this could me=
an that a
non-modem call was received. In TCS3.0, failToTrain will be added to h=
elp
isolate non-modem calls.
rcvdGatewayDiscCmd(62) =BE 'Gateway Disconnect Command Received'
The Gateway card sent the modem a disconnect command. This is a normal=
method
of terminating a call locally. This only applies to calls on the packe=
tbus and
is analogous to dtrDrop on the RS-232 NIC interface.
Meng Tsai <tsaim@mft.com> on 16/02/99 01:32:22
Please respond to usr-tc@lists.xmission.com
cc: (Ray Whelan/IE/3Com)
=
--0__=aaxfZp9asd3FZbwtWtjunhuIwsnrwvmRP8D4ywWHtf7sW3VCGSs1eCC4
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Looking at the PORT's "Session Performance".
There is a column named "Reason for Call Termination"
What does these words means
(1) v42DisconnectCMD(26)
(2) none(32)
(3) rcvdGatewayDiscCmd(62)
(4) ds0Teardown(37)
And how many other reasons that could be possible shown in
this field and how do I know what they means ?
Thanks for help.
Meng Tsai
tsaim@mft.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.
--0__=aaxfZp9asd3FZbwtWtjunhuIwsnrwvmRP8D4ywWHtf7sW3VCGSs1eCC4--
http://mrtg.cableone.net
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 John C Hill II
Sent: Monday, February 15, 1999 6:28 PM
Could you post the website of this graph?
John C Hill II
North East Texas Internet
-----Original Message-----
Use something similar to the following in your mrtg.cfg file
Replace public with your community name (of course you don't use public)
Replace 127.0.0.1 with the ip address of the network management card.
Replace Maxbytes value with the modem capacity of the chassis.
Target[MYTCH1]: `perl c:\perl\lib\tch-pri.pl public@127.0.0.1`
MaxBytes[MYTCH1]: 46
Unscaled[MYTCH1]:ymwd
Title[MYTCH1]: My Total Control Hub
PageTop[MYTCH1]: <H1>My TCH Modem Utilization </H1>
YLegend[MYTCH1]:Modem Capacity
Options[MYTCH1]:gauge,growright
ShortLegend[MYTCH1]:Modems
Legend1[MYTCH1]:  Utilization  
Legend2[MYTCH1]:  Capacity  
Legend3[MYTCH1]:  Connections  
Legend4[MYTCH1]:  Capacity  
LegendI[MYTCH1]:  Utilization  
LegendO[MYTCH1]:  Capacity  
Thanks
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Billy Huddleston
Sent: Monday, February 15, 1999 4:47 PM
How do you integrate this scrip into MRTG?
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter
> Sent: Monday, February 15, 1999 6:08 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) MRTG Solutions
>
>
> I modified my hiperdsp.pl script to monitor the utilization
> of the modems.
> It now grabs the DS0 status in bulk and performs much much
> faster. You
> can get it at http://www.cableone.net/ebilleter/hiperdsp.pl
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> You will need MRTG 2.5.3 running ( I will not help you
> troubleshoot that
> part )
> IMPORTANT: The IP address you are polling is the NMC, not
> the HiperArc.
>
> I also have scripts that will work with the Dual PRI and Dual
> T1 cards.
>
> Thanks
> Eric T. Billeter Cable One
> Internet Engineer 1314 North 3rd Street
> ebilleter@cableone.net Phoenix, AZ 85004
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:(usr-tc) ISDN DOVBS From: Charles Sprickman <spork@inch.com> Date: 1999-02-16 11:30:42
Hi,
I asked this a long, long time ago, and now it's come up again... Is
there any USR equipment that supports DOVBS? We are looking to add some
more cards that will take PRIs and are looking to sell ISDN service off
them. In New York City, a DOVBS call has no per-minute charge, so it's
very important that the equipment support this. I know that under the old
Netserver/Quad combo this couldn't be done. Can the ARC/DSP combo handle
this? If so, what does one do to enable it? Will I need a different lead
# for DOVBS to signal that the call is data rather than voice?
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Mike Andrews <mandrews@termfrost.org> writes:
> We have only 2 racks of Quads, and so only two NMC's with the keys -- as
> luck would have it, it's one of those two NMC's that's dead. I've got a
> spare 16 meg NMC in there now, but that NMC came from a DSP bundle and it
> doesn't have the x2 key for the quads, and they'll be kinda unhappy about
> that if we have a power outage...
You do realize that just installing the spare NMC should have disabled
x2/V.90 on your quads, right? The quads would maintain their previous
x2/V.90 setting as long as the NMC was down or not communicating with
them, but as soon as the new NMC boots up the new communication with
the quads will clear any features not enabled in the NMC you just
installed.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| UUNET Technologies, Inc. \ Phone: (914) 701-5327 |
/ 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \
\-----------------------------------------------------------------------/
On Tue, 16 Feb 1999, David Bolen wrote:
> Mike Andrews <mandrews@termfrost.org> writes:
>
> > We have only 2 racks of Quads, and so only two NMC's with the keys -- as
> > luck would have it, it's one of those two NMC's that's dead. I've got a
> > spare 16 meg NMC in there now, but that NMC came from a DSP bundle and it
> > doesn't have the x2 key for the quads, and they'll be kinda unhappy about
> > that if we have a power outage...
>
> You do realize that just installing the spare NMC should have disabled
> x2/V.90 on your quads, right? The quads would maintain their previous
> x2/V.90 setting as long as the NMC was down or not communicating with
> them, but as soon as the new NMC boots up the new communication with
> the quads will clear any features not enabled in the NMC you just
> installed.
Should have, but didn't -- only one card has lost x2/v.90 so far
(according to the uchasSlotStatFeEna object). The last time I
experimented with this, the Quad seemed to hold the key until it was
rebooted, and would then lose it.
But it's not behavior I want to rely on by any means, which is why I'm
begging for someone to sell me an NMC with the feature enabled on it. So
far the only offers have been for cards without it. I could spend $1056
on a new key, worst case, I guess, but... yuck. :)
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:(usr-tc) Can't get quad modem on-line after replacing Hipe Arc From: Chris Peltier <cpeltier@iectech.com> Date: 1999-02-16 13:10:04
I had a problem with a Hiper Arc after flashing
the new ER-Release 4.1.59. I replaced the Hiper Arc
and now one of my 12 Quad modem cards will not
transfer calls to the Hiper ARC. This chassis is
set up for Channelized T1. The calls come to the
card and the modem LED turns red. The Quad card
is on the T1 TDM bus. There are no errors on the
chassis as far as TCM is concerned. Hiper ARC
shows:
list interfaces
INTERFACES
Interface Oper Admin
Name Status Status
eth:1 Up Up
eth:2 Down Up
internal Up Up
loopback Up Up
slot:2/mod:1 Down Up
slot:2/mod:2 Down Up
slot:2/mod:3 Down Up
slot:2/mod:4 Down Up
slot:3/mod:1 Up Up
slot:3/mod:2 Up Up
slot:3/mod:3 Up Up
slot:3/mod:4 Up Up
slot:4/mod:1 Up Up
slot:4/mod:2 Up Up
slot:4/mod:3 Up Up
slot:4/mod:4 Up Up
slot:5/mod:1 Up Up
slot:5/mod:2 Up Up
slot:5/mod:3 Up Up
slot:5/mod:4 Up Up
slot:6/mod:1 Up Up
slot:6/mod:2 Up Up
slot:6/mod:3 Up Up
slot:6/mod:4 Up Up
slot:7/mod:1 Up Up
slot:7/mod:2 Up Up
slot:7/mod:3 Up Up
slot:7/mod:4 Up Up
slot:8/mod:1 Up Up
slot:8/mod:2 Up Up
slot:8/mod:3 Up Up
slot:8/mod:4 Up Up
slot:9/mod:1 Up Up
slot:9/mod:2 Up Up
slot:9/mod:3 Up Up
slot:9/mod:4 Up Up
slot:10/mod:1 Up Up
slot:10/mod:2 Up Up
slot:10/mod:3 Up Up
slot:10/mod:4 Up Up
slot:11/mod:1 Up Up
slot:11/mod:2 Up Up
slot:6/mod:1 Up Up
slot:6/mod:2 Up Up
slot:6/mod:3 Up Up
slot:6/mod:4 Up Up
slot:7/mod:1 Up Up
slot:7/mod:2 Up Up
slot:7/mod:3 Up Up
slot:7/mod:4 Up Up
slot:8/mod:1 Up Up
slot:8/mod:2 Up Up
slot:8/mod:3 Up Up
slot:8/mod:4 Up Up
slot:9/mod:1 Up Up
slot:9/mod:2 Up Up
slot:9/mod:3 Up Up
slot:9/mod:4 Up Up
slot:10/mod:1 Up Up
slot:10/mod:2 Up Up
slot:10/mod:3 Up Up
slot:10/mod:4 Up Up
slot:11/mod:1 Up Up
slot:11/mod:2 Up Up
slot:11/mod:3 Up Up
slot:11/mod:4 Up Up
slot:12/mod:1 Up Up
slot:12/mod:2 Up Up
slot:12/mod:3 Up Up
slot:12/mod:4 Up Up
slot:13/mod:1 Up Up
slot:13/mod:2 Up Up
slot:13/mod:3 Up Up
slot:13/mod:4 Up Up
Any idea what went wrong? Is the card bad or is it a config
problem?
Thanks - Chris
Thus spake Mike Andrews
>But it's not behavior I want to rely on by any means, which is why I'm
>begging for someone to sell me an NMC with the feature enabled on it. So
>far the only offers have been for cards without it. I could spend $1056
>on a new key, worst case, I guess, but... yuck. :)
<rant mode=replay type="why still charging for x2/v.90 enable key?">
OK...gotta ask again...
Why on earth is 3Com still charging for this? Get a clue folks,
x2/v.90 is no longer a *feature*, its a *requirement*. Its time to
eliminate the charge for this...heck, as far as I'm concerned, there was
never a time to charge for it to begin with, but this is *really*
getting ridiculous.
</rant>
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
On Tue, Feb 16, 1999 at 11:30:42AM -0500, Charles Sprickman wrote:
> Hi,
>
> I asked this a long, long time ago, and now it's come up again... Is
> there any USR equipment that supports DOVBS? We are looking to add some
> more cards that will take PRIs and are looking to sell ISDN service off
> them. In New York City, a DOVBS call has no per-minute charge, so it's
> very important that the equipment support this. I know that under the old
> Netserver/Quad combo this couldn't be done. Can the ARC/DSP combo handle
> this? If so, what does one do to enable it? Will I need a different lead
> # for DOVBS to signal that the call is data rather than voice?
>
> Thanks,
>
*Supposedly* the tcr equipment can, but only for Quad modems, with ISDN
terminated on the quads (intead of the munich card). You are supposed to need
a sep. lead number and special DNIS configuration.
Unfortunately, I've never been able to get this to work. I followed Krish's
instructions explicitly (and made sure I understood them) from
interproc.ae.usr.com, but was unable to actually make a DOVBS connection
(using a pipeline 130 on the remote end).
If anyone knows HOW to get this to work, I would definitely be interested in
learning more. ;)
Regards,
--
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) Can't get quad modem on-line after replacing Hipe Arc From: Charles Sprickman <spork@inch.com> Date: 1999-02-16 13:27:00
Try the following:
Select the modem in TCM and hit the "commands" button. Execute a "restore
from default", "hardware flow control default", "save to nvram", and then
a "hardware reset". Add any local changes before the saving to nvram.
If the card still shows down/up, post what you see with a "show chass slot
2" on the Hiper.
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
On Tue, 16 Feb 1999, Chris Peltier wrote:
>
> I had a problem with a Hiper Arc after flashing
> the new ER-Release 4.1.59. I replaced the Hiper Arc
> and now one of my 12 Quad modem cards will not
> transfer calls to the Hiper ARC. This chassis is
> set up for Channelized T1. The calls come to the
> card and the modem LED turns red. The Quad card
> is on the T1 TDM bus. There are no errors on the
> chassis as far as TCM is concerned. Hiper ARC
> shows:
>
> list interfaces
>
> INTERFACES
> Interface Oper Admin
> Name Status Status
> eth:1 Up Up
> eth:2 Down Up
> internal Up Up
> loopback Up Up
> slot:2/mod:1 Down Up
> slot:2/mod:2 Down Up
> slot:2/mod:3 Down Up
> slot:2/mod:4 Down Up
> slot:3/mod:1 Up Up
> slot:3/mod:2 Up Up
> slot:3/mod:3 Up Up
> slot:3/mod:4 Up Up
> slot:4/mod:1 Up Up
> slot:4/mod:2 Up Up
> slot:4/mod:3 Up Up
> slot:4/mod:4 Up Up
> slot:5/mod:1 Up Up
> slot:5/mod:2 Up Up
> slot:5/mod:3 Up Up
> slot:5/mod:4 Up Up
> slot:6/mod:1 Up Up
> slot:6/mod:2 Up Up
> slot:6/mod:3 Up Up
> slot:6/mod:4 Up Up
> slot:7/mod:1 Up Up
> slot:7/mod:2 Up Up
> slot:7/mod:3 Up Up
> slot:7/mod:4 Up Up
> slot:8/mod:1 Up Up
> slot:8/mod:2 Up Up
> slot:8/mod:3 Up Up
> slot:8/mod:4 Up Up
> slot:9/mod:1 Up Up
> slot:9/mod:2 Up Up
> slot:9/mod:3 Up Up
> slot:9/mod:4 Up Up
> slot:10/mod:1 Up Up
> slot:10/mod:2 Up Up
> slot:10/mod:3 Up Up
> slot:10/mod:4 Up Up
> slot:11/mod:1 Up Up
> slot:11/mod:2 Up Up
> slot:6/mod:1 Up Up
> slot:6/mod:2 Up Up
> slot:6/mod:3 Up Up
> slot:6/mod:4 Up Up
> slot:7/mod:1 Up Up
> slot:7/mod:2 Up Up
> slot:7/mod:3 Up Up
> slot:7/mod:4 Up Up
> slot:8/mod:1 Up Up
> slot:8/mod:2 Up Up
> slot:8/mod:3 Up Up
> slot:8/mod:4 Up Up
> slot:9/mod:1 Up Up
> slot:9/mod:2 Up Up
> slot:9/mod:3 Up Up
> slot:9/mod:4 Up Up
> slot:10/mod:1 Up Up
> slot:10/mod:2 Up Up
> slot:10/mod:3 Up Up
> slot:10/mod:4 Up Up
> slot:11/mod:1 Up Up
> slot:11/mod:2 Up Up
> slot:11/mod:3 Up Up
> slot:11/mod:4 Up Up
> slot:12/mod:1 Up Up
> slot:12/mod:2 Up Up
> slot:12/mod:3 Up Up
> slot:12/mod:4 Up Up
> slot:13/mod:1 Up Up
> slot:13/mod:2 Up Up
> slot:13/mod:3 Up Up
> slot:13/mod:4 Up Up
>
> Any idea what went wrong? Is the card bad or is it a config
> problem?
>
> Thanks - Chris
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) MRTG for Totalcontrol chassis. From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-16 13:42:39
For Dual PRI or Dual T1 cards use
http://www.cableone.net/ebilleter/dualpri.pl
HiperDSP Cards use
http://www.cableone.net/ebilleter/hiperdsp.pl
MRTG Configuration sample
http://www.cableone.net/ebilleter/mrtg-cfg.txt
My results
http://mrtg.cableone.net
Remember to poll the NMC and not the netserver or hiperarc.
If it works for you let me know.. if not let me know too.
Thanks
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
Subject:RE: (usr-tc) MRTG for Totalcontrol chassis. From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-16 14:09:38
I suppose you could combine them in your mrtg config
Target[combotch]: `perl c:\perl\lib\dualpri.pl public@127.1.1.1`+`perl
c:\perl\lib\hiperdsp.pl public@127.1.1.1`
MaxBytes[tchtotal]: 92
Title[combotch]: Total Control Hub Totals
PageTop[combotch]: <H1>Total Modem Utilization </H1>
YLegend[combotch]:Modem Capacity
Options[combotch]:gauge,growright
ShortLegend[combotch]:Modems
Legend1[combotch]:  Utilization  
Legend2[combotch]:  Capacity  
Legend3[combotch]:  Connections  
Legend4[combotch]:  Capacity  
LegendI[combotch]:  Utilization  
LegendO[combotch]:  Capacity  
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 Billy Huddleston
Sent: Tuesday, February 16, 1999 1:59 PM
What if you have a mixed system? 2 HyperDSP's and a Dual PRI?
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter
> Sent: Tuesday, February 16, 1999 3:43 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) MRTG for Totalcontrol chassis.
>
>
> For Dual PRI or Dual T1 cards use
>
> http://www.cableone.net/ebilleter/dualpri.pl
>
>
> HiperDSP Cards use
> http://www.cableone.net/ebilleter/hiperdsp.pl
>
>
> MRTG Configuration sample
> http://www.cableone.net/ebilleter/mrtg-cfg.txt
>
> My results
> http://mrtg.cableone.net
>
>
> Remember to poll the NMC and not the netserver or hiperarc.
>
>
> If it works for you let me know.. if not let me know too.
> Thanks
>
> Eric T. Billeter Cable One
> Internet Engineer 1314 North 3rd Street
> ebilleter@cableone.net Phoenix, AZ 85004
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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) Correction for dualt1 config with mrtg From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-16 14:10:21
Dual t1 config should use http://www.cableone.net/ebilleter/dualt1.pl
not dualpri as I specified in the previous post.
dualpri.pl for pri code
dualt1.pl for t1 code
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
Subject:(usr-tc) Radius Tools From: Mike Wronski <mike@coredump.ae.usr.com> Date: 1999-02-16 15:21:56
I have gotten around to fixing and adding to my radius tools. There is now a
radtools distribution available containing the following:
raddebug: decoder for radius packets captured with snoop or tcpdump.
-Supports 3com/USR VSA's
-Supports RFC defined VSA's
-Some fragmented packet support (Sloppy but works)
-More (see README)
client: Simple radius client. Can send authentication and accounting requests and
display the response.
-Supports 128 char passwords. (Others I have used don't.)
mkpkt: Makes a binary file containing a packet you defined similarly to radius
user file definitions.
sndpkt: Can send a packet (or any binary data) to a host. Supports source
spoofing. Does not wait for a reply.
As before, the source and some old binaries are available at
http://coredump.ae.usr.com/raddebug
It compiles fine on Solaris 2.5+ and Linux. Please don't ask about win32, I don't
have the time.
Enjoy!
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) MRTG for Totalcontrol chassis. From: Billy Huddleston <billy@nxs.net> Date: 1999-02-16 15:58:49
What if you have a mixed system? 2 HyperDSP's and a Dual PRI?
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter
> Sent: Tuesday, February 16, 1999 3:43 PM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) MRTG for Totalcontrol chassis.
>
>
> For Dual PRI or Dual T1 cards use
>
> http://www.cableone.net/ebilleter/dualpri.pl
>
>
> HiperDSP Cards use
> http://www.cableone.net/ebilleter/hiperdsp.pl
>
>
> MRTG Configuration sample
> http://www.cableone.net/ebilleter/mrtg-cfg.txt
>
> My results
> http://mrtg.cableone.net
>
>
> Remember to poll the NMC and not the netserver or hiperarc.
>
>
> If it works for you let me know.. if not let me know too.
> Thanks
>
> Eric T. Billeter Cable One
> Internet Engineer 1314 North 3rd Street
> ebilleter@cableone.net Phoenix, AZ 85004
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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 in Quad cards or Munich card? From: Darren Widenmaier <darren@quadrant.net> Date: 1999-02-16 17:05:09
Somewhat of a dated question, but just wanted to get the authoritative
answer (i.e. whatever the newgroup says ;-) ).
Should ISDN calls be terminated on the Quad cards or the Munich card on a
Netserver? I remember seeing somewhere that at one point, the Quads didn't
do digital, and thus the Munich card was developed, and then later digital
Quads appeared. Thus, I'm assuming that if you have the choice, ISDN calls
should be terminated on the Quad cards for the best performance.
Thanks.
-Darren
Subject:(usr-tc) Slow ISDN authentications (Radius or local) From: Darren Widenmaier <darren@quadrant.net> Date: 1999-02-16 17:21:38
How long should ISDN authentication take, and how can I speed it up? How
much faster is it on a HiPer system?
Using: Netserver/Quad modems/Dual PRI, TCS 3.1.1, and accounts stored in
the Netserver (which is faster than with Radius authentication); ISDN calls
terminated on the Quads.
Authentication with this setup takes several seconds, over 5 seconds in
some cases. Using a Livingston PM-2 and BRIs, (_and_ Radius)
authentication only takes 1 second or less. I realize a TC Hub has a lot
more work to do, but I thought call setup with a PRI would be faster than a
BRI...
With this setup, we can't use ISDN to provide "instant-on/always-on" access
(as we do with the PM-2), as the client routers don't get a connection fast
enough to prevent client workstations from getting DNS timeouts on their
first connection attempt.
Thanks.
-Darren
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.
>
Subject:Re: (usr-tc) TCM's "Reason for call termination" From: Brian Uechi <brianu@lava.net> Date: 1999-02-16 18:03:59
On Tue, 16 Feb 1999, Ray Whelan wrote:
> Disconnect/Failure to Connect Reasons
Great info! Where can I find docs for all disconnect reason?
Thanks,
---
Brian K. Uechi Email: brianu@lava.net
Technical Support Engineer Phone: 808-545-5282
LavaNet, Inc. FAX : 808-545-7020
Subject:RE: (usr-tc) Slow ISDN authentications (Radius or local) From: Billy Huddleston <billy@nxs.net> Date: 1999-02-16 18:39:38
I got around slower authentication times with "part-time routed" by pointing
the client's DNS to the router and then having the router get the DNS
servers when it connects. This way the user doesn't get a Can not contact
DNS error message and it also makes the setup a tad easier in the event you
ever change the IP's of your DNS servers.
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Darren Widenmaier
> Sent: Tuesday, February 16, 1999 6:22 PM
> To: usr-tc-digest@lists.xmission.com
> Subject: (usr-tc) Slow ISDN authentications (Radius or local)
>
>
> How long should ISDN authentication take, and how can I speed
> it up? How
> much faster is it on a HiPer system?
>
> Using: Netserver/Quad modems/Dual PRI, TCS 3.1.1, and
> accounts stored in
> the Netserver (which is faster than with Radius
> authentication); ISDN calls
> terminated on the Quads.
>
> Authentication with this setup takes several seconds, over 5
> seconds in
> some cases. Using a Livingston PM-2 and BRIs, (_and_ Radius)
> authentication only takes 1 second or less. I realize a TC
> Hub has a lot
> more work to do, but I thought call setup with a PRI would be
> faster than a
> BRI...
>
> With this setup, we can't use ISDN to provide
> "instant-on/always-on" access
> (as we do with the PM-2), as the client routers don't get a
> connection fast
> enough to prevent client workstations from getting DNS
> timeouts on their
> first connection attempt.
>
> Thanks.
>
> -Darren
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
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.
Subject:Re: (usr-tc) ISDN in Quad cards or Munich card? From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-16 18:55:37
On Tue, 16 Feb 1999, Darren Widenmaier wrote:
> Somewhat of a dated question, but just wanted to get the authoritative
> answer (i.e. whatever the newgroup says ;-) ).
>
> Should ISDN calls be terminated on the Quad cards or the Munich card on a
> Netserver? I remember seeing somewhere that at one point, the Quads didn't
> do digital, and thus the Munich card was developed, and then later digital
> Quads appeared. Thus, I'm assuming that if you have the choice, ISDN calls
> should be terminated on the Quad cards for the best performance.
The old modem code (quad 3.x) did not support ISDN. For this very reason
ISDN calls were terminated on the Munich daughter card. The later
version support ISDN calls.
The quad modem should be used to terminate the ISDN calls. It is a
hardware device and has better performance compared to the Munich card.
krish
>
> Thanks.
>
> -Darren
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
On Tue, 16 Feb 1999, Darren Widenmaier wrote:
> How long should ISDN authentication take, and how can I speed it up? How
> much faster is it on a HiPer system?
The hiper arc (4.1.59 ) takes 1 sec to complete lcp and 5-7 sec to
complete the authentication .
>
> Using: Netserver/Quad modems/Dual PRI, TCS 3.1.1, and accounts stored in
> the Netserver (which is faster than with Radius authentication); ISDN calls
> terminated on the Quads.
Net server takes anywhere between 7-14 sec.
>
> Authentication with this setup takes several seconds, over 5 seconds in
> some cases. Using a Livingston PM-2 and BRIs, (_and_ Radius)
> authentication only takes 1 second or less. I realize a TC Hub has a lot
> more work to do, but I thought call setup with a PRI would be faster than a
> BRI...
>
Depends - the NETServer does take 7-14 sec. The hiper arc is lot faster.
krish
> With this setup, we can't use ISDN to provide "instant-on/always-on" access
> (as we do with the PM-2), as the client routers don't get a connection fast
> enough to prevent client workstations from getting DNS timeouts on their
> first connection attempt.
>
> Thanks.
>
> -Darren
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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 Box needs Help From: Jamie Dolan <jamie@powernetonline.com> Date: 1999-02-16 19:21:52
Hello,
I have a box running 3.6.28, on the netserver, the modems are flashed to
latest code and reset. Starting last night, this unit devloped a problem.
When some users dial in, they get connected, they can ping most of the time,
but all web sites, ICQ, IRC, etc, all time out. The PRI's look ok, and the
unit seems to be taking all of the incoming calls. Any ideas as to why it
would have started acting like this?
Thank You.
--
Jamie Dolan
PowerNet Online LLC.
Internet Access Provider
920-725-5015
http://uspower.net
Subject:RE: (usr-tc) Can't get quad modem on-line after replacing Hipe Ar c From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-16 19:26:51
Do you have a open ticket on this issue? If not do open one. From what
you have said here - the modem is not responding to the packet bus
commands. Either you have a bad hardware or you have a config problem -
We need to investigate and run debug to find this out.
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 Tue, 16 Feb 1999, Chris Peltier wrote:
>
> I restored from the HW default profile, saved to NVRAM
> and did a software reset. No change. I did a hardware reset
> and still no change. The modems do not want to connect to
> the Hiper ARC.
> -chris
> >
> > If the card still shows down/up, post what you see with a
> > "show chass slot
> > 2" on the Hiper.
> >
> HiPer>> show chassis slot 2
>
> CHASSIS SLOT 2 SETTINGS
> Owner: YES
> Description: Gen. 2 V.34 Digital Modem NAC
> Number of Ports: 4
> Type: DYNAMIC Console: NO
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
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.
>
Subject:RE: (usr-tc) Can't get quad modem on-line after replacing Hipe Ar From: Chris Peltier <cpeltier@iectech.com> Date: 1999-02-16 19:40:17
I restored from the HW default profile, saved to NVRAM
and did a software reset. No change. I did a hardware reset
and still no change. The modems do not want to connect to
the Hiper ARC.
-chris
>
> If the card still shows down/up, post what you see with a
> "show chass slot
> 2" on the Hiper.
>
HiPer>> show chassis slot 2
CHASSIS SLOT 2 SETTINGS
Owner: YES
Description: Gen. 2 V.34 Digital Modem NAC
Number of Ports: 4
Type: DYNAMIC Console: NO
On Tue, 16 Feb 1999, Jamie Dolan wrote:
> Hello,
>
> I have a box running 3.6.28, on the netserver, the modems are flashed to
> latest code and reset. Starting last night, this unit devloped a problem.
^^^^^^^^
If you have the latest quad code - then you should have the latest 3.8.1
NETServer code. You see all this falls into syste releases. So the
latest code in quad have some packet bus enhancement that 3.6.x code may
not work with
krish
> When some users dial in, they get connected, they can ping most of the time,
> but all web sites, ICQ, IRC, etc, all time out. The PRI's look ok, and the
> unit seems to be taking all of the incoming calls. Any ideas as to why it
> would have started acting like this?
>
> Thank You.
>
> --
> Jamie Dolan
> PowerNet Online LLC.
> Internet Access Provider
> 920-725-5015
> http://uspower.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) Slow ISDN authentications (Radius or local) From: Darren Widenmaier <darren@quadrant.net> Date: 1999-02-16 19:51:32
At 19:09 -0600 1999-02-16, Tatai SV Krishnan wrote:
>> How long should ISDN authentication take, and how can I speed it up?
>The hiper arc (4.1.59 ) takes 1 sec to complete lcp and 5-7 sec to
>complete the authentication .
>Net server takes anywhere between 7-14 sec.
>> With this setup, we can't use ISDN to provide "instant-on/always-on" access
>> (as we do with the PM-2), as the client routers don't get a connection fast
>> enough to prevent client workstations from getting DNS timeouts on their
>> first connection attempt.
Whoa! (Thanks for the answers, BTW). So what is everyone on the list
using to provide "instant-on/always-on" LAN access to clients (via ISDN),
or is this application just not as common as I thought? We currently
provide this service to lots of our corporate clients, and although we are
gradually moving to SDSL for those users, we still have many to support via
ISDN, and had hoped to do it on the TC platform.
Thanks.
-Darren
I don't know if i ever tried that particular OID, however the
ones I did try when originally doing this, wouldn't count a multilink
call as 2 users (since it is using 2 channels) but only one user.
I also like to see that the capacity (all ds0's) is what it
should be. If a ds0 goes out of service, or hangs it gets represented.
I also like to see max usage and not averages on the graphs.
I really don't care what the average count is. I only
need to worry about peak usage.
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 K Mitchell
Sent: Tuesday, February 16, 1999 9:35 PM
At 10:09 AM 2/16/99 -0700, "Eric Billeter" <ebilleter@cableone.net> wrote:
>http://mrtg.cableone.net
http://mrtg.cableone.net/PHXTCH1.html is one example
Other than the dark green and magenta, which I find kinda pointless for
this usage, what difference does using the perl script make from just using;
Target[tch1]:
1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:<community>@<ARC IP>
as seen at http://www.keyconn.net/mrtg/tch1.html(This is for a HiPer
chassis)?
I'm not knocking your method, just wondering what I'm missing.
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.
At 10:09 AM 2/16/99 -0700, "Eric Billeter" <ebilleter@cableone.net> wrote:
>http://mrtg.cableone.net
http://mrtg.cableone.net/PHXTCH1.html is one example
Other than the dark green and magenta, which I find kinda pointless for
this usage, what difference does using the perl script make from just using;
Target[tch1]:
1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:<community>@<ARC IP>
as seen at http://www.keyconn.net/mrtg/tch1.html(This is for a HiPer chassis)?
I'm not knocking your method, just wondering what I'm missing.
Kirk
Kirk Mitchell-General Manager sysadmin@keyconn.net
Keystone Connect http://www.keyconn.net
Altoona, PA 814-941-5000 We Unlock the World
At 10:07 PM 2/16/99 -0700, you wrote:
>I don't know if i ever tried that particular OID, however the
>ones I did try when originally doing this, wouldn't count a multilink
>call as 2 users (since it is using 2 channels) but only one user.
I don't know about that, as we have no multichannel users.
>I also like to see that the capacity (all ds0's) is what it
>should be. If a ds0 goes out of service, or hangs it gets represented.
>I also like to see max usage and not averages on the graphs.
>I really don't care what the average count is. I only
>need to worry about peak usage.
I understand and agree with the capacity measurement, but I must be missing
something on the useage. What is the difference then between the
'utilization' and 'connections' measurements? Shouldn't they both be the
same as they're snapshots taken every 5 minutes of the usage at that time?
Kirk
Kirk Mitchell-General Manager sysadmin@keyconn.net
Keystone Connect http://www.keyconn.net
Altoona, PA 814-941-5000 We Unlock the World
HI,
I found out what was wrong. The Ethernet NIC went bad. I replaced it and
uped the code to the latest version. Everything seems to be working well,
except, the box no longer seems to show ISDN Connections or support them. I
do a show sessions and there is nothing listed for I0 I1 I2 I3 I4 etc. What
could be causing this?
Thank You.
--
Jamie Dolan
PowerNet Online LLC.
Internet Access Provider
920-725-5015
http://uspower.net
Subject:RE: (usr-tc) (USR-TC) CORRECTION FOR D From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-17 09:05:51
Actually that is my next project.. I will post when finished
Eric T. Billeter Cable One
Internet Engineer 1314 North 3rd Street
ebilleter@cableone.net Phoenix, AZ 85004
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
Sent: Wednesday, February 17, 1999 8:56 AM
Eric,
Have you looked into pulling the ESF stats off of the Dual PRIs or
HDMs ? I was looking to do the current group every 15 minutes for at
least errored seconds to start. I haven't spent the time parsing the
MIBs yet to get the OIDs.
Jeff Binkley
ASA Network Computing
U>Dual t1 config should use http://www.cableone.net/ebilleter/dualt1.pl
U>not dualpri as I specified in the previous post.
U>dualpri.pl for pri code
U>dualt1.pl for t1 code
U>Eric T. Billeter Cable One
U>Internet Engineer 1314 North 3rd Street
U>ebilleter@cableone.net Phoenix, AZ 85004
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.
CMPQwk 1.42 9999
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
FYI -
The IPX limitation Krishnan stated applies only to 64Mb HARC boards. The 128Mb
cards, should be OK
for 14 spans. In fact, stress/stability testing is performed at the 15 span
level.
-- Matt
Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 02/16/99 07:31:00 PM
Please respond to usr-tc@lists.xmission.com
cc: usr-tc@lists.xmission.com (Matt Harper/MW/US/3Com)
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) MRTG for Totalcontrol chassis. From: Phil Dye <pmd@tcp.net.uk> Date: 1999-02-17 10:42:50
On Tue, Feb 16, 1999 at 01:42:39PM -0700, Eric Billeter wrote:
> For Dual PRI or Dual T1 cards use
>
> http://www.cableone.net/ebilleter/dualpri.pl
>
[snip]
> If it works for you let me know.. if not let me know too.
It kinda works...
I'm a bit confused what the second figure (capacity) is supposed to
represent; no matter which chassis I run it on, I always get 44, which
doesn't seem to bear any relation to available channels (each chassis
is different, as we don't use full PRI's on some chassis).
--
Phil Dye | Work: pmd@tcp.net.uk
Network Manager | Play: phil@dye.net ICQ: 21191147
Total Connectivity Providers | Consider myself properly disclaimed
"The team building will continue until morale improves" - simes
Jeff,
While I agree with you, isn't this only an issue with quads ?
Jeff Binkley
ASA Network Computing
U>Thus spake Mike Andrews
U>>But it's not behavior I want to rely on by any means, which is why
U>I'm >begging for someone to sell me an NMC with the feature enabled on
U>it. So >far the only offers have been for cards without it. I could
U>spend $1056 >on a new key, worst case, I guess, but... yuck. :)
U><rant mode=replay type="why still charging for x2/v.90 enable key?">
U>OK...gotta ask again...
U>Why on earth is 3Com still charging for this? Get a clue folks,
U>x2/v.90 is no longer a *feature*, its a *requirement*. Its time to
U>eliminate the charge for this...heck, as far as I'm concerned, there
U>was never a time to charge for it to begin with, but this is *really*
U>getting ridiculous.
CMPQwk 1.42 9999
Subject:(usr-tc) (USR-TC) CORRECTION FOR D From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-17 10:56:00
Eric,
Have you looked into pulling the ESF stats off of the Dual PRIs or
HDMs ? I was looking to do the current group every 15 minutes for at
least errored seconds to start. I haven't spent the time parsing the
MIBs yet to get the OIDs.
Jeff Binkley
ASA Network Computing
U>Dual t1 config should use http://www.cableone.net/ebilleter/dualt1.pl
U>not dualpri as I specified in the previous post.
U>dualpri.pl for pri code
U>dualt1.pl for t1 code
U>Eric T. Billeter Cable One
U>Internet Engineer 1314 North 3rd Street
U>ebilleter@cableone.net Phoenix, AZ 85004
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.
CMPQwk 1.42 9999
Thus spake Jeff Binkley
>While I agree with you, isn't this only an issue with quads ?
Yes...it is only an issue with the quads...the DSP's don't look at the
enable key...which just makes the idea that they still charge for the
enable key for the quads that much more idiotic!
>U>Thus spake Mike Andrews
>U>>But it's not behavior I want to rely on by any means, which is why
>U>I'm >begging for someone to sell me an NMC with the feature enabled on
>U>it. So >far the only offers have been for cards without it. I could
>U>spend $1056 >on a new key, worst case, I guess, but... yuck. :)
>U><rant mode=replay type="why still charging for x2/v.90 enable key?">
>U>OK...gotta ask again...
>U>Why on earth is 3Com still charging for this? Get a clue folks,
>U>x2/v.90 is no longer a *feature*, its a *requirement*. Its time to
>U>eliminate the charge for this...heck, as far as I'm concerned, there
>U>was never a time to charge for it to begin with, but this is *really*
>U>getting ridiculous.
>CMPQwk 1.42 9999
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) LanLinker to Hiper ISDN failing From: Kent Tambling <kent@acceleration.net> Date: 1999-02-17 11:10:11
Am having a problem getting a LanLinker BRI to connect with
a Hiper Chassis. Enabled v110 on the DSPs.
Any other ideas?
Kent Tambling
kent@acceleration.net
System Administrator
www.acceleration.net
Subject:Re: (usr-tc) Slow ISDN authentications (Radius or local) From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-17 11:21:35
FYI -
There was an issue of long LCP connect times for the HARC that has been fixed in
the last few service releases.
I'm sure 4.1.59 has this fix in it. After this fix LCP connect times dropped
dramatically for the HARC....
The same issue that was addressed in the HARC exists in ALL Netserver code
releases.
The long LCP delays were due to LCP packets getting mangled/discarded during the
PPP autodetection startup sequence.
-- Matt
Ricky Beam <jfbeam@enterprise.interpath.net> on 02/17/99 10:51:43 AM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
Tatai SV Krishnan was heard to say:
>On Tue, 16 Feb 1999, Darren Widenmaier wrote:
>> How long should ISDN authentication take, and how can I speed it up? How
>> much faster is it on a HiPer system?
>
>The hiper arc (4.1.59 ) takes 1 sec to complete lcp and 5-7 sec to
>complete the authentication.
>> Using: Netserver/Quad modems/Dual PRI, TCS 3.1.1, and accounts stored in
>> the Netserver (which is faster than with Radius authentication); ISDN calls
>> terminated on the Quads.
>
>Net server takes anywhere between 7-14 sec.
In my experience using ISDN... HARC takes 2-3 seconds to even BEGIN LCP. The
call sets up on the HDSP instantly (as it should.) The authentication process
takes less than a second. The NetServer, however, takes a few seconds for
the quad modem to connect -- I can forgive that -- and then 9 seconds to
begin LCP! The authentication process takes less than a second as well.
I'm at a loss to explain what the LCP delays are. But, in any case, they
are inexcusable. No other dialup product(s) do that -- even the hands-down
worst device in the world (the Nortel Rapport) doesn't have any delay.
The Cisco hardware -- which I don't particually care for, but that's a
different mess -- is lightening fast in this respect.
I catch flak all day about "why does it take so long for my ISDN to login?"
It should take a fraction of a second; and the actual ISDN call setup does
take a fraction of a second. What's the deal here?
--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:(usr-tc) USR BOX From: Jamie Dolan <jamie@powernetonline.com> Date: 1999-02-17 11:43:28
I do not think this ever made it to the list, sorry if it is a duplicate
post.
HI,
I found out what was wrong. The Ethernet NIC went bad. I replaced it and
uped the code to the latest version. Everything seems to be working well,
except, the box no longer seems to show ISDN Connections or support them. I
do a show sessions and there is nothing listed for I0 I1 I2 I3 I4 etc. What
could be causing this?
The ISDN connections seem to be my only real problem.
Thank You.
--
Jamie Dolan
PowerNet Online LLC.
Internet Access Provider
920-725-5015
http://uspower.net
Tatai SV Krishnan was heard to say:
>On Tue, 16 Feb 1999, Darren Widenmaier wrote:
>> How long should ISDN authentication take, and how can I speed it up? How
>> much faster is it on a HiPer system?
>
>The hiper arc (4.1.59 ) takes 1 sec to complete lcp and 5-7 sec to
>complete the authentication.
>> Using: Netserver/Quad modems/Dual PRI, TCS 3.1.1, and accounts stored in
>> the Netserver (which is faster than with Radius authentication); ISDN calls
>> terminated on the Quads.
>
>Net server takes anywhere between 7-14 sec.
In my experience using ISDN... HARC takes 2-3 seconds to even BEGIN LCP. The
call sets up on the HDSP instantly (as it should.) The authentication process
takes less than a second. The NetServer, however, takes a few seconds for
the quad modem to connect -- I can forgive that -- and then 9 seconds to
begin LCP! The authentication process takes less than a second as well.
I'm at a loss to explain what the LCP delays are. But, in any case, they
are inexcusable. No other dialup product(s) do that -- even the hands-down
worst device in the world (the Nortel Rapport) doesn't have any delay.
The Cisco hardware -- which I don't particually care for, but that's a
different mess -- is lightening fast in this respect.
I catch flak all day about "why does it take so long for my ISDN to login?"
It should take a fraction of a second; and the actual ISDN call setup does
take a fraction of a second. What's the deal here?
--Ricky
Subject:RE: (usr-tc) Slow ISDN authentications (Radius or local) From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-17 12:01:57
We use a Hiper chassis for this kind of stuff. The customer uses a =
Zyxel
Prestige or a cisco 1603. Typical dial time and authentication is 5-7
seconds so DNS does not timeout. Radius authentication is slowing =
things
down a bit. For comparison, we also have a PRI card in a cisco 3640, =
and
there it takes 2-3 seconds for dial and authentication. I haven't tried =
to
put the users locally into the TC...
Robert=20
--
Robert von Bismarck
Network Systems Engineer
Petrel Communications SA / SPAN
Tel : +41 22 304 47 47
Fax : +41 22 300 48 43
WWW : http://www.petrel.ch
e-mail : rvb@petrel.ch
> -----Original Message-----
> From: Darren Widenmaier [SMTP:darren@quadrant.net]
> Sent: mercredi, 17. f=E9vrier 1999 02:52
> To: Tatai SV Krishnan
> Cc: usr-tc-digest@lists.xmission.com
> Subject: Re: (usr-tc) Slow ISDN authentications (Radius or local)
>=20
> At 19:09 -0600 1999-02-16, Tatai SV Krishnan wrote:
>=20
> >> How long should ISDN authentication take, and how can I speed it =
up?
>=20
> >The hiper arc (4.1.59 ) takes 1 sec to complete lcp and 5-7 sec to
> >complete the authentication .
>=20
> >Net server takes anywhere between 7-14 sec.
>=20
> >> With this setup, we can't use ISDN to provide =
"instant-on/always-on"
> access
> >> (as we do with the PM-2), as the client routers don't get a =
connection
> fast
> >> enough to prevent client workstations from getting DNS timeouts on
> their
> >> first connection attempt.
>=20
> Whoa! (Thanks for the answers, BTW). So what is everyone on the =
list
> using to provide "instant-on/always-on" LAN access to clients (via =
ISDN),
> or is this application just not as common as I thought? We currently
> provide this service to lots of our corporate clients, and although =
we are
> gradually moving to SDSL for those users, we still have many to =
support
> via
> ISDN, and had hoped to do it on the TC platform.
>=20
> Thanks.
>=20
> -Darren
>=20
>=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.
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-17 12:03:01
Jeff Mcadams said once upon a time:
>We needed the timeout because we still have many user using scripted
>logins for various reasons that after the connect message, waited for
>"ogin:", so we needed to have the access server eventually go ahead and
>telnet/rlogin to the shell server so they would get the ogin: and the
>scripts would continue processing. Having it wait at the access server
>indefinitely would break those login scripts.
Hmmm. We're doing something similar, but we don't rely on the prompt_delay
for login. You may want to consider our setup, since it is a bit more
secure than opening a rlogind to any login.
I hacked radiusd to set the type based upon account (PPP), account@shell
(login), and account@slip (SLIP). That way, we get the best of all worlds,
and since PAP authenticates with just the user name, they can either use
PAP, or the Netserver/ARC prompt to connect. Then I hacked rlogind to
strip off the @shell portion and authenticate based upon username. Put the
ARC/Netserver in hosts.equiv and they don't need to authenticate twice.
I'd also imagine that you have your rlogind tcp-wrapped, if you don't, you
should.
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-17 12:08:49
Aaron Nabil said once upon a time:
>
>Pete Ashdown writes...
>>We tracked down the Macintosh connection problem to the PAP
>>authentication.
>
>What did you do to fix it?
Switched the affected users to a scripted login.
On Wed, 17 Feb 1999, Ricky Beam wrote:
> Tatai SV Krishnan was heard to say:
> >On Tue, 16 Feb 1999, Darren Widenmaier wrote:
> >> How long should ISDN authentication take, and how can I speed it up? How
> >> much faster is it on a HiPer system?
> >
> >The hiper arc (4.1.59 ) takes 1 sec to complete lcp and 5-7 sec to
> >complete the authentication.
>
> >> Using: Netserver/Quad modems/Dual PRI, TCS 3.1.1, and accounts stored in
> >> the Netserver (which is faster than with Radius authentication); ISDN calls
> >> terminated on the Quads.
> >
> >Net server takes anywhere between 7-14 sec.
>
> In my experience using ISDN... HARC takes 2-3 seconds to even BEGIN LCP. The
> call sets up on the HDSP instantly (as it should.) The authentication process
> takes less than a second. The NetServer, however, takes a few seconds for
> the quad modem to connect -- I can forgive that -- and then 9 seconds to
> begin LCP! The authentication process takes less than a second as well.
>
Again - 4.1.59 code is the one that has this feature, the previous code
used to take around 5 sec or more. Check your stats with this code.
krish
> I'm at a loss to explain what the LCP delays are. But, in any case, they
> are inexcusable. No other dialup product(s) do that -- even the hands-down
> worst device in the world (the Nortel Rapport) doesn't have any delay.
>
> The Cisco hardware -- which I don't particually care for, but that's a
> different mess -- is lightening fast in this respect.
>
> I catch flak all day about "why does it take so long for my ISDN to login?"
> It should take a fraction of a second; and the actual ISDN call setup does
> take a fraction of a second. What's the deal here?
>
> --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) Slow ISDN authentications (Radius or local) From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-17 13:12:52
Thus spake Tatai SV Krishnan
>On Wed, 17 Feb 1999, Ricky Beam wrote:
>>In my experience using ISDN... HARC takes 2-3 seconds to even BEGIN LCP. The
>>call sets up on the HDSP instantly (as it should.) The authentication process
>>takes less than a second. The NetServer, however, takes a few seconds for
>>the quad modem to connect -- I can forgive that -- and then 9 seconds to
>>begin LCP! The authentication process takes less than a second as well.
>Again - 4.1.59 code is the one that has this feature, the previous code
s/feature/bug-fix/ I hate it when people try to pass off something as a
feature when its really a fix for something they screwed up to begin
with...or try to pass something off as a feature that's really a bug.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
K Mitchell <mitch@keyconn.net> writes:
> Other than the dark green and magenta, which I find kinda pointless for
> this usage, what difference does using the perl script make from just using;
> Target[tch1]:
> 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:<community>@<ARC IP>
> as seen at http://www.keyconn.net/mrtg/tch1.html(This is for a HiPer chassis)?
> I'm not knocking your method, just wondering what I'm missing.
It's just that querying the HiperARC for active users (the OID you
give is for usrUserManActiveUsers) is checking a different part of the
chassis for information. Depending on your needs it may be more or
less suitable, but except in a properly working steady state it's
probably not quite identical.
Polling the HiperARC asks it how many users it perceives are active
(e.g., the "back-end" of the TC chassis), whereas polling the modem or
in particular DS0 status checks the "front-end" - where the users
first arrive. When the chassis is unchanging and working properly
those two values will likely match.
While you'll probably never see the ARC value exceed the DS0 value
(except possibly in some brief race conditions during call teardown),
the latter could certainly be true if you are having problems
delivering calls from the DS0s to modems (more likely with quads but
can happen with misconfigured HiperDSPs on some code revisions) or if
some of your DS0s are in a bad state. And since DS0 availability is
what users really perceive as the first line of availability, that's
probably the most critical to understanding the availability of your
chassis.
Also, the HiperARC won't consider a channel as an "active" user until
it authenticates as a user. That means that polling the HiperARC will
not include any channels/modems that are in the process of training,
nor those that are at the login prompt. In normal circumstances this
should be fine, but if you are concerned with the most precise gauge
of utilization/availability of a chassis, the DS0 status is best. For
example, you may be having circuit problems that result in a very high
failure to train rate and/or people not negotiating error control and
then being unable to log into the HiperARC due to line noise. Both of
these conditions could result in your inbound DS0s filling up as
people are trying to train/login, but your HiperARC polls would show
that you were under-capacity.
That's not to say that querying the HiperARC isn't a very usable and
probably perfectly acceptable thing to do in most cases - it's just
that at a fine level, there are differences in polling each of the
"locations" (DS0, modem, HiperARC/NETServer) within the call path in a
chassis.
Oh of course, one other difference is that you can only poll the
HiperARC if you have one, whereas although the actual bulk DS0 query
is different by card type (CT1, PRI, HiperDSP), conceptually the
information is the same, so it works on all chassis configurations.
The same generality (even more so since the objects are identical
between quads and HiperDSP) holds for polling the modem status,
although for performance you may end up reverting to checking the
LED status which isn't quite as precise.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| UUNET Technologies, Inc. \ Phone: (914) 701-5327 |
/ 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \
\-----------------------------------------------------------------------/
At 01:15 PM 2/17/99 EST, David Bolen <db3l@ans.net> wrote:
>
>It's just that querying the HiperARC for active users (the OID you
>give is for usrUserManActiveUsers) is checking a different part of the
>chassis for information. Depending on your needs it may be more or
>less suitable, but except in a properly working steady state it's
>probably not quite identical.
[snip]
Your explanation cleared things up in my mind quite a bit, 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) Fixing an aborted software download From: David Bolen <db3l@ans.net> Date: 1999-02-17 14:21:08
Brian Elfert <brian@citilink.com> writes:
> Apparently, the copy of PCSDL I had doesn't like the quad modem DSL files.
>
> When I told it the prefix was qr, it complained about a unknown prefix.
Hmm, that must be a pretty old copy of PCSDL :-)
Check that you've got at least 3.0.2 just to be safe, although I'm
pretty sure that everything past at least 2.0.0 would handle arbitrary
prefixes - if I recall it was only the 1.x.x series that had hardcoded
prefix values. Of course, "latest" for 3.0.2 is circa late '95 :-)
I think you can still find copies of PCSDL.EXE inside of various code
image zip files from Total Service (like the CT1 or quad code).
-- 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) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-17 14:24:10
Thus spake Pete Ashdown
>Jeff Mcadams said once upon a time:
>>We needed the timeout because we still have many user using scripted
>>logins for various reasons that after the connect message, waited for
>>"ogin:", so we needed to have the access server eventually go ahead and
>>telnet/rlogin to the shell server so they would get the ogin: and the
>>scripts would continue processing. Having it wait at the access server
>>indefinitely would break those login scripts.
>Hmmm. We're doing something similar, but we don't rely on the prompt_delay
>for login. You may want to consider our setup, since it is a bit more
>secure than opening a rlogind to any login.
Well...keep in mind...we hacked this rlogind to *always* put up a login
prompt...ie, no trust relationships in it at all. Basically we're using
rlogin so we can ensure 8-bit clean connections. We were using telnet,
until we hit a version of the NETServer code that didn't do an 8-bit
clean telnet (was quickly fixed, but we never did switch back). Because
the rlogind *always* presents a login prompt, regardless of hosts.equiv
or whatever, its basically funtioning as a telnetd, just with the rlogin
transport to ensure 8-bit clean transport.
>I hacked radiusd to set the type based upon account (PPP), account@shell
>(login), and account@slip (SLIP).
Man...we looked at that back when we were using Xyplex equipment and
considering switching to PortMasters (that's back in the 3.3.1 and
earlier ComOS days...MZ proly remembers me from portmaster-users back
then...I was a PITA back then too :) and rejected that for the (IMHO)
hideous, ugly, hack that it is.
Besides...even back then, we were already having to support legacy,
scripted logins (we started providing Internet Services back in the
mid-80's...we've been at this for a while) that would have broken with
that kludge too.
This all hails back from our start-up days when we ran PPP on our shell
servers because we didn't have any access servers to run it on...we used
DigiBoards connected to first a Linux box (1.0.8 and earlier vintage),
and then to a Sparc (Solaris 2.3 vintage). We still have some logins in
use from back in those days and still support them using the same
scripts to login...which expect CONNECT, then ogin:, then present their
userid. We couldn't, because of that, depend on everyone entering
"@ppp" or "@slip" or "@shell" afterwards with thier userid.
We kludged around with the PortMasters (ComOS version 3.0.4 and 3.3.1 if
I remember correctly) to have them present a fake shell server login
(basically duplicated our /etc/issue file in the PM's login prompt), and
then use rlogin (with the PM's in /etc/hosts.equiv) to get access to the
shell server without re-authenticating....that was obviously rather
ugly.
Anyway...the prompt delay works quite well...is rather clean, works with
all our legacy setups, etc. The only real downside to it is if the PPP
software on the users end doesn't get PPP frames up and flowing to the
NETServer/Harc, then they get connected to the shell server and then
their PPP connection fails...That happens so infrequently though that
its really not a problem.
>That way, we get the best of all worlds,
>and since PAP authenticates with just the user name, they can either use
>PAP, or the Netserver/ARC prompt to connect.
Ew...hope you're not using Multi-Link and allowing logins with the
NETServer/ARC login prompt without at least requiring PAP authentication
as well as that's rather an insecure way of handling MP.
>Then I hacked rlogind to
>strip off the @shell portion and authenticate based upon username. Put the
>ARC/Netserver in hosts.equiv and they don't need to authenticate twice.
Trust relationships...no thanks. :) I'll just have rlogind prompt for
a password all the time and trust no-one. :)
>I'd also imagine that you have your rlogind tcp-wrapped, if you don't, you
>should.
Oh yes, *everything* that we start out of inetd.conf (which is precious
little) is tcp wrapped. Not a perfect security solution, but definitely
better than not doing it.
Regardless though, since the rlogind always presents a login prompt,
regardless of hosts.equiv and such, its really not *necessary* (though
certainly nice to get the logging and such that tcpd provides).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-17 14:24:50
Thus spake Pete Ashdown
>Aaron Nabil said once upon a time:
>>Pete Ashdown writes...
>>>We tracked down the Macintosh connection problem to the PAP
>>>authentication.
>>What did you do to fix it?
>Switched the affected users to a scripted login.
Hope they're not using Multi-link PPP.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) pap and chap From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-17 14:51:39
I have customers calling me with a error 5 message on Windows NT. This
problem is only isolated to Windows NT users. I first thought it was a
problem with PAP and CHAP. I have set my PPP recieve authentication to PAP
and I have also tried ANY but no change.
Does anyone have any ideas on this error 5 on Windows NT.
Also, I am running the latest code on my Hiper Arc and DSP's
Thanks
Paul JR.
AlaWeb Network Admin.
You can always add RAM to it.. But then new cards also have more flash that is
soldered to the board. So older cards are not field upgradable. There really is
no application now that requires more RAM/FLASH. As always, RAM is cheaper now
than it was when the first cards were made. It makes sense to include it for
future application use.
-M
|-----Original Message-----
|From: owner-usr-tc@lists.xmission.com
|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
|Sent: Wednesday, February 17, 1999 2:44 PM
|To: usr-tc@lists.xmission.com
|Subject: RE: (usr-tc) 14 DSP, 2ARC
|
|
|
|
|
|Is there an upgrade for the HiPerArc from 64Mb to 128Mb ?
|
|Jeff Binkley
|ASA Network Computing
|
|
|
|u>FYI -
|
|u>The IPX limitation Krishnan stated applies only to 64Mb HARC boards.
|u>The 128Mb
|u>cards, should be OK
|u>for 14 spans. In fact, stress/stability testing is performed at the
|u>15 span level.
|
|u>-- Matt
|
|
|
|
|
|u>Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 02/16/99 07:31:00 PM
|
|u>Please respond to usr-tc@lists.xmission.com
|
|u>To: Randy Cosby <dcosby@infowest.com>
|u>cc: usr-tc@lists.xmission.com (Matt Harper/MW/US/3Com)
|u>Subject: RE: (usr-tc) 14 DSP, 2ARC chassis configuration
|
|
|
|
|u>As long as you do not use IPX - Hiper arc will support 14 DSPs
|u>4.1.59 code
|u>krish
|
|CMPQwk 1.42 9999
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| with "unsubscribe usr-tc" in the body of the message.
| For information on digests or retrieving files and old messages send
| "help" to the same address. Do not use quotes in your message.
|
Is there an upgrade for the HiPerArc from 64Mb to 128Mb ?
Jeff Binkley
ASA Network Computing
u>FYI -
u>The IPX limitation Krishnan stated applies only to 64Mb HARC boards.
u>The 128Mb
u>cards, should be OK
u>for 14 spans. In fact, stress/stability testing is performed at the
u>15 span level.
u>-- Matt
u>Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 02/16/99 07:31:00 PM
u>Please respond to usr-tc@lists.xmission.com
u>To: Randy Cosby <dcosby@infowest.com>
u>cc: usr-tc@lists.xmission.com (Matt Harper/MW/US/3Com)
u>Subject: RE: (usr-tc) 14 DSP, 2ARC chassis configuration
u>As long as you do not use IPX - Hiper arc will support 14 DSPs
u>4.1.59 code
u>krish
CMPQwk 1.42 9999
Subject:(usr-tc) Class C not big enough for 14 DSPs From: Mailing List Reader <mlist@strato.net> Date: 1999-02-17 16:32:40
Anyone know how to configure an ARC card with 14 DSP cards with two
different class C ip pools? The obvious problem is that a single class C
doesn't have enough addresses for the 336 ports.
Subject:(usr-tc) Quad modem card refuses to upgrade. From: Stephen Amadei <amadei@dandy.net> Date: 1999-02-17 16:42:41
Hello, I have a Quad Digital/Analog modem in a box we recently bought
used. The USR isn't in production yet, so I'm not sure if the card works,
but it does pass all the LED tests. All the cards in this USR box are at
level 5.10.9, except the one, which is 5.1.7. Being a perfectionist, I
have been fighting with this one card for some time trying to upgrade it
to 5.10.9, which fails. I also tried upgrading to 5.6.7, thinking the
other upgrade was to big of a jump... nothing.
The error I keep getting is:
Failed. TFTP Error: Access Violation.
The other cards flashed fine, and I even tried moving the card in the box,
but it always fails. I also checked the dip switches, they are fine
compared with the other cards.
----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ
Subject:Re: (usr-tc) Quad modem card refuses to upgrade. From: David Bolen <db3l@ans.net> Date: 1999-02-17 16:54:57
Stephen Amadei <amadei@dandy.net> writes:
> All the cards in this USR box are at
> level 5.10.9, except the one, which is 5.1.7. Being a perfectionist, I
> have been fighting with this one card for some time trying to upgrade it
> to 5.10.9, which fails. I also tried upgrading to 5.6.7, thinking the
> other upgrade was to big of a jump... nothing.
>
> The error I keep getting is:
> Failed. TFTP Error: Access Violation.
One typical cause for this is if you download the wrong code - it'll
fail during the SDL stage with this error (TFTP errors are very few
and don't map well to the actual error) when the NMC detects that the
code is for a different card.
For recent code cycles, the quad code has been kept such that 5.x.y
was for double-sided (older) cards and 5.x+1.y was for single-sided
(later design).
Both your 5.10.x code and 5.6.x code are for single sided. If you
have a double-sided card you'll need 5.9.x and 5.5.x respectively. Oh
yes, the filenames for double-sided will be qf* versus qr* for
single-sided.
You can check the card type from the NMC - if the NAC type is a modem
type with "G2" in it (as defined by the MIB) then it's single-sided,
otherwise double-sided.
They'll both work fine functionally - you just need to pick the proper
code.
-- 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 modem card refuses to upgrade. From: Stephen Amadei <amadei@dandy.net> Date: 1999-02-17 18:16:42
On Wed, 17 Feb 1999, David Bolen wrote:
> Stephen Amadei <amadei@dandy.net> writes:
>
> > All the cards in this USR box are at
> > level 5.10.9, except the one, which is 5.1.7. Being a perfectionist, I
> > have been fighting with this one card for some time trying to upgrade it
> > to 5.10.9, which fails. I also tried upgrading to 5.6.7, thinking the
> > other upgrade was to big of a jump... nothing.
>
> One typical cause for this is if you download the wrong code - it'll
> fail during the SDL stage with this error (TFTP errors are very few
> and don't map well to the actual error) when the NMC detects that the
> code is for a different card.
The SDL stage is the quick upload, right? Mine seems to fail during the
NAC upload... at 4%, actually.
> Both your 5.10.x code and 5.6.x code are for single sided. If you
> have a double-sided card you'll need 5.9.x and 5.5.x respectively. Oh
> yes, the filenames for double-sided will be qf* versus qr* for
> single-sided.
Which type of card is the 5.1.7 code for?
> You can check the card type from the NMC - if the NAC type is a modem
> type with "G2" in it (as defined by the MIB) then it's single-sided,
> otherwise double-sided.
I was unable to find the 'G2' on anything, but the cards only have
circuitry on one side... so I would think they are single sided. I've
never seen double sided.
----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ
Does anyone know whether or not 3Com intends to "tweak" the quad
code anymore? I would hope that with all of the changes to the DSPs that
they would make an attempt to correct some connection problems with the
quads... Currently we have 2 racks. One with HiperArc and 12 QAUD
cards and one HiperArc with DSPs. The HperArcs are running 4.1.72-7 and
4.1.59-1 respectively. The DSPs are running the 1.2.60 code currently.
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
==============================================================================
Is there a way to get stats on a specific DS0? I.E. We have 2 HyperDSP's
setup with Point-to-Point PRI's for a remote POP, so they're essentially
another modem pool and would like to monitor it as such.
Thanks, Billy
Subject:Re: (usr-tc) Quad modem card refuses to upgrade. From: David Bolen <db3l@ans.net> Date: 1999-02-17 22:23:14
Stephen Amadei <amadei@dandy.net> writes:
> The SDL stage is the quick upload, right? Mine seems to fail during the
> NAC upload... at 4%, actually.
Yes, the SDL stage is the first file (the SDL file) which is quite
fast. If you're not failing until later on, then it's probably not a
card mismatch.
> Which type of card is the 5.1.7 code for?
I'm not absolutely positive (we jumped right from 3.5.x to 5.5.x) but
I believe that 5.1.x was single sided and 5.0.x was double sided.
> I was unable to find the 'G2' on anything
The "G2" reference was for the NAC type name that is in the MIB (e.g.,
the stuff that TCM should show you if you query the type of card in
each slot).
> but the cards only have
> circuitry on one side... so I would think they are single sided. I've
> never seen double sided.
Yep, that'd be single sided (at most you'll see some small caps on the
reverse side).
Ok - another possibility would be a card with bad flash or some other
hardware affecting its ability to reprogram flash. When the TFTP
fails, query the command table for the card in question. In
particular you want the "result" and "code" objects from that table
(MIB objects uchasCmdResult and uchasCmdCode). You should probably
see the result object show failed or aborted, and the code object with
a reason. There are several codes ("programmingDataError" is probably
most common) that can reflect a hardware problem on the card that will
prevent the acceptance of new code.
Since the failure is pretty early on in the NAC transmission, and
presuming the card still functions after the failure, it would seem to
be failing during the initial flash erase at the front of accepting
new code. If that's the case, you'll probably need to replace the
card.
-- 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:(usr-tc) Hiper DSPs crashing on 1.2.59 From: Chris Peltier <cpeltier@iectech.com> Date: 1999-02-17 22:32:25
I have been having another problem that last few days
with many of my HIPER DSPs rebooting using the new
release (1.2.59,4.1.59). It happens at about the same
time every evening and it cycles through many of my
six cards in one rack. It is my guess that a user with
a rogue modem is causing the problem?
Has anyone seen this? I am currently down reving to 1.2.60
Is there a newer ER release for the DSPs?
-Chris
"Billy Huddleston" <billy@nxs.net> writes:
> Is there a way to get stats on a specific DS0? I.E. We have 2 HyperDSP's
> setup with Point-to-Point PRI's for a remote POP, so they're essentially
> another modem pool and would like to monitor it as such.
You may need to qualify what you mean by "stats" a bit further, but...
You can query DS0 status on a HiperDSP card (specific current status
and configuration) using the RDS0-MIB objects. You can find their
definitions in the rds0.mib file that comes with the NMC MIBs.
The two main tables in the RDS0-MIB are:
usrds0CfgTable Can provide information about the mapping from DS0 to
modem and/or a permanently configured service state.
usrds0StatTable Individual timeslot status. Gives operational
status, current connection and service state
information, any pending activity (e.g., soft out of
service) and some Q.931 call info if available.
My guess is the latter will probably give you whatever you want on the
individual DS0.
Alternatively, if by "stats" you mean things like error counters, then
those occur at the DS1 span level containing the DS0s and you'll find
that information documented and queryable by the objects in RFC1406
(supplied as rfc1406.mib with the NMC MIBs). This MIB contains both
some configuration state information as well as current and historical
interval stats. You may want to get an actual copy of the RFC as well
since it has some further textual descriptions of the various error
counters.
If you are interested in very rapid polling of individual DS0 status
(e.g., the key objects in the usrds0StatTable from RDS0-MIB) for a
large number of channels, I'd suggest checking out the bulk query
objects (specifically usrds0BlkAccessStatDs0Mdm from RDS1-MIB, in the
file rds1.mib) which combines all of the individual status information
into a single query. The recent thread on this list about some
scripts to poll that information to integrate it into MRTG may be
helpful.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| UUNET Technologies, Inc. \ Phone: (914) 701-5327 |
/ 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \
\-----------------------------------------------------------------------/
I have seen this where the card will reboot forever. My fix was to take out
the card (and NIC) and put them into another chassis (quad/netserver chassi
but I don't think it matters) and then I am able to reflash the card here
... I then move it back to it's original chass iand it works fine ... very
strange but it has worked on at least 5 seperate occasions for me ...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
-----Original Message-----
>
>I have been having another problem that last few days
>with many of my HIPER DSPs rebooting using the new
>release (1.2.59,4.1.59). It happens at about the same
>time every evening and it cycles through many of my
>six cards in one rack. It is my guess that a user with
>a rogue modem is causing the problem?
>Has anyone seen this? I am currently down reving to 1.2.60
>Is there a newer ER release for the DSPs?
>
>-Chris
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
Stats refereed to the number of DS0's used on the DS1. Instead of getting
the number used for the whole TC, I just want stats for specific
HyperDSP's/Dual PRI's. Not everyone has all there modem pools in a single
hunt group and taking bulk readings for the whole TC wouldn't provide
accurate information.
-----Original Message-----
>"Billy Huddleston" <billy@nxs.net> writes:
>
>> Is there a way to get stats on a specific DS0? I.E. We have 2 HyperDSP's
>> setup with Point-to-Point PRI's for a remote POP, so they're essentially
>> another modem pool and would like to monitor it as such.
>
>You may need to qualify what you mean by "stats" a bit further, but...
>
>You can query DS0 status on a HiperDSP card (specific current status
>and configuration) using the RDS0-MIB objects. You can find their
>definitions in the rds0.mib file that comes with the NMC MIBs.
>
>The two main tables in the RDS0-MIB are:
>
>usrds0CfgTable Can provide information about the mapping from DS0 to
> modem and/or a permanently configured service state.
>
>usrds0StatTable Individual timeslot status. Gives operational
> status, current connection and service state
> information, any pending activity (e.g., soft out of
> service) and some Q.931 call info if available.
>
>My guess is the latter will probably give you whatever you want on the
>individual DS0.
>
>Alternatively, if by "stats" you mean things like error counters, then
>those occur at the DS1 span level containing the DS0s and you'll find
>that information documented and queryable by the objects in RFC1406
>(supplied as rfc1406.mib with the NMC MIBs). This MIB contains both
>some configuration state information as well as current and historical
>interval stats. You may want to get an actual copy of the RFC as well
>since it has some further textual descriptions of the various error
>counters.
>
>If you are interested in very rapid polling of individual DS0 status
>(e.g., the key objects in the usrds0StatTable from RDS0-MIB) for a
>large number of channels, I'd suggest checking out the bulk query
>objects (specifically usrds0BlkAccessStatDs0Mdm from RDS1-MIB, in the
>file rds1.mib) which combines all of the individual status information
>into a single query. The recent thread on this list about some
>scripts to poll that information to integrate it into MRTG may be
>helpful.
>
>-- 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.
"Billy Huddleston" <billy@nxs.net> writes:
> Stats refereed to the number of DS0's used on the DS1. Instead of getting
> the number used for the whole TC, I just want stats for specific
> HyperDSP's/Dual PRI's. Not everyone has all there modem pools in a single
> hunt group and taking bulk readings for the whole TC wouldn't provide
> accurate information.
usrds0StatTable objects should do just fine for what you want - just
poll the appropriate DS0s (you probably want the usrds0StatDs0 object
to see any DS0s in a non-idle state, taking into account those that
will reflect a D channel). Using the usrds0StatDs0 object rather than
the bulk objects is easier with standard SNMP tools, but can be
significantly slower for several spans (e.g., 5+ seconds per span if
queried in groups of 8 DS0s or so, versus virtually instantaneous).
The "bulk" information in the recent thread and that I was referring
to in my reply is a "per-DS1" object (the usrds0BlkAccessStatDs0Mdm
objects is indexed by DS1 entity within the MIBs), and summarizes DS0
status on a per-DS1 level, so that sounds pretty much along the lines
of what you want. Of course, the scripts mentioned on the list might
not be exactly what you want, but they should provide a starting point
for parsing the relevant opaque data in the object. There's also an
earlier note of mine that should be in the archive that talks about
the bulk objects, including for the non-HiperDSP cards.
Then again, even if it wasn't per-DS1, if you can take the time to
break it apart, the speed difference for a dense chassis can be well
worth it (and once broken into DS0 level information you can summarize
at any granularity you want, whether per-DS1, sub-DS1, or any other).
For example, using a relatively efficient tool of mine, the non-bulk
query of all DS0 information in a hub with 14 HiperDSP cards takes
about 38s, but using the bulk queries its sub-second. So in this kind
of case, even post-processing the query to get the specific grouping
that you may prefer is far more efficient than using finer granularity
queries.
But that's probably moot - if you're mostly concerned with per-DS1
span information, the bulk object is a direct fit. But if speed isn't
critical, then just walking the stat table should be fine.
-- 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:(usr-tc) 1.2.59 opinions From: Brian <signal@shreve.net> Date: 1999-02-18 08:01:54
So what is the overall opinion of 1.2.59? Is it stable? Does it seem to
be better than 1.2.60? Any *major* issues fixed from 1.2.60 to 1.2.59?
Any issues introduced?
We are still at 4.1.59 / 1.2.60
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:(usr-tc) 1.2.59 opinions From: Brian <signal@shreve.net> Date: 1999-02-18 08:01:54
So what is the overall opinion of 1.2.59? Is it stable? Does it seem to
be better than 1.2.60? Any *major* issues fixed from 1.2.60 to 1.2.59?
Any issues introduced?
We are still at 4.1.59 / 1.2.60
Brian Feeny (BF304) signal@shreve.net
318-222-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
>> http://www.cableone.net/ebilleter/dualpri.pl
I am correct in assuming that the above only reports digital line usage?
Running it here reports less than the number of users online by what
appears to be the number of users on the old analog lines.
Drew
Subject:(usr-tc) LanLinker to Hiper problem, any ideas? From: Kent Tambling <kent@acceleration.net> Date: 1999-02-18 11:32:24
Anyone have any ideas on what I need to
change from defaults on HiperDSP/ARC
to get LanLinker BRI to connect? Already
enabled v110.
Thanks in advance..
Kent Tambling
kent@acceleration.net
System Administrator
www.acceleration.net
Brian said once upon a time:
>
>
>So what is the overall opinion of 1.2.59? Is it stable? Does it seem to
>be better than 1.2.60? Any *major* issues fixed from 1.2.60 to 1.2.59?
>Any issues introduced?
>
>We are still at 4.1.59 / 1.2.60
BTW, the modem code for 1.2.59 still reports itself as 1.2.60 via SNMP.
Anyway, I give it the thumbs up. The v.90 disconnects are way down, and
the PAP login speed is way up. The only issue is that the PAP login is too
fast for some Macs (we really haven't established what the common factor
is) and Webramps. Switching these customers to a scripted login fixed that
situation.
Subject:Re: (usr-tc) Class C not big enough for 14 DSPs From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-18 12:57:13
Mailing List Reader said once upon a time:
>
>Anyone know how to configure an ARC card with 14 DSP cards with two
>different class C ip pools? The obvious problem is that a single class C
>doesn't have enough addresses for the 336 ports.
Which is why I only use 11 DSP cards per chassis, 11 x 23 = 253 = 1 less of
a /24.
If you really want to do 14, the most efficient way to do it would be with
three pools:
/24 = 254
/28 = 62
/27 = 30
254 + 62 + 30 = 337 usable addresses
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-18 13:03:57
Jeff Mcadams said once upon a time:
>>That way, we get the best of all worlds,
>>and since PAP authenticates with just the user name, they can either use
>>PAP, or the Netserver/ARC prompt to connect.
>
>Ew...hope you're not using Multi-Link and allowing logins with the
>NETServer/ARC login prompt without at least requiring PAP authentication
>as well as that's rather an insecure way of handling MP.
No, all connections require authentication via the RADIUS server.
>>Then I hacked rlogind to
>>strip off the @shell portion and authenticate based upon username. Put the
>>ARC/Netserver in hosts.equiv and they don't need to authenticate twice.
>
>Trust relationships...no thanks. :) I'll just have rlogind prompt for
>a password all the time and trust no-one. :)
Maybe I misunderstood, but it sounds like your rlogind accepts logins
without a password. Isn't that a trust relationship?
Subject:RE: (usr-tc) MRTG for Totalcontrol chassis. From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-18 13:46:56
Yes.. it is checking the status of the DS0's on the T1 or PRI span.
I do not have a script for processing pots calls.
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 Drew Whittle
Sent: Wednesday, February 17, 1999 3:11 PM
>> http://www.cableone.net/ebilleter/dualpri.pl
I am correct in assuming that the above only reports digital line usage?
Running it here reports less than the number of users online by what
appears to be the number of users on the old analog lines.
Drew
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
pferraro@wna-linknet.com said once upon a time:
> What kind of script did you provide the MAC users? We have some and
>haven't had any reports of inability to login, but it would be nice to
>have something to fall back on!
>
> We are running 4.1.72-7 on hub with quads and 4.1.59-1 on hub with DSPs
>flashed w/1.2.60
The Mac PPP needs something like this:
Waitfor "ogin:"
Send (account)
Waitfor "word:"
Send (password)
(start PPP)
Where did you find the meaning of the bytes retruned from that
OID?
- Marcelo
On Mon, 15 Feb 1999, Eric Billeter wrote:
|I modified my hiperdsp.pl script to monitor the utilization of the modems.
|It now grabs the DS0 status in bulk and performs much much faster. You
|can get it at http://www.cableone.net/ebilleter/hiperdsp.pl
|
|I also have scripts that will work with the Dual PRI and Dual T1 cards.
|
|You will need MRTG 2.5.3 running ( I will not help you troubleshoot that
|part )
|IMPORTANT: The IP address you are polling is the NMC, not the HiperArc.
|
|I also have scripts that will work with the Dual PRI and Dual T1 cards.
|
|Thanks
|Eric T. Billeter Cable One
|Internet Engineer 1314 North 3rd Street
|ebilleter@cableone.net Phoenix, AZ 85004
|
|
|
|
|-
| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
| with "unsubscribe usr-tc" in the body of the 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) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-18 15:13:06
Thus spake Pete Ashdown
>Jeff Mcadams said once upon a time:
>>>That way, we get the best of all worlds,
>>>and since PAP authenticates with just the user name, they can either use
>>>PAP, or the Netserver/ARC prompt to connect.
>>Ew...hope you're not using Multi-Link and allowing logins with the
>>NETServer/ARC login prompt without at least requiring PAP authentication
>>as well as that's rather an insecure way of handling MP.
>No, all connections require authentication via the RADIUS server.
Yes, but for multilink connections, without using a PPP based
authentication scheme (PAP, CHAP, EAP, whatever) the bundling of
channels into bundles is insecure. The userid used in a PPP
authentication scheme is used as part of the decision making process on
whether to bundle channels together.
So, for example, without using PAP, CHAP or whatever, the only
information the access server has to go on is the EDO class and value.
Its conceivable (and I believe WebRamps are one of the boxes that do
this if I remember correctly from recent BugTraq posts) that these boxes
could all use the same EDO class and value. In this case, the access
server will try to bundle channels together that shouldn't be resulting
in what amounts to unuseable connections for both customers.
>>>Then I hacked rlogind to
>>>strip off the @shell portion and authenticate based upon username. Put the
>>>ARC/Netserver in hosts.equiv and they don't need to authenticate twice.
>>Trust relationships...no thanks. :) I'll just have rlogind prompt for
>>a password all the time and trust no-one. :)
>Maybe I misunderstood, but it sounds like your rlogind accepts logins
>without a password. Isn't that a trust relationship?
Must have misunderstood. We hacked our rlogind to basically act like
telnetd...issues the /etc/issue, then always prompts for userid *and*
password. We just use the rlogind base code because we can assure that
the transport is 8-bit clean, which is important if you're trying to run
ppp, and uucp traffic over top of it which we do some (again, those
legacy setups).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Quad modem card refuses to upgrade. From: Stephen Amadei <amadei@dandy.net> Date: 1999-02-18 15:54:26
On Wed, 17 Feb 1999, David Bolen wrote:
> Ok - another possibility would be a card with bad flash or some other
> hardware affecting its ability to reprogram flash. When the TFTP
> fails, query the command table for the card in question. In
> particular you want the "result" and "code" objects from that table
> (MIB objects uchasCmdResult and uchasCmdCode). You should probably
> see the result object show failed or aborted, and the code object with
> a reason. There are several codes ("programmingDataError" is probably
> most common) that can reflect a hardware problem on the card that will
> prevent the acceptance of new code.
The actions/commands page shows me a ProgDataErr.
Do you have OIDs for those MIBs? It's easier for me to poke the TC
using OIDs and snmpwalk.
> Since the failure is pretty early on in the NAC transmission, and
> presuming the card still functions after the failure, it would seem to
> be failing during the initial flash erase at the front of accepting
> new code. If that's the case, you'll probably need to replace the
> card.
Well, it gets through the EPROM erase (180 second timeout) in 3 seconds,
then claims it is uploading the NAC file. It dies at 4% everytime now.
The card does, however, work. It answers and though some quick testing
it maintained a connection on a production TC.
Is there anything that can be done with this card?... if not I need to
return it ASAP.
----Steve
Stephen Amadei
Director of MIS
Dandy Connections, Inc.
Atlantic City, NJ
Subject:Re: (usr-tc) Quad modem card refuses to upgrade. From: David Bolen <db3l@ans.net> Date: 1999-02-18 15:59:35
Stephen Amadei <amadei@dandy.net> writes:
> The actions/commands page shows me a ProgDataErr.
>
> Do you have OIDs for those MIBs? It's easier for me to poke the TC
> using OIDs and snmpwalk.
Sure - although any SNMP tool should be able to lookup names from the
supplied MIBs that come with the NMC, and I find names to be more
readable in scripts and what not...
For the NMC 5.9/10.x MIBs:
uchasCmdResult (1.3.6.1.4.1.429.1.1.7.1.1.7)
Unique: Result
Parent: uchasCmdEntry
Type : Integer
Access: Read-Only
Status: Mandatory
Enumerated values (7 total):
none(1), success(2), inProgress(3), notSupported(4), unAbleToRun(5),
aborted(6), failed(7)
Description:
This object contains the result of the most recently
requested test, or the value none(1) if not commands have
been requested since the last reset. Note that this
facility provides no provision for saving the results of
one command when starting another, as could be required if
used by multiple managers concurrently.
uchasCmdCode (1.3.6.1.4.1.429.1.1.7.1.1.8)
Unique: Code
Parent: uchasCmdEntry
Type : Integer
Access: Read-Only
Status: Mandatory
Enumerated values (39 total):
noError(1), unable(2), unrecognizedCommand(6), slotEmpty(8),
noResponse(12), connected(14), unsupportedCommand(20),
nonManagedDevice(21), deviceDisabled(22), userInterfaceActive(58),
badFlashRomID(61), badFlashVoltage(62), flashEraseError(63),
eraseSequenceError(64), eraseExecutionError(65),
receiveBufferOverflow(66), badAddressInData(67), badProgramVoltage(68),
programmingDataError(69), programCodeError(70), invalidCodeError(71),
romCrcBad(72), pendingSoftwareDownload(73), ramCrcBad(74),
invalidRomId(75), sdlTrigger(76), downloadingSdlFile(77),
crcTestingSdlFile(78), queryWorkSpaceSize(79), executeLoadedProgram(80),
erasingFlash(81), downloadingNacFile(82), resetingNac(83),
cardIdMismatch(84), cardIdUnknown(85), tftpTimeout(86),
flashEraseTimeout(87), invalidFileHeader(88), pendingSdl2(113)
Description:
The value of this object upon command completion indicates
a further description of what went wrong if the command was
unsuccessful. This object is also used as an indication of
the in progress status of the software download command.
You'll need to use an instance on each of these OIDs that corresponds
to the slot you are interested in (e.g., ".1000" for slot 1, ".14000"
for slot 14 etc..)
> Well, it gets through the EPROM erase (180 second timeout) in 3 seconds,
> then claims it is uploading the NAC file. It dies at 4% everytime now.
Part of this is due to the fact that the receipt of the code by the
NMC and the actual transmission/programming of the code by the modem
are somewhat distinct operations. So you can get a bit of overlap in
sending later data before receiving an error that is actually from a
bit earlier in the process.
> The card does, however, work. It answers and though some quick testing
> it maintained a connection on a production TC.
This would seem to imply to me that the basic flash erasure operation
isn't actually succeeding or else you'd lose the previous code base on
the card.
> Is there anything that can be done with this card?... if not I need to
> return it ASAP.
We always consider programmingDataError failures a hard failure and
replace the card.
-- 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) What does prompt_delay buy me? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-18 16:17:42
Jeff Mcadams said once upon a time:
>Hope they're not using Multi-link PPP.
Mac's don't support multilink.
I might also add that I've got a user on the phone right now who is using
scripted login with the Mac, and it STILL doesn't recognize the PPP
protocol. It works 1 out of 10 times. Thanks 3com!
Subject:(usr-tc) Mac PPP debug From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-18 16:48:35
This is the kind of crap I'm seeing with a particular Mac FreePPP
customer. See below for possible solution:
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_REQ ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_ACK ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_REQ ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_ACK ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_NAK AUTH_TYPE c0 23
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_NAK AUTH_TYPE c0 23
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_REQ ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_ACK ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_REQ MRU 05 dc
ASYNC_MAP ff ff ff ff
MAGIC_NUM 4b 8d 24 dc
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_NAK AUTH_TYPE c0 23
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_REQ MRU 05 dc
ASYNC_MAP ff ff ff ff
MAGIC_NUM 4b 8d 24 dc
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_REQ MRU 05 dc
ASYNC_MAP ff ff ff ff
MAGIC_NUM 4b 8d 24 dc
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_REQ ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_ACK ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Incoming PPP Data on interface: slot:2/mod:4
LCP CFG_REQ ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
Outgoing PPP Data on interface: slot:2/mod:4
LCP CFG_ACK ASYNC_MAP ff ff ff ff
MAGIC_NUM 00 00 00 2a
(until they die)
On a hunch, I messed around with FreePPP until I found a solution. If you
go into the "options" tab and hold down the "option key" when you hit the
tab, you'll be given some extra options. Choose "Advanced LCP Options"
andd then make sure the "want" and "will" for both "local" and "remote" for
"async char control map" and "magic number" are UNCHECKED.
My customer still had to login with a script, we didn't try a PAP login,
but he connected every time after that.
Subject:Re: (usr-tc) Class C not big enough for 14 DSPs From: Jeff Lynch <jeff@mercury.jorsm.com> Date: 1999-02-18 17:22:20
On Thu, 18 Feb 1999, Pete Ashdown wrote:
> If you really want to do 14, the most efficient way to do it would be with
> three pools:
>
> /24 = 254
> /28 = 62
^^^
/26
But, we knew you meant that.
> /27 = 30
>
> 254 + 62 + 30 = 337 usable addresses
============================================================================
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) What does prompt_delay buy me? From: Andy Berkvam <aberkvam@coredcs.com> Date: 1999-02-18 18:19:54
On Thu, 18 Feb 1999, Pete Ashdown wrote:
> Mac's don't support multilink.
>
Hmmm.... I suppose you could say that the PPP software that comes with
the Mac OS doesn't support multilink but you can do multilink on a Mac.
You just have to get different PPP software. Check out LinkUPPP! Turbo
<http://www.fcr.com/LinkUPPP_Turbo/LinkUPPP.html>. I haven't had a chance
to actually test it on our system yet.
Andy
--
===========================================================================
Andy Berkvam | "People say that I'm out of touch with reality.
| That I'm insane. Sometimes I forget things.
Email: | Who I am. Where I am. Unimportant things.
aberkvam@coredcs.com | But I'm not insane. I am a Tick." - The Tick
(MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/>
===========================================================================
Subject:Re: (usr-tc) Class C not big enough for 14 DSPs From: Mailing List Reader <mlist@strato.net> Date: 1999-02-18 18:35:03
At 12:57 PM 2/18/99 -0700, you wrote:
>Mailing List Reader said once upon a time:
>>
>>Anyone know how to configure an ARC card with 14 DSP cards with two
>>different class C ip pools? The obvious problem is that a single class C
>>doesn't have enough addresses for the 336 ports.
>
>Which is why I only use 11 DSP cards per chassis, 11 x 23 = 253 = 1 less of
>a /24.
>
>If you really want to do 14, the most efficient way to do it would be with
>three pools:
>
> /24 = 254
> /28 = 62
> /27 = 30
>
>254 + 62 + 30 = 337 usable addresses
>
OK multiple 3 ip pools in the box from different Class C's. What
additional configuration is required?
Subject:(usr-tc) 3COM Chassis's Worth? From: Alan D. Criado <acriado@elink.net> Date: 1999-02-18 18:55:52
Just two questions perhaps someone can help me with:
1. Next month I'll be selling my 3Com Total Control Chassis (1 Pwr, 1 Hiper
Arc, 2 Hiper DSPs), what is a fair price to ask for it?
2. Where on the net is a good location to advertise that it's for sale?
Thanks.
Alan
Subject:Re: (usr-tc) Mac PPP debug From: Charles Sprickman <spork@inch.com> Date: 1999-02-18 19:11:50
On Thu, 18 Feb 1999, Pete Ashdown wrote:
> This is the kind of crap I'm seeing with a particular Mac FreePPP
> customer. See below for possible solution:
Which version of FreePPP is this? Do you see similar problems with the
older "ConfigPPP"? Are O/T people OK?
Thanks,
Charles
> On a hunch, I messed around with FreePPP until I found a solution. If you
> go into the "options" tab and hold down the "option key" when you hit the
> tab, you'll be given some extra options. Choose "Advanced LCP Options"
> andd then make sure the "want" and "will" for both "local" and "remote" for
> "async char control map" and "magic number" are UNCHECKED.
>
> My customer still had to login with a script, we didn't try a PAP login,
> but he connected every time after that.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
In looking into a problem today, I suddenly realized I had no way to see
this kind of debugging detail from a hiperDSP:
uccu_get_new_uccb: attach uccb to end of list. tcid: 0x6d89 ucid: 0x00004b42
uccu_get_new_uccb: ALLOC tcid: 0x6d89 ucid: 0x00004b42, allocated = 10, dsl_id=1
sfn:ucc_null,evt:20-SETUP_IND,tcid:0x6d89,ucid:0x00004b42
ucc_setup_in_call: tcid: 0x6d89, CRV: 2950 (0xb86)
ucc_setup_in_call: ANI (calling_phnum) >9198779509<, len = 10, err = 0x21
uccidm_search_DNIS_reserved_pool: len_called_num = 7: stripped inbound phone >9540042<, len = 7
uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1
uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1
uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1
uccidm_search_DNIS_reserved_pool: local stripped DNIS >?<, len = 1
ds0_res_call_type: dsl: 1, intid: 0, ds0: 14, bct: 73, err: 0 verdict: 1
uccidm_reserve_ds0: SUCCESS: call_type: ANALOG, span=1, ds0=15, in_flag=1
uccidm_get_fixed_mdm: span=1, ds0=15, mdm_id=42, err=-9
ERR:ucc_gen_error,ucc_setup_in_call,uccidm_get_idle_mdm,fail,drop_call:,err:-9
uccu_releasing uccb: DE-ALLOC: tcid = 0x6d89, ucid = 0x00004b42
uccidm_release_ds0: span = 1, ds0 = 15
uccu_release_bchs: DE-ALLOC ucid: 0x00004b42
Mdm Devive Table:
ID S# C# Stat Pbstat Pb_hdl mdmCp CallRej KaToDrop Instl Remov CallsAccep
40 11 1 2 2 -1 2 0 0 1 1 0
41 11 2 2 2 -1 2 0 0 1 1 0
42 11 3 2 2 -1 2 0 0 1 1 0
43 11 4 1 1 39 2 0 0 1 0 0
Is there such a way to see these things from the inner recesses of the DSP?
(Note: this stuff is from the PRI card console debug mode.)
--Ricky
Subject:(usr-tc) USR Win int Modem wont connect From: Magnolia Internet Billing <gowens@magnolia-net.com> Date: 1999-02-18 20:31:53
We have a customer with a USR 56k win int modem that has to dial in
sometimes 20+ times to ever connect.This only started once we went to V.90.
Once he connects it is a good 50+ connection and doesn't drop. Anyone know
if any issues or init strings to use with this modem to help him connect. We
have tried the comma trick with no success... We are running 1.2.5 on our
end.
Greg Owens
Magnolia Internet Services
On Thu, 18 Feb 1999, Pete Ashdown wrote:
> This is the kind of crap I'm seeing with a particular Mac FreePPP
> customer. See below for possible solution:
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_ACK ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_ACK ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
It looks like the client or the DSP is not applying the async map correctly.
Can I get a hex dump of this?
krish
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_NAK AUTH_TYPE c0 23
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_NAK AUTH_TYPE c0 23
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_ACK ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ MRU 05 dc
> ASYNC_MAP ff ff ff ff
> MAGIC_NUM 4b 8d 24 dc
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_NAK AUTH_TYPE c0 23
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ MRU 05 dc
> ASYNC_MAP ff ff ff ff
> MAGIC_NUM 4b 8d 24 dc
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ MRU 05 dc
> ASYNC_MAP ff ff ff ff
> MAGIC_NUM 4b 8d 24 dc
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_ACK ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Incoming PPP Data on interface: slot:2/mod:4
> LCP CFG_REQ ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> Outgoing PPP Data on interface: slot:2/mod:4
> LCP CFG_ACK ASYNC_MAP ff ff ff ff
> MAGIC_NUM 00 00 00 2a
>
> (until they die)
>
>
> On a hunch, I messed around with FreePPP until I found a solution. If you
> go into the "options" tab and hold down the "option key" when you hit the
> tab, you'll be given some extra options. Choose "Advanced LCP Options"
> andd then make sure the "want" and "will" for both "local" and "remote" for
> "async char control map" and "magic number" are UNCHECKED.
>
> My customer still had to login with a script, we didn't try a PAP login,
> but he connected every time after that.
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-18 21:42:53
Thus spake Pete Ashdown
>Jeff Mcadams said once upon a time:
>>Hope they're not using Multi-link PPP.
>Mac's don't support multilink.
Its still possible for an ISDN TA connected to a MAC to do multi-link,
so its not that easy to say it won't affect them.
Anyway...something to keep an eye out when moving to scripted logins.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
On Thu, 18 Feb 1999, Alan D. Criado wrote:
>
> Just two questions perhaps someone can help me with:
>
> 1. Next month I'll be selling my 3Com Total Control Chassis (1 Pwr, 1 Hiper
> Arc, 2 Hiper DSPs), what is a fair price to ask for it?
I would say maybe $6000-$7000 used.
>
> 2. Where on the net is a good location to advertise that it's for sale?
>
here and isp-services@ispc.org
> Thanks.
>
> Alan
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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-26318 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-19 09:26:46
Jeff Mcadams said once upon a time:
>Its still possible for an ISDN TA connected to a MAC to do multi-link,
>so its not that easy to say it won't affect them.
They aren't affected by the FreePPP PAP problem then, and have no need to
go to a scripted login.
isp-equipment.com
-----Original Message-----
[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Alan D. Criado
Sent: Thursday, February 18, 1999 5:56 PM
Just two questions perhaps someone can help me with:
1. Next month I'll be selling my 3Com Total Control Chassis (1 Pwr, 1 Hiper
Arc, 2 Hiper DSPs), what is a fair price to ask for it?
2. Where on the net is a good location to advertise that it's for sale?
Thanks.
Alan
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Once upon a time pferraro@wna-linknet.com shaped the electrons to say...
> Does anyone know whether or not 3Com intends to "tweak" the quad
>code anymore? I would hope that with all of the changes to the DSPs that
>they would make an attempt to correct some connection problems with the
My understanding is that 3Com can no longer make OS changes as the license
to ComOS has expired. They could update the modem code I believe, but I
don't think they're able to do anything to the OS -other than replace it,
and they've stated that they won't do that.
I'm sure someone from 3Com will correct me if I'm wrong.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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) What is it? From: Charles Sprickman <spork@inch.com> Date: 1999-02-19 11:52:59
I'm starting to grow a little perl script that pokes and prods our TCs for
some basic stats to verify proper operation, and I came across this one in
the "rds1" mib:
enterprises.usr.nas.rds1.usrds1StatTable.usrds1StatEntry.usrdiscNoTelcoRespDialI
n.14025 = 68
Anyone know what it means?
Also, anyone know how to get some info out of the Bulk objects?
And lastly, I'm trying to build something of a "map" of the usr-specific
mibs, and it's really time consuming. I'll be doing the same for lots of
other snmp-aware stuff as well. How do you know where to look for what
you want? Is there any (free) software that can look at a directory full
of mib definitions and generate a "tree" of what is where?
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Subject:(usr-tc) Has AnyOne used a LanLinker BRI with a Hiper? From: Kent Tambling <kent@acceleration.net> Date: 1999-02-19 12:11:59
Anyone have any ideas on what I need to
change from defaults on HiperDSP/ARC
to get LanLinker BRI to connect? Already
enabled v110.
Thanks in advance..
Kent Tambling
kent@acceleration.net
System Administrator
www.acceleration.net
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Jamie Orzechowski <mhz@recorder.ca> Date: 1999-02-19 14:06:23
just wondering HOW I set prompt_delay in the ARC??? I cannot find it
anywhere in the command set ...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
-----Original Message-----
>Jeff Mcadams said once upon a time:
>
>>Its still possible for an ISDN TA connected to a MAC to do multi-link,
>>so its not that easy to say it won't affect them.
>
>They aren't affected by the FreePPP PAP problem then, and have no need to
>go to a scripted login.
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
MegaZone <megazone@megazone.org> writes:
> Once upon a time pferraro@wna-linknet.com shaped the electrons to say...
> > Does anyone know whether or not 3Com intends to "tweak" the quad
> >code anymore? I would hope that with all of the changes to the DSPs that
> >they would make an attempt to correct some connection problems with the
(...)
> My understanding is that 3Com can no longer make OS changes as the license
> to ComOS has expired. They could update the modem code I believe, but I
> don't think they're able to do anything to the OS -other than replace it,
> and they've stated that they won't do that.
Right - but while the ComOS point is true, as you say that only
affects the NETServers and not the quads at all - the quads are
entirely 3Com/USR code. True, they couldn't change the packet bus
interface in the quads in a way that would require changes on the
NETServer but that's not really an issue when dealing with the
modem/network side of the coin.
-- 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:(usr-tc) 3COM RADIUS and Billing From: Ralph Helfenberger <rhelfenberger@comlight.ch> Date: 1999-02-19 17:47:15
Hi
Is anybody using the 3Com Security and Accounting server together with a
billing solution? We would like to introduce billing based on the data
gathered with this RADIUS accounting. Any hint would be appreciated.
Best regards
Ralph
Subject:RE: (usr-tc) Has AnyOne used a LanLinker BRI with a Hiper? From: Blake Fithen <fithen@networksplus.com> Date: 1999-02-19 18:43:13
3com dropped it (LanLinker BRI) like a hot potato. I did
the same after fiddling with it for a few hours.
blake
> -----Original Message-----
> From: Kent Tambling [mailto:Kent@acceleration.net]
> Sent: Friday, February 19, 1999 11:12 AM
> To: usr-tc@lists.xmission.com
> Subject: (usr-tc) Has AnyOne used a LanLinker BRI with a Hiper?
>
>
> Anyone have any ideas on what I need to
> change from defaults on HiperDSP/ARC
> to get LanLinker BRI to connect? Already
> enabled v110.
>
> Thanks in advance..
>
> Kent Tambling
> kent@acceleration.net
> System Administrator
> www.acceleration.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) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-19 21:51:05
Thus spake Pete Ashdown
>Jeff Mcadams said once upon a time:
>>Its still possible for an ISDN TA connected to a MAC to do multi-link,
>>so its not that easy to say it won't affect them.
>They aren't affected by the FreePPP PAP problem then, and have no need to
>go to a scripted login.
You sure about that? (not trying to be a pain here...just making sure
you're aware of all the issues in this) With a TA that does PPP to MP
conversion off of a serial port, the PAP would be done in software on
the computer. I'm not sure (haven't followed it closely enough...my
apologies for that) what exactly the problem is with PAP and FreePPP,
but with a TA like this, FreePPP would be doing the PAP, not the as
such.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-19 21:53:27
Thus spake Jamie Orzechowski
>just wondering HOW I set prompt_delay in the ARC??? I cannot find it
>anywhere in the command set ...
You need 4.1.59 -2.
The command is "set modem_group all prompt_delay n"
Also, you could replace modem_group all with switched interface
slot:x/mod:y as well.
"n" is the number of seconds to delay before automatically
authenticating with the default userid/password.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake MegaZone
>Once upon a time pferraro@wna-linknet.com shaped the electrons to say...
>> Does anyone know whether or not 3Com intends to "tweak" the quad
>>code anymore? I would hope that with all of the changes to the DSPs that
>>they would make an attempt to correct some connection problems with the
>My understanding is that 3Com can no longer make OS changes as the license
>to ComOS has expired. They could update the modem code I believe, but I
>don't think they're able to do anything to the OS -other than replace it,
>and they've stated that they won't do that.
>I'm sure someone from 3Com will correct me if I'm wrong.
I think you're right...but the question was really about the modem code
I think, not the NETServer code. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-19 22:20:58
Jeff Mcadams was heard to say:
>Thus spake Pete Ashdown
>>They aren't affected by the FreePPP PAP problem then, and have no need to
>>go to a scripted login.
>
>You sure about that? (not trying to be a pain here...just making sure
>you're aware of all the issues in this) With a TA that does PPP to MP
>conversion off of a serial port, the PAP would be done in software on
>the computer. I'm not sure (haven't followed it closely enough...my
>apologies for that) what exactly the problem is with PAP and FreePPP,
>but with a TA like this, FreePPP would be doing the PAP, not the as
>such.
Multilink PPP via a TA (modem for lack of a better term) is usually handled
by the the TA itself. The TA understand PPP enough to grab the PAP info
so it can bring up the second channel all on it's own. The machine
connected to the TA doesn't have to know there are two lines being bundled
together. This is how the I-Modem does it. (That's why you have to use
PAP on those things.)
--Ricky
Subject:RE: (usr-tc) Has AnyOne used a LanLinker BRI with a Hiper? From: Charles Sprickman <spork@inch.com> Date: 1999-02-19 23:21:40
On Fri, 19 Feb 1999, Blake Fithen wrote:
> 3com dropped it (LanLinker BRI) like a hot potato. I did
> the same after fiddling with it for a few hours.
Hey now, don't be so rough on the poor thing. One of our admins has one
(gratis from USR) at home, and it really works well. He's had no problems
dialing into Ascend (our old ISDN equipment) or Cisco (new stuff). We'd
love to try it on our USR gear, but no one can tell us how to do DOVBS on
the DSPs or quads (hint hint to the 3com-ers on the list).
The funny thing is he's not our modem guy, but he logged into a HiPer arc
to poke around and found himself already a little familiar with the
interface, as the LanLinker runs the Pilgrim code...
Charles
ps - what does it take to find out for sure if DOVBS works on HiPer
gear??? I'm pulling hair here as it's holding up a new service
offering...
>
> blake
>
> > -----Original Message-----
> > From: Kent Tambling [mailto:Kent@acceleration.net]
> > Sent: Friday, February 19, 1999 11:12 AM
> > To: usr-tc@lists.xmission.com
> > Subject: (usr-tc) Has AnyOne used a LanLinker BRI with a Hiper?
> >
> >
> > Anyone have any ideas on what I need to
> > change from defaults on HiperDSP/ARC
> > to get LanLinker BRI to connect? Already
> > enabled v110.
> >
> > Thanks in advance..
> >
> > Kent Tambling
> > kent@acceleration.net
> > System Administrator
> > www.acceleration.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) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-20 08:51:57
Thus spake Ricky Beam
>Jeff Mcadams was heard to say:
>>Thus spake Pete Ashdown
>>>They aren't affected by the FreePPP PAP problem then, and have no need to
>>>go to a scripted login.
>>You sure about that? (not trying to be a pain here...just making sure
>>you're aware of all the issues in this) With a TA that does PPP to MP
>>conversion off of a serial port, the PAP would be done in software on
>>the computer. I'm not sure (haven't followed it closely enough...my
>>apologies for that) what exactly the problem is with PAP and FreePPP,
>>but with a TA like this, FreePPP would be doing the PAP, not the as
>>such.
>Multilink PPP via a TA (modem for lack of a better term) is usually handled
>by the the TA itself. The TA understand PPP enough to grab the PAP info
>so it can bring up the second channel all on it's own. The machine
>connected to the TA doesn't have to know there are two lines being bundled
>together. This is how the I-Modem does it. (That's why you have to use
>PAP on those things.)
Yeah...my point exactly. PAP on the initial line is just passed through
basically untouched, so if there's a PAP issue between FreePPP and the
HiPer Arc, it might still affect it (I don't know as I haven't had any
situations where I've had to play with it). Essentially the TA/modem
kind of "caches" the PAP exchange to reuse with later
channels...basically exhibiting PAP's vulnerability to replay attacks
(and sniffing...PAP sends userid and password in the clear).
Its been said that its a timing thing with this PAP issue I think
(again, don't remember the whole thread and for that I apologize), and
the TA's might alter the timing so it does work. In which
case...great...glad to know it works. :) Anyway...like I said
earlier...just something to be aware of as a possible problem.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-20 13:26:18
Jeff Mcadams was heard to say:
>... Essentially the TA/modem
>kind of "caches" the PAP exchange to reuse with later
>channels...basically exhibiting PAP's vulnerability to replay attacks
>(and sniffing...PAP sends userid and password in the clear).
Oh good god, PAP is only between the PPP client machine and the PPP serving
machine. The only place your password is "out in the open" is on your
serial line, the phone line between modems, and the packet bus inside the
chassis. I think that's more than reasonably secure -- at least as secure
as your password in the win95 password list or registry or on that post-it
on the front of your monitor.
I've had this arguement with idiots within Interpath. For us to allow CHAP,
we would have to store the dialup passwords in plain text (or something that
is reversable to plain text.) Which is the bigger security risk, a database
with thousands of plain text passwords setting in one central location or
you writing your password on a post-it stuck to your monitor in the office
where you have no door?
I am absolutely, hands down, give me a gun against storing passwords in a
database where they have any chance of being recovered (i.e. stolen.) I
never what anyone to have the ability to go to the RADIUS database and be
able to tell a user what his password is, EVER. That password is the only
thing that proves who they are. SSN#, CC#, address, mother's maiden name...
none of those are secure identification over the phone. Anyone on helpdesk
could have that information...
But, I digress.
--Ricky
Subject:(usr-tc) Looking for Old Standard Chassis's to buy. (slightly off topic) From: Sean Herr <sean@ync.net> Date: 1999-02-20 17:02:52
Does anyone have any laying around? Or cards.
Please contact off list at sean@ync.net
Thanks,
Sean Herr
@YourNET Connection, Inc.
847-524-3910
http://www.ync.net
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-21 08:31:39
Thus spake Ricky Beam
>Jeff Mcadams was heard to say:
>>... Essentially the TA/modem
>>kind of "caches" the PAP exchange to reuse with later
>>channels...basically exhibiting PAP's vulnerability to replay attacks
>>(and sniffing...PAP sends userid and password in the clear).
>Oh good god, PAP is only between the PPP client machine and the PPP serving
>machine. The only place your password is "out in the open" is on your
>serial line, the phone line between modems, and the packet bus inside the
>chassis. I think that's more than reasonably secure -- at least as secure
>as your password in the win95 password list or registry or on that post-it
>on the front of your monitor.
Whoa...take a chill pill Ricky. I wasn't saying PAP was inherently
insecure or anything. Just explaining how the PAP caching mechanism in
an ISDN TA worked. Yes, 99% of the time, PAP will only go over a phone
line, and that's rather secure, but PAP *is* susceptible to replay
attacks, even outright sniffing if you can get the access to it.
Since my whole post was merely to point out possible problems with
switching people to scripted logins (makes multi-link bundling
insecure), and it was stated that this wasn't a problem with TA's, I
wanted to clarify how it might be. Again, I don't know how Mac's and
various TA's handle this for sure, but it *might* be an issue (the
multilink bundling that is). Also, if you have some sort of funky
setup, where your access servers rlogin or telnet to a PPP server and
use PAP there, then PAP *could* be sniffed from the ethernet. Yes, this
is very rare, but it can occur.
>I've had this arguement with idiots within Interpath. For us to allow CHAP,
>we would have to store the dialup passwords in plain text (or something that
>is reversable to plain text.) Which is the bigger security risk, a database
>with thousands of plain text passwords setting in one central location or
>you writing your password on a post-it stuck to your monitor in the office
>where you have no door?
Oh, I definitely agree there. We don't support CHAP either, mainly for
that reason, also because we authenticate off our UNIX password database
so we can keep the same userid/password combo for both PPP and shell
access.
>I am absolutely, hands down, give me a gun against storing passwords in a
>database where they have any chance of being recovered (i.e. stolen.)
Well...any database conceivably has that danger, its just a matter of
degree, and making it sufficiently hard to recover them that its not worth
the effort. :)
>I
>never what anyone to have the ability to go to the RADIUS database and be
>able to tell a user what his password is, EVER.
>That password is the only
>thing that proves who they are. SSN#, CC#, address, mother's maiden name...
>none of those are secure identification over the phone. Anyone on helpdesk
>could have that information...
Agreed there as well...no clear-text passwords in the RADIUS
database...or if there were, I certainly wouldn't give helpdesk access
to that/those file(s). If the user forgets their password...set a new
one.
>But, I digress.
Yup, you did. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) 4.1.59-1, Any fix for Mac yet ? From: d baud <dbaud@bigfoot.com> Date: 1999-02-21 14:04:28
Since we upgraded our Harc to 4.1.59-1 we received many Mac users not
being able to connect via PAP. Has anyone come up with a fix preferably
from the server side (The HARC box)
BTW, it seems that winNT users can no-longer connect if the check box is
enabled on "Enable PPP LCP extensions" Am I right to assume that this
is also related to the Mac problem as well. I wish there was a way to
fix this issue from the HARC box so to avoid the technical support calls
burden.
D Baud
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-21 17:22:54
Jeff Mcadams was heard to say:
>Whoa...take a chill pill Ricky. I wasn't saying PAP was inherently
>insecure or anything. Just explaining how the PAP caching mechanism in
>an ISDN TA worked.
<grin> there's some pent up hostility on that subject...
>>I am absolutely, hands down, give me a gun against storing passwords in a
>>database where they have any chance of being recovered (i.e. stolen.)
>
>Well...any database conceivably has that danger, its just a matter of
>degree, and making it sufficiently hard to recover them that its not worth
>the effort. :)
I can send you our entire password list... they're UNIX crypt()ed passwords.
You can _guess_ the password, but you cannot _recover_ the password. I don't
want anyone to be able to type in the encrypted password and get back the
unencrypted password. USR's RADIUS server ENCRYPT() function is laughably
insecure.
--Ricky
Subject:(usr-tc) Cisco 766 dropping packets when connecting to netserver. From: Ernie Pritchard <elp@inline.com> Date: 1999-02-21 20:44:18
Hi,
I have been experiencing upstreampacket loss with cisco 76x series
routers when connecting to my netserver chassis. Has anyone else seen
anything like this or know of a fix. Cisco recommends turning off the
ppp negotiation integrity off but this is no help.
Thanks,
Ernie Pritchard
InLine Connections.
Subject:(usr-tc) Security & Accounting for NT on Dec Alpha.. From: Rick <rickyz@mindspring.com> Date: 1999-02-22 07:10:52
Hello 3Com-
Would you happen to know if there are plans for a version of Security and Accounting that will run under NT on a Dec Alpha?
Thanks in advance,
RickyZ
Subject:Re: (usr-tc) 4.1.59-1, Any fix for Mac yet ? From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-22 09:08:07
I was told HARC code 4.1.59-5 contains a fix to address this issue.
-- Matt
d baud <dbaud@bigfoot.com> on 02/21/99 01:04:28 PM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
Since we upgraded our Harc to 4.1.59-1 we received many Mac users not
being able to connect via PAP. Has anyone come up with a fix preferably
from the server side (The HARC box)
BTW, it seems that winNT users can no-longer connect if the check box is
enabled on "Enable PPP LCP extensions" Am I right to assume that this
is also related to the Mac problem as well. I wish there was a way to
fix this issue from the HARC box so to avoid the technical support calls
burden.
D 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) 4.1.59-1, Any fix for Mac yet ? From: pferraro@wna-linknet.com Date: 1999-02-22 10:44:04
So where do we find 4.1.59-5? We have 4.1.59-1 currently and we
do experience some problems with mac user using v.90 modems, especially
the Supra 56K SP Godd connect and verification, but drops it in a few
minutes!
==============================================================================
Phillip Ferraro WorldNet Access, Inc
pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
Voice (910) 346-0835 824 Gumbranch Square, Suite R3
FAX (910) 455-1933 Jacksonville, Nc 28540-6269
==============================================================================
On Mon, 22 Feb 1999, Matt Harper wrote:
>
>
> I was told HARC code 4.1.59-5 contains a fix to address this issue.
>
> -- Matt
>
>
>
>
>
> d baud <dbaud@bigfoot.com> on 02/21/99 01:04:28 PM
>
> Please respond to usr-tc@lists.xmission.com
>
> To: usr-tc@lists.xmission.com
> cc: (Matt Harper/MW/US/3Com)
> Subject: (usr-tc) 4.1.59-1, Any fix for Mac yet ?
>
>
>
>
> Since we upgraded our Harc to 4.1.59-1 we received many Mac users not
> being able to connect via PAP. Has anyone come up with a fix preferably
> from the server side (The HARC box)
>
> BTW, it seems that winNT users can no-longer connect if the check box is
> enabled on "Enable PPP LCP extensions" Am I right to assume that this
> is also related to the Mac problem as well. I wish there was a way to
> fix this issue from the HARC box so to avoid the technical support calls
> burden.
>
> D 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.
>
>
>
>
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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-1, Any fix for Mac yet ? From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-22 11:34:02
pferraro@wna-linknet.com said once upon a time:
>
>
> So where do we find 4.1.59-5? We have 4.1.59-1 currently and we
>do experience some problems with mac user using v.90 modems, especially
>the Supra 56K SP Godd connect and verification, but drops it in a few
>minutes!
Ditto. I need 4.1.59-5 in a bad way. The PAP connection problems are
spreading to OS/2 and Linux platforms.
dip swith 5. If you put it on and boot the card every config on the
netserver will be erased and will go back to factory defaults
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Fri, 12 Feb 1999, acparks wrote:
> I need to know what i need to do to eraset he netserver's configuration
> back to factory settings?
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) Mime-Version: 1.0 From: John Campbell <sparky@roava.net> Date: 1999-02-22 13:33:56
Having a problem with one of my customers coming in on dialup ISDN.
Subject:Re: (usr-tc) 4.1.59-1, Any fix for Mac yet ? From: Dale Hege <fhege@sover.net> Date: 1999-02-22 13:41:08
There are still some problems with freeppp. -6 works better but they still
have some more to do.
-Dale
On Mon, 22 Feb 1999 pferraro@wna-linknet.com wrote:
>
> So where do we find 4.1.59-5? We have 4.1.59-1 currently and we
> do experience some problems with mac user using v.90 modems, especially
> the Supra 56K SP Godd connect and verification, but drops it in a few
> minutes!
>
> ==============================================================================
> Phillip Ferraro WorldNet Access, Inc
> pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service
> Voice (910) 346-0835 824 Gumbranch Square, Suite R3
> FAX (910) 455-1933 Jacksonville, Nc 28540-6269
> ==============================================================================
>
> On Mon, 22 Feb 1999, Matt Harper wrote:
>
> >
> >
> > I was told HARC code 4.1.59-5 contains a fix to address this issue.
> >
> > -- Matt
> >
> >
> >
> >
> >
> > d baud <dbaud@bigfoot.com> on 02/21/99 01:04:28 PM
> >
> > Please respond to usr-tc@lists.xmission.com
> >
> > To: usr-tc@lists.xmission.com
> > cc: (Matt Harper/MW/US/3Com)
> > Subject: (usr-tc) 4.1.59-1, Any fix for Mac yet ?
> >
> >
> >
> >
> > Since we upgraded our Harc to 4.1.59-1 we received many Mac users not
> > being able to connect via PAP. Has anyone come up with a fix preferably
> > from the server side (The HARC box)
> >
> > BTW, it seems that winNT users can no-longer connect if the check box is
> > enabled on "Enable PPP LCP extensions" Am I right to assume that this
> > is also related to the Mac problem as well. I wish there was a way to
> > fix this issue from the HARC box so to avoid the technical support calls
> > burden.
> >
> > D 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.
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
Thus spake John Campbell
> Having a problem with one of my customers coming in on dialup ISDN.
>Here's the deal:
> There are two access servers and a router on an Ethernet. The customer
> (ISDN) has fixed IP address and gets connected to different access
> servers on different calls. The router has the customer's IP address
> mapped to the MAC address of the access server used on the previous
> call.
>What should happen is that the access server should send a "gratuitous
>ARP" when a user starts PPP. This would cause the router to replace
>its ARP cache entry with the correct mapping.
Actually...proly a better solution is to enable RIP routing (or OSPF
once that becomes available)
Relying on proxyarp means your static IP addresses are limited to only
hitting a hunt group of a limited number of servers (ie, servers that
are in the same subnet)...trust me...this doesn't scale. We used to
have to do this with the *old* Xyplex terminal servers we used. Left
them because they couldn't support any active routing protocols (not
even RIP).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) how to enable prompt_delay? From: Jamie Orzechowski <mhz@recorder.ca> Date: 1999-02-22 14:37:40
just wondering HOW I enable prompt_delay? I cannot find it anywhere in the
arc commands ...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
Subject:Re: (usr-tc) 4.1.59-1 From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-22 15:26:13
When I type a command thru telnet and want to use that command agian I would
like to use the up arrow. In my case the up arrow does not display that
command agian. I have read some docs and it states that it should. Is this
just some feature that I have not enabled? I know this worked with the
netservers.
Thanks
Paul JR.
AlaWeb Network Admin.
Subject:Re: (usr-tc) 4.1.59-1, Any fix for Mac yet ? From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-22 15:32:51
What modem of webramp has this problems? Can you tell me the model
number software version etc?
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, 22 Feb 1999, Jeff Binkley wrote:
>
> Definetly 4.1.59-1 kills the WebRamps. I'd avoid it all together.
> 3Com should take this off their website.
>
>
> Jeff Binkley
> ASA Network Computing
>
>
> -> There are still some problems with freeppp. -6 works better but they still
> -> have some more to do.
> ->
> -> -Dale
> ->
> -> On Mon, 22 Feb 1999 pferraro@wna-linknet.com wrote:
> ->
> -> >
> -> > So where do we find 4.1.59-5? We have 4.1.59-1 currently and we > do
> -> experience some problems with mac user using v.90 modems, especially > the
> -> Supra 56K SP Godd connect and verification, but drops it in a few >
> -> minutes!
> -> >
> -> >
> -> ============================================================================
> -> > Phillip Ferraro WorldNet Access, Inc
> -> > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice
> -> (910) 346-0835 824 Gumbranch Square, Suite R3
> -> > FAX (910) 455-1933 Jacksonville, Nc 28540-6269
> -> >
> -> ============================================================================
> -> >
> -> > On Mon, 22 Feb 1999, Matt Harper wrote:
> -> >
> -> > >
> -> > >
> -> > > I was told HARC code 4.1.59-5 contains a fix to address this issue. > >
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) how to enable prompt_delay? From: Janakiraman Senthilnathan <janakiraman_senthilnathan@mw.3com.com> Date: 1999-02-22 15:43:22
Use:
set modem_group <grp> prompt_delay <>
or
set switched interface <intf> prompt_delay <>
senthil.
"Jamie Orzechowski" <mhz@recorder.ca> on 02/22/99 01:37:40 PM
Please respond to usr-tc@lists.xmission.com
cc: (Janakiraman Senthilnathan/MW/US/3Com)
just wondering HOW I enable prompt_delay? I cannot find it anywhere in the
arc commands ...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.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) 4.1.59-1, Any fix for Mac yet ? From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-22 15:58:00
Definetly 4.1.59-1 kills the WebRamps. I'd avoid it all together.
3Com should take this off their website.
Jeff Binkley
ASA Network Computing
-> There are still some problems with freeppp. -6 works better but they still
-> have some more to do.
->
-> -Dale
->
-> On Mon, 22 Feb 1999 pferraro@wna-linknet.com wrote:
->
-> >
-> > So where do we find 4.1.59-5? We have 4.1.59-1 currently and we > do
-> experience some problems with mac user using v.90 modems, especially > the
-> Supra 56K SP Godd connect and verification, but drops it in a few >
-> minutes!
-> >
-> >
-> ============================================================================
-> > Phillip Ferraro WorldNet Access, Inc
-> > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice
-> (910) 346-0835 824 Gumbranch Square, Suite R3
-> > FAX (910) 455-1933 Jacksonville, Nc 28540-6269
-> >
-> ============================================================================
-> >
-> > On Mon, 22 Feb 1999, Matt Harper wrote:
-> >
-> > >
-> > >
-> > > I was told HARC code 4.1.59-5 contains a fix to address this issue. > >
Subject:Re: (usr-tc) 4.1.59-1 From: Matt Harper <matt_harper@mw.3com.com> Date: 1999-02-22 16:04:59
If you are using window telnet, click terminal/preferences - then enable VT100
arrows.
Windows has this disabled by default.
-- Matt
"Paul Jr. (AlaWeb Support)" <jr@alaweb.com> on 02/22/99 03:26:13 PM
Please respond to usr-tc@lists.xmission.com
cc: (Matt Harper/MW/US/3Com)
When I type a command thru telnet and want to use that command agian I would
like to use the up arrow. In my case the up arrow does not display that
command agian. I have read some docs and it states that it should. Is this
just some feature that I have not enabled? I know this worked with the
netservers.
Thanks
Paul JR.
AlaWeb Network Admin.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
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-1 From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-22 16:09:26
Thanks... The below fixed it.
Sorry I had to ask such a dumb question.
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
http://www.alaweb.com/support.html
----- Original Message -----
Sent: Monday, February 22, 1999 4:04 PM
>
>
>If you are using window telnet, click terminal/preferences - then enable
VT100
>arrows.
>Windows has this disabled by default.
>
>-- Matt
>
>
>
>
>
>"Paul Jr. (AlaWeb Support)" <jr@alaweb.com> on 02/22/99 03:26:13 PM
>
>Please respond to usr-tc@lists.xmission.com
>
>To: usr-tc@lists.xmission.com
>cc: (Matt Harper/MW/US/3Com)
>Subject: Re: (usr-tc) 4.1.59-1
>
>
>
>
>When I type a command thru telnet and want to use that command agian I
would
>like to use the up arrow. In my case the up arrow does not display that
>command agian. I have read some docs and it states that it should. Is
this
>just some feature that I have not enabled? I know this worked with the
>netservers.
>
>
>Thanks
>Paul JR.
>AlaWeb Network Admin.
>
>
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
Paul Jr. was heard to say:
>When I type a command thru telnet and want to use that command agian I would
>like to use the up arrow. In my case the up arrow does not display that
>command agian. I have read some docs and it states that it should. Is this
>just some feature that I have not enabled? I know this worked with the
>netservers.
What? Netserver never had an editable command history. I'd check your
telnet setting to so what your up arrow is sending. If in doubt, try using:
[crtl]-p -- previous line
[crtl]-n -- next line
[crtl]-f -- forward character
[crtl]-b -- backward character
--Ricky
Subject:Re: (usr-tc) 4.1.59-1 From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-22 16:44:26
Works for me on 4.1.59-1.
It could be your terminal emulation's not sending the right escape
sequence for the arrow keys. I'm using SecureCRT in vt220 mode here.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Mon, 22 Feb 1999, Paul Jr. (AlaWeb Support) wrote:
> When I type a command thru telnet and want to use that command agian I would
> like to use the up arrow. In my case the up arrow does not display that
> command agian. I have read some docs and it states that it should. Is this
> just some feature that I have not enabled? I know this worked with the
> netservers.
Subject:Re: (usr-tc) Class C not big enough for 14 DSPs From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-22 16:55:33
Mailing List Reader said once upon a time:
>OK multiple 3 ip pools in the box from different Class C's. What
>additional configuration is required?
Some way for your router to know they are there. I prefer static, but you
could have them announced via RIP.
Subject:Re: (usr-tc) What does prompt_delay buy me? From: Jamie Orzechowski <mhz@ripnet.com> Date: 1999-02-22 18:27:20
just wondering also what is the DEFAULT prompt_delay??
I just set mine to 5 seconds ...
-----Original Message-----
>Thus spake Ricky Beam
>>Jeff Mcadams was heard to say:
>>>Thus spake Pete Ashdown
>>>>They aren't affected by the FreePPP PAP problem then, and have no need
to
>>>>go to a scripted login.
>
>>>You sure about that? (not trying to be a pain here...just making sure
>>>you're aware of all the issues in this) With a TA that does PPP to MP
>>>conversion off of a serial port, the PAP would be done in software on
>>>the computer. I'm not sure (haven't followed it closely enough...my
>>>apologies for that) what exactly the problem is with PAP and FreePPP,
>>>but with a TA like this, FreePPP would be doing the PAP, not the as
>>>such.
>
>>Multilink PPP via a TA (modem for lack of a better term) is usually
handled
>>by the the TA itself. The TA understand PPP enough to grab the PAP info
>>so it can bring up the second channel all on it's own. The machine
>>connected to the TA doesn't have to know there are two lines being bundled
>>together. This is how the I-Modem does it. (That's why you have to use
>>PAP on those things.)
>
>Yeah...my point exactly. PAP on the initial line is just passed through
>basically untouched, so if there's a PAP issue between FreePPP and the
>HiPer Arc, it might still affect it (I don't know as I haven't had any
>situations where I've had to play with it). Essentially the TA/modem
>kind of "caches" the PAP exchange to reuse with later
>channels...basically exhibiting PAP's vulnerability to replay attacks
>(and sniffing...PAP sends userid and password in the clear).
>
>Its been said that its a timing thing with this PAP issue I think
>(again, don't remember the whole thread and for that I apologize), and
>the TA's might alter the timing so it does work. In which
>case...great...glad to know it works. :) Anyway...like I said
>earlier...just something to be aware of as a possible problem.
>--
>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) 4.1.59-1, Any fix for Mac yet ? From: Blake Fithen <fithen@networksplus.com> Date: 1999-02-22 18:36:18
Our customers who have the Webramp Entre with software
version 1.01 (or 1.1?) are having problems. The newer
Webramp 300e's work ok. we're running 4.1.59 and 1.2.59.
Had a spare chassis with 4.1.72 and 1.2.5 - they connect
ok to it.
blake
> -----Original Message-----
> From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com]
> Sent: Monday, February 22, 1999 3:33 PM
> To: Jeff Binkley
> Cc: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 4.1.59-1, Any fix for Mac yet ?
>
>
> What modem of webramp has this problems? Can you tell me the model
> number software version etc?
>
> 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, 22 Feb 1999, Jeff Binkley wrote:
>
> >
> > Definetly 4.1.59-1 kills the WebRamps. I'd avoid it all together.
> > 3Com should take this off their website.
> >
> >
> > Jeff Binkley
> > ASA Network Computing
> >
> >
> > -> There are still some problems with freeppp. -6 works
> better but they still
> > -> have some more to do.
> > ->
> > -> -Dale
> > ->
> > -> On Mon, 22 Feb 1999 pferraro@wna-linknet.com wrote:
> > ->
> > -> >
> > -> > So where do we find 4.1.59-5? We have 4.1.59-1
> currently and we > do
> > -> experience some problems with mac user using v.90
> modems, especially > the
> > -> Supra 56K SP Godd connect and verification, but drops
> it in a few >
> > -> minutes!
> > -> >
> > -> >
> > ->
> ==============================================================
> ==============
> > -> > Phillip Ferraro WorldNet Access, Inc
> > -> > pferraro@wna-linknet.com Onslow County's PREMIER
> InterNet Service > Voice
> > -> (910) 346-0835 824 Gumbranch Square, Suite R3
> > -> > FAX (910) 455-1933 Jacksonville, Nc 28540-6269
> > -> >
> > ->
> ==============================================================
> ==============
> > -> >
> > -> > On Mon, 22 Feb 1999, Matt Harper wrote:
> > -> >
> > -> > >
> > -> > >
> > -> > > I was told HARC code 4.1.59-5 contains a fix to
> address this issue. > >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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) disconnect log From: K Mitchell <mitch@keyconn.net> Date: 1999-02-22 19:46:43
I have a user getting disconnected immediately after logon. Monitoring
PPP(I'm fairly sure that it was monitoring the right session) shows the
following at the time of disconnect;
Incoming PPP Data on interface: slot:14/mod:20
48bb 21 a5 18 96 7f 34 58 55 11 42 05 db 2b fa 6d aa 18 65 76 c9 ...
Outgoing PPP Data on interface: slot:14/mod:20
LCP PROT_REJ Unknown
Incoming PPP Data on interface: slot:14/mod:20
CCP RESET_REQ
Incoming PPP Data on interface: slot:14/mod:20
007f 97 cd 69 d3 9a 81 5e f0 78 c7 ed be ff ab 1f 8d cf
Outgoing PPP Data on interface: slot:14/mod:20
LCP PROT_REJ Unknown
Incoming PPP Data on interface: slot:14/mod:20
IPCP CFG_REQ NEW_ADDRS cc ab 1f bf
PRIM DNS cc ab 1f 04
SEC DNS cc ab 1f 05
....Tracing the current/next session; Escape to stop...
Can anybody help me interpret this to determine what might be causing the
problem. This is a Mac Powerbook/Global Village modem connecting to my
Hiper DSP 1.2.60/ARC 4.1.72
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) What does prompt_delay buy me? From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-22 20:32:45
Thus spake Jamie Orzechowski
>just wondering also what is the DEFAULT prompt_delay??
>I just set mine to 5 seconds ...
I think its 1 second. I believe prior to 4.1.59-2, it was a fixed pause
of 1 second before doing whatever. I think kind of to give the modems a
second to stabilize before starting up whatever.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) 4.1.59-1, Any fix for Mac yet ? From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-22 20:56:00
-> What modem of webramp has this problems? Can you tell me the model number
-> software version etc?
->
-> krish
Krish,
We are using USR Sportster 56K X2 modems on 2 different Web Ramps. I don't
have release numbers for the Sportster code. it has worked even with the
4.1.64 code you made for me until now. This is the first time they started
failing with the HiPerArc. This is with Quads running 5.10.9 code.
Jeff
On Mon, 22 Feb 1999, K Mitchell wrote:
> I have a user getting disconnected immediately after logon. Monitoring
> PPP(I'm fairly sure that it was monitoring the right session) shows the
> following at the time of disconnect;
>
> Incoming PPP Data on interface: slot:14/mod:20
> 48bb 21 a5 18 96 7f 34 58 55 11 42 05 db 2b fa 6d aa 18 65 76 c9 ...
>
> Outgoing PPP Data on interface: slot:14/mod:20
> LCP PROT_REJ Unknown
>
> Incoming PPP Data on interface: slot:14/mod:20
> CCP RESET_REQ
Ther eis a incoming ccp request before starting any network protocol.
That will be rejected. The client should not send this.
krish
> Incoming PPP Data on interface: slot:14/mod:20
> 007f 97 cd 69 d3 9a 81 5e f0 78 c7 ed be ff ab 1f 8d cf
>
> Outgoing PPP Data on interface: slot:14/mod:20
> LCP PROT_REJ Unknown
>
> Incoming PPP Data on interface: slot:14/mod:20
> IPCP CFG_REQ NEW_ADDRS cc ab 1f bf
> PRIM DNS cc ab 1f 04
> SEC DNS cc ab 1f 05
> ....Tracing the current/next session; Escape to stop...
>
> Can anybody help me interpret this to determine what might be causing the
> problem. This is a Mac Powerbook/Global Village modem connecting to my
> Hiper DSP 1.2.60/ARC 4.1.72
>
> 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:(usr-tc) Physical State From: Marcelo Souza <mpsouza@centroin.com.br> Date: 1999-02-23 09:46:07
What should be the correct OID, to get the physical State for a
Dual E1 CAS board (usrds1StatE1PhysicalState)?
I tryied:
1.3.6.1.4.1.429.1.27.2.1.6
1.3.6.1.4.1.429.1.4.5.1.9
But both return: 0 (zero)
Even with TCM I could not get the response.
- Marcelo
Subject:Re: (usr-tc) 4.1.59-1, Any fix for Mac yet ? From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-23 10:04:50
On Mon, 22 Feb 1999, Jeff Binkley wrote:
> -> What modem of webramp has this problems? Can you tell me the model number
> -> software version etc?
> ->
> -> krish
>
> Krish,
>
> We are using USR Sportster 56K X2 modems on 2 different Web Ramps. I don't
> have release numbers for the Sportster code. it has worked even with the
> 4.1.64 code you made for me until now. This is the first time they started
> failing with the HiPerArc. This is with Quads running 5.10.9 code.
>
The last thing I heard about the problem was that the webram needed an
upgrade to work with the latest DSP and hiper arc code. If you can
arrange for a webram to call our hiper arc here - I can get this issue
fixed asap.
regards
krish
>
> Jeff
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Subject:(usr-tc) v.42bis problems in latest DSP code? From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-23 10:31:35
Has anyone seen any weird problems with spontaneous disconnects in either
1.2.60 or 1.2.59 DSP code? We had a big problem with this for a few days,
after we moved some DSP's closer to the front of our hunt group. (We
moved two into each of our Quad racks.) People could check their email,
but as soon as they went to browse the web, they got disconnected.
I figured "cheap buggy HCF modems" at first, until I was able to reproduce
it on a v.90 Courier...
It's not PPP related at all. Dial in, log into a shell account (not PPP),
then do "ls -lR /" to generate a ton of output. About 100 lines into it,
the output will get trashed (as if the decompression table got corrupted),
then NO CARRIER. The Courier says the disconnect reason is "Invalid
codeword". The DSP says "link abort", at least most of the time.
(It's hard to tell the DSP disconnect reason, because the DSP has an
off-by-one bug in its accounting, and our Radius server has a hack to
manually increment the values when it sees an accounting packet from the
NMC that looks like it's from a DSP. Bleah! But that's a separate
problem. :)
I fixed this by turning v.42bis compression off. Not really an ideal fix.
Has anyone else seen this, or am I just going crazy (as usual)?
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:(usr-tc) ISDN DOVBS HiperDSP or Quads From: Charles Sprickman <spork@inch.com> Date: 1999-02-23 11:39:44
Hi,
This is mainly for the 3com folks reading the list, but if anyone else can
step forth and give a solid answer I'd be happy too...
Can the TCH equipment in any configuration do DOVBS? In NYC, you *are not
charged* per minute when you place an ISDN call as a "voice" call. This
is generally referred to here as "Data over Voice". All Ascend, Cisco,
and Lucent dial equipment supports this, so I find it hard to believe the
USR/3Com gear cannot.
So here's what I have: All chassis are Hiper ARC based with a mixture of
DSPs and Quad-I's. Can I do this on either/both of these modem cards?
What are the requirements?
Please, if you know, tell me! I'm pulling my hair out here!
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
Subject:RE: (usr-tc) 4.1.59-1 From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-23 11:52:33
That's just windows telnet that's broken (what else ain't ?).... Telnet =
from
linux or solaris works just fine...
Robert
> -----Original Message-----
> From: Paul Jr. (AlaWeb Support) [SMTP:jr@alaweb.com]
> Sent: lundi, 22. f=E9vrier 1999 22:26
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) 4.1.59-1
>=20
> When I type a command thru telnet and want to use that command agian =
I
> would
> like to use the up arrow. In my case the up arrow does not display =
that
> command agian. I have read some docs and it states that it should. =
Is
> this
> just some feature that I have not enabled? I know this worked with =
the
> netservers.
>=20
>=20
> Thanks
> Paul JR.
> AlaWeb Network Admin.
>=20
>=20
>=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.
Subject:Re: (usr-tc) v.42bis problems in latest DSP code? From: Ronald E. Kushner <ron@glis.net> Date: 1999-02-23 13:46:46
Mike Andrews wrote:
>
> Has anyone seen any weird problems with spontaneous disconnects in either
> 1.2.60 or 1.2.59 DSP code? We had a big problem with this for a few days,
> after we moved some DSP's closer to the front of our hunt group. (We
> moved two into each of our Quad racks.) People could check their email,
> but as soon as they went to browse the web, they got disconnected.
>
> I figured "cheap buggy HCF modems" at first, until I was able to reproduce
> it on a v.90 Courier...
<snip>
> I fixed this by turning v.42bis compression off. Not really an ideal fix.
>
> Has anyone else seen this, or am I just going crazy (as usual)?
I always keep V.42bis off on all my dialup modems, because it's ALWAYS
caused strange disconnection problems ever since it's been introduced in
cheaper modems the early 1990's. I think it's just software bugs in the
coding on one side or the others, generally a Courier to a Courier will
never have this happen, nor will a Hayes to a Hayes, and even a Hayes to a
Courier works quite well, but have a Hayes call a Supra and look out! (Is
Supra still in business? Haven't seen one in awhile)
-Ron
GLISnet, Inc.
+1 810/939.9885
Subject:Re: (usr-tc) v.42bis problems in latest DSP code? From: Lon R. Stockton, Jr. <lon@moonstar.com> Date: 1999-02-23 15:41:50
On Tue, 23 Feb 1999, Ronald E. Kushner wrote:
> [...] Is Supra still in business? Haven't seen one in awhile)
Oh yeah, 'cept they've been bought by Diamond. One of their more
recent products is a really sexy dual-56k internal modem that does
bonding (rest of the world calls it multilink, they call it Shotgun<tm>).
Don't know about any other gear, but our HiPer TC's support it
beautifully. Customers can get ISDNish speeds without the prices and
alleged headaches of ISDN. Tell your power users about them and you
can look in their face and see the satisfaction levels jumping.
Tell your prospective customers about 'em, and lay waste to your
competition that sells unlimited accounts which are limited to one
connection at a time. Oh, I'm sorry, to be PC and not offend anyone,
I've gotta say 'unmetered' accounts.
Also should mention that it's not limited to Diamond Supra modems;
if the user has the appropriate version of Win95 (or Win98), they
can do the same thing with any two modems they have laying around
by using the MultiLink features.
I don't know of anything specific one has to do to their TC gear
to make it work; when I tested 'em on mine, it worked out of the
box on the first shot with no problems.
Subject:(usr-tc) Debug codes From: Carl Litt <carl@execulink.com> Date: 1999-02-23 17:42:21
What are the various debug tools included in the cards? I know
there are undocumented commands on the DSP console, and there is
at least one hidden menu on the Dual-T1 card. We should start
a repository for this stuff.
There are a lot of times I'm working with a problem chassis, just
wishing for more information. I know it's there. I've heard the
3Com tech people mumble debugging output to themselves. I want
to see it.
In particular, I'm having problems with fast busies on Dual-T1
cards with HARC and 2 DSP's in the chassis too. The telco is 100%
sure the T1's are OK, and I tend to side with them in this case.
They worked fine before.
I would much rather filter useless information than get frustrated
over the lack of it (much as I do now).
Subject:(usr-tc) HARCs and WebTV From: Walt Gnann <wgnann@islc.net> Date: 1999-02-23 18:03:40
I just finished upgrading our Netserver/Quad Modem chasis to an HARC. I
didn't put in any HDSPs just the HARC. I'm now getting weird entries in our
Radius detail file like:
Tue Feb 23 17:42:51 1999
User-Name = "unauthenticated"
Client-Id = 208.224.174.5
Acct-Status-Type = Stop
Acct-Session-Id = "67305473"
Acct-Delay-Time = 0
User-Service-Type = Framed-User
Client-Port-Id = 1028
Framed-Protocol = PPP
Framed-Address = 0.0.0.0
Acct-Session-Time = 49
No start record. Coincidentally, it appears our WebTV users are no longer
able to connect. I suspected it was a problem with the HARC code (4.1.11).
I downloaded and flashed the HARC to 4.1.59 and the problem persists. I'm
not positive that the Radius error message above is for a WebTV it simply
corresponds. I have the HARC set to perform PAP authentication.
I guess my questions are: 1) Is there a HARC software version that supports
WebTV connects; and 2) Is the radius log entry above typical for a failed
WebTV connect and if not what else could it be?
Thanks for your help.
Walt
Walter N. Gnann
ISLC, Manager
843.770.1000
843.770.1002 (fax)
wgnann@islc.net
http://www.islc.net
http://www.beaufortcomputerclub.org
Subject:(usr-tc) Bad modems From: Mark Pansing <markp@infinet.com> Date: 1999-02-23 18:12:10
I am starting to have a rash of modem failures on our HiperDSPs. We are
using version 1.2.60 and terminating on a PRI set for Prisw5ess. The
modems show an inordinate amount of Incoming Connections Failed. The DSO
stats show Incoming call is dialing(3) instead of Incoming call
is connected(5) and the modem shows ringRcvd(5). We do not have anything
set to dial out. If we reset the whole card, the problem goes away for a
day or two. Any ideas?
Mark Pansing
Infinet Engineering Staff
(614) 848-4638 x203
markp@infinet.com
> I am starting to have a rash of modem failures on our HiperDSPs. We are
> using version 1.2.60 and terminating on a PRI set for Prisw5ess. The
> modems show an inordinate amount of Incoming Connections Failed. The DSO
> stats show Incoming call is dialing(3) instead of Incoming call
> is connected(5) and the modem shows ringRcvd(5). We do not have anything
> set to dial out. If we reset the whole card, the problem goes away for a
> day or two. Any ideas?
I've had this problem since the original code for the HDM (1.0.3?)
It's gotten a lot better over the different revisions of the code, but it
is definatly still there. For some reason, the DSP locks up, and takes
out 2 modems with it - and never resets until you reboot the whole card.
FWIW, it's not related to PRI's at all either. I use channelized T1's out
of a DMS100 - same thing. It doesn't happen as often as you are saying,
however. I usually put my chassis on a schedule to busy out and fully
reboot the entire box every 2 months or so.
| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt |
| Senior Vice President - Exec-PC, Inc. |
Subject:(usr-tc) Win Modems From: G. Owens <gowens@magnolia-net.com> Date: 1999-02-23 20:10:48
Since I didn't get a response the first time and have had 3 more phone calls
today from different users. I will ask it again. We are having alot problems
with users with USR Win INT modems failing to connect the first time. Many
are having to dial in up to 20 trys before establishing connection. If we
upgrade to the 1.2.59 code will this help these users. I know you have said
it will help the Rockwell based modems and others, or do I need to have my
users update there end. Also what is the command to disable v90 in a USR
modem......Many Thanks :-)
Greg Owens
Magnolia Internet Services
Subject:Re: (usr-tc) v.42bis problems in latest DSP code? From: Brian Uechi <brianu@lava.net> Date: 1999-02-24 00:13:34
On Tue, 23 Feb 1999, Mike Andrews wrote:
> Has anyone seen any weird problems with spontaneous disconnects in either
> 1.2.60 or 1.2.59 DSP code? We had a big problem with this for a few days,
I see this a lot calling .60 and .59 using a v.90 courier. Calling a
quad/netserver chassis works fine from the same modem and phone line.
I checked the PRI stats on the DSP and there is nothing wrong with
the PRI.
> I fixed this by turning v.42bis compression off. Not really an ideal fix.
>
> Has anyone else seen this, or am I just going crazy (as usual)?
I'll try this and see if this helps.
Disable info for v.90 can be found here:
http://www.56k.com/trouble/interop.shtml
Russ Miescke
Power Web Connect
russm@powerweb.net
http://www.powerweb.net
----- Original Message -----
Sent: Tuesday, February 23, 1999 8:10 PM
>Since I didn't get a response the first time and have had 3 more phone
calls
>today from different users. I will ask it again. We are having alot
problems
>with users with USR Win INT modems failing to connect the first time. Many
>are having to dial in up to 20 trys before establishing connection. If we
>upgrade to the 1.2.59 code will this help these users. I know you have said
>it will help the Rockwell based modems and others, or do I need to have my
>users update there end. Also what is the command to disable v90 in a USR
>modem......Many Thanks :-)
> 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.
>
Greg,
We see this a lot too with Winmodems from many vendors that have the
Lucent chipset. Download the latest Winmodem code (5.32 or higher) and
the problem goes away. There are a couple of good web pages out there
on the subject.
Jeff Binkley
ASA Network Computing
U>Since I didn't get a response the first time and have had 3 more phone
U>calls today from different users. I will ask it again. We are having
U>alot problems with users with USR Win INT modems failing to connect
U>the first time. Many are having to dial in up to 20 trys before
U>establishing connection. If we upgrade to the 1.2.59 code will this
U>help these users. I know you have said it will help the Rockwell based
U>modems and others, or do I need to have my users update there end.
U>Also what is the command to disable v90 in a USR modem......Many
U>Thanks :-) Greg Owens
U>Magnolia Internet Services
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.
CMPQwk 1.42 9999
Subject:Re: (usr-tc) ISDN DOVBS HiperDSP or Quads From: Charles Sprickman <spork@inch.com> Date: 1999-02-24 11:41:08
Grrr... Our local rep spoke to "engineering" here in the US and stated
that "No current TCH configuration (quads/dsps/netserver/arcs) supports
this feature [...] and support will not be in beta until November at the
earliest".
Please, if anyone could refute this my boss would be very happy and I
wouldn't have to start shopping again...
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
On Wed, 24 Feb 1999, Ray Whelan wrote:
>
>
> Hi Charles,
>
> DOVBS protocol is currently in beta the release date is April ,the Hiper DSP
> will support this application .
>
> Ray Whelan
> Net System
> Dublin
>
>
>
>
> Charles Sprickman <spork@inch.com> on 23/02/99 16:39:44
>
> Please respond to usr-tc@lists.xmission.com
>
> To: usr-tc@lists.xmission.com
> cc: (Ray Whelan/IE/3Com)
> Subject: (usr-tc) ISDN DOVBS HiperDSP or Quads
>
>
>
>
> Hi,
>
> This is mainly for the 3com folks reading the list, but if anyone else can
> step forth and give a solid answer I'd be happy too...
>
> Can the TCH equipment in any configuration do DOVBS? In NYC, you *are not
> charged* per minute when you place an ISDN call as a "voice" call. This
> is generally referred to here as "Data over Voice". All Ascend, Cisco,
> and Lucent dial equipment supports this, so I find it hard to believe the
> USR/3Com gear cannot.
>
> So here's what I have: All chassis are Hiper ARC based with a mixture of
> DSPs and Quad-I's. Can I do this on either/both of these modem cards?
> What are the requirements?
>
> Please, if you know, tell me! I'm pulling my hair out here!
>
> Thanks,
>
> Charles
>
> --
> =-----------------= =
> | Charles Sprickman Internet Channel |
> | INCH System Administration Team (212)243-5200 |
> | spork@inch.com access@inch.com |
> = =----------------=
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
On Wed, 24 Feb 1999, Charles Sprickman wrote:
> Grrr... Our local rep spoke to "engineering" here in the US and stated
> that "No current TCH configuration (quads/dsps/netserver/arcs) supports
> this feature [...] and support will not be in beta until November at the
> earliest".
Quads, with PRI can do this with either netserver or hiper arc. You have
to setup the pri card to do this. The dsp does not support this yet.
krish
>
> Please, if anyone could refute this my boss would be very happy and I
> wouldn't have to start shopping again...
>
> Thanks,
>
> Charles
>
> --
> =-----------------= =
> | Charles Sprickman Internet Channel |
> | INCH System Administration Team (212)243-5200 |
> | spork@inch.com access@inch.com |
> = =----------------=
>
> On Wed, 24 Feb 1999, Ray Whelan wrote:
>
> >
> >
> > Hi Charles,
> >
> > DOVBS protocol is currently in beta the release date is April ,the Hiper DSP
> > will support this application .
> >
> > Ray Whelan
> > Net System
> > Dublin
> >
> >
> >
> >
> > Charles Sprickman <spork@inch.com> on 23/02/99 16:39:44
> >
> > Please respond to usr-tc@lists.xmission.com
> >
> > To: usr-tc@lists.xmission.com
> > cc: (Ray Whelan/IE/3Com)
> > Subject: (usr-tc) ISDN DOVBS HiperDSP or Quads
> >
> >
> >
> >
> > Hi,
> >
> > This is mainly for the 3com folks reading the list, but if anyone else can
> > step forth and give a solid answer I'd be happy too...
> >
> > Can the TCH equipment in any configuration do DOVBS? In NYC, you *are not
> > charged* per minute when you place an ISDN call as a "voice" call. This
> > is generally referred to here as "Data over Voice". All Ascend, Cisco,
> > and Lucent dial equipment supports this, so I find it hard to believe the
> > USR/3Com gear cannot.
> >
> > So here's what I have: All chassis are Hiper ARC based with a mixture of
> > DSPs and Quad-I's. Can I do this on either/both of these modem cards?
> > What are the requirements?
> >
> > Please, if you know, tell me! I'm pulling my hair out here!
> >
> > Thanks,
> >
> > Charles
> >
> > --
> > =-----------------= =
> > | Charles Sprickman Internet Channel |
> > | INCH System Administration Team (212)243-5200 |
> > | spork@inch.com access@inch.com |
> > = =----------------=
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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) FS: USR Total Control 48 port chassis $7,500 From: Brian <forsale@xmission.com> Date: 1999-02-24 12:25:17
FS: USR Total Control 48 port chassis $7,500
Total Control Hub : 16-slot chassis
single 110v ac 70Amp power supply, fan tray,
ethernet network management card
12 Quad Digital Modem NAC (48 ports total, 56k v.90)
HiPer ARC Router
Dual T1 - supports analog, but no ISDN
Asking $7,500 for above bundle.
OR separately:
Quad Digital Modem NAC v.90 $500
USR Courier v.90 ext . modem $150
All products are used and in excellent condition.
Buyer is responsible for shipping.
Contact forsale@xmission.com, or call Brian at 801-539-0852, extension 131.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
XMission Internet Access | Save a Tree -- Use Email!
51 E. 400 S, Suite 200 |
Salt Lake City, UT 84111 |
Voice 801.539.0852 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Setup and configuration info for setting up dovbs on the pri/quad is as
follows
Data over voice bearer service (DOVBS) on the dual pri card
should be attempted with pri code 3.02 (tcs 3.0) or higher. The setup
process is as follows:
1. Setup the default gateway slot on the pri card to be none (0).
2. Under card configuration, go to chassis slot device configuration,
and configure the slot where the gateway card is residing to be none
(e.g. if the netserver is in slot 16, then the command would be n:16).
3. Under the same menu, type i:2-13 if there are quad modems in slots 2-13.
4. Escape to main menu and then select inbound call routing
configuration and from there select inbound phone number routing
configuration, wherein, you can configure a b channel to associate itself
with a dnis number (the pri number) and indicate the call type for that b
channel to be digital (e.g. command: 1:ph=2221234,ct=d {on b channel
1, the number is 2221234 and call type is set to digital). This process
is really easy from tcm where at the click of the mouse button you can
configure the dnis number and the call type for all the b channels rather
than manually typing those commands from the console. From tcm you would
have to click on the entire pri card and then go to Inbound call routing
group.
5. Once the configuration is done, you would have to save the pri card
to NVRAM (under card configuration, select save chassis to NVRAM and
execute it).
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 Wed, 24 Feb 1999, Charles Sprickman wrote:
> Grrr... Our local rep spoke to "engineering" here in the US and stated
> that "No current TCH configuration (quads/dsps/netserver/arcs) supports
> this feature [...] and support will not be in beta until November at the
> earliest".
>
> Please, if anyone could refute this my boss would be very happy and I
> wouldn't have to start shopping again...
>
> Thanks,
>
> Charles
>
> --
> =-----------------= =
> | Charles Sprickman Internet Channel |
> | INCH System Administration Team (212)243-5200 |
> | spork@inch.com access@inch.com |
> = =----------------=
>
> On Wed, 24 Feb 1999, Ray Whelan wrote:
>
> >
> >
> > Hi Charles,
> >
> > DOVBS protocol is currently in beta the release date is April ,the Hiper DSP
> > will support this application .
> >
> > Ray Whelan
> > Net System
> > Dublin
> >
> >
> >
> >
> > Charles Sprickman <spork@inch.com> on 23/02/99 16:39:44
> >
> > Please respond to usr-tc@lists.xmission.com
> >
> > To: usr-tc@lists.xmission.com
> > cc: (Ray Whelan/IE/3Com)
> > Subject: (usr-tc) ISDN DOVBS HiperDSP or Quads
> >
> >
> >
> >
> > Hi,
> >
> > This is mainly for the 3com folks reading the list, but if anyone else can
> > step forth and give a solid answer I'd be happy too...
> >
> > Can the TCH equipment in any configuration do DOVBS? In NYC, you *are not
> > charged* per minute when you place an ISDN call as a "voice" call. This
> > is generally referred to here as "Data over Voice". All Ascend, Cisco,
> > and Lucent dial equipment supports this, so I find it hard to believe the
> > USR/3Com gear cannot.
> >
> > So here's what I have: All chassis are Hiper ARC based with a mixture of
> > DSPs and Quad-I's. Can I do this on either/both of these modem cards?
> > What are the requirements?
> >
> > Please, if you know, tell me! I'm pulling my hair out here!
> >
> > Thanks,
> >
> > Charles
> >
> > --
> > =-----------------= =
> > | Charles Sprickman Internet Channel |
> > | INCH System Administration Team (212)243-5200 |
> > | spork@inch.com access@inch.com |
> > = =----------------=
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the message.
> > For information on digests or retrieving files and old messages send
> > "help" to the same address. Do not use quotes in your message.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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) More than 10 DSPs in one HiperARC chassis From: Frank Basso <frank@got.net> Date: 1999-02-24 13:42:51
10 Cards to an ARC and the 70A power supply, to add more you will need a
second ARC, 7 DSP's per and the 130A power supply.
-----Original Message-----
>A 3com SE told me today that I would start to see major performance
>degredation if I lit up more than 10 DSPs in a HiperARC chassis
>and that I should put a second ARC card in it.
>
>Can anbody comment on whether this is true and how much of an
>issue it is? 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) More than 10 DSPs in one HiperARC chassis From: Frank Basso <frank@got.net> Date: 1999-02-24 13:57:50
The boys at 3Com have told me that the power supplies are redundant not load
balancing.
-Frank
-----Original Message-----
>Thus spake Frank Basso
>>10 Cards to an ARC and the 70A power supply, to add more you will need a
>>second ARC, 7 DSP's per and the 130A power supply.
>
>You could also just add a second 70A power supply...
>--
>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) More than 10 DSPs in one HiperARC chassis From: blann_firestone@3com.com Date: 1999-02-24 14:24:33
Here's the maximum amount of modems/routers that can go in each chassis:
HiPer based (DSP & ARC):
45 AMP - 6 DSPs, 1 ARC (144 sessions)
70 AMP - 10 DSPs, 2 ARCs (240 sessions)
130 AMP - 14 DSPs, 2 ARCs (336 sessions)
Mixed (DSPs w/ NETServers):
45 AMP - 4 DSPs, 1 NETServer (96 sessions)
70 AMP - 8 DSPs, 2 NETServers (192 sessions)
130 AMP - 12 DSPs, 3 NETServers (288 sessions)
Best regards...
Blann Firestone
3Com Carrier NC
"Frank Basso" <frank@got.net> on 02/24/99 01:42:51 PM
Please respond to usr-tc@lists.xmission.com
cc: (Blann Firestone/HQ/3Com)
10 Cards to an ARC and the 70A power supply, to add more you will need a
second ARC, 7 DSP's per and the 130A power supply.
-----Original Message-----
>A 3com SE told me today that I would start to see major performance
>degredation if I lit up more than 10 DSPs in a HiperARC chassis
>and that I should put a second ARC card in it.
>
>Can anbody comment on whether this is true and how much of an
>issue it is? 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) More than 10 DSPs in one HiperARC chassis From: Mark Lemmert <cto@athenet.net> Date: 1999-02-24 15:00:27
A 3com SE told me today that I would start to see major performance
degredation if I lit up more than 10 DSPs in a HiperARC chassis
and that I should put a second ARC card in it.
Can anbody comment on whether this is true and how much of an
issue it is? Thanks!
-Mark Lemmert AthEnet Data Exchange
Chief Technical Officer 888-919-8700
Subject:Re: (usr-tc) ISDN DOVBS HiperDSP or Quads From: Ray Whelan <ray_whelan@3com.com> Date: 1999-02-24 15:39:33
Hi Charles,
DOVBS protocol is currently in beta the release date is April ,the Hiper DSP
will support this application .
Ray Whelan
Net System
Dublin
Charles Sprickman <spork@inch.com> on 23/02/99 16:39:44
Please respond to usr-tc@lists.xmission.com
cc: (Ray Whelan/IE/3Com)
Hi,
This is mainly for the 3com folks reading the list, but if anyone else can
step forth and give a solid answer I'd be happy too...
Can the TCH equipment in any configuration do DOVBS? In NYC, you *are not
charged* per minute when you place an ISDN call as a "voice" call. This
is generally referred to here as "Data over Voice". All Ascend, Cisco,
and Lucent dial equipment supports this, so I find it hard to believe the
USR/3Com gear cannot.
So here's what I have: All chassis are Hiper ARC based with a mixture of
DSPs and Quad-I's. Can I do this on either/both of these modem cards?
What are the requirements?
Please, if you know, tell me! I'm pulling my hair out here!
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-24 16:46:53
Thus spake Frank Basso
>10 Cards to an ARC and the 70A power supply, to add more you will need a
>second ARC, 7 DSP's per and the 130A power supply.
You could also just add a second 70A power supply...
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
From one of our techs.
slack said once upon a time:
>From jhansen@xmission.com Wed Feb 24 14:59:08 1999
>Date: Wed, 24 Feb 1999 14:58:55 -0700
>From: slack <jhansen@xmission.com>
>To: techs@xmission.com
>Subject: ISDN Oddities...
>Message-ID: <19990224145854.B14992@xmission.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>X-Mailer: Mutt 0.95i
>
>Here is a monitor ppp session of a guy with an ISDN adaptor that is failing
>at the same point after about 176k has come over the line. The traffic will
>flow as usual, until it reaches this point, then all ip stops. He must
>disconnect and re-connect to fix it.
>
>This was from the number 9900901. He was unable to connect to 413-5100...
>Getting an error about LCP extensions... I couldn't even get any PPP call
>events from slc5-tc...
>
>The session follows...
>
>--
>--------------------------------------------------------------------------
>Jason Hansen jhansen@xmission.com
>
>
>--------------------------------------------------------------------
>Connection:
>--------------------------------------------------------------------
>Outgoing PPP Data on interface: slot:11/mod:21
> IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00
> NEW_ADDRS a6 46 01 29
>
>Incoming PPP Data on interface: slot:11/mod:21
> IPCP CFG_REQ NEW_ADDRS 00 00 00 00
> PRIM DNS c6 3c 16 02
> PRIM NBNS 00 00 00 00
> SEC DNS c6 3c 16 16
> SEC NBNS 00 00 00 00
>
>Outgoing PPP Data on interface: slot:11/mod:21
> IPCP CFG_REJ PRIM NBNS 00 00 00 00
> SEC DNS c6 3c 16 16
> SEC NBNS 00 00 00 00
>
>Incoming PPP Data on interface: slot:11/mod:21
> IPCP CFG_REJ COMPR_TYPE 00 2d 0f 00
>
>Outgoing PPP Data on interface: slot:11/mod:21
> IPCP CFG_REQ NEW_ADDRS a6 46 01 29
>
>Incoming PPP Data on interface: slot:11/mod:21
> IPCP CFG_REQ NEW_ADDRS 00 00 00 00
> PRIM DNS c6 3c 16 02
>
>Outgoing PPP Data on interface: slot:11/mod:21
> IPCP CFG_NAK NEW_ADDRS cf 87 80 61
> PRIM DNS c6 3c 16 16
>
>Incoming PPP Data on interface: slot:11/mod:21
> IPCP CFG_ACK NEW_ADDRS a6 46 01 29
>
>Incoming PPP Data on interface: slot:11/mod:21
> IPCP CFG_REQ NEW_ADDRS cf 87 80 61
> PRIM DNS c6 3c 16 16
>
>Outgoing PPP Data on interface: slot:11/mod:21
> IPCP CFG_ACK NEW_ADDRS cf 87 80 61
> PRIM DNS c6 3c 16 16
>
>Incoming PPP Data on interface: slot:11/mod:21
> CCP CFG_REQ STAC_COMP 00 01 03
>
>Outgoing PPP Data on interface: slot:11/mod:21
> CCP CFG_ACK STAC_COMP 00 01 03
>
>Outgoing PPP Data on interface: slot:11/mod:21
> CCP CFG_REQ STAC_COMP 00 01 03
>
>Incoming PPP Data on interface: slot:11/mod:21
> CCP CFG_ACK STAC_COMP 00 01 03
>
>
>---------------------------------------------------------------------
>When it fails:
>---------------------------------------------------------------------
>Incoming PPP Data on interface: slot:11/mod:21
> CCP RESET_REQ 00
> 01 2e 40 00 1f 06 ce 4c a6
> 46 7a 8f ce 40 7b 37 20
> 37 64 20 2e 2e 2e 0d 0a
> 60 81 61 62 63 64 65 66
> 67
>
>Outgoing PPP Data on interface: slot:11/mod:21
> CCP RESET_ACK 00
>
>Incoming PPP Data on interface: slot:11/mod:21
> 0000 00 00 00 00 39 00 00 00 00 00 5e 00 00 00 00 00 00 00 00 00 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> LCP PROT_REJ Unknown
>
>Outgoing PPP Data on interface: slot:11/mod:21
> IP_DATA 45 00 02 40 1b 34 40 00 74 06 86 a5 cb 78 47 7d cf 87 80 61 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> IP_DATA 45 00 02 40 1c 34 40 00 74 06 85 a5 cb 78 47 7d cf 87 80 61 ...
>
>Incoming PPP Data on interface: slot:11/mod:21
> 0000 00 00 00 00 3a 00 00 00 00 00 5d 00 00 00 00 00 00 00 00 00 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> LCP PROT_REJ Unknown
>
>Incoming PPP Data on interface: slot:11/mod:21
> 0000 00 00 00 00 3b 00 00 00 00 00 5c 00 00 00 00 00 00 00 00 00 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> LCP PROT_REJ Unknown
>
>Incoming PPP Data on interface: slot:11/mod:21
> 0000 00 00 00 00 3c 00 00 00 00 00 5b 00 00 00 00 00 00 00 00 00 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> LCP PROT_REJ Unknown
>
>Incoming PPP Data on interface: slot:11/mod:21
> 0000 00 00 00 00 3d 00 00 00 00 00 5a 00 00 00 00 00 00 00 00 00 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> LCP PROT_REJ Unknown
>
>Incoming PPP Data on interface: slot:11/mod:21
> 0000 00 00 00 00 3e 00 00 00 00 00 59 00 00 00 00 00 00 00 00 00 ...
>
>Outgoing PPP Data on interface: slot:11/mod:21
> LCP PROT_REJ Unknown
>
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-24 17:01:55
Thus spake Frank Basso
>The boys at 3Com have told me that the power supplies are redundant not load
>balancing.
Uhm...the boys at 3Com told you wrong then.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) ISDN DOVBS HiperDSP or Quads From: Ray Whelan <ray_whelan@3com.com> Date: 1999-02-24 17:11:44
I have read the functional spec on TCS35 on DOVBS and PRI is also supported.
Ray Whelan.
"Ray Whelan" <Ray_Whelan@3com.com> on 24/02/99 15:39:33
Please respond to usr-tc@lists.xmission.com
cc: (Ray Whelan/IE/3Com)
Hi Charles,
DOVBS protocol is currently in beta the release date is April ,the Hiper DSP
will support this application .
Ray Whelan
Net System
Dublin
Charles Sprickman <spork@inch.com> on 23/02/99 16:39:44
Please respond to usr-tc@lists.xmission.com
cc: (Ray Whelan/IE/3Com)
Hi,
This is mainly for the 3com folks reading the list, but if anyone else can
step forth and give a solid answer I'd be happy too...
Can the TCH equipment in any configuration do DOVBS? In NYC, you *are not
charged* per minute when you place an ISDN call as a "voice" call. This
is generally referred to here as "Data over Voice". All Ascend, Cisco,
and Lucent dial equipment supports this, so I find it hard to believe the
USR/3Com gear cannot.
So here's what I have: All chassis are Hiper ARC based with a mixture of
DSPs and Quad-I's. Can I do this on either/both of these modem cards?
What are the requirements?
Please, if you know, tell me! I'm pulling my hair out here!
Thanks,
Charles
--
=-----------------= =
| Charles Sprickman Internet Channel |
| INCH System Administration Team (212)243-5200 |
| spork@inch.com access@inch.com |
= =----------------=
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
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) More than 10 DSPs in one HiperARC chassis From: Ronald E. Kushner <ron@glis.net> Date: 1999-02-24 17:16:48
Frank Basso wrote:
>
> The boys at 3Com have told me that the power supplies are redundant not load
> balancing.
This is out of the Documentation Library System Release 3.1:
> Product Description PSUs take the chassis AC or DC input power and convert it to DC
> voltages required by the cards in the chassis. The chassis supports
> up to two PSUs for redundancy and load sharing.
>
> A second PSU is optional, but strongly recommended for a fully loaded
> chassis.
>
> PSUs are available in both AC and DC versions. Verify that you have
> received the correct version by checking the silk-screen label on the front
> panel. Also, notice that the DC PSU does not have a line voltage strap.
I would assume reading this that load balancing and load sharing pretty much
means the same thing.
On the older 35/45 power supplies, if you fully loaded a chassis, you lost
your redundant power supply and the chassis couldn't run on just one power
supply.
-Ron
GLISnet, Inc.
+1 810/939.9885
On Tue, 23 Feb 1999, Carl Litt wrote:
>
> What are the various debug tools included in the cards? I know
> there are undocumented commands on the DSP console, and there is
> at least one hidden menu on the Dual-T1 card. We should start
> a repository for this stuff.
>
> There are a lot of times I'm working with a problem chassis, just
> wishing for more information. I know it's there. I've heard the
> 3Com tech people mumble debugging output to themselves. I want
> to see it.
Debug in readable form is available mostly only on the hiper arc. The
HIper dsp does not give you any meaningful info - it can dump hex data
and then you can debug the same.
To enable the trace you need to be on the console of the dsp.
You can then go to a modem and issue modem 'at ' commands for modem debug
info. Like a ati6 will tell you what was the disconnection reason etc.
and on the span level you can debug
for your problem a typically you can use this debug command to see if you
are getting any info from the switch
chdev span
tra deb 25 2
When a call comes in you will see the info - now you can use the pridebug
program to convert the hex into the q93 info etc.
to turn off debug the command is
tra off
krish
>
> In particular, I'm having problems with fast busies on Dual-T1
> cards with HARC and 2 DSP's in the chassis too. The telco is 100%
> sure the T1's are OK, and I tend to side with them in this case.
> They worked fine before.
>
> I would much rather filter useless information than get frustrated
> over the lack of it (much as I do now).
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
What client is your customer using? Also what version of hiper arc 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 Wed, 24 Feb 1999, Pete Ashdown wrote:
> >From one of our techs.
>
>
> slack said once upon a time:
> >From jhansen@xmission.com Wed Feb 24 14:59:08 1999
> >Date: Wed, 24 Feb 1999 14:58:55 -0700
> >From: slack <jhansen@xmission.com>
> >To: techs@xmission.com
> >Subject: ISDN Oddities...
> >Message-ID: <19990224145854.B14992@xmission.com>
> >Mime-Version: 1.0
> >Content-Type: text/plain; charset=us-ascii
> >X-Mailer: Mutt 0.95i
> >
> >Here is a monitor ppp session of a guy with an ISDN adaptor that is failing
> >at the same point after about 176k has come over the line. The traffic will
> >flow as usual, until it reaches this point, then all ip stops. He must
> >disconnect and re-connect to fix it.
> >
> >This was from the number 9900901. He was unable to connect to 413-5100...
> >Getting an error about LCP extensions... I couldn't even get any PPP call
> >events from slc5-tc...
> >
> >The session follows...
> >
> >--
> >--------------------------------------------------------------------------
> >Jason Hansen jhansen@xmission.com
> >
> >
> >--------------------------------------------------------------------
> >Connection:
> >--------------------------------------------------------------------
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00
> > NEW_ADDRS a6 46 01 29
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REQ NEW_ADDRS 00 00 00 00
> > PRIM DNS c6 3c 16 02
> > PRIM NBNS 00 00 00 00
> > SEC DNS c6 3c 16 16
> > SEC NBNS 00 00 00 00
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REJ PRIM NBNS 00 00 00 00
> > SEC DNS c6 3c 16 16
> > SEC NBNS 00 00 00 00
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REJ COMPR_TYPE 00 2d 0f 00
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REQ NEW_ADDRS a6 46 01 29
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REQ NEW_ADDRS 00 00 00 00
> > PRIM DNS c6 3c 16 02
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IPCP CFG_NAK NEW_ADDRS cf 87 80 61
> > PRIM DNS c6 3c 16 16
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > IPCP CFG_ACK NEW_ADDRS a6 46 01 29
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > IPCP CFG_REQ NEW_ADDRS cf 87 80 61
> > PRIM DNS c6 3c 16 16
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IPCP CFG_ACK NEW_ADDRS cf 87 80 61
> > PRIM DNS c6 3c 16 16
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > CCP CFG_REQ STAC_COMP 00 01 03
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > CCP CFG_ACK STAC_COMP 00 01 03
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > CCP CFG_REQ STAC_COMP 00 01 03
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > CCP CFG_ACK STAC_COMP 00 01 03
> >
> >
> >---------------------------------------------------------------------
> >When it fails:
> >---------------------------------------------------------------------
> >Incoming PPP Data on interface: slot:11/mod:21
> > CCP RESET_REQ 00
> > 01 2e 40 00 1f 06 ce 4c a6
> > 46 7a 8f ce 40 7b 37 20
> > 37 64 20 2e 2e 2e 0d 0a
> > 60 81 61 62 63 64 65 66
> > 67
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > CCP RESET_ACK 00
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > 0000 00 00 00 00 39 00 00 00 00 00 5e 00 00 00 00 00 00 00 00 00 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > LCP PROT_REJ Unknown
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IP_DATA 45 00 02 40 1b 34 40 00 74 06 86 a5 cb 78 47 7d cf 87 80 61 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > IP_DATA 45 00 02 40 1c 34 40 00 74 06 85 a5 cb 78 47 7d cf 87 80 61 ...
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > 0000 00 00 00 00 3a 00 00 00 00 00 5d 00 00 00 00 00 00 00 00 00 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > LCP PROT_REJ Unknown
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > 0000 00 00 00 00 3b 00 00 00 00 00 5c 00 00 00 00 00 00 00 00 00 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > LCP PROT_REJ Unknown
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > 0000 00 00 00 00 3c 00 00 00 00 00 5b 00 00 00 00 00 00 00 00 00 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > LCP PROT_REJ Unknown
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > 0000 00 00 00 00 3d 00 00 00 00 00 5a 00 00 00 00 00 00 00 00 00 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > LCP PROT_REJ Unknown
> >
> >Incoming PPP Data on interface: slot:11/mod:21
> > 0000 00 00 00 00 3e 00 00 00 00 00 59 00 00 00 00 00 00 00 00 00 ...
> >
> >Outgoing PPP Data on interface: slot:11/mod:21
> > LCP PROT_REJ 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) More than 10 DSPs in one HiperARC chassis From: Marshall Morgan <marshall@netdoor.com> Date: 1999-02-24 23:51:58
On Wednesday, February 24, 1999 4:25 PM, Blann_Firestone@3com.com
[SMTP:Blann_Firestone@3com.com] wrote:
>
> Here's the maximum amount of modems/routers that can go in each chassis:
>
> HiPer based (DSP & ARC):
> 45 AMP - 6 DSPs, 1 ARC (144 sessions)
> 70 AMP - 10 DSPs, 2 ARCs (240 sessions)
> 130 AMP - 14 DSPs, 2 ARCs (336 sessions)
For clarity:
(2) 70 AMP - 1 NMC, 14 DSPs, 2 ARCs (336 sessions)
Is that OK?
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) geo-book connect From: Ray Bagby <rbagby@yore.net> Date: 1999-02-25 01:21:21
Greetings,
I am having trouble connecting a client who is using a Brother Geo-Book.
I'm using a TC chassis with HiPer ARC and DSP. No trouble with Anyone before
this. The Brother folks say I need to assign IP and mask and gateway but I
work with a pool.
Anyone have a suggestion?
Thanks
Tatai SV Krishnan was heard to say:
>Debug in readable form is available mostly only on the hiper arc. The
And what kind of debug stuff can one get from the ARC (and how?)
>and on the span level you can debug
>for your problem a typically you can use this debug command to see if you
>are getting any info from the switch
>
>chdev span
>
>tra deb 25 2
FWIW, not with the latest beta DSP code... (2.0.15)
[root@liberty] ~ [2:26am]:telnet 199.72.1.251 8015
Trying 199.72.1.251...
Connected to 199.72.1.251.
Escape character is '^]'.
Interpath Communications, Inc.
dsp:15 Login: noc
Password:
Console Password:
> chdev span
span1> tra deb 25 2
tra is not a valid command
usage: help display|set|chdev|dump|probe|trc
Valid HELP sub-commands are:
chdev - Change device/command prompt level
clear - Clear parameter
cmd - Execute a command
date - Display system time/date
display - Display parameters
help - List valid commands
quit - Quit console interface
reboot - Reboot card
rmt - Set/Display remote console settings
set - Set parameter
uptime - Show system uptime
version - Show version
span1>
There is 'trc' but that's not exactly the same type of output.
--Ricky
PS: The telnet-to-the-console thing is a neat trick :-)
Where can I find the pridebug program? Does it only works for E1/R2
signaling too or just PRI?
On Wed, 24 Feb 1999, Tatai SV Krishnan wrote:
> When a call comes in you will see the info - now you can use the pridebug
> program to convert the hex into the q93 info etc.
>
Jose Roberto Bulcao - RioLink Internet
Tel : (021) 577-8899
e-mail : bulcao@rio.com.br
Carl and others,
Debug information is covered in the ISP Network Management Guide, which is
buried in the Totalservice web site.
I don't believe you need to log in for this.
Go here http://totalservice.3com.com/
Click Documentation Library.
As the search term, type ISP;
ALL Documentation types
ALL Product families
Click Start Search.
The file is ispmgt.pdf.
Hope it helps. Would love to get your feedback.
Jim Curran
> > >Incoming PPP Data on interface: slot:11/mod:21
> > > 0000 00 00 00 00 39 00 00 00 00 00 5e 00 00 00 00 00 00 00 00 00 ...
> > >
> > >Outgoing PPP Data on interface: slot:11/mod:21
> > > LCP PROT_REJ Unknown
We've seen this happen on ISDN as well. A customer using a Shiva
Access port firmware 2.1 and STAC compression.
Turning STAC off seems to solve the problem - but its not the
solution.
Rick
Subject:RE: (usr-tc) Debug codes From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-25 09:45:42
Is this also valid for E1-PRI ? I had a hell of a time setting up a DSP =
from
one carrier to another (one using Ericsson switches, the other uses =
Siemens
EWSD) and q931 messages would have been very helpful
Thanks for any info
Robert
> -----Original Message-----
> From: Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com]
> Sent: jeudi, 25. f=E9vrier 1999 03:51
> To: Carl Litt
> Cc: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Debug codes
>=20
> On Tue, 23 Feb 1999, Carl Litt wrote:
>=20
> >=20
> > What are the various debug tools included in the cards? I know
> > there are undocumented commands on the DSP console, and there is
> > at least one hidden menu on the Dual-T1 card. We should start
> > a repository for this stuff.
> >=20
> > There are a lot of times I'm working with a problem chassis, just
> > wishing for more information. I know it's there. I've heard the
> > 3Com tech people mumble debugging output to themselves. I want
> > to see it.
>=20
> Debug in readable form is available mostly only on the hiper arc. =
The=20
> HIper dsp does not give you any meaningful info - it can dump hex =
data=20
> and then you can debug the same. =20
>=20
> To enable the trace you need to be on the console of the dsp.
> You can then go to a modem and issue modem 'at ' commands for modem =
debug=20
> info. Like a ati6 will tell you what was the disconnection reason =
etc.
>=20
> and on the span level you can debug=20
> for your problem a typically you can use this debug command to see if =
you=20
> are getting any info from the switch
>=20
> chdev span
>=20
> tra deb 25 2
>=20
> When a call comes in you will see the info - now you can use the =
pridebug=20
> program to convert the hex into the q93 info etc.
>=20
> to turn off debug the command is
>=20
> tra off
>=20
> krish
>=20
> >=20
> > In particular, I'm having problems with fast busies on Dual-T1
> > cards with HARC and 2 DSP's in the chassis too. The telco is 100%
> > sure the T1's are OK, and I tend to side with them in this case.
> > They worked fine before.
> >=20
> > I would much rather filter useless information than get frustrated
> > over the lack of it (much as I do now).
> >=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.
--0__=Z25BiRfWMJenxtMX1xHH91yIIGxhmGnuXEC6dFK3csfaxfEKUuDZ4IWn
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
AT -DF25,3 to enable
AT -DF25,0 to turn off
Ray W
Robert von Bismarck <rvb@petrel.ch> on 25/02/99 08:45:42
Please respond to usr-tc@lists.xmission.com
cc: (Ray Whelan/IE/3Com)
--0__=Z25BiRfWMJenxtMX1xHH91yIIGxhmGnuXEC6dFK3csfaxfEKUuDZ4IWn
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
Is this also valid for E1-PRI ? I had a hell of a time setting up a DSP=
from
one carrier to another (one using Ericsson switches, the other uses Sie=
mens
EWSD) and q931 messages would have been very helpful
Thanks for any info
Robert
> -----Original Message-----
> From: Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com]
> Sent: jeudi, 25. f=E9vrier 1999 03:51
> To: Carl Litt
> Cc: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) Debug codes
>
> On Tue, 23 Feb 1999, Carl Litt wrote:
>
> >
> > What are the various debug tools included in the cards? I know
> > there are undocumented commands on the DSP console, and there is
> > at least one hidden menu on the Dual-T1 card. We should start
> > a repository for this stuff.
> >
> > There are a lot of times I'm working with a problem chassis, just
> > wishing for more information. I know it's there. I've heard the
> > 3Com tech people mumble debugging output to themselves. I want
> > to see it.
>
> Debug in readable form is available mostly only on the hiper arc. Th=
e
> HIper dsp does not give you any meaningful info - it can dump hex dat=
a
> and then you can debug the same.
>
> To enable the trace you need to be on the console of the dsp.
> You can then go to a modem and issue modem 'at ' commands for modem d=
ebug
> info. Like a ati6 will tell you what was the disconnection reason et=
c.
>
> and on the span level you can debug
> for your problem a typically you can use this debug command to see if=
you
> are getting any info from the switch
>
> chdev span
>
> tra deb 25 2
>
> When a call comes in you will see the info - now you can use the prid=
ebug
> program to convert the hex into the q93 info etc.
>
> to turn off debug the command is
>
> tra off
>
> krish
>
> >
> > In particular, I'm having problems with fast busies on Dual-T1
> > cards with HARC and 2 DSP's in the chassis too. The telco is 100%
> > sure the T1's are OK, and I tend to side with them in this case.
> > They worked fine before.
> >
> > I would much rather filter useless information than get frustrated
> > over the lack of it (much as I do now).
> >
> > -
> > To unsubscribe to usr-tc, send an email 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.
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
=
--0__=Z25BiRfWMJenxtMX1xHH91yIIGxhmGnuXEC6dFK3csfaxfEKUuDZ4IWn--
Subject:RE: (usr-tc) MRTG for Totalcontrol chassis. From: Eric Billeter <ebilleter@cableone.net> Date: 1999-02-25 10:19:16
If you look at the status of the DS0's in TCM
Select Span
Performance Counters
Timeslot
Select All
Timeslot Status Group
Under Timeslot Status they will show up as Idle, Dialing In,
Connected In, DS0 Out of Service,
DS0 Dchannel etc.
The scripts interpret normal codes (Idle, Connected, Connecting etc)
to increment capacity.. if the DS0 is out of service, Dchannel
or maintenance mode, it will not increment capacity.
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 Phil Dye
Sent: Wednesday, February 17, 1999 3:43 AM
On Tue, Feb 16, 1999 at 01:42:39PM -0700, Eric Billeter wrote:
> For Dual PRI or Dual T1 cards use
>
> http://www.cableone.net/ebilleter/dualpri.pl
>
[snip]
> If it works for you let me know.. if not let me know too.
It kinda works...
I'm a bit confused what the second figure (capacity) is supposed to
represent; no matter which chassis I run it on, I always get 44, which
doesn't seem to bear any relation to available channels (each chassis
is different, as we don't use full PRI's on some chassis).
--
Phil Dye | Work: pmd@tcp.net.uk
Network Manager | Play: phil@dye.net ICQ: 21191147
Total Connectivity Providers | Consider myself properly disclaimed
"The team building will continue until morale improves" - simes
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
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) Preferences in RADIUS servers From: David Cartwright <david_cartwright@mw.3com.com> Date: 1999-02-25 10:55:54
Do you use RADIUS in your remote access environment? We're taking a
poll to better understand your preferences in RADIUS servers. Please
take a few moments (it shouldn't take anymore than a minute or two) and
complete the survey located at:
http://totalservice.3com.com/radius.html
Thanks in advance for your time and feedback.
Dave
3Com Customer Support
Subject:RE: (usr-tc) More than 10 DSPs in one HiperARC chassis From: blann_firestone@3com.com Date: 1999-02-25 10:57:01
Marshall,
This configuration requires 130 AMP power supplies.
Blann
Marshall Morgan <marshall@netdoor.com> on 02/24/99 09:51:58 PM
Please respond to usr-tc@lists.xmission.com
cc: (Blann Firestone/HQ/3Com)
On Wednesday, February 24, 1999 4:25 PM, Blann_Firestone@3com.com
[SMTP:Blann_Firestone@3com.com] wrote:
>
> Here's the maximum amount of modems/routers that can go in each chassis:
>
> HiPer based (DSP & ARC):
> 45 AMP - 6 DSPs, 1 ARC (144 sessions)
> 70 AMP - 10 DSPs, 2 ARCs (240 sessions)
> 130 AMP - 14 DSPs, 2 ARCs (336 sessions)
For clarity:
(2) 70 AMP - 1 NMC, 14 DSPs, 2 ARCs (336 sessions)
Is that OK?
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
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
At 09:01 AM 2/25/99 -0600, you wrote:
>
>Debug information is covered in the ISP Network Management Guide, which is
>buried in the Totalservice web site.
>
>
>The file is ispmgt.pdf.
Can this be gotten via FTP, so I don't have to print it out via browser?
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) More than 10 DSPs in one HiperARC chassis From: Curt Shambeau <curt@execpc.com> Date: 1999-02-25 13:18:24
> This configuration requires 130 AMP power supplies.
Ok, that's what 3COM's official responce is, but now I'll tell you I've
had a dual 70A chassis running with 14DSPs+2ARCs for over a year with no
problems at all. And yes, it will run off a single 70A supply as well,
although I have never tested it for more than 5 minutes or so.
> Marshall Morgan <marshall@netdoor.com> on 02/24/99 09:51:58 PM
>
> Please respond to usr-tc@lists.xmission.com
>
> To: "'usr-tc @lists.xmission.com'" <usr-tc@lists.xmission.com>
> cc: (Blann Firestone/HQ/3Com)
> Subject: RE: (usr-tc) More than 10 DSPs in one HiperARC chassis
>
>
>
>
> On Wednesday, February 24, 1999 4:25 PM, Blann_Firestone@3com.com
> [SMTP:Blann_Firestone@3com.com] wrote:
> >
> > Here's the maximum amount of modems/routers that can go in each chassis:
> >
> > HiPer based (DSP & ARC):
> > 45 AMP - 6 DSPs, 1 ARC (144 sessions)
> > 70 AMP - 10 DSPs, 2 ARCs (240 sessions)
> > 130 AMP - 14 DSPs, 2 ARCs (336 sessions)
>
> For clarity:
>
> (2) 70 AMP - 1 NMC, 14 DSPs, 2 ARCs (336 sessions)
>
> Is that OK?
>
> 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
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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.
>
| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt |
| Senior Vice President - Exec-PC, Inc. |
We have four Total Control chassis in our office. All our Quad modem
cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
current versions of the software.
We upgraded one of the chassis with one Hiper Router and Hiper DSP card
(removing the NETserver card). Once we did this most of our customers are
able to dial into that chassis and connect. We originally had all the
chassis configured to prompt for "host". This new chassis is not prompting
for this information. Where would we set this up? What is the command?
Taino Johnston
Manager, Technical Support
Access Internet Communications
+----------------------------------------------------------------+
| Taino d Johnston | Phone: (408) 777-8190 |
| Manager, Technical Support | Tech Support: (408) 342-0551 |
| | Fax: (408) 777-8191 |
| Access Internet Communications | http://www.accesscom.com/ |
| tdj@accesscom.com | support@accesscom.com |
+----------------------------------------------------------------+
On Thu, 25 Feb 1999, Jim Curran wrote:
> Carl and others,
>
> Debug information is covered in the ISP Network Management Guide, which is
> buried in the Totalservice web site.
Thanks for the doc! I'd love to see more good info like this, it's a
really helpful reference. When's version 1.1 come out? :)
Here's the direct link: ftp://totalservice.usr.com/pub/.docs/ispmgt.pdf
Thanks,
Charles
> I don't believe you need to log in for this.
>
> Go here http://totalservice.3com.com/
>
> Click Documentation Library.
>
> As the search term, type ISP;
> ALL Documentation types
> ALL Product families
>
> Click Start Search.
>
> The file is ispmgt.pdf.
>
> Hope it helps. Would love to get your feedback.
>
> Jim Curran
>
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) More than 10 DSPs in one HiperARC chassis From: Curt Shambeau <curt@execpc.com> Date: 1999-02-25 13:49:04
> Thus spake Curt Shambeau
> >> This configuration requires 130 AMP power supplies.
>
> >Ok, that's what 3COM's official responce is, but now I'll tell you I've
> >had a dual 70A chassis running with 14DSPs+2ARCs for over a year with no
> >problems at all. And yes, it will run off a single 70A supply as well,
> >although I have never tested it for more than 5 minutes or so.
>
> Heh...wups...I saw 3Com walking in to that one.
>
> How about this one?
>
> Why does the NETServer have a problem with Quake Lag? ;)
>
> Maybe, if we keep this up, 3Com will learn to be upfront with their
> customers instead of trying to screw them out of more money all the
> time.
Having never run my dual-70A chassis for any length of time on just one of
the power supplies, I'm not sure they are trying to screw anyone. The
chassis in question is in my main NOC. If it was at a remote POP, I
wouldn't trust it with the 70A supplies - I would upgrade it to 130 right
away. In any case, all my other fully loaded chassis have dual 130's,
just to be safe... <grin>
| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt |
| Senior Vice President - Exec-PC, Inc. |
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-25 14:29:08
Thus spake Curt Shambeau
>> This configuration requires 130 AMP power supplies.
>Ok, that's what 3COM's official responce is, but now I'll tell you I've
>had a dual 70A chassis running with 14DSPs+2ARCs for over a year with no
>problems at all. And yes, it will run off a single 70A supply as well,
>although I have never tested it for more than 5 minutes or so.
Heh...wups...I saw 3Com walking in to that one.
How about this one?
Why does the NETServer have a problem with Quake Lag? ;)
Maybe, if we keep this up, 3Com will learn to be upfront with their
customers instead of trying to screw them out of more money all the
time.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Our first problem is with the Hiper card is with the
'interfaces.ifNumber.0' snmp variable. With all other terminal servers
(including USR TC chassis) and I believe according to snmp specs, this
lists only active interfaces. On the hypercards it lists all possible
interfaces, so via snmp there is no way to determine how many modems are in
use.
We also don't know where to get the snmp mib for this device, maybe USR has
implemented an alternative method for getting this info, but without the
mib we'll never know.
Taino Johnston
Manager, Technical Support
Access Internet Communications
+----------------------------------------------------------------+
| Taino d Johnston | Phone: (408) 777-8190 |
| Manager, Technical Support | Tech Support: (408) 342-0551 |
| | Fax: (408) 777-8191 |
| Access Internet Communications | http://www.accesscom.com/ |
| tdj@accesscom.com | support@accesscom.com |
+----------------------------------------------------------------+
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Curt Shambeau <curt@execpc.com> Date: 1999-02-25 14:39:42
> They probably aren't in this case...at least not much...but let's face
> it...assuming these power supplies load-share (which I'm all but
> absolutely positive they do), these things *should* have more excess
> power available to them running on dual-70's than a single-130.
I'm positive they load share - I plug each power supply into a seperate
UPS. Turn them both on, there is load on each UPS.
> FWIW, I *have* run a dual-PRI, 12 quads, 2 DSP's, a NETServer and an NMC
> with a single 70 for an extended period of time with no problems. The
> mitigating factor here is that I never had more than 46 ports in use at
> any one time (since modems use less power at idle than they do when in
> use...also explains why the NETServer had decent performance with that
> setup).
I did this on over 40 chassis - full 96 calls on a box with no problems at
all. I believe it is rated to do this in 70A.
> Anyway...at the very least, I'd say that their estimates of power
> consumption are quite conservative to say the least, and alone, I
> wouldn't make much of that, but given other examples of 3Com trying to
> make people pay for stuff when they shouldn't have to (x2/v.90 enable
> keys from my previous rant, I'll proly post soon about our ordeals with
> MPIP again as another example of this), I tend to start thinking that
> 3Com is intentionally screwing over their customer for short term
> gains...even sacrificing long-term customer happiness in the process.
> I'd say this is *extremely* short sighted of 3Com, and hope they soon
> have a change of heart.
I personally feel it's just a CYA on their part. It may be close with a
single 70A, in which case, if one fails, the other 70A would take all the
load, and may not make it.
| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt |
| Senior Vice President - Exec-PC, Inc. |
We recently purchased a Total Control Rack with X2. How can I confirm that
the NMC has the X2 feature?
Thanks.
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-25 15:10:21
Thus spake Curt Shambeau
>Having never run my dual-70A chassis for any length of time on just one of
>the power supplies, I'm not sure they are trying to screw anyone.
They probably aren't in this case...at least not much...but let's face
it...assuming these power supplies load-share (which I'm all but
absolutely positive they do), these things *should* have more excess
power available to them running on dual-70's than a single-130.
Then you consider the possibility that it *might* even run OK on a
single-70 (I know...you haven't tested it out for long and I really
can't blame you), then it starts to sound like they're trying to get us
to buy more than necessary.
FWIW, I *have* run a dual-PRI, 12 quads, 2 DSP's, a NETServer and an NMC
with a single 70 for an extended period of time with no problems. The
mitigating factor here is that I never had more than 46 ports in use at
any one time (since modems use less power at idle than they do when in
use...also explains why the NETServer had decent performance with that
setup).
Anyway...at the very least, I'd say that their estimates of power
consumption are quite conservative to say the least, and alone, I
wouldn't make much of that, but given other examples of 3Com trying to
make people pay for stuff when they shouldn't have to (x2/v.90 enable
keys from my previous rant, I'll proly post soon about our ordeals with
MPIP again as another example of this), I tend to start thinking that
3Com is intentionally screwing over their customer for short term
gains...even sacrificing long-term customer happiness in the process.
I'd say this is *extremely* short sighted of 3Com, and hope they soon
have a change of heart.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Actually our dial-up users should be prompted for three things:
host:
login:
password:
What we need to do is add the host prompt before the login prompt.
Taino Johnston
Manager, Technical Support
Access Internet Communications
At 4:52 PM -0600 2/25/99, Tatai SV Krishnan wrote:
>On Thu, 25 Feb 1999, Taino Johnston wrote:
>
>> We have four Total Control chassis in our office. All our Quad modem
>> cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
>> current versions of the software.
>>
>> We upgraded one of the chassis with one Hiper Router and Hiper DSP card
>> (removing the NETserver card). Once we did this most of our customers are
>> able to dial into that chassis and connect. We originally had all the
>> chassis configured to prompt for "host". This new chassis is not prompting
>> for this information. Where would we set this up? What is the command?
>
>You can use chat scripts on the hiper arc to do this exact function on
>the hiper arc.
>
>Need to understand how your users were setup on the NETServer. Meaning
>
>case 1
>
>When a user dials in if you are looking for the prompt
>host:
>
>instead of a login:
>And then the user does plain authentication then you have to just change
>the login prompt on the hiper arc.
>
>case 2:
>
>By setting the netserver to host and by setting security off the
>netserver would prompt for a host but if the user starts ppp it will do
>ppp else you ask the user to type the host ip address and telnet to it.
>
>For this you need to use chat scripts
>
>krish
>
>
>>
>> Taino Johnston
>> Manager, Technical Support
>> Access Internet Communications
>> +----------------------------------------------------------------+
>> | Taino d Johnston | Phone: (408) 777-8190 |
>> | Manager, Technical Support | Tech Support: (408) 342-0551 |
>> | | Fax: (408) 777-8191 |
>> | Access Internet Communications | http://www.accesscom.com/ |
>> | tdj@accesscom.com | support@accesscom.com |
>> +----------------------------------------------------------------+
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the message.
>> For information on digests or retrieving files and old messages send
>> "help" to the same address. Do not use quotes in your message.
>>
+----------------------------------------------------------------+
| Taino d Johnston | Phone: (408) 777-8190 |
| Manager, Technical Support | Tech Support: (408) 342-0551 |
| | Fax: (408) 777-8191 |
| Access Internet Communications | http://www.accesscom.com/ |
| tdj@accesscom.com | support@accesscom.com |
+----------------------------------------------------------------+
Yes I am making reference to our dial-up users. They should be
prompted for three things:
host:
login:
password:
What we need to do is add the host prompt before the login prompt.
Taino Johnston
Manager, Technical Support
Access Internet Communications
At 5:48 PM -0500 2/25/99, D P Kern wrote:
<excerpt>Taino,
Saw your post on the user forum. We run several TCH with Hiper and
I'm familiar with the Netserver also. When you say it does'nt prompt
for host are you talking about dial-in users? Prompt for host meaning
authentication prompt, user ID, password, etc. If you could clarify
what you mean by prompt for host I probably could help you out pretty
quick. E-mail me or call 717-337-2424 and I'll try to help you out.
We switched from Netserver to Hiper about a year ago and I've spent
considerable time on HiperArc commands.
Dennis P. Kern
Wide Open Communications
</excerpt>
+----------------------------------------------------------------+
| Taino d Johnston | Phone: (408) 777-8190 |
| Manager, Technical Support | Tech Support: (408) 342-0551 |
| | Fax: (408) 777-8191 |
| Access Internet Communications | http://www.accesscom.com/ |
| tdj@accesscom.com | support@accesscom.com |
+----------------------------------------------------------------+
We upgraded the memory for the NMC card when installing the HiPer Router
and DSP card. Those are the only changes we made. Now we are constantly
getting 75 connections from this chassis. We get this whether there have 1
or 69 (three PRI lines) connections to this chassis.
Taino Johnston
Manager, Technical Support
Access Internet Communications
At 5:03 PM -0600 2/25/99, Paul Jr. (AlaWeb Support) wrote:
>You would get this information from the NMC card.. I am assumeing your
>talking about something like this
>http://netman.alaweb.com/mrtg/all-andalusia.html
>
>Thanks
>Paul JR.
>AlaWeb Network Admin.
>1800-427-8896
>http://www.alaweb.com/support.html
>
>
>
>
>----- Original Message -----
>From: Taino Johnston <usr-list@accesscom.com>
>To: <usr-tc@lists.xmission.com>
>Sent: Thursday, February 25, 1999 4:31 PM
>Subject: (usr-tc) Hiper card SNMP settings
>
>
>>Our first problem is with the Hiper card is with the
>>'interfaces.ifNumber.0' snmp variable. With all other terminal servers
>>(including USR TC chassis) and I believe according to snmp specs, this
>>lists only active interfaces. On the hypercards it lists all possible
>>interfaces, so via snmp there is no way to determine how many modems are in
>>use.
>>
>>We also don't know where to get the snmp mib for this device, maybe USR has
>>implemented an alternative method for getting this info, but without the
>>mib we'll never know.
>>
>>Taino Johnston
>>Manager, Technical Support
>>Access Internet Communications
>>+----------------------------------------------------------------+
>>| Taino d Johnston | Phone: (408) 777-8190 |
>>| Manager, Technical Support | Tech Support: (408) 342-0551 |
>>| | Fax: (408) 777-8191 |
>>| Access Internet Communications | http://www.accesscom.com/ |
>>| tdj@accesscom.com | support@accesscom.com |
>>+----------------------------------------------------------------+
>>
>>-
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the message.
>> For information on digests or retrieving files and old messages send
>> "help" to the same address. Do not use quotes in your message.
>>
+----------------------------------------------------------------+
| Taino d Johnston | Phone: (408) 777-8190 |
| Manager, Technical Support | Tech Support: (408) 342-0551 |
| | Fax: (408) 777-8191 |
| Access Internet Communications | http://www.accesscom.com/ |
| tdj@accesscom.com | support@accesscom.com |
+----------------------------------------------------------------+
Subject:(usr-tc) USR Reseller From: Tony Loosle <tony@tcsourceone.com> Date: 1999-02-25 15:23:31
Is there any USRobotics resellers on this list??
I have been trying to buy an upgrade to the usr radius software and no
one at USR can help. They say I need a support contract. Ok, sell me a
support contract for the software, but then USR can't even get me with
someone who knows how to sell it to me.
I really need the new version as soon as possible, any help would be
appreciated!!
Tony
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-25 15:39:39
Jeff Mcadams was heard to say:
>Why does the NETServer have a problem with Quake Lag? ;)
Umm, because it's not a portmaster but it's running portmaster code.
(Crowbared into place by a few monkeys on loan from the local zoo?)
>Maybe, if we keep this up, 3Com will learn to be upfront with their
>customers instead of trying to screw them out of more money all the
>time.
Well, if they charged people what the @$@%% equipment costs to make
and sell instead of selling everything at a 50% discount.
And speaking of "screw[ing] them"... I was just thinking about that
4500$ hardware service contract _per_ *chassis*. If your chassis is
filled with quad modems, then you are indeed being screwed with a
very big d***. But if the chassis has 14DSPs, 2 ARCs, a HNMC, and
two 130A PSen, then it's damn good deal :-) (That's ~215k$US list.)
They _should_ charge per device (card, power supply, midplane, etc.)
instead of per rack unit. (Of course, that's one hell of a paperwork
nightmare in serial numbers.)
--Ricky
On Wed, Feb 24, 1999 at 01:35:48PM -0600, Tatai SV Krishnan wrote:
> Setup and configuration info for setting up dovbs on the pri/quad is as
> follows
>
>
> Data over voice bearer service (DOVBS) on the dual pri card
>
> should be attempted with pri code 3.02 (tcs 3.0) or higher. The setup
> process is as follows:
>
> 1. Setup the default gateway slot on the pri card to be none (0).
>
> 2. Under card configuration, go to chassis slot device configuration,
> and configure the slot where the gateway card is residing to be none
> (e.g. if the netserver is in slot 16, then the command would be n:16).
>
> 3. Under the same menu, type i:2-13 if there are quad modems in slots 2-13.
>
> 4. Escape to main menu and then select inbound call routing
> configuration and from there select inbound phone number routing
> configuration, wherein, you can configure a b channel to associate itself
> with a dnis number (the pri number) and indicate the call type for that b
> channel to be digital (e.g. command: 1:ph=2221234,ct=d {on b channel
> 1, the number is 2221234 and call type is set to digital). This process
> is really easy from tcm where at the click of the mouse button you can
> configure the dnis number and the call type for all the b channels rather
> than manually typing those commands from the console. From tcm you would
> have to click on the entire pri card and then go to Inbound call routing
> group.
>
> 5. Once the configuration is done, you would have to save the pri card
> to NVRAM (under card configuration, select save chassis to NVRAM and
> execute it).
I have done *EXACTLY* this before on a TC w/ dual-pri, quads and data calls
terminating on the quads. No joy. I also tried just about every variation of
this that I could think of (and yes, I do have a sep. dnis just for this
application). Has anyone out there actually gotten this to work? The calling
side was a Pipeline 130. Calls would connect in Voice mode, however the pipe
would only register massive CRC errors.
--
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) More than 10 DSPs in one HiperARC chassis From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-25 15:54:55
Thus spake Ricky Beam
>Jeff Mcadams was heard to say:
>>Why does the NETServer have a problem with Quake Lag? ;)
>Umm, because it's not a portmaster but it's running portmaster code.
>(Crowbared into place by a few monkeys on loan from the local zoo?)
Heh...of course that question was more an example of where 3Com hasn't
been up-front with us.
>And speaking of "screw[ing] them"... I was just thinking about that
>4500$ hardware service contract _per_ *chassis*. If your chassis is
>filled with quad modems, then you are indeed being screwed with a
>very big d***. But if the chassis has 14DSPs, 2 ARCs, a HNMC, and
>two 130A PSen, then it's damn good deal :-) (That's ~215k$US list.)
Except that their idea of a "chassis" is a rack with up to 48 ports. If
you have more than 48 ports in a chassis, you get charged extra on
that...some value based on the number of ports above 48...at least
that's what their contract information says. Lovely huh?
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
It currently shows as disabled, so I guess I can assume that the card
doesn't have it. Correct?
-----Original Message-----
Sent: Thursday, February 25, 1999 3:45 PM
Load TCM and select the NMC. Then click on
configure > program settings > added cost features.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jason W jwatkins@iland.net
I-Land NOC Tech http://www.iland.net
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----Original Message-----
:We recently purchased a Total Control Rack with X2. How can I confirm that
:the NMC has the X2 feature?
:
: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.
On Thu, 25 Feb 1999, Taino Johnston wrote:
> We have four Total Control chassis in our office. All our Quad modem
> cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
> current versions of the software.
>
> We upgraded one of the chassis with one Hiper Router and Hiper DSP card
> (removing the NETserver card). Once we did this most of our customers are
> able to dial into that chassis and connect. We originally had all the
> chassis configured to prompt for "host". This new chassis is not prompting
> for this information. Where would we set this up? What is the command?
You can use chat scripts on the hiper arc to do this exact function on
the hiper arc.
Need to understand how your users were setup on the NETServer. Meaning
case 1
When a user dials in if you are looking for the prompt
host:
instead of a login:
And then the user does plain authentication then you have to just change
the login prompt on the hiper arc.
case 2:
By setting the netserver to host and by setting security off the
netserver would prompt for a host but if the user starts ppp it will do
ppp else you ask the user to type the host ip address and telnet to it.
For this you need to use chat scripts
krish
>
> Taino Johnston
> Manager, Technical Support
> Access Internet Communications
> +----------------------------------------------------------------+
> | Taino d Johnston | Phone: (408) 777-8190 |
> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> | | Fax: (408) 777-8191 |
> | Access Internet Communications | http://www.accesscom.com/ |
> | tdj@accesscom.com | support@accesscom.com |
> +----------------------------------------------------------------+
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Actually at the host: prompt they would type ppp.
Then they would just type their username and password which authenticates
against our RADIUS. This was put in place a few years back on some of our
MicroCom equipment. So users that have setup modem dial-up scripts are
looking for the host: prompt. We will be removing this but for the time
being we need users being prompted for these three things.
Taino Johnston
Manager, Technical Support
Access Internet Communications
At 7:01 PM -0600 2/25/99, Tatai SV Krishnan wrote:
>On Thu, 25 Feb 1999, Taino Johnston wrote:
>
>> Actually our dial-up users should be prompted for three things:
>>
>> host:
>
>So here the user types the IP or the name of the host correct?
>
>> login:
>> password:
>>
>This login and password comes from the remote host right?
>
>krish
>
>
>> What we need to do is add the host prompt before the login prompt.
>>
>> Taino Johnston
>> Manager, Technical Support
>> Access Internet Communications
>>
>> At 4:52 PM -0600 2/25/99, Tatai SV Krishnan wrote:
>> >On Thu, 25 Feb 1999, Taino Johnston wrote:
>> >
>> >> We have four Total Control chassis in our office. All our Quad modem
>> >> cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
>> >> current versions of the software.
>> >>
>> >> We upgraded one of the chassis with one Hiper Router and Hiper DSP card
>> >> (removing the NETserver card). Once we did this most of our
>>customers are
>> >> able to dial into that chassis and connect. We originally had all the
>> >> chassis configured to prompt for "host". This new chassis is not
>>prompting
>> >> for this information. Where would we set this up? What is the command?
>> >
>> >You can use chat scripts on the hiper arc to do this exact function on
>> >the hiper arc.
>> >
>> >Need to understand how your users were setup on the NETServer. Meaning
>> >
>> >case 1
>> >
>> >When a user dials in if you are looking for the prompt
>> >host:
>> >
>> >instead of a login:
>> >And then the user does plain authentication then you have to just change
>> >the login prompt on the hiper arc.
>> >
>> >case 2:
>> >
>> >By setting the netserver to host and by setting security off the
>> >netserver would prompt for a host but if the user starts ppp it will do
>> >ppp else you ask the user to type the host ip address and telnet to it.
>> >
>> >For this you need to use chat scripts
>> >
>> >krish
>> >
>> >
>> >>
>> >> Taino Johnston
>> >> Manager, Technical Support
>> >> Access Internet Communications
>> >> +----------------------------------------------------------------+
>> >> | Taino d Johnston | Phone: (408) 777-8190 |
>> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
>> >> | | Fax: (408) 777-8191 |
>> >> | Access Internet Communications | http://www.accesscom.com/ |
>> >> | tdj@accesscom.com | support@accesscom.com |
>> >> +----------------------------------------------------------------+
>> >>
>> >> -
>> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> >> with "unsubscribe usr-tc" in the body of the message.
>> >> For information on digests or retrieving files and old messages send
>> >> "help" to the same address. Do not use quotes in your message.
>> >>
>> +----------------------------------------------------------------+
>> | Taino d Johnston | Phone: (408) 777-8190 |
>> | Manager, Technical Support | Tech Support: (408) 342-0551 |
>> | | Fax: (408) 777-8191 |
>> | Access Internet Communications | http://www.accesscom.com/ |
>> | tdj@accesscom.com | support@accesscom.com |
>> +----------------------------------------------------------------+
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the message.
>> For information on digests or retrieving files and old messages send
>> "help" to the same address. Do not use quotes in your message.
>>
+----------------------------------------------------------------+
| Taino d Johnston | Phone: (408) 777-8190 |
| Manager, Technical Support | Tech Support: (408) 342-0551 |
| | Fax: (408) 777-8191 |
| Access Internet Communications | http://www.accesscom.com/ |
| tdj@accesscom.com | support@accesscom.com |
+----------------------------------------------------------------+
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-25 17:05:16
Curt Shambeau was heard to say:
>I'm positive they load share - I plug each power supply into a seperate
>UPS. Turn them both on, there is load on each UPS.
Despite what the sales drones may say, the power supplies are load shared.
There is no associated logic that I've been able to find on the midplane
for electrical cross-overs or what not. PLUS, there's ample documents
instructing the user to NEVER EVER hot swap a power supply -- i.e. never
change the power supply in a powered chassis.
>I did this on over 40 chassis - full 96 calls on a box with no problems at
>all. I believe it is rated to do this in 70A.
...
There is a power utilization chart from 3Com somewhere in the ARC documents
as I recall (I got one directly from 3Com) that tells you what each card
in the chassis requires as well as what each power supply can support.
Just do the math. (Assume there is some safety margin in the numbers.)
--Ricky
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: David Bolen <db3l@ans.net> Date: 1999-02-25 17:20:29
Ricky Beam <jfbeam@enterprise.interpath.net> writes:
> PLUS, there's ample documents
> instructing the user to NEVER EVER hot swap a power supply -- i.e. never
> change the power supply in a powered chassis.
Hmm, that's certainly news to me - we certainly hot swap power
supplies and/or replace ones that have gone bad, and that's certainly
something I tested in the lab and wanted to ensure would function in
the field. Certainly appropriate precautions should be taken with
respect to possible existing voltages when manipulating the supplies.
It is true that if you aren't nice and smooth and steady when
inserting the new supply that it wouldn't always come online, but I've
never had the chassis itself react adversely to such cases (just pull
it out and try again :-)).
With that said, yes, the load is shared between the supplies, even
though earlier (and maybe current) documentation discussed them as if
they were primary and backup. The older 35A/45A supplies had a pretty
passive system simply by being tied to the same polls (e.g., in
parallel) and naturally load shared. My understanding is that the
130A supplies (not sure about the 70A) have a bit of a more active
system in order to have more effective sharing.
-- 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) More than 10 DSPs in one HiperARC chassis From: Mark Lemmert <cto@athenet.net> Date: 1999-02-25 17:24:30
>> PLUS, there's ample documents
>> instructing the user to NEVER EVER hot swap a power supply -- i.e. never
>> change the power supply in a powered chassis.
>
>Hmm, that's certainly news to me - we certainly hot swap power
>supplies and/or replace ones that have gone bad, and that's certainly
>something I tested in the lab and wanted to ensure would function in
>the field. Certainly appropriate precautions should be taken with
>respect to possible existing voltages when manipulating the supplies.
So is there anything to installing a second PSU other than just sticking
it in?
-Mark Lemmert AthEnet Data Exchange
Chief Technical Officer 888-919-8700
Load TCM and select the NMC. Then click on
configure > program settings > added cost features.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jason W jwatkins@iland.net
I-Land NOC Tech http://www.iland.net
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----Original Message-----
:We recently purchased a Total Control Rack with X2. How can I confirm that
:the NMC has the X2 feature?
:
: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 DOVBS HiperDSP or Quads From: Charles Sprickman <spork@inch.com> Date: 1999-02-25 18:04:09
On Thu, 25 Feb 1999, Jesse Sipprell wrote:
> I have done *EXACTLY* this before on a TC w/ dual-pri, quads and data calls
> terminating on the quads. No joy. I also tried just about every variation of
> this that I could think of (and yes, I do have a sep. dnis just for this
> application). Has anyone out there actually gotten this to work? The calling
> side was a Pipeline 130. Calls would connect in Voice mode, however the pipe
> would only register massive CRC errors.
Sounds quite a bit like it is "taking" the call and treating it digital,
but at 64kb rather than 56kb... Now if there's a setting to force that
based on DNIS, we're set.
Our local rep is supposed to try this in their lab and let us know what
happens before we commit resources.
Word has it that DOVBS is supported in beta now on E1 DSPs but not T1. I
won't go into the reasons for them stalling on the T1 models, as it would
make you very angry... If you look at the release history of the code,
you'll see T1 and E1 pretty much track each other exactly, except for this
particular case.
Charles
Hello!
Is there something in 4.1.59-1 that prevents windows nt users from connecting?
Playing with disabling PPP LCP extenstions on the client gives them
ability to login once out of 5 tries.
Yevgeniy Kruglov, email: yk@cifnet.com
System Administrator phone: (773)989-0442
CIFNet, Inc. fax: (773)989-8477
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-25 18:44:22
I have also seen this problem... I placed a call to 3com about this and the
fix they gave me was to turn off IP Header Compression. After doing this NT
connects fine. I really do not think I should have to turn off IP header
compression.
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
http://www.alaweb.com/support.html
----- Original Message -----
Sent: Thursday, February 25, 1999 6:20 PM
>Hello!
>
>Is there something in 4.1.59-1 that prevents windows nt users from
connecting?
>Playing with disabling PPP LCP extenstions on the client gives them
>ability to login once out of 5 tries.
>
>Yevgeniy Kruglov, email: yk@cifnet.com
>System Administrator phone: (773)989-0442
>CIFNet, Inc. fax: (773)989-8477
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) More than 10 DSPs in one HiperARC chassis From: Ronald E. Kushner <ron@glis.net> Date: 1999-02-25 18:52:04
Ricky Beam wrote:
>
> Curt Shambeau was heard to say:
> >I'm positive they load share - I plug each power supply into a seperate
> >UPS. Turn them both on, there is load on each UPS.
>
> Despite what the sales drones may say, the power supplies are load shared.
> There is no associated logic that I've been able to find on the midplane
> for electrical cross-overs or what not. PLUS, there's ample documents
> instructing the user to NEVER EVER hot swap a power supply -- i.e. never
> change the power supply in a powered chassis.
Actually, the documentation says PSU's are hot swapable.
To quote again:
> 1 Determine if power needs to be removed:
> WARNING: Wait 10 seconds to allow all capacitors on the PSI to
> discharge�do not touch the PSI during this period. After 10 seconds,
> the PSI can be removed, however components such as the heat sinks may
> still be very hot. The capacitors are fully discharged when the RUN/FAIL
> (RN/FL) LED turns off.
> 2 Loosen the PSI fasteners (screws).
> Number of
> PSUs Installed
> Number of PSUs
> to be Removed
> Remove Chassis Power�
> Switch to the Off (�0�) Position?
> 1 1 Yes
> 2 1 No; PSUs are hot-swappable
> 2 2 Yes
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Ronald E. Kushner <ron@glis.net> Date: 1999-02-25 18:58:34
Mark Lemmert wrote:
>
> >> PLUS, there's ample documents
> >> instructing the user to NEVER EVER hot swap a power supply -- i.e. never
> >> change the power supply in a powered chassis.
> >
> >Hmm, that's certainly news to me - we certainly hot swap power
> >supplies and/or replace ones that have gone bad, and that's certainly
> >something I tested in the lab and wanted to ensure would function in
> >the field. Certainly appropriate precautions should be taken with
> >respect to possible existing voltages when manipulating the supplies.
>
> So is there anything to installing a second PSU other than just sticking
> it in?
That's how I added my second 70A power supply. I just followed the
directions on the Documentation Library System Release 3.1 CD-ROM. I forget
if I put the PSI or PSU in first. I think the only thing you have to look
out for is if you're in a 240V enviroment in the US, you have to change a
jumper since they come configured for 120V.
-Ron
What version of HiPer arc code you are using?
4.1.59 has fixes for the lcp retransmission problem that geo-book has
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, 25 Feb 1999, Ray Bagby wrote:
> Greetings,
> I am having trouble connecting a client who is using a Brother Geo-Book.
> I'm using a TC chassis with HiPer ARC and DSP. No trouble with Anyone before
> this. The Brother folks say I need to assign IP and mask and gateway but I
> work with a pool.
> Anyone have a suggestion?
>
> 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) geo-book connect From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-25 19:00:42
I am useing the 4.1.59 on my Hiper Arc. This problem seems to only be
isolated to NT users.
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
http://www.alaweb.com/support.html
----- Original Message -----
Cc: <usr-tc@xmission.com>
Sent: Thursday, February 25, 1999 6:59 PM
>What version of HiPer arc code you are using?
>4.1.59 has fixes for the lcp retransmission problem that geo-book has
>
>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, 25 Feb 1999, Ray Bagby wrote:
>
>> Greetings,
>> I am having trouble connecting a client who is using a Brother
Geo-Book.
>> I'm using a TC chassis with HiPer ARC and DSP. No trouble with Anyone
before
>> this. The Brother folks say I need to assign IP and mask and gateway but
I
>> work with a pool.
>> Anyone have a suggestion?
>>
>> 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.
>
On Thu, 25 Feb 1999, Taino Johnston wrote:
> Actually our dial-up users should be prompted for three things:
>
> host:
So here the user types the IP or the name of the host correct?
> login:
> password:
>
This login and password comes from the remote host right?
krish
> What we need to do is add the host prompt before the login prompt.
>
> Taino Johnston
> Manager, Technical Support
> Access Internet Communications
>
> At 4:52 PM -0600 2/25/99, Tatai SV Krishnan wrote:
> >On Thu, 25 Feb 1999, Taino Johnston wrote:
> >
> >> We have four Total Control chassis in our office. All our Quad modem
> >> cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
> >> current versions of the software.
> >>
> >> We upgraded one of the chassis with one Hiper Router and Hiper DSP card
> >> (removing the NETserver card). Once we did this most of our customers are
> >> able to dial into that chassis and connect. We originally had all the
> >> chassis configured to prompt for "host". This new chassis is not prompting
> >> for this information. Where would we set this up? What is the command?
> >
> >You can use chat scripts on the hiper arc to do this exact function on
> >the hiper arc.
> >
> >Need to understand how your users were setup on the NETServer. Meaning
> >
> >case 1
> >
> >When a user dials in if you are looking for the prompt
> >host:
> >
> >instead of a login:
> >And then the user does plain authentication then you have to just change
> >the login prompt on the hiper arc.
> >
> >case 2:
> >
> >By setting the netserver to host and by setting security off the
> >netserver would prompt for a host but if the user starts ppp it will do
> >ppp else you ask the user to type the host ip address and telnet to it.
> >
> >For this you need to use chat scripts
> >
> >krish
> >
> >
> >>
> >> Taino Johnston
> >> Manager, Technical Support
> >> Access Internet Communications
> >> +----------------------------------------------------------------+
> >> | Taino d Johnston | Phone: (408) 777-8190 |
> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> >> | | Fax: (408) 777-8191 |
> >> | Access Internet Communications | http://www.accesscom.com/ |
> >> | tdj@accesscom.com | support@accesscom.com |
> >> +----------------------------------------------------------------+
> >>
> >> -
> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> >> with "unsubscribe usr-tc" in the body of the message.
> >> For information on digests or retrieving files and old messages send
> >> "help" to the same address. Do not use quotes in your message.
> >>
> +----------------------------------------------------------------+
> | Taino d Johnston | Phone: (408) 777-8190 |
> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> | | Fax: (408) 777-8191 |
> | Access Internet Communications | http://www.accesscom.com/ |
> | tdj@accesscom.com | support@accesscom.com |
> +----------------------------------------------------------------+
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
On Thu, 25 Feb 1999, Taino Johnston wrote:
> Actually at the host: prompt they would type ppp.
>
> Then they would just type their username and password which authenticates
> against our RADIUS. This was put in place a few years back on some of our
> MicroCom equipment. So users that have setup modem dial-up scripts are
> looking for the host: prompt. We will be removing this but for the time
> being we need users being prompted for these three things.
Need to modify the chat script to do this. That is the only way out.
Would you also have login users here?
krish
>
> Taino Johnston
> Manager, Technical Support
> Access Internet Communications
>
> At 7:01 PM -0600 2/25/99, Tatai SV Krishnan wrote:
> >On Thu, 25 Feb 1999, Taino Johnston wrote:
> >
> >> Actually our dial-up users should be prompted for three things:
> >>
> >> host:
> >
> >So here the user types the IP or the name of the host correct?
> >
> >> login:
> >> password:
> >>
> >This login and password comes from the remote host right?
> >
> >krish
> >
> >
> >> What we need to do is add the host prompt before the login prompt.
> >>
> >> Taino Johnston
> >> Manager, Technical Support
> >> Access Internet Communications
> >>
> >> At 4:52 PM -0600 2/25/99, Tatai SV Krishnan wrote:
> >> >On Thu, 25 Feb 1999, Taino Johnston wrote:
> >> >
> >> >> We have four Total Control chassis in our office. All our Quad modem
> >> >> cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
> >> >> current versions of the software.
> >> >>
> >> >> We upgraded one of the chassis with one Hiper Router and Hiper DSP card
> >> >> (removing the NETserver card). Once we did this most of our
> >>customers are
> >> >> able to dial into that chassis and connect. We originally had all the
> >> >> chassis configured to prompt for "host". This new chassis is not
> >>prompting
> >> >> for this information. Where would we set this up? What is the command?
> >> >
> >> >You can use chat scripts on the hiper arc to do this exact function on
> >> >the hiper arc.
> >> >
> >> >Need to understand how your users were setup on the NETServer. Meaning
> >> >
> >> >case 1
> >> >
> >> >When a user dials in if you are looking for the prompt
> >> >host:
> >> >
> >> >instead of a login:
> >> >And then the user does plain authentication then you have to just change
> >> >the login prompt on the hiper arc.
> >> >
> >> >case 2:
> >> >
> >> >By setting the netserver to host and by setting security off the
> >> >netserver would prompt for a host but if the user starts ppp it will do
> >> >ppp else you ask the user to type the host ip address and telnet to it.
> >> >
> >> >For this you need to use chat scripts
> >> >
> >> >krish
> >> >
> >> >
> >> >>
> >> >> Taino Johnston
> >> >> Manager, Technical Support
> >> >> Access Internet Communications
> >> >> +----------------------------------------------------------------+
> >> >> | Taino d Johnston | Phone: (408) 777-8190 |
> >> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> >> >> | | Fax: (408) 777-8191 |
> >> >> | Access Internet Communications | http://www.accesscom.com/ |
> >> >> | tdj@accesscom.com | support@accesscom.com |
> >> >> +----------------------------------------------------------------+
> >> >>
> >> >> -
> >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> >> >> with "unsubscribe usr-tc" in the body of the message.
> >> >> For information on digests or retrieving files and old messages send
> >> >> "help" to the same address. Do not use quotes in your message.
> >> >>
> >> +----------------------------------------------------------------+
> >> | Taino d Johnston | Phone: (408) 777-8190 |
> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> >> | | Fax: (408) 777-8191 |
> >> | Access Internet Communications | http://www.accesscom.com/ |
> >> | tdj@accesscom.com | support@accesscom.com |
> >> +----------------------------------------------------------------+
> >>
> >> -
> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> >> with "unsubscribe usr-tc" in the body of the message.
> >> For information on digests or retrieving files and old messages send
> >> "help" to the same address. Do not use quotes in your message.
> >>
> +----------------------------------------------------------------+
> | Taino d Johnston | Phone: (408) 777-8190 |
> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> | | Fax: (408) 777-8191 |
> | Access Internet Communications | http://www.accesscom.com/ |
> | tdj@accesscom.com | support@accesscom.com |
> +----------------------------------------------------------------+
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) getting host prompt From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-25 19:57:36
What would cause when I saved my chassis to NVRAM all cards rebooted
NMC,Hiper Router, Hiper DSP's and Quads. When they came back up all of the
dialin addresses on all modems was set to DNIS. It was set to No address
before I saved to NVRAM. Any help will be appreciated.
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
http://www.alaweb.com/support.html
----- Original Message -----
Cc: <usr-tc@lists.xmission.com>
Sent: Thursday, February 25, 1999 7:33 PM
>On Thu, 25 Feb 1999, Taino Johnston wrote:
>
>> Actually at the host: prompt they would type ppp.
>>
>> Then they would just type their username and password which authenticates
>> against our RADIUS. This was put in place a few years back on some of
our
>> MicroCom equipment. So users that have setup modem dial-up scripts are
>> looking for the host: prompt. We will be removing this but for the time
>> being we need users being prompted for these three things.
>
>Need to modify the chat script to do this. That is the only way out.
>Would you also have login users here?
>
>krish
>
>
>>
>> Taino Johnston
>> Manager, Technical Support
>> Access Internet Communications
>>
>> At 7:01 PM -0600 2/25/99, Tatai SV Krishnan wrote:
>> >On Thu, 25 Feb 1999, Taino Johnston wrote:
>> >
>> >> Actually our dial-up users should be prompted for three things:
>> >>
>> >> host:
>> >
>> >So here the user types the IP or the name of the host correct?
>> >
>> >> login:
>> >> password:
>> >>
>> >This login and password comes from the remote host right?
>> >
>> >krish
>> >
>> >
>> >> What we need to do is add the host prompt before the login prompt.
>> >>
>> >> Taino Johnston
>> >> Manager, Technical Support
>> >> Access Internet Communications
>> >>
>> >> At 4:52 PM -0600 2/25/99, Tatai SV Krishnan wrote:
>> >> >On Thu, 25 Feb 1999, Taino Johnston wrote:
>> >> >
>> >> >> We have four Total Control chassis in our office. All our Quad
modem
>> >> >> cards, NETserver PRI cards, Dual PRI cards and NMC cards are
running the
>> >> >> current versions of the software.
>> >> >>
>> >> >> We upgraded one of the chassis with one Hiper Router and Hiper DSP
card
>> >> >> (removing the NETserver card). Once we did this most of our
>> >>customers are
>> >> >> able to dial into that chassis and connect. We originally had all
the
>> >> >> chassis configured to prompt for "host". This new chassis is not
>> >>prompting
>> >> >> for this information. Where would we set this up? What is the
command?
>> >> >
>> >> >You can use chat scripts on the hiper arc to do this exact function
on
>> >> >the hiper arc.
>> >> >
>> >> >Need to understand how your users were setup on the NETServer.
Meaning
>> >> >
>> >> >case 1
>> >> >
>> >> >When a user dials in if you are looking for the prompt
>> >> >host:
>> >> >
>> >> >instead of a login:
>> >> >And then the user does plain authentication then you have to just
change
>> >> >the login prompt on the hiper arc.
>> >> >
>> >> >case 2:
>> >> >
>> >> >By setting the netserver to host and by setting security off the
>> >> >netserver would prompt for a host but if the user starts ppp it will
do
>> >> >ppp else you ask the user to type the host ip address and telnet to
it.
>> >> >
>> >> >For this you need to use chat scripts
>> >> >
>> >> >krish
>> >> >
>> >> >
>> >> >>
>> >> >> Taino Johnston
>> >> >> Manager, Technical Support
>> >> >> Access Internet Communications
>> >> >> +----------------------------------------------------------------+
>> >> >> | Taino d Johnston | Phone: (408) 777-8190 |
>> >> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
>> >> >> | | Fax: (408) 777-8191 |
>> >> >> | Access Internet Communications | http://www.accesscom.com/ |
>> >> >> | tdj@accesscom.com | support@accesscom.com |
>> >> >> +----------------------------------------------------------------+
>> >> >>
>> >> >> -
>> >> >> To unsubscribe to usr-tc, send an email to
"majordomo@xmission.com"
>> >> >> with "unsubscribe usr-tc" in the body of the message.
>> >> >> For information on digests or retrieving files and old messages
send
>> >> >> "help" to the same address. Do not use quotes in your message.
>> >> >>
>> >> +----------------------------------------------------------------+
>> >> | Taino d Johnston | Phone: (408) 777-8190 |
>> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
>> >> | | Fax: (408) 777-8191 |
>> >> | Access Internet Communications | http://www.accesscom.com/ |
>> >> | tdj@accesscom.com | support@accesscom.com |
>> >> +----------------------------------------------------------------+
>> >>
>> >> -
>> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> >> with "unsubscribe usr-tc" in the body of the message.
>> >> For information on digests or retrieving files and old messages send
>> >> "help" to the same address. Do not use quotes in your message.
>> >>
>> +----------------------------------------------------------------+
>> | Taino d Johnston | Phone: (408) 777-8190 |
>> | Manager, Technical Support | Tech Support: (408) 342-0551 |
>> | | Fax: (408) 777-8191 |
>> | Access Internet Communications | http://www.accesscom.com/ |
>> | tdj@accesscom.com | support@accesscom.com |
>> +----------------------------------------------------------------+
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the 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.
>
Well, that must be my problem. I'm running 4.1.72. I understand that a newer
release would have a smaller number right? So I need to go to 4.1.59 for the
Arc. OK
Thanks!
-----Original Message-----
>I am useing the 4.1.59 on my Hiper Arc. This problem seems to only be
>isolated to NT users.
>
>
>Thanks
>Paul JR.
>AlaWeb Network Admin.
>1800-427-8896
>http://www.alaweb.com/support.html
>
>
>
>
>----- Original Message -----
>From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
>To: Ray Bagby <rbagby@yore.net>
>Cc: <usr-tc@xmission.com>
>Sent: Thursday, February 25, 1999 6:59 PM
>Subject: Re: (usr-tc) geo-book connect
>
>
>>What version of HiPer arc code you are using?
>>4.1.59 has fixes for the lcp retransmission problem that geo-book has
>>
>>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, 25 Feb 1999, Ray Bagby wrote:
>>
>>> Greetings,
>>> I am having trouble connecting a client who is using a Brother
>Geo-Book.
>>> I'm using a TC chassis with HiPer ARC and DSP. No trouble with Anyone
>before
>>> this. The Brother folks say I need to assign IP and mask and gateway but
>I
>>> work with a pool.
>>> Anyone have a suggestion?
>>>
>>> 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.
>>
>
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) geo-book connect From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-25 22:59:00
-> Greetings,
-> I am having trouble connecting a client who is using a Brother Geo-Book.
-> I'm using a TC chassis with HiPer ARC and DSP. No trouble with Anyone before
-> this. The Brother folks say I need to assign IP and mask and gateway but I
-> work with a pool.
-> Anyone have a suggestion?
Talk to Krish. he and I worked on this and you must have 4.1.64 of HiPerArc
code or higher.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-25 23:01:00
-> I have also seen this problem... I placed a call to 3com about this and the
-> fix they gave me was to turn off IP Header Compression. After doing this NT
-> connects fine. I really do not think I should have to turn off IP header
-> compression.
How about having your NT users turn it on ? By default I have all of our users
turn it on and we've never had a problem with it.
Jeff Binkley
ASA network Computing
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-26 07:28:45
Thus spake Paul Jr.
>I have also seen this problem... I placed a call to 3com about this and the
>fix they gave me was to turn off IP Header Compression. After doing this NT
>connects fine. I really do not think I should have to turn off IP header
>compression.
That's a long-standing problem with NT. Not a problem with the 3Com
gear...we've been having to do this with NT for many iterations of code.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-26 07:34:07
Thus spake Jeff Mcadams
>Thus spake Paul Jr.
>>I have also seen this problem... I placed a call to 3com about this and the
>>fix they gave me was to turn off IP Header Compression. After doing this NT
>>connects fine. I really do not think I should have to turn off IP header
>>compression.
>That's a long-standing problem with NT. Not a problem with the 3Com
>gear...we've been having to do this with NT for many iterations of code.
Let me clarify that (too early in the morning yet). We tell our NT
customers to turn off VJ, we leave it on in our equipment. We also are
very sure to tell our customers that its an NT bug.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) Preferences in RADIUS servers From: Al Huefner <al_huefner@mw.3com.com> Date: 1999-02-26 08:12:26
Dave, you should put these out on our forum first and then forward the email
copy to the usr-tc list. This will provide all the usr-tc users with the URL
links that are now at the bottom of our forum emails. You should keep doing
that with every opportunity to provide suttle encouragement to move to our site.
--- AL
"David Cartwright" <David_Cartwright@3com.com> on 02/25/99 10:55:54 AM
Please respond to usr-tc@lists.xmission.com
cc: (Al Huefner/MW/US/3Com)
Do you use RADIUS in your remote access environment? We're taking a
poll to better understand your preferences in RADIUS servers. Please
take a few moments (it shouldn't take anymore than a minute or two) and
complete the survey located at:
http://totalservice.3com.com/radius.html
Thanks in advance for your time and feedback.
Dave
3Com Customer Support
-
To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
with "unsubscribe usr-tc" in the body of the message.
For information on digests or retrieving files and old messages send
"help" to the same address. Do not use quotes in your message.
On Thu, 25 Feb 1999, Tony Loosle wrote:
> Is there any USRobotics resellers on this list??
>
> I have been trying to buy an upgrade to the usr radius software and no
> one at USR can help. They say I need a support contract. Ok, sell me a
> support contract for the software, but then USR can't even get me with
> someone who knows how to sell it to me.
This is the PRIMARY reason we dont use USR.
I cant believe they cant just sell you support directly.
~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Jake Messinger, VP. ph:713-772-6690 Lucent Dealer
AMS, Inc. fx:713-774-3498 Medical Billing
8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services
Houston, Texas 77074 www.ams.com/~jake and Hardware
Adjunct Professor University of Houston, CBA jake@uh.edu
~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
INVENTOR OF the _.,-*~' '~*-,._ SQUIGGLES (c) 1978
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-26 08:54:23
Thus spake matthews
>To upgrade a chassis to a bigger power supply, is it as simple as a
>swap-out or does the whole chassis need to be replaced? I have all 45 amp
>units and I'm starting to get concerned that they won't handle the growth I
>thought they would.
With 45A PS'es, that means you have the older style chassis (without the
integrated fan-tray), those cannot be upgraded any further.
With the newer style of chassis (with integrated fan-tray), its just a
matter of powering down the chassis, removing the PS'es, sticking the
new ones in and powering back up.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Hi, what cards do you have ??
At 04:39 PM 2/25/99 -0800, you wrote:
>It currently shows as disabled, so I guess I can assume that the card
>doesn't have it. Correct?
>
>-----Original Message-----
>From: Jason [mailto:jwatkins@iland.net]
>Sent: Thursday, February 25, 1999 3:45 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) X2 NMC Key
>
>
>Load TCM and select the NMC. Then click on
>configure > program settings > added cost features.
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Jason W jwatkins@iland.net
>I-Land NOC Tech http://www.iland.net
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>-----Original Message-----
>From: Jolliffe, Anu <ajolliffe@imagen.net>
>To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com>
>Date: Thursday, February 25, 1999 4:46 PM
>Subject: (usr-tc) X2 NMC Key
>
>
>:We recently purchased a Total Control Rack with X2. How can I confirm that
>:the NMC has the X2 feature?
>:
>: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.
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) More than 10 DSPs in one HiperARC chassis From: matthews <matthews@brunnet.net> Date: 1999-02-26 09:12:31
On Thursday, February 25, 1999 2:57 PM, Blann_Firestone@3com.com
[SMTP:Blann_Firestone@3com.com] wrote:
>
>
>
> Marshall,
>
> This configuration requires 130 AMP power supplies.
>
> Blann
>
To upgrade a chassis to a bigger power supply, is it as simple as a
swap-out or does the whole chassis need to be replaced? I have all 45 amp
units and I'm starting to get concerned that they won't handle the growth I
thought they would.
Matthew Stainforth
Technical Services Manager
BrunNet Inc.
Subject:Re: (usr-tc) Preferences in RADIUS servers From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-26 09:19:06
Phil Dye said once upon a time:
>Such is the problem of setting Reply-To to the list.
I can change it if so desired. What does everyone else think?
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Pete Ashdown <pashdown@xmission.com> Date: 1999-02-26 09:22:04
Jeff Binkley said once upon a time:
>
>-> I have also seen this problem... I placed a call to 3com about this and the
>-> fix they gave me was to turn off IP Header Compression. After doing this NT
>-> connects fine. I really do not think I should have to turn off IP header
>-> compression.
>
>How about having your NT users turn it on ? By default I have all of our users
>turn it on and we've never had a problem with it.
Where do you specify compression being on with your side? How does it
handle people who have it off?
Subject:Re: (usr-tc) Preferences in RADIUS servers From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-26 09:37:20
Thus spake Al Huefner
>Dave, you should put these out on our forum first and then forward the email
>copy to the usr-tc list. This will provide all the usr-tc users with the URL
>links that are now at the bottom of our forum emails. You should keep doing
>that with every opportunity to provide suttle encouragement to move to our site.
>--- AL
Oh man...I'm not even sure what to say about this...
BTW, the spelling is "subtle"
(usually not one to do spelling flames, but I'm getting so fed up with
3Com's attitude in general that I'm willing at the moment to flame just
about anything.
>"David Cartwright" <David_Cartwright@3com.com> on 02/25/99 10:55:54 AM
>Please respond to usr-tc@lists.xmission.com
>To: usr-tc@lists.xmission.com
>cc: (Al Huefner/MW/US/3Com)
>Subject: (usr-tc) Preferences in RADIUS servers
>Do you use RADIUS in your remote access environment? We're taking a
>poll to better understand your preferences in RADIUS servers. Please
>take a few moments (it shouldn't take anymore than a minute or two) and
>complete the survey located at:
>http://totalservice.3com.com/radius.html
>Thanks in advance for your time and feedback.
>Dave
>3Com Customer Support
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Two messages in response to this...this first one addresses the
operational issues re: NETServers and MPIP...second one will be a rant
about 3Com attitudes.
Thus spake Phil Le Clercq
>Using Netservers 3.8.1 and quads 5.9.9
>I have been setting up MPIP across chassis and subnets, and thanks to this
>list it works ok, well sort of....
Heh...that's about the size of it.
>It only works for a day give or take. I thought I had narrowed it down to
>using a remote timeserver, and the possibility of lack of synchronisation.
>So I set up a time server on my LAN and the netservers all get the correct
>time from it.
I seriously doubt that time sync is your problem. MPIP is just broken
in the NETServers (and in HiPer Arcs from what I've seen, but at least
there's a chance of getting that fixed).
>The trouble is after I have set MPIP up the only way it will
>work is after a reboot of the MPIP clients. Using reset time does not do the
>job, so there is the chance that time sync. is not the problem. I know Jeff
>is the MPIP Netserver king so I was wondering if any one had any ideas?
Heh...MPIP NETServer king...I like that. :)
Here's the deal...let's say you have 3 NETServers, just gonna use
numbers for them, 1, 2, and 3.
Customer calls in, first channel hits NETServer 1. It starts up MP, so
NETServer 1 (we'll call it N1 for short), contacts the MPIP server
asking if any bundles exist with the userid, EDO class, and EDO value.
Since this is the first call and first channel, the MPIP server says no,
and N1 sets up the bundle and informs the MPIP server that it is doing
so. Second call comes in on N2, N2 contacts the MPIP server asking if a
bundle exists with the specified userid, EDO class, and EDO value...MPIP
server says it does, on N1, so N2 sets up a tunnel to N1 to connect its
link to the bundle head which is on N1. Everything works hunky-dory.
Customer then disconnects...typically, both channels will disconnect at
the same time...then its a race to see which NETServer gets the
notification to the MPIP server first. If N2 gets it there first, then
everything *should* be OK, but let's say that N1 gets it there first.
N1 tells the MPIP server that its link has dropped. The MPIP server
then removes that link from its linked list of MP links in its memory.
This leaves the MPIP server thinking that the bundle head is hosted on
N1, and the only link in that bundle is on N2...which is correct.
What happens at this point is a little hazy as I'm doing black box
debugging here (ie, trying to figure out what's going on based on
external input and behavior...I don't have access to the code to really
look at what's going on internally). The MPIP server then gets N2's
link deregistration request (saying that the link has been
disconnected). For some reason, this request doesn't have the full
effect that its supposed to. After this request goes through, the MPIP
server *should* see that there are no more links in the bundle,
therefore the bundle should be removed. What happens though, is that
the MPIP server still thinks the bundle exists...whether it thinks it
has 1 or 0 links active I'm unsure about, but based on using a HiPer Arc
as an MPIP server, I *believe* it still thinks the link is active
too...regardless, the MPIP server doesn't remove the bundle as its
supposed to. This sets up things for future failures.
Here's where the failure actually occurs. The customer dials in again
sometime later. Let's say they get connected to N3 (would do the same
if they got connected to N2, or indeed any NETServer other than N1). N3
contacts the MPIP server to ask if this MP bundle already exists. The
MPIP server, still thinking that the bundle from the previous call still
exists, tells N3 that the bundle does indeed exist, and its hosted on
N1. N3 then tries to set up a tunnel to N1 to connect this link with
the bundle that it's been told exists on N1. N1 gets the request to set
up the tunnel for the MP bundle, looks through its information for the
MP bundle...sees it *doesn't* exist and rejects the tunnel connection.
Both NETServers then syslog an error (look for the string "Err=36" in
your syslog) and N3 drops the call without further ado.
What are the workarounds? Well, you can reboot all the MPIP clients as
you've found already, when the clients boot up, they send a reboot
notification to the MPIP server, so the MPIP server clears out any
bundles that it has listed that are hosted on that MPIP client...so in
our example case, when you reboot N1, when N1 boots, it sends a reboot
notification to the MPIP server, so the MPIP server clears out any
bundles that it has listed as being hosted on N1, including the bogus
one that it thought was hosted there but wasn't really. The downside of
that is that you have to boot off any users that are currently connected
to the MPIP client NETServers. This workaround actually works better
wrt MPIP than the next, but is more disruptive to customers.
The other workaround is to reboot the MPIP *server*. This, obviously,
clears out *all* MPIP bundles that the MPIP server knows
about...unfortunately, this also means it clears out ones that are
actually active on your systems. This workaround works for less time (I
reboot our MPIP server once every 3 hours), but is less disruptive to
customers as only the one NETServer that is serving as the MPIP server
needs to be rebooted. The disruption can be minimized even more by
setting up an MPIP server on a dedicated NETServer (or HiPer Arc doesn't
really matter there), ie, a NETServer that isn't taking any calls. This
means you can reboot the NETServer almost at will without disconnecting
any customers. The downside of this is that customers that are
connected with MP when the MPIP server is rebooted will not be able to
add any new channels to their MP bundle as knowledge of all valid
bundles is lost from the MPIP server along with the bogus ones.
So, there are the issues involved with MPIP on NETServers...basically,
its broken, and since 3Com no longer has access to the ComOS based
source-code, it won't be fixed on NETServers (unless they reverse what
was a brain-dead decision to not back port HiPer OS to the NETServers
like they originally said they would). You're best bet is to upgrade to
HiPer Arcs, where the problem still exists at this point from what I'm
aware of, but at least has a chance of being fixed.
>There is a call logged with 3Com Europe no answers yet.
My ticket wrt this is 58316...its back from April of 1998, has lots of
information in it so you can tell them to reference it...not that they
can do a whole lot about it...maybe you can scream and yell at them to
upgrade you to HiPer Arcs like we are (see my next message/rant about
our travails with this).
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Here is what you are looking for as a chat script on the Hiper arc
Create a chat script file on a unix host and tftp the same to the hiper arc.
The chat script itself should be like this
SEND "Welcome to what ever\n";
do_host:
Send "Host:";
EXPECT %host;
IF ($host == " some host") GOTO do_host;
Telnet $host;
GOTO hang;
do_ppp:
AUTHENTICAT LOGIN_BANNER=""LOGIN_PROMPT="Username:";
hang:
HANGUP;
And on the hiper arc CLI commands:
1. set modem_group all connection_type no_prompt message " "
login_service <telnet | rlogin | cleartcp>
2. set user default chat_script netserve.chat
3. add chat_script netserve.chat
Hope this helps
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, 25 Feb 1999, Taino Johnston wrote:
> Actually at the host: prompt they would type ppp.
>
> Then they would just type their username and password which authenticates
> against our RADIUS. This was put in place a few years back on some of our
> MicroCom equipment. So users that have setup modem dial-up scripts are
> looking for the host: prompt. We will be removing this but for the time
> being we need users being prompted for these three things.
>
> Taino Johnston
> Manager, Technical Support
> Access Internet Communications
>
> At 7:01 PM -0600 2/25/99, Tatai SV Krishnan wrote:
> >On Thu, 25 Feb 1999, Taino Johnston wrote:
> >
> >> Actually our dial-up users should be prompted for three things:
> >>
> >> host:
> >
> >So here the user types the IP or the name of the host correct?
> >
> >> login:
> >> password:
> >>
> >This login and password comes from the remote host right?
> >
> >krish
> >
> >
> >> What we need to do is add the host prompt before the login prompt.
> >>
> >> Taino Johnston
> >> Manager, Technical Support
> >> Access Internet Communications
> >>
> >> At 4:52 PM -0600 2/25/99, Tatai SV Krishnan wrote:
> >> >On Thu, 25 Feb 1999, Taino Johnston wrote:
> >> >
> >> >> We have four Total Control chassis in our office. All our Quad modem
> >> >> cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the
> >> >> current versions of the software.
> >> >>
> >> >> We upgraded one of the chassis with one Hiper Router and Hiper DSP card
> >> >> (removing the NETserver card). Once we did this most of our
> >>customers are
> >> >> able to dial into that chassis and connect. We originally had all the
> >> >> chassis configured to prompt for "host". This new chassis is not
> >>prompting
> >> >> for this information. Where would we set this up? What is the command?
> >> >
> >> >You can use chat scripts on the hiper arc to do this exact function on
> >> >the hiper arc.
> >> >
> >> >Need to understand how your users were setup on the NETServer. Meaning
> >> >
> >> >case 1
> >> >
> >> >When a user dials in if you are looking for the prompt
> >> >host:
> >> >
> >> >instead of a login:
> >> >And then the user does plain authentication then you have to just change
> >> >the login prompt on the hiper arc.
> >> >
> >> >case 2:
> >> >
> >> >By setting the netserver to host and by setting security off the
> >> >netserver would prompt for a host but if the user starts ppp it will do
> >> >ppp else you ask the user to type the host ip address and telnet to it.
> >> >
> >> >For this you need to use chat scripts
> >> >
> >> >krish
> >> >
> >> >
> >> >>
> >> >> Taino Johnston
> >> >> Manager, Technical Support
> >> >> Access Internet Communications
> >> >> +----------------------------------------------------------------+
> >> >> | Taino d Johnston | Phone: (408) 777-8190 |
> >> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> >> >> | | Fax: (408) 777-8191 |
> >> >> | Access Internet Communications | http://www.accesscom.com/ |
> >> >> | tdj@accesscom.com | support@accesscom.com |
> >> >> +----------------------------------------------------------------+
> >> >>
> >> >> -
> >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> >> >> with "unsubscribe usr-tc" in the body of the message.
> >> >> For information on digests or retrieving files and old messages send
> >> >> "help" to the same address. Do not use quotes in your message.
> >> >>
> >> +----------------------------------------------------------------+
> >> | Taino d Johnston | Phone: (408) 777-8190 |
> >> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> >> | | Fax: (408) 777-8191 |
> >> | Access Internet Communications | http://www.accesscom.com/ |
> >> | tdj@accesscom.com | support@accesscom.com |
> >> +----------------------------------------------------------------+
> >>
> >> -
> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> >> with "unsubscribe usr-tc" in the body of the message.
> >> For information on digests or retrieving files and old messages send
> >> "help" to the same address. Do not use quotes in your message.
> >>
> +----------------------------------------------------------------+
> | Taino d Johnston | Phone: (408) 777-8190 |
> | Manager, Technical Support | Tech Support: (408) 342-0551 |
> | | Fax: (408) 777-8191 |
> | Access Internet Communications | http://www.accesscom.com/ |
> | tdj@accesscom.com | support@accesscom.com |
> +----------------------------------------------------------------+
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> 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) More than 10 DSPs in one HiperARC chassis From: Ben Nolen <ben_nolen@mw.3com.com> Date: 1999-02-26 11:24:50
--0__=o4OmQnkjJE4OGsvU2ZtFkyZcOc5UwzGhXdgY0iAshKacJZEg2N6R0M3Y
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Mr. Mark Lemmert,
User Forum Question:
So is there anything to installing a second PSU other than just sticking it in?
3Com Carrier TechCom Answer:
If you already have a power supply in the chassis, you can leave the chassis on
(powered up) while installing a second power supply unit and power interface in
that chassis.
Page 2-4 of the 70 and 130 Amp AC and DC Power Supply Unit and Power Supply
Interface Getting Started Guide (3Com Part Number 1.024.1312-00) contains a
procedure on how to determine when you need to remove power from a chassis to
work on, replace, or install a PSU.
(See attached file: 24131200.pdf)
Page 2-3 of this PDF contains a similar discussion for the 35 / 45 Amp PSU.
(See attached file: 24132700.pdf)
Both of these documents are on the Total Control System 3.1 Documentation CD ROM
(3Com Part Number 1.035.0008-02). Both documents, including some updates to the
70 / 130 Getting Started Guide, are also scheduled for publication on the Total
Control System 3.5 Documentation CD ROM (3Com Part Number 1.035.0008-03).
Thanks,
Ben Nolen Jessica Rucka
Group Manager - Technical Communication Technical Writer
Carrier Systems Business Unit Carrier Systems Business Unit
John Rosberg/MW/US/3Com
02/26/99 08:23 AM
cc:
Guys
?
rosberg
---------------------- Forwarded by John Rosberg/MW/US/3Com on 02/26/99 08:15 AM
Subject:Re: (usr-tc) Hayes Accura - connect failure From: John Powell <jp@packet.ae.usr.com> Date: 1999-02-26 11:27:23
Fred,
From your description, this appears to be caused by a bug in the Rockwell
modems that occasionally (this is a line specific issue) incorrectly
detects an extra A/D conversion. This issue does appear dialing into an
Ascend, but it is much more prevalent dialing into ours (for reasons that
would take pages to describe).
Have the user set S202=32 on his fine Hayes modem and I am 98% sure that
will solve this issue.
Hope this helps!
JP
PS. This fix is noted in my V.90 troubleshooting doc found at
http://totalservice.3com.com/documents/ along with several other little
tidbits like this.
On Fri, 26 Feb 1999, Fred Williams wrote:
> We have a user with Hayes Accura 5669GB modem flashed up
> with the "latest" V90 code. The version is described as 2.083ho3.
> The problem is that the user is unable to get anything better than a
> 33600 connection when dialling into either Quads with Netserver
> or Hiper DSP. He gets the same symptoms with another ISP using
> USR kit. When he dials into an Ascend equipped ISP he gets a V90
> connection.
>
> Does anyone have any (sensible) suggestions 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) More than 10 DSPs in one HiperARC chassis From: David Bolen <db3l@ans.net> Date: 1999-02-26 12:00:27
"Andres Kroonmaa" <andre@ml.ee> writes:
> What they mean is NEVER EVER muck round with PSU plugged into wall and
> switched ON. If you pull the PSU that is under the load out of the chassis,
> you'll get what you deserve: bright welding flash along with all the damage.
Hmm, I don't think even that is a problem. I've pulled PSUs (although
I'd probably unplug a PSI just to make it easier) without following
that procedure. I agree it's probably a more conservative and safer
procedure to disconnect/power it off first, but I don't agree that
you'll actually cause physical damage by not following it.
> Right, you first switch the PSU off, unplug it from wall, then let it
> discharge, and then pull it out.
Unless you have the older chassis without the separate cords/switches :-)
> Of course, some earlier TC PSU's might have been not swappable even then,
> but I'm not sure.
They were. Just pull out the PSU slightly until it disconnects from
the midplane - you can see the RN/FL LED dim as the capacitors
discharge - and then remove it fully.
-- 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:(usr-tc) Call Routing From: Martin Oberle <moberle@gmx.de> Date: 1999-02-26 12:01:12
Hi.
Can I route inbound calls based on the number the user dialed
to different modems/gatways on an Total Control Hub (systemrelease 2.5)?
I want to terminate some digital calls on the netserver card for
dial in clients and use a pool of Modems for other dial in services.
What must be configured in the E1/PRI-card?
Thanks
I got it all sorted out. 3Com, sent me a new key.
-----Original Message-----
Sent: Friday, February 26, 1999 3:56 AM
Hi, what cards do you have ??
At 04:39 PM 2/25/99 -0800, you wrote:
>It currently shows as disabled, so I guess I can assume that the card
>doesn't have it. Correct?
>
>-----Original Message-----
>From: Jason [mailto:jwatkins@iland.net]
>Sent: Thursday, February 25, 1999 3:45 PM
>To: usr-tc@lists.xmission.com
>Subject: Re: (usr-tc) X2 NMC Key
>
>
>Load TCM and select the NMC. Then click on
>configure > program settings > added cost features.
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Jason W jwatkins@iland.net
>I-Land NOC Tech http://www.iland.net
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>-----Original Message-----
>From: Jolliffe, Anu <ajolliffe@imagen.net>
>To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com>
>Date: Thursday, February 25, 1999 4:46 PM
>Subject: (usr-tc) X2 NMC Key
>
>
>:We recently purchased a Total Control Rack with X2. How can I confirm
that
>:the NMC has the X2 feature?
>:
>: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.
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the 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-1 and WinNT From: Brian Elfert <brian@citilink.com> Date: 1999-02-26 12:26:46
On Thu, 25 Feb 1999, Paul Jr. (AlaWeb Support) wrote:
> I have also seen this problem... I placed a call to 3com about this and the
> fix they gave me was to turn off IP Header Compression. After doing this NT
> connects fine. I really do not think I should have to turn off IP header
> compression.
NT is picky no matter what term server is used. I've had customers who
had to play around with the various compression items to get NT to connect
to Netserver cards and Portmasters.
Brian
Subject:(usr-tc) 3Com Problems. From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-26 12:36:14
2nd of 2 messages...hang on tight folks...this one's going to be a wild
ride.
Thus spake Phil Le Clercq
>There is a call logged with 3Com Europe no answers yet.
This is a reply to Phil only in the most basic of senses...in that I'm
taking off from his message into my own area. (thus the Subject: change)
As most of you all know, we opened a ticket with 3Com back in April
concerning MPIP on NETServers (58316). MPIP has *never* worked reliably
on NETServers, and because of its ComOS heritage and 3Com's lack of access
to source code at this point, never will. So what is 3Com's response to
this situation? They're telling us to pay to upgrade to HiPer Arc's.
Well, for obvious reasons, we really don't particularly like this
option. What this amounts to is a Bait and Switch. "Here, buy this
product that does x, y, and z." "Oh, this product doesn't do x, y, and
z? Ok, here buy this one then, this one *really* does what you want it
to." This is *particularly* true when you consider 3Com's (lame IMHO)
decision to not back-port HiPer OS to the NETServer hardware, which
would have avoided us having to obtain new hardware to fix a software
problem.
So, what's been done about this so far? Well, about a month ago, we
here at IgLou sat down with our 3Com sales rep and reseller and
explained to them our thoughts on the whole situation. That was about a
2 hour meeting, and that was *before* we went to lunch. :) In that
meeting we covered 3Com's attitudes towards support contracts (a whole
other rant entirely), 3Com's handling of the NETServer to HiPer Arc
upgrade problems, and several other, fairly insignificant, issues.
This message isn't going to deal with the support issues since we found
a way to get the support we need and the only other result is that 3Com
shot themselves in their foot.
This does deal with the NETServer to HiPer Arc upgrade issue. During
our meeting, we expressed to Tom (our 3Com sales rep) our dissatifaction
with 3Com's handling of their current, especially long-term, customers,
particularly in relation to the migration from NETServer to HiPer Arc.
Basically, because 3Com refuses to port and support HiPerOS on the
NETServer hardware, our only choice is to buy HiPer Arc cards to replace
all of our NETServer cards. This amounts to 3Com screwing us over
because we have been customers of theirs long enough to have a large
number of NETServer cards.
We were told (I *believe* by Tom, though I don't remember this
explicitely) that 3Com's idea is that any and all upgrade deals should
be "revenue positive." Meaning that 3Com isn't willing to upgrade our
NETServer's to HiPer Arcs because they won't make any money on it.
Again, this goes back to the Bait and Switch argument I made above.
So, what *is* 3Com willing to do. Well, they are willing to set up
"deals", or promotional bundles. So far, we've seen a few different
promotional bundles that are attempts to get people upgraded from
NETServers to HiPer Arcs. First, there was a bundle where you bought
(again, revenue positive for 3Com) a HiPer Arc, then once you got the
HiPer Arc, you sent them back a NETServer for, I believe, a $3200
rebate/refund. That's OK, nothing spectacular, but OK. It doesn't,
however, change the Bait and Switch argument; 3Com is requiring us to
pay more money to them to fix something that *they* didn't do right in
the first place. Next, they tried to sweeten that promotion by upping
the price of it slightly and adding a HiPer DSP to the deal. While this
is a nice deal if you're trying to increase your total number of ports,
for us to participate in this deal would mean, 1) we're still paying
(Bait and Switch) to get a fix, and 2) we're going to end up with a
fairly significant number of extra ports after the upgrade.
Again, we're having to pay more money because 3Com is unwilling to make
the situation right when they failed to deliver the capabilities they
promised.
What do we think 3Com should do?
Primarily, I believe 3Com should ditch this "revenue positive" attitude
that they seem to have. This attitude seems to be pervasive throughout
all of 3Com. The result of this attitude is that 3Com ends up screwing
their longest and most loyal customers. Customers such as us that have
had USR/3Com gear for years have to pay more money to keep our equipment
up to date and to work around bugs that 3Com was unable to fix, and
their poor planning in not having an upgrade path available for the
older equipment. We have a large number of NETServer cards, and the
only three options that we have are to throw that investment into the
trash, try to sell these things used which throws most of our investment
into the trash, or send them back to 3Com for a $3200 rebate on new
purchases, which still throws a significant investment into the trash.
3Com needs to "Do the right thing" here and give us, their longest, and
most loyal, customers a real fix for their problems. That may mean
swapping out NETServers for HiPer Arcs 1 for 1, or it may mean swapping
out NETServers for HiPer Arcs at some smaller ratio and throwing in some
DSP's to make up for the port density problems. I really don't care
*how* 3Com does this, all I know is that I need to get HiPer Arcs on my
network in place of NETServers, and I really don't think I should have
to pay to do it since the only reason I have to do this is because 3Com
couldn't deliver on their promise.
3Com needs to start treating their loyal customers like the assets that
we are, rather than just prospective future customers. If someone asks
me what I think about 3Com, I tell them that we use TC's, then I tell
them that if they can at all avoid it, not to make the same mistake we
did. I tell them that 3Com is an absolute *nightmare* to work with
corporately because they don't care about their current customers at
all. All 3Com seems to care about is where their next source of revenue
is going to be.
Perhaps 3Com is concerned about their stock price, which is at
approximately the same price now that it was 2 years ago, actually, a
little lower! Perhaps their stock price would do better if 3Com's
customers actually *liked* working with them instead of *dreading* it
because they knew they were going to get screwed in the process.
So, what's it going to be 3Com? Are you going to do the right thing?
Are you going to learn to treat your current customers with respect?
Are you going to try to earn the respect of your customers? Or are you
going to continue to treat us as another source of revenue, regardless
of how you've screwed us over in the past? (Do I need to address future
letters to the Office of the Attorney General?)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:(usr-tc) MPIP problems. From: Phil Le Clercq <phil.le.clercq@cinergy.net> Date: 1999-02-26 12:52:32
Hello all.
Using Netservers 3.8.1 and quads 5.9.9
I have been setting up MPIP across chassis and subnets, and thanks to this
list it works ok, well sort of....
It only works for a day give or take. I thought I had narrowed it down to
using a remote timeserver, and the possibility of lack of synchronisation.
So I set up a time server on my LAN and the netservers all get the correct
time from it. The trouble is after I have set MPIP up the only way it will
work is after a reboot of the MPIP clients. Using reset time does not do the
job, so there is the chance that time sync. is not the problem. I know Jeff
is the MPIP Netserver king so I was wondering if any one had any ideas?
There is a call logged with 3Com Europe no answers yet.
Cheer's
Phil
Cinergy Communications
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-26 13:02:00
-> >
-> >-> I have also seen this problem... I placed a call to 3com about this and
-> the
-> >-> fix they gave me was to turn off IP Header Compression. After doing
-> this NT
-> >-> connects fine. I really do not think I should have to turn off IP
-> header >-> compression.
-> >
-> >How about having your NT users turn it on ? By default I have all of our
-> users
-> >turn it on and we've never had a problem with it.
->
-> Where do you specify compression being on with your side? How does it
-> handle people who have it off?
We do it for the default FRAMED-PPP user in RADIUS. I think folks who have it
turned off can't connect but we have them always turn it on when we set them up
initially.
Jeff Binkley
ASA Network Computing
Subject:RE: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Robert von Bismarck <rvb@petrel.ch> Date: 1999-02-26 13:10:19
huh ?
It seems to me that the PSU's are made to be hot swapped. Take one out,
check the connector that goes into the chassis. You will see that one =
pin is
longer than the others, and this is almost certainly for ground =
balancing
when you plug it into the chassis.
Robert
PS : what are dual redundant power supplies good for, when you can't
hot-swap 'em ? Same as in RAID arrays, what are multiple redundant =
disks
good for, if you can't hot swap 'em ?
> -----Original Message-----
> From: Ricky Beam [SMTP:jfbeam@enterprise.interpath.net]
> Sent: jeudi, 25. f=E9vrier 1999 23:05
> To: usr-tc@lists.xmission.com
> Subject: Re: (usr-tc) More than 10 DSPs in one HiperARC chassis
>=20
> Curt Shambeau was heard to say:
> >I'm positive they load share - I plug each power supply into a =
seperate
> >UPS. Turn them both on, there is load on each UPS.
>=20
> Despite what the sales drones may say, the power supplies are load =
shared.
> There is no associated logic that I've been able to find on the =
midplane
> for electrical cross-overs or what not. PLUS, there's ample =
documents
> instructing the user to NEVER EVER hot swap a power supply -- i.e. =
never
> change the power supply in a powered chassis.
>=20
> >I did this on over 40 chassis - full 96 calls on a box with no =
problems
> at
> >all. I believe it is rated to do this in 70A.
> ...
>=20
> There is a power utilization chart from 3Com somewhere in the ARC
> documents
> as I recall (I got one directly from 3Com) that tells you what each =
card
> in the chassis requires as well as what each power supply can =
support.
> Just do the math. (Assume there is some safety margin in the =
numbers.)
>=20
> --Ricky
>=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.
Subject:Re: (usr-tc) 4.1.59-1 and WinNT From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1999-02-26 13:59:00
-> > I have also seen this problem... I placed a call to 3com about this and
-> the > fix they gave me was to turn off IP Header Compression. After doing
-> this NT > connects fine. I really do not think I should have to turn off IP
-> header > compression.
->
-> NT is picky no matter what term server is used. I've had customers who had
-> to play around with the various compression items to get NT to connect to
-> Netserver cards and Portmasters.
Brian,
Perhaps but we've never had a single problem reported on them. Now the
Winmodems, that's another story. NT seems to be better than 95 in a lot
of instances, especially with respect to stability of the protocol stack.
Jeff Binkley
ASA Network Computing
Jeff Mcadams was heard to say:
>As most of you all know, we opened a ticket with 3Com back in April
>concerning MPIP on NETServers (58316). MPIP has *never* worked reliably
>on NETServers, and because of its ComOS heritage and 3Com's lack of access
>to source code at this point, never will. So what is 3Com's response to
>this situation? They're telling us to pay to upgrade to HiPer Arc's.
And even when they did, they didn't fix it... they were too busy working
on Pilgrim (the hiperARC code.)
>This is *particularly* true when you consider 3Com's (lame IMHO)
>decision to not back-port HiPer OS to the NETServer hardware, which
>would have avoided us having to obtain new hardware to fix a software
>problem.
Well, something tells me Pilgrim is so hideously inefficient that you would
not want to see it running on a NetServer -- however I think they did port
it to some of the netserver/i models. I'm not familiar with that hardware.
>Basically, because 3Com refuses to port and support HiPerOS on the
>NETServer hardware, our only choice is to buy HiPer Arc cards to replace
>all of our NETServer cards. This amounts to 3Com screwing us over
>because we have been customers of theirs long enough to have a large
>number of NETServer cards.
You cannot blame a company for dropping support for clearly out dated
hardware. The Netservers are 10 year old technology -- 486s. Why would
any company devote large amounts of resources to keeping old shit out there
when they _really_ don't want that junk to still be out there?
Did you go around screaming when Microsoft dropped support for several other
platforms?
>We were told (I *believe* by Tom, though I don't remember this
>explicitely) that 3Com's idea is that any and all upgrade deals should
>be "revenue positive." Meaning that 3Com isn't willing to upgrade our
>NETServer's to HiPer Arcs because they won't make any money on it.
>Again, this goes back to the Bait and Switch argument I made above.
No, it goes back to a business that has to make money. What you are arguing
for is a free upgrade path. That's like going to Dell and arguing that you
want a free upgrade from a PPro to a PII machine. 3Com is dropping support
for the netserver - period. As of 2/26/1999, 3Com no longer services
netservers.
Companies move forward with new technologies. They cannot continue to support
the old stuff for ever -- if they try to then they end up with MacOS... And
you cannot expect them to out-right give you the new wiz-bang hardware for
free.
[deals...]
In this respect, I think 3Com is trying to be reasonable here. Do the math.
After all is said and done, the cost of the new ARC is around 2k$ depending
on your particular discount with 3Com or dealer. We could have upgraded
our entire dialup network for somewhere around 100k$. That's an order
of magnitude less than it will cost to replace it with someone else's
hardware. And when you add in personel and training... switching your
dialup hardware is major expense and pain in the ass. (We've done it once
and about to do it again.)
>Again, we're having to pay more money because 3Com is unwilling to make
>the situation right when they failed to deliver the capabilities they
>promised.
And what did they fail to deliver? MPIP works. It just doesn't work
very well.
> Customers such as us that have
>had USR/3Com gear for years have to pay more money to keep our equipment
>up to date and to work around bugs that 3Com was unable to fix, and
>their poor planning in not having an upgrade path available for the
>older equipment.
What you appear to be expecting is a free migration path...
eg. 286 -> 386 -> 486 -> Pentium -> PPro -> PII -> PIII
It costs money to support stuff. I assume you charge your customers.
Do you give your customers a free technological upgrade path?
> We have a large number of NETServer cards, and the
>only three options that we have are to throw that investment into the
>trash, try to sell these things used which throws most of our investment
>into the trash, or send them back to 3Com for a $3200 rebate on new
>purchases, which still throws a significant investment into the trash.
No, it's an investment to keep the existing investment worth something.
The money sunk into the netserver hardware years ago is gradually dwindling
to nothing. It's the same with your aging desktop computers; how much did
you pay for a 486dx2-66 "power house" a few years ago and what's it worth
today?
Don't whine about your investment becoming worthless. It's not worthless
to you simply because of the amount of time and money spent in building it
and the same that it will take to replace it. Even if you completely
replaced all of the 3Com hardware, the same thing will happen on down the
road.
Would Cisco upgrade a 2500 series router to a 2600 series router for free?
The answer is "hell no". It's next to impossible to get any measurable
discount out of Cisco -- talk about revenue anal people...
> it may mean swapping
>out NETServers for HiPer Arcs at some smaller ratio and throwing in some
>DSP's to make up for the port density problems.
True, you don't need a hiperARC to drive 48 modems. I'd expect some sort
of deal to increase the density of ports on the hiperARC. But, in some
places, DSP hardware makes no sense.
> I really don't care
>*how* 3Com does this, all I know is that I need to get HiPer Arcs on my
>network in place of NETServers, and I really don't think I should have
>to pay to do it since the only reason I have to do this is because 3Com
>couldn't deliver on their promise.
Apparently you *do* care...
>3Com needs to start treating their loyal customers like the assets that
>we are, rather than just prospective future customers. If someone asks
I would just like to interject a distinction between USR and 3Com...
Most (if not all) of the current problems can be traced back to everything
being run by 3Com. It takes time for the dust to settle. And it takes time
for USR customers to get used to dealing with 3Com instead of USR.
>me what I think about 3Com, I tell them that we use TC's, then I tell
>them that if they can at all avoid it, not to make the same mistake we
>did. I tell them that 3Com is an absolute *nightmare* to work with
>corporately because they don't care about their current customers at
>all. All 3Com seems to care about is where their next source of revenue
>is going to be.
Well, 3Com corp. aside, USR makes some damn good dialup hardware. Lucent
is about the only ones I know of that rival the USR toys. (and cisco ain't
even on the map.)
--Ricky
With all the problems with 4.1.59-1 we've seen on the list, I'm reluctant to
make this change, but I now have my first GeoBook customer. When will the
later versions like 4.1.59-5 be available for download?
Wayne Barber
Coastal Telco Services
> -----Original Message-----
> From: owner-usr-tc@lists.xmission.com
> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ray Bagby
> Sent: Thursday, February 25, 1999 10:40 PM
> To: usr-tc@xmission.com
> Subject: Fw: (usr-tc) geo-book connect
>
>
> Well, that must be my problem. I'm running 4.1.72. I understand
> that a newer
> release would have a smaller number right? So I need to go to
> 4.1.59 for the
> Arc. OK
>
> Thanks!
>
>
> -----Original Message-----
> From: Paul Jr. (AlaWeb Support) <jr@alaweb.com>
> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
> Date: Thursday, February 25, 1999 7:01 PM
> Subject: Re: (usr-tc) geo-book connect
>
>
> >I am useing the 4.1.59 on my Hiper Arc. This problem seems to only be
> >isolated to NT users.
> >
> >
> >Thanks
> >Paul JR.
> >AlaWeb Network Admin.
> >1800-427-8896
> >http://www.alaweb.com/support.html
> >
> >
> >
> >
> >----- Original Message -----
> >From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
> >To: Ray Bagby <rbagby@yore.net>
> >Cc: <usr-tc@xmission.com>
> >Sent: Thursday, February 25, 1999 6:59 PM
> >Subject: Re: (usr-tc) geo-book connect
> >
> >
> >>What version of HiPer arc code you are using?
> >>4.1.59 has fixes for the lcp retransmission problem that geo-book has
> >>
> >>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, 25 Feb 1999, Ray Bagby wrote:
> >>
> >>> Greetings,
> >>> I am having trouble connecting a client who is using a Brother
> >Geo-Book.
> >>> I'm using a TC chassis with HiPer ARC and DSP. No trouble with Anyone
> >before
> >>> this. The Brother folks say I need to assign IP and mask and
> gateway but
> >I
> >>> work with a pool.
> >>> Anyone have a suggestion?
> >>>
> >>> 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.
> >>
> >
> >
> >
> >
> >-
> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> > with "unsubscribe usr-tc" in the body of the 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.
>
On Fri, 26 Feb 1999, Jeff Mcadams wrote:
> The other workaround is to reboot the MPIP *server*. This, obviously,
If your MPIP server is an ARC, I found a slightly less drastic way to do
this -- "set mpip server_state off" followed by "set mpip server_state on"
turns the MPIP server off then back on. That clears the whole bundle list
without rebooting the whole card and knocking all your single-channel
users off of that ARC. (It still screws up any live multilink users of
course... but it saves you from needing a dedicated MPIP server.)
I never got to try the NETserver equivalent to see if it would have the
same effect.
What I ended up doing about 2 months ago was writing a Perl script to list
all the bundles on the MPIP server ("list mpip bundle" on an ARC), then
check all the NETservers and ARCs to make sure all the listed people were
really still there (using pmwho and arcwho). If it finds a non-empty
bundle list, but sees none of the listed users online at all, then it
resets the MPIP server as above. So it may take longer to fix the problem
when it does pop up (because you have to wait for everyone to log off),
but when it does, you can fix without any disruption.
For what it's worth, though... ever since we got rid of all our NETservers
2 weeks ago, the stale bundle problem has almost completely disappeared.
We do still have a few random cases where the users can only bring up one
channel, but the Err=36 that kept them from logging in *at all* sometimes
seems to be fixed now that we're an all-ARC shop (4.1.59-1).
I totally agree with your rant, and I'm not saying I particularly
*enjoyed* having to pay $13100 (minus $6400 in rebates we're still waiting
for) to get that fix -- however, in our case we did actually need the two
DSP's, and so in the end it ends up being $6700 for two DSP's and
essentially a free NETserver-to-ARC upgrade... so it worked out being a
good deal for us. If you don't need the DSP's though then it's not such a
great deal.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:Re: (usr-tc) More than 10 DSPs in one HiperARC chassis From: Andres Kroonmaa <andre@ml.ee> Date: 1999-02-26 14:51:22
On 25 Feb 99, at 18:52, Ronald E. Kushner <usr-tc@lists.xmission.com> wrot=
e:
> Ricky Beam wrote:
> >
> > Curt Shambeau was heard to say:
> > >I'm positive they load share - I plug each power supply into a sepera=
te
> > >UPS. Turn them both on, there is load on each UPS.
> >
> > Despite what the sales drones may say, the power supplies are load sha=
red.
> > There is no associated logic that I've been able to find on the midpla=
ne
> > for electrical cross-overs or what not. PLUS, there's ample documents
> > instructing the user to NEVER EVER hot swap a power supply -- i.e. nev=
er
> > change the power supply in a powered chassis.
What they mean is NEVER EVER muck round with PSU plugged into wall and
switched ON. If you pull the PSU that is under the load out of the chassi=
s,
you'll get what you deserve: bright welding flash along with all the dama=
ge.
> Actually, the documentation says PSU's are hot swapable.
>
> To quote again:
>
> > 1 Determine if power needs to be removed:
> > WARNING: Wait 10 seconds to allow all capacitors on the PSI to
> > discharge=97do not touch the PSI during this period. After 10 seconds,
> > the PSI can be removed, however components such as the heat sinks may
> > still be very hot. The capacitors are fully discharged when the RUN/FA=
IL
> > (RN/FL) LED turns off.
Right, you first switch the PSU off, unplug it from wall, then let it
discharge, and then pull it out.
All this while the remaining PSU is providing power to the chassis.
I've done this and it all went very smooth.
Of course, some earlier TC PSU's might have been not swappable even then,
but I'm not sure.
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Network Manager
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
It's definitely not everyone. It has been working fine until today. We are
also getting a lot of users that are not able to handshake at all. Must be
a problem at the switch I guess.
-----Original Message-----
>Generally correct. It could be a "line-side" T1, but then EVERYONE that
>tries x2/V.90 would get that result.
>
>On Fri, 26 Feb 1999, Mike Andrews wrote:
>
>> Nope... Bad local loop on the client end, or a non-optimal SLC setup, or
>> something else that puts extra D/A conversions on their line that keep
>> x2/v.90 from working.
>>
>>
>> Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort
KY
>> mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see
me
>> getting beaten by the police, put down the video camera and come help
me!"
>>
>> On Fri, 26 Feb 1999, Theodore Cekan wrote:
>>
>> > What would cause an x2 Status value of excessiveHFAttenuation(12)? Is
this
>> > a T1 problem?
>> >
>> > Ted
>>
>>
>> -
>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
>> with "unsubscribe usr-tc" in the body of the 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) Preferences in RADIUS servers From: Phil Dye <pmd@tcp.net.uk> Date: 1999-02-26 15:34:08
On Fri, Feb 26, 1999 at 08:12:26AM -0600, Al Huefner wrote:
>
> Dave, you should put these out on our forum first and then forward the email
> copy to the usr-tc list. This will provide all the usr-tc users with the URL
> links that are now at the bottom of our forum emails. You should keep doing
> that with every opportunity to provide suttle encouragement to move to our site.
> --- AL
>
Hmm, /me thinks someone didn't really mean to send this to the list... ;->
Such is the problem of setting Reply-To to the list.
--
Phil Dye | Work: pmd@tcp.net.uk
Network Manager | Play: phil@dye.net ICQ: 21191147
Total Connectivity Providers | Consider myself properly disclaimed
"The team building will continue until morale improves" - simes
Generally correct. It could be a "line-side" T1, but then EVERYONE that
tries x2/V.90 would get that result.
On Fri, 26 Feb 1999, Mike Andrews wrote:
> Nope... Bad local loop on the client end, or a non-optimal SLC setup, or
> something else that puts extra D/A conversions on their line that keep
> x2/v.90 from working.
>
>
> Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
> getting beaten by the police, put down the video camera and come help me!"
>
> On Fri, 26 Feb 1999, Theodore Cekan wrote:
>
> > What would cause an x2 Status value of excessiveHFAttenuation(12)? Is this
> > a T1 problem?
> >
> > Ted
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
On Friday, February 26, 1999 3:22 PM, Ricky Beam
[SMTP:jfbeam@enterprise.interpath.net] wrote:
> >Again, we're having to pay more money because 3Com is unwilling to make
> >the situation right when they failed to deliver the capabilities they
> >promised.
>
> And what did they fail to deliver? MPIP works. It just doesn't work
> very well.
>
I don't know, but I would be righteously pissed if one of the reasons I
bought USR/3Com hardware was because it claimed to do MPIP and then came to
find out that it didn't work consistently. I would be demanding a full
refund the moment I found out that it was a problem unless I was promised
that a fix was in the works. And I'd REALLY be righteously pissed if the
promise was made and then was told that, due to licensing issues, there
would be no fix and I would have to dump more money into hardware in order
to do the job that the original hardware was supposed to do.
I'd be interested to know if it could be proven in court that, if the ma
nufacturer was claiming a particular attribute of their product in order to
make the product more sellable, and it turned out to be a false claim,
whether the customer would be due at least a partial refund. I believe it
could be but I'm no lawyer.
Matthew....
Nope... Bad local loop on the client end, or a non-optimal SLC setup, or
something else that puts extra D/A conversions on their line that keep
x2/v.90 from working.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Fri, 26 Feb 1999, Theodore Cekan wrote:
> What would cause an x2 Status value of excessiveHFAttenuation(12)? Is this
> a T1 problem?
>
> Ted
Subject:(usr-tc) Hayes Accura - connect failure From: Fred Williams <fwilliams@gtnet.gov.uk> Date: 1999-02-26 16:30:21
We have a user with Hayes Accura 5669GB modem flashed up
with the "latest" V90 code. The version is described as 2.083ho3.
The problem is that the user is unable to get anything better than a
33600 connection when dialling into either Quads with Netserver
or Hiper DSP. He gets the same symptoms with another ISP using
USR kit. When he dials into an Ascend equipped ISP he gets a V90
connection.
Does anyone have any (sensible) suggestions 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) 3Com Problems. From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-26 17:31:38
Somebody Drowned on Bushisle road today...I do not know who....
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
http://www.alaweb.com/support.html
----- Original Message -----
Sent: Friday, February 26, 1999 5:24 PM
>Bob Purdon was heard to say:
>>> That's like going to Dell and arguing that you want a free upgrade
>>> from a PPro to a PII machine.
>>
>>If I had a PPro that didn't work right, then I'd do the same - not
>>necessarily to a PII, but to something equivalent that worked.
>
>There isn't anything "equivalent" to a netserver. The ARC is a much more
>powerful platform -- and 3Com has a right to at least break-even on it.
>
>>> Companies move forward with new technologies. They cannot continue to
>>> support the old stuff for ever -- if they try to then they end up with
>>> MacOS... And you cannot expect them to out-right give you the new
>>> wiz-bang hardware for free.
>>
>>I don't think anyone is arguing with that. The point is that MPIP has
>>never been stable, despite it being sold as a working system. 3COM need
>>to fix that issue. As a customer, I don't care how they do it, as long as
>>I don't have to pay any more for something I bought in good faith.
>
>If that's the case, then I think you have a good chance to get a good deal
>on upgrading your hardware. There's simply not going to be a fix for the
>MPIP problems in the netserver code. If the problem is in the server side
>of the code, then it can be fixed external to the netserver. However, I've
>not had time to dig into the MPIP server stuff.
>
>>If they were broken, didn't meet the manufacturer's own specifications,
>>and weren't going to be fixed, then yes. Didn't Intel give a free swap-out
>>to people with broken Pentium's a while back? It was broken, couldn't be
>>fixed, so they swapped it for a good part?
>
>Yes they did, only after people sued them. And then, you sent in a P90,
>Intel sent back a P90. In this case, you're sending in a 486 and getting
>back a PPC.
>
>--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) 3Com Problems. From: Paul Jr. (AlaWeb Support) <jr@alaweb.com> Date: 1999-02-26 17:36:16
Sorry Guys.. I hit reply on the wrong email..Please ignore the previous
email from me.
Thanks
Paul JR.
AlaWeb Network Admin.
1800-427-8896
http://www.alaweb.com/support.html
----- Original Message -----
Sent: Friday, February 26, 1999 5:31 PM
>Somebody Drowned on Bushisle road today...I do not know who....
>
>
>
>Thanks
>Paul JR.
>AlaWeb Network Admin.
>1800-427-8896
>http://www.alaweb.com/support.html
>
>
>
>
>----- Original Message -----
>From: Ricky Beam <jfbeam@enterprise.interpath.net>
>To: <usr-tc@lists.xmission.com>
>Sent: Friday, February 26, 1999 5:24 PM
>Subject: Re: (usr-tc) 3Com Problems.
>
>
>>Bob Purdon was heard to say:
>>>> That's like going to Dell and arguing that you want a free upgrade
>>>> from a PPro to a PII machine.
>>>
>>>If I had a PPro that didn't work right, then I'd do the same - not
>>>necessarily to a PII, but to something equivalent that worked.
>>
>>There isn't anything "equivalent" to a netserver. The ARC is a much more
>>powerful platform -- and 3Com has a right to at least break-even on it.
>>
>>>> Companies move forward with new technologies. They cannot continue to
>>>> support the old stuff for ever -- if they try to then they end up with
>>>> MacOS... And you cannot expect them to out-right give you the new
>>>> wiz-bang hardware for free.
>>>
>>>I don't think anyone is arguing with that. The point is that MPIP has
>>>never been stable, despite it being sold as a working system. 3COM need
>>>to fix that issue. As a customer, I don't care how they do it, as long
as
>>>I don't have to pay any more for something I bought in good faith.
>>
>>If that's the case, then I think you have a good chance to get a good deal
>>on upgrading your hardware. There's simply not going to be a fix for the
>>MPIP problems in the netserver code. If the problem is in the server side
>>of the code, then it can be fixed external to the netserver. However,
I've
>>not had time to dig into the MPIP server stuff.
>>
>>>If they were broken, didn't meet the manufacturer's own specifications,
>>>and weren't going to be fixed, then yes. Didn't Intel give a free
swap-out
>>>to people with broken Pentium's a while back? It was broken, couldn't be
>>>fixed, so they swapped it for a good part?
>>
>>Yes they did, only after people sued them. And then, you sent in a P90,
>>Intel sent back a P90. In this case, you're sending in a 486 and getting
>>back a PPC.
>>
>>--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.
>>
>
>
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Bob Purdon was heard to say:
>> That's like going to Dell and arguing that you want a free upgrade
>> from a PPro to a PII machine.
>
>If I had a PPro that didn't work right, then I'd do the same - not
>necessarily to a PII, but to something equivalent that worked.
There isn't anything "equivalent" to a netserver. The ARC is a much more
powerful platform -- and 3Com has a right to at least break-even on it.
>> Companies move forward with new technologies. They cannot continue to
>> support the old stuff for ever -- if they try to then they end up with
>> MacOS... And you cannot expect them to out-right give you the new
>> wiz-bang hardware for free.
>
>I don't think anyone is arguing with that. The point is that MPIP has
>never been stable, despite it being sold as a working system. 3COM need
>to fix that issue. As a customer, I don't care how they do it, as long as
>I don't have to pay any more for something I bought in good faith.
If that's the case, then I think you have a good chance to get a good deal
on upgrading your hardware. There's simply not going to be a fix for the
MPIP problems in the netserver code. If the problem is in the server side
of the code, then it can be fixed external to the netserver. However, I've
not had time to dig into the MPIP server stuff.
>If they were broken, didn't meet the manufacturer's own specifications,
>and weren't going to be fixed, then yes. Didn't Intel give a free swap-out
>to people with broken Pentium's a while back? It was broken, couldn't be
>fixed, so they swapped it for a good part?
Yes they did, only after people sued them. And then, you sent in a P90,
Intel sent back a P90. In this case, you're sending in a 486 and getting
back a PPC.
--Ricky
Subject:(usr-tc) connecting to hdm console or quad/dsp for outbound From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-26 23:19:08
I've seen some hints in ARC documentation/release notes that say there's a
way to connect to an HDM console through the ARC somehow (presumably over
the packet bus)... but I can't find the exact syntax anywhere. This
would save me a few serial ports...
I'm also trying to figure out how to connect to a particular Quad (or DSP)
to feed it AT commands. I have a channel on a Quad I suspect is dead and
I'm trying to poke at it a bit to see if it's really dead...
Someone want to point me at the relevant chunk of documentation? Maybe
"search" in Acrobat just doesn't work well, but I'm having trouble finding
it. (Call me blind.)
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Bob Purdon was heard to say:
>> If the problem is in the server side of the code, then it can be fixed
>> external to the netserver. However, I've not had time to dig into the
>> MPIP server stuff.
>
>I thought the code you had was based on the NETserver's code anyway, in
>which case it'd surely be covered by the Lucington license, and you'd be
>unable to use it (as would 3COM)?
First, I signed no NDA, so... Second, I don't think the MPIP is part of
Livingston's code -- it's USR's mess.
>It's not as if this is only a new problem - it raised it's head (on this
>list from memory) only a month or so after we bought our gear. At that
>time the platform was actively supported and code developed. The ARC, to
>my memory, wasn't even a product back then.
>
>I could understand, almost, their attitude if this problem was only
>reported last week. Old hardware, end of life, etc.
The Netserver has been "end of life" for almost two years. When we got the
first TCH here in 3/97, we were made aware then that the netserver was being
replaced. We were under NDA at the time for the project coded "Pilgrim"...
--Ricky
Subject:Re: (usr-tc) connecting to hdm console or quad/dsp for outbound From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-27 01:47:14
Mike Andrews was heard to say:
>I've seen some hints in ARC documentation/release notes that say there's a
>way to connect to an HDM console through the ARC somehow (presumably over
>the packet bus)... but I can't find the exact syntax anywhere. This
>would save me a few serial ports...
##
## HiperDSP Consoles
##
### slot:14
add network service dsp:14 server_type telnetd socket <###> data "service_type=dialout,interface=\"SLOT:14/CON:1\",login_banner=\"\r\nInterpath Communications, Inc.\r\n\",login_prompt=\"DSP:14 Login: \",auth=on"
### slot:15
add network service dsp:15 server_type telnetd socket <###> data "service_type=dialout,interface=\"SLOT:15/CON:1\",login_banner=\"\r\nInterpath Communications, Inc.\r\n\",login_prompt=\"DSP:15 Login: \",auth=on"
>I'm also trying to figure out how to connect to a particular Quad (or DSP)
>to feed it AT commands. I have a channel on a Quad I suspect is dead and
>I'm trying to poke at it a bit to see if it's really dead...
From the arc... do the same thing but change the ''interface='' part to that
interface (slot:3/mod:4 for example)
--Ricky
Bob Purdon was heard to say:
>> First, I signed no NDA, so... Second, I don't think the MPIP is part of
>> Livingston's code -- it's USR's mess.
>
>Ah, yeah, OK.
If you've ever seen parts of the code, you'd know I was being nice. I
generally cannot talk about USR's code without the use of multiple
expletives.
>We bought ours at almost the same time and were told nothing of the sort.
>In fact, the TC chassis was a fairly new product here having only just
>undergone Austel approval (equivalent of FCC I think).
>
>As I recall, the PRI card didn't get Austel approval until after we bought
>the gear. The whole shebang was very much a new product here, and nobody
>said anything about end-of-life.
I could make a crack about oz, but I won't :-)
--Ricky
Thus spake Ricky Beam
>The Netserver has been "end of life" for almost two years. When we got the
>first TCH here in 3/97, we were made aware then that the netserver was being
>replaced. We were under NDA at the time for the project coded "Pilgrim"...
To add some more weight to what Bob has said (and Bob has basically made
all my arguments for me here, thanks Bob!), we weren't told the
NETServer was going to be discontinued until sometime...oh...mid-to-late
last year or so. I distinctly remember being very surprised about this
development during the course of working on the MPIP problem working
with tech support, so that makes it at least after April.
I also can't believe that as large of a company as 3Com would "end of
sales", "end of life", and "end of support" a product so quickly.
Again, 3Com was selling NETServers as recently as 6 months ago!
I'll echo Bob on another point too.
All I want is a fix for MPIP, as I've said before, if they can give me
that fix on the NETServers via a software update, or through some
equipvalent equipment swap-out...hey, more power to them. I am unaware
of any options for 3Com to do that. The only "fix" for MPIP it seems is
to swap-out for the Arcs. All I'm demanding is a fix for MPIP, again, I
don't care how 3Com does it, but to make me pay for it is a Bait and
Switch tactic, and as such, illegal.
I believe this thought was originally brought up during the "Quake Lag"
issues. 3Com was saying the "fix" for Quake Lag was to upgrade to Arcs,
I (and others I believed) brought up the thought that if that was a
"fix" then 3Com should swap out these cards free of charge.
This is even *more* of an issue than the Quake Lag IMHO, since Quake Lag
could, arguably at least, be said that its just a factor of the
NETServer being under-powered (I don't buy that, but it could be
argued). This MPIP problem is *purely* a software issue, it *can't* be
argued that its a performance issue.
An analogy, if you will. You go to buy a car, and the dealership sells
you a car for 15 grand telling you it has air-conditioning in it. You
go drive the car, and on the first hot day, you find that the
air-conditioning doesn't work. You go back to the dealership (the car
is still under warranty even!) and they tell you that they can't work on
that car anymore, but for just 10 grand more, they can upgrade you to a
newer car that *really* will have air-conditioning. I don't know about
you, but I'd be off to talk to my lawyer there...and the Better Business
Bureau...and the Office of the Attorney General...etc.
3Com, if you can fix the air-conditioning in the car I have...great,
more power to you. If you have to give me a new car to give me the
air-conditioning you promised, then that's your problem, not mine.
3Com, do the right thing. Don't screw your long-time, loyal (at least
for now) customers.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
> No, it goes back to a business that has to make money. What you are
> arguing for is a free upgrade path.
No, I think he's arguing for a NETserver with working MPIP, but since 3COM
won't/can't give him that, he wants a platform that *does* work as
advertised.
> That's like going to Dell and arguing that you want a free upgrade
> from a PPro to a PII machine.
If I had a PPro that didn't work right, then I'd do the same - not
necessarily to a PII, but to something equivalent that worked.
> Companies move forward with new technologies. They cannot continue to
> support the old stuff for ever -- if they try to then they end up with
> MacOS... And you cannot expect them to out-right give you the new
> wiz-bang hardware for free.
I don't think anyone is arguing with that. The point is that MPIP has
never been stable, despite it being sold as a working system. 3COM need
to fix that issue. As a customer, I don't care how they do it, as long as
I don't have to pay any more for something I bought in good faith.
> In this respect, I think 3Com is trying to be reasonable here. Do the
> math. After all is said and done, the cost of the new ARC is around
> 2k$ depending on your particular discount with 3Com or dealer. We
> could have upgraded our entire dialup network for somewhere around
> 100k$.
As an upgrade plan, I agree. I find it unreasonable to have to pay US$2k
per card to fix a problem that 3COM could have, and should have, fixed.
> What you appear to be expecting is a free migration path...
> eg. 286 -> 386 -> 486 -> Pentium -> PPro -> PII -> PIII
If they were broken, didn't meet the manufacturer's own specifications,
and weren't going to be fixed, then yes. Didn't Intel give a free swap-out
to people with broken Pentium's a while back? It was broken, couldn't be
fixed, so they swapped it for a good part?
> Would Cisco upgrade a 2500 series router to a 2600 series router for
> free?
I've seen cases where Cisco have replaced hardware where the old hardware
was demonstrated to be below specification. Replaced with a similar unit.
> Well, 3Com corp. aside, USR makes some damn good dialup hardware.
Agreed. They don't write real good MPIP code but...
Regards,
Bob Purdon,
Technical Manager,
Southern Internet Services.
> There isn't anything "equivalent" to a netserver. The ARC is a much
> more powerful platform -- and 3Com has a right to at least break-even
> on it.
As an upgrade, yes. As a problem fix, no. It's their own fault they
can't fix the NETserver - why should I pay for that?
If an upgrade was what I wanted, I'd be happy to pay for it.
> If the problem is in the server side of the code, then it can be fixed
> external to the netserver. However, I've not had time to dig into the
> MPIP server stuff.
I thought the code you had was based on the NETserver's code anyway, in
which case it'd surely be covered by the Lucington license, and you'd be
unable to use it (as would 3COM)?
> Yes they did, only after people sued them. And then, you sent in a
> P90, Intel sent back a P90. In this case, you're sending in a 486 and
> getting back a PPC.
I'm not asking to send in a 486 and get a PPC - I'm asking to get working
MPIP code. If 3COM have to give me a PPC to achieve that, then that's
their problem - they shouldn't have sold me a product with MPIP that
doesn't work properly.
I'm happy to have working MPIP on a 486 NETserver. That's what we paid
for, and that's all I'm asking for.
It's not as if this is only a new problem - it raised it's head (on this
list from memory) only a month or so after we bought our gear. At that
time the platform was actively supported and code developed. The ARC, to
my memory, wasn't even a product back then.
I could understand, almost, their attitude if this problem was only
reported last week. Old hardware, end of life, etc.
Regards,
Bob Purdon,
Technical Manager,
Southern Internet Services.
On Sat, 27 Feb 1999, Jeff Mcadams wrote:
> 3Com, if you can fix the air-conditioning in the car I have...great,
> more power to you. If you have to give me a new car to give me the
> air-conditioning you promised, then that's your problem, not mine.
This wouldn't be a stuble hint to package air-conditioning with those hot
Netserver racks, would it? :-)
(sorry, couldn't resist)
---
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
What switch(es) do I need to flip to erase the netserver card?
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) connecting to hdm console or quad/dsp for outbound From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1999-02-27 16:19:05
On Fri, 26 Feb 1999, Mike Andrews wrote:
> I've seen some hints in ARC documentation/release notes that say there's a
> way to connect to an HDM console through the ARC somehow (presumably over
> the packet bus)... but I can't find the exact syntax anywhere. This
> would save me a few serial ports...
This is available with the beta code of HDM and the current HiPer arc code.
You can set a console port on the hiper arc - basically set it up as a
telnet port and then telnet to that port. The info is available on yadda
yadda search - http://interproc.ae.usr.com/tkb.html
>
> I'm also trying to figure out how to connect to a particular Quad (or DSP)
> to feed it AT commands. I have a channel on a Quad I suspect is dead and
> I'm trying to poke at it a bit to see if it's really dead...
>
You can send at commands to the modems with hiper arc
set swi inter slot:x/mod:y at ati4
will give you the necessary result.
krish
> Someone want to point me at the relevant chunk of documentation? Maybe
> "search" in Acrobat just doesn't work well, but I'm having trouble finding
> it. (Call me blind.)
>
>
> Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
> mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
> getting beaten by the police, put down the video camera and come help me!"
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Dip switch 5
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Sat, 27 Feb 1999, Greg Coffey wrote:
> What switch(es) do I need to flip to erase the netserver card?
>
> 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
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
> First, I signed no NDA, so... Second, I don't think the MPIP is part of
> Livingston's code -- it's USR's mess.
Ah, yeah, OK.
> The Netserver has been "end of life" for almost two years. When we
> got the first TCH here in 3/97, we were made aware then that the
> netserver was being replaced.
We bought ours at almost the same time and were told nothing of the sort.
In fact, the TC chassis was a fairly new product here having only just
undergone Austel approval (equivalent of FCC I think).
As I recall, the PRI card didn't get Austel approval until after we bought
the gear. The whole shebang was very much a new product here, and nobody
said anything about end-of-life.
They did some very attractive pricing on it, but then so did Cisco...
Regards,
Bob Purdon,
Technical Manager,
Southern Internet Services.
Subject:Re: (usr-tc) 3Com Problems. From: Paul M. Oster <devious@minot.com> Date: 1999-02-28 00:24:13
Ok here's one for you, another example of 3com's deplorable bait and
switch manuvering... I did buy a Hyper-Arc upgrade (I wanted the DSP
ports for my Arc chassis) pop the arc in a netserver chassis and 1/2 the
quad modems quit responding... I call 3com inside my 90 day support
windows, and I"m told my quad code is not current and I need to upgrade to
get the modems to work correctly with the Arc. Login to totalservice to
grab the code, and surprise I'm locked out (my contracts did expire, and I
REFUSE to pay for a contract on something they wont support anyway (the
netserver chassis) Call up tech support again and I'm told I have to pay
another 1500 for a support contract on the chassis to get to the code (900
when I talked to my reseller for software only)...
Now, all you 3com people on this list... WHY do I have to pay for code
to make your Arc work as promised...
2 hours later, I'm digging through tapes off my NT server and I find out
I have the code (lucky for me)
Maybe to elminate issues like this you should give us 1Arc, and 3dsp's
for the 3300 bucks and we send back a netserver and 12 quads...
And the other pet peeve is that the "upgrade" I pay for does not have
all the features I'm used to on the Netservers... but thats another rant
entirely....
On Sat, 27 Feb 1999, Bryan Wann wrote:
> On Sat, 27 Feb 1999, Jeff Mcadams wrote:
>
> > 3Com, if you can fix the air-conditioning in the car I have...great,
> > more power to you. If you have to give me a new car to give me the
> > air-conditioning you promised, then that's your problem, not mine.
>
> This wouldn't be a stuble hint to package air-conditioning with those hot
> Netserver racks, would it? :-)
>
>
> (sorry, couldn't resist)
>
>
> ---
> 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
>
>
> -
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
Paul M. Oster was heard to say:
> Now, all you 3com people on this list... WHY do I have to pay for code
>to make your Arc work as promised...
The "as promised" part includes chassis software release versions. Get an
older rev of ARC code and the quads will work just fine. They don't bundle
TCS versions for nothing.
> And the other pet peeve is that the "upgrade" I pay for does not have
>all the features I'm used to on the Netservers... but thats another rant
>entirely....
Yes, there's not a one-to-one between the netserver and the ARC. I was
unhappy with it, too. But, once you get used to the ARC interface, it's
no different than the netserver. (Idle time is about the only thing you
cannot get at.) It takes some getting used to not having all the stuff
in one neat package ("show all" and "show sessions"), but you'll get used
to it. (I still miss the netblazer interface.)
--Ricky
At 12:36 PM 2/26/99 -0500, Jeff Mcadams wrote:
>Primarily, I believe 3Com should ditch this "revenue positive" attitude
>that they seem to have. This attitude seems to be pervasive throughout
>all of 3Com. The result of this attitude is that 3Com ends up screwing
>their longest and most loyal customers. Customers such as us that have
>had USR/3Com gear for years have to pay more money to keep our equipment
>up to date and to work around bugs that 3Com was unable to fix, and
>their poor planning in not having an upgrade path available for the
>older equipment. We have a large number of NETServer cards, and the
>only three options that we have are to throw that investment into the
>trash, try to sell these things used which throws most of our investment
>into the trash, or send them back to 3Com for a $3200 rebate on new
>purchases, which still throws a significant investment into the trash.
>
How about this idea Jeff.. Purchase the upgrade, send in your netserver
for the rebate, then sell off the HDM.. Since standalone HDM's are not
cheap, I bet you could the the "free" upgrade you desire albeit with a
little leg work...
I know I'd be happy to pay $3200 ea for HDM's.. We now have a dozen or
more chassis stripped of HDM's.. I'd really like to just purchase HDM's
and I'd even be willing to swap an ARC or two for HDM's..
When it comes to USR upgrades, you just have to be a little inventive
and imaginative.. and a little compromising... I was able to upgrade
all our netservers to arcs one year ago without too much pain, and there
was NO upgrade path at all at that time.. Sure we had to hustle a little,
but it sure was worth it to get rid of Quake lag, broke MPIP, etc.. I
really don't care which direction the relief comes from as long as
it gets there.. :)
I really fought hard for that upgrade path Jeff, and I didn't even get
to take advantage of it myself.. It just hurts a little to see someone
less happy and yet better positioned to fix the problem than we were..
And if the energy spent banging heads with 3COM corporate types is less
than that spent to really *solve the problem*, I'd be surprised.. Not
that I'm against matters of principle, it's just my principles are
tempered by an overall lack of time and energy I guess..
However good luck in your quest, and you really have a good rep (Tom)
on your side. Tom really does care, follow though, and will "go to bat"
for his customers..
<dredging up old memories>
Speaking of promises though, whatever happened to OSPF? not on the
netserver (I'm not completely stupid) but on the ARC? Think we might
see it this year? (or have I just been out of the loop too long) It
sure would be nice to use a decent interior routing protocol besides
RIP...
Allen
Once upon a time Charles Sprickman shaped the electrons to say...
>Word has it that DOVBS is supported in beta now on E1 DSPs but not T1. I
>won't go into the reasons for them stalling on the T1 models, as it would
>make you very angry... If you look at the release history of the code,
No, please do - as this doesn't make any sense. DOSBS is common in the US
but rare in most of the rest of the world. The desire for DOSBS stems
mainly from tarriffing where DATA is per minute and VOICE is not. That
and the desire to take 56K DOSBS over a CT1.
Why would E1 come before T1? If anything the other way makes sense. And
really, I would expect the same code to be involved since it is interface
independent.
I can't imaging a logical reason - what is it?
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
Once upon a time Jeff Mcadams shaped the electrons to say...
>Oh man...I'm not even sure what to say about this...
>BTW, the spelling is "subtle"
You know their forums are 3Com owners only. I was rejected. :-)
Maybe I shouldn't have sold that old NetServer I had collecting dust.
This summer perhaps I'll buy some dead 3Com/USR gear at the MIT flea
and then insist they let me in as an owner. ;-)
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
Once upon a time Pete Ashdown shaped the electrons to say...
>I can change it if so desired. What does everyone else think?
Might as well keep it. If you were starting a new list I wouldn't do
it, but changing behavior on an existing list tends to cause much confusion
and misdirected email.
Besides, we wouldn't get entertaining nuggets like the one that started
this thread. :-)
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
Once upon a time Ricky Beam shaped the electrons to say...
>Bob Purdon was heard to say:
>>If I had a PPro that didn't work right, then I'd do the same - not
>>necessarily to a PII, but to something equivalent that worked.
>powerful platform -- and 3Com has a right to at least break-even on it.
>There isn't anything "equivalent" to a netserver. The ARC is a much more
I disagree. It is not the *customer's* fault that there is nothing\
equivalent.
Someone bought a NetServer which claimed to support MPIP. It is
advertised as a working feature. The fact is it is broken. It is therefore
*defective*. The manufacturer has a responsibility to fix the defect and
make the product do what it was advertised as being capable of. Normally
it would just be a software fix. And it *could* be.
3Com decided NOT to port Pilgrim to the NetServer. Again, this is NOT the
*customer's* fault. It could be a software fix - but 3Com decided NOT to
make it one. That is their decision.
That leaves hardware, which means the HiPer. If that is the only fix, then
so be it. 3Com had the chance to make it work before they lost the ComOS
license. They did not do it. 3Com had the chance to port Pilgrim and
make it a software fix. They did not do it.
None of this is the fault of the customer, and none of it excuses 3Com from
the responsibility of providing a product that performs as advertised, as it
was sold to do so. All that is being asked for is a fix, for the product to
work as advertised. The format of that fix is up to 3Com.
Livingston sold the original ADI modems for the PM-3 and claimed they would
be software upgradable to new modem standards. Well, PCM came out and there
was no codebase for the ADI chipsets. When the decision was made that the
best course of action was new HW, Lucent chipsets, they stood by the
customer and did *free* trades for the new HW. They could have ducked it
by saying no one saw PCM coming and ADI users would have to wait for
someone to code PCM for those chipsets, and sold 'upgrades' to the new HW.
But that isn't a good way to stand by your loyal customers - and this isn't
either.
>Intel sent back a P90. In this case, you're sending in a 486 and getting
>back a PPC.
Too bad, that's 3Com's fault.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
Once upon a time Allen Marsalis shaped the electrons to say...
>Speaking of promises though, whatever happened to OSPF? not on the
>netserver (I'm not completely stupid) but on the ARC? Think we might
Of course, it was originally promised on the NetServer. Just another
'screw you' to people who believed 3Com/USR would keep their word.
But there have been reports here that OSPF is part of the beta for the next
Pilgrim release. So it looks like it is finally poised to appear - at least
on the HiPer.
And Nortel (Bay) finally has it in beta for their next revision as well.
Looks like both are finally joining the modern routing world.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
Once upon a time Ricky Beam shaped the electrons to say...
>The Netserver has been "end of life" for almost two years. When we got the
That's not true. 3Com/USR certainly did not announce an end of life on
the product that long ago. And it was being sold new less than a year ago,
with no announcement of a halt in software development (which had already
happened), let alone HW.
Yes, one can argue that once the HiPer was public knowledge it wasn't had to
deduce that the old HW was on the way out. And those following the license
wrangling know ComOS was a dead issue. But originally it was expected that
Pilgrim would be back ported. And reasonably so. Many vendors have produced
software releases for products that have had no new HW development. Even
Ascend is producing a last TAOS release for the MAX4000 family, and placing
it on maintenance for security and bug fixes.
None of the issues surrounding the NetServer are the customers' fault, but
they are being forced to handle it. 3Com/USR knew well, well in advance that
ComOS was going away. Hell, they got an extra year even. It seems like
the plan to screw existing customers was in place for quite a while - they
knowingly developed the HiPer and Pilgrim with no apparent intent to provide
any option to their existing users. Even while they were *still selling*
NetServers! It is that list piece that really upsets me. They were selling
a product as 'new' knowing they intended to abruptly end of life it, without
so much as fixing known issues. It looks like they were just stalling until
they could ship the HiPer and Pilgrim.
I'm kind of surprised they haven't been sued yet.
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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!
On Sun, 28 Feb 1999, MegaZone wrote:
> And Nortel (Bay) finally has it in beta for their next revision as well.
> Looks like both are finally joining the modern routing world.
And as bad as people claim 3com is, most vendors are worse. OSPF support
is the exception not the rule. Still OSPF is not some magic bullet that
solves all routing problems although some would try to convince you
otherwise.
But the next purchase will not be 3com or Livingston but rather Cisco. :-)
Not that were displeased with 3com Hiper or anything (its nice hardware,
and I like the interface better than ComOS), just that under months of
testing Cisco gave our customers more consistent and stable modem
connections than either Hiper or PM3 and in the end its customer
satisfaction not admin satisfaction that counts. Whatever magic DSP code
Cisco has it works and thats all that matters.
And please no "run code version XYZ it will give better connects than
Cisco" because it doesnt. No code versons on either 3com or Livingston
made appreciably better or worse connections than any other version.
-Dan
Once upon a time Dan Hollis shaped the electrons to say...
>Not that were displeased with 3com Hiper or anything (its nice hardware,
>and I like the interface better than ComOS), just that under months of
>testing Cisco gave our customers more consistent and stable modem
>connections than either Hiper or PM3 and in the end its customer
I presume this was a MICA equipped system and not one using the older
Microcom (Rockwell) boards?
-MZ
--
-=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
<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:Re: (usr-tc) Preferences in RADIUS servers From: Jeff Mcadams <jeffm@iglou.com> Date: 1999-02-28 07:49:45
Thus spake MegaZone
>Once upon a time Jeff Mcadams shaped the electrons to say...
>>Oh man...I'm not even sure what to say about this...
>>BTW, the spelling is "subtle"
>You know their forums are 3Com owners only. I was rejected. :-)
Nah, just point any ol' random news reader at totalservice.usr.com. No
login required. :) To get in through the web interface, login's are
required, but straight nntp access doesn't, and I know you're savvy
enough to handle that. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake Allen Marsalis
>At 12:36 PM 2/26/99 -0500, Jeff Mcadams wrote:
>>Primarily, I believe 3Com should ditch this "revenue positive" attitude
>>that they seem to have. This attitude seems to be pervasive throughout
>>all of 3Com. The result of this attitude is that 3Com ends up screwing
>>their longest and most loyal customers. Customers such as us that have
>>had USR/3Com gear for years have to pay more money to keep our equipment
>>up to date and to work around bugs that 3Com was unable to fix, and
>>their poor planning in not having an upgrade path available for the
>>older equipment. We have a large number of NETServer cards, and the
>>only three options that we have are to throw that investment into the
>>trash, try to sell these things used which throws most of our investment
>>into the trash, or send them back to 3Com for a $3200 rebate on new
>>purchases, which still throws a significant investment into the trash.
>How about this idea Jeff.. Purchase the upgrade, send in your netserver
>for the rebate, then sell off the HDM.. Since standalone HDM's are not
>cheap, I bet you could the the "free" upgrade you desire albeit with a
>little leg work...
Still a *lot* of hassle to take care of this, and the initial
expenditure of the money...even if it is all recouped at the end. To do
full upgrades that way (well, we can't at this point, the Arc + DSP and
return a NETServer promotional bundle expired Fri.) would have cost
$52,000 for us to do the full upgrade...initial expenditures would have
been around $90,000 I believe, and that was assuming that we were actually
going to use the DSP's...would be even more if we were going to sell them.
We're not that big of a shop...we can't afford that.
>I know I'd be happy to pay $3200 ea for HDM's..
Would have to be $4000 to recoup the full cost of the bundle, and that
still doesn't address initial expenditures and time and hassle to deal
with this.
>We now have a dozen or
>more chassis stripped of HDM's.. I'd really like to just purchase HDM's
>and I'd even be willing to swap an ARC or two for HDM's..
Well, that bundle was not a bad deal if you wanted to add more
ports...and indeed we did take advantage of it for that reason (I think
we're getting 5 of those bundles), but to get a bug fix for the
NETServers, its just totally unreasonable.
>When it comes to USR upgrades, you just have to be a little inventive
>and imaginative..
I don't *need* an upgrade though. I *need* a bug-fix for MPIP.
>and a little compromising... I was able to upgrade
>all our netservers to arcs one year ago without too much pain, and there
>was NO upgrade path at all at that time.. Sure we had to hustle a little,
>but it sure was worth it to get rid of Quake lag, broke MPIP, etc.. I
>really don't care which direction the relief comes from as long as
>it gets there.. :)
Yeah, but to have to pay at least $90,000 for this relief (even with
recouping some of it), is not relief.
>I really fought hard for that upgrade path Jeff, and I didn't even get
>to take advantage of it myself..
Yeah, and I've been fighting this battle, with some of the same rants
for almost two months already (Fri. was just the first day I brought it
to usr-tc), and you know what result I've seen so far? Well, we were
told about a promotional deal that is just as poorly thought out as all
the rest have been for this. The idea was to make the upgrade cheaper,
well, the cheapest way for us to have done this upgrade was the arc+dsp
bundle fully...even with the new promo bundle. The new promo bundle
just isn't going to be cost effective for this. We were told that this
promo bundle was a direct result of our complaints through Tom (not
blaming Tom here at all), so 3Com comes up with a bundle that makes it
*more* expensive to get this fix, and discontinues the bundle that's the
cheapest route. And they *still* are making us *pay* for a bug fix for
their broken code!
>It just hurts a little to see someone
>less happy and yet better positioned to fix the problem than we were..
>And if the energy spent banging heads with 3COM corporate types is less
>than that spent to really *solve the problem*, I'd be surprised..
The problem is, is that it doesn't really solve the problem, its yet
another workaround really. If we did this bundle purchase to replace
them all, our problem would then be one of finances, so the problem is
changed, but not solved. It also doesn't solve the problem of 3Com's
apparent "screw the long-time loyal customer" corporate culture. So,
while this may fix the immediate problem, it will only arise again.
>Not
>that I'm against matters of principle, it's just my principles are
>tempered by an overall lack of time and energy I guess..
Well, my principles are saying to bite the bullet and make the painful
and costly transition to AS5200's, 5300's and 5800's and work with a
company that knows how to treat it customers.
>However good luck in your quest, and you really have a good rep (Tom)
>on your side. Tom really does care, follow though, and will "go to bat"
>for his customers..
I agree. Tom is wonderful, but he isn't the decision maker here. I
also know that there are some higher up folks on this list...thus an
effort to make them understand why we're unhappy, since they don't seem
to be listening to thier own sales folks.
><dredging up old memories>
>Speaking of promises though, whatever happened to OSPF? not on the
>netserver (I'm not completely stupid) but on the ARC? Think we might
>see it this year?
Its basically public knowledge that its going to be on 4.2.x.
>(or have I just been out of the loop too long) It
>sure would be nice to use a decent interior routing protocol besides
>RIP...
Agreed...we've got enough RIP being blasted out from our TC racks that
its bring our spiffy new 7507 main CPU to its knees. Would be lovely to
get off that crap.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake MegaZone
>Yes, one can argue that once the HiPer was public knowledge it wasn't had to
>deduce that the old HW was on the way out.
Actually, I'd even argue that...there was no reason for us to believe
that the old hardware was on the way out because we had *explicitly*
been told in the past that Pilgrim/HiPerOS/whatever you want to call it
was going to be back-ported to the NETServer hardware. (I'm still
ticked about that decision. Can you tell? ;)
>It seems like
>the plan to screw existing customers was in place for quite a while - they
>knowingly developed the HiPer and Pilgrim with no apparent intent to provide
>any option to their existing users.
Shoot...it seems like corporate culture there. Have you looked at the
new Palm IIIx's and V's? Guess what? Absolutely *no* upgrade path for
existing Palm owners (I have a Pro), so the "screw the long-time, loyal
customer attitude seems to permeate the company from the biggest product
lines to the smallest.
>Even while they were *still selling*
>NetServers! It is that list piece that really upsets me. They were selling
>a product as 'new' knowing they intended to abruptly end of life it, without
>so much as fixing known issues.
Well, I will say they did *try* to fix MPIP in the NETServers from what
I saw...I got about 4 new code revs. between Sept. and Dec. of last year
in an effort to fix it...it just seems that they were incompetent to do
so.
>It looks like they were just stalling until
>they could ship the HiPer and Pilgrim.
>I'm kind of surprised they haven't been sued yet.
If I hadn't have wanted to get that email out as soon as I did, I really
was going to look up email addresses for the Attorneys General of CA,
IL, and KY (3Com in CA, USR-and thus a large chunk of 3Com that deals
with this stuff in IL, and us in KY), and CC: them on it as well.
Truly, the only reason that I didn't was because we were limited in time
(the arc+dsp bundle expired Fri.) and was *trying* to get that out in
time for 3Com to possibly respond to it...only call I got was from our
tech support person that had been working with us on the MPIP issue and
on getting the features in the Arc that we needed...he's been great, but
again, not in a position to help here...he said he had heard I had been
sending email. :) And the idea of a lawsuit certainly isn't ruled out
here.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Mark R. Lindsey <mark@vielle.datasys.net> Date: 1999-02-28 10:21:54
Jeff, Dan, and other disgruntled TC users:
Let's admit it -- we've been shafted. Between us all, we've tried to use
every variation of equipment and code that 3Com makes for the ISP biz.
In many cases, we've been sorely disappointed.
And I honestly think that our problem hasn't been with the development of
the platform, which has some great strengths and demonstrates the work
of a lot of smart people. OUR PROBLEM IS WITH EVERYTHING AT 3COM
*EXCEPT* THE ENGINEERS.
That's why I hate to have to stop using the product of so many
creative people. But
* We need answers to questions, and
* We need the product that was advertised
and we can't get either, no matter how much we pay. As my boss said on
occasion, ``We can't even *buy* a break.''.
We've been violated, and it hurts. We've put in hours shuffling through
mediocre-to-poor documentation, spent countless days on hold, and rue
the day we heard of Total Control. So it's time to regroup.
If you want to stay in this business, exercise your resourcefulness and
make one more hard decision: Stop Supporting 3Com.
Evaluate the PM3, or the PM4, or the AS5300, or the AS5800. And replace
your current hardware.
Your life will be better. (Mine has.)
You won't hate dialup as much. (We don't.)
Your customers will be more happy. (Ours are.)
You'll be able to get answers to questions. (We do.)
Stop supporting 3Com.
On Sun, 28 Feb 1999, Jeff Mcadams wrote:
> Shoot...it seems like corporate culture there. Have you looked at the
> new Palm IIIx's and V's? Guess what? Absolutely *no* upgrade path for
> existing Palm owners (I have a Pro), so the "screw the long-time, loyal
> customer attitude seems to permeate the company from the biggest product
> lines to the smallest.
Why should 3Com be expected to provide an upgrade to the Palm IIIx and V
from the Pro?
I have a '98 Dodge Intrepid. If Dodge comes out with a 3.3 liter V6 in
2000, should I really expect to be able to go to the dealer and get an
engine upgrade? They could probably do it, but the cost would probably be
more than the car costs new.
The netserver issue is different because the software is defective and
doesn't do what was promised.
Brian
Subject:Re: (usr-tc) Preferences in RADIUS servers From: K Mitchell <mitch@keyconn.net> Date: 1999-02-28 12:19:09
At 10:55 AM 2/25/99 -0600, <David_Cartwright@mw.3com.com> wrote:
>
>Do you use RADIUS in your remote access environment? We're taking a
>poll to better understand your preferences in RADIUS servers. Please
>take a few moments (it shouldn't take anymore than a minute or two) and
>complete the survey located at:
>
>http://totalservice.3com.com/radius.html
>
>Thanks in advance for your time and feedback.
How about a real survey! Was this survey simply an attempt to show that
you care how your customers feel, or do you truly expect to gain enough
information from this to "provide you with the features and information you
want."? Let me propose a few questions to add to the basic "What type of
business are you and what do you use?" questions that are already there;
.Are you satisfied with your current RADIUS server?
.What do you feel are it's shortcomings?
.Would you prefer to run RADIUS on, NT or unix?
.Aside from basic authentication, what features do you feel are most
important to have in a RADIUS server?
.What database would you prefer to use for RADIUS?
.What is your preferred method of adding customers to the RADIUS list?
.Do you feel RADIUS should be included with the purchase of RAS equipment,
or should it cost extra?
.Any additional comments...
This is a short list, I'm sure others could come up with more questions
that would serve much better to give you a true picture of what your
customers want and need.
Kirk "Yes, I am a 3Com customer" Mitchell
Kirk Mitchell-General Manager sysadmin@keyconn.net
Keystone Connect http://www.keyconn.net
Altoona, PA 814-941-5000 We Unlock the World
At 08:14 AM 2/28/99 -0500, Jeff Mcadams wrote:
>Thus spake Allen Marsalis
>>How about this idea Jeff.. Purchase the upgrade, send in your netserver
>>for the rebate, then sell off the HDM.. Since standalone HDM's are not
>>cheap, I bet you could the the "free" upgrade you desire albeit with a
>>little leg work...
>
>Still a *lot* of hassle to take care of this, and the initial
>expenditure of the money...even if it is all recouped at the end.
Well the way I dealt with this was to esblish a Line of Credit at
the bank.. I ended up needing about 30 days float max.. The
interest turned out to be like 80 bux or something.. it was
negligible.. And that LOC has come in handy since.. mainly for
this type of deal.. It's tricky to upgrade something with 0 downtime :)
>To do
>full upgrades that way (well, we can't at this point, the Arc + DSP and
>return a NETServer promotional bundle expired Fri.)
Oh, I didn't know that.. But I think your effort should be to get 3COM
to extend this for you (bet they would) to give you time to make the
above deal.. They may even work with you and a dealer to give you a
one time 30 day account to help float the deal, so you don't have to
go to a bank..
>would have cost
>$52,000 for us to do the full upgrade...initial expenditures would have
>been around $90,000 I believe, and that was assuming that we were actually
>going to use the DSP's...would be even more if we were going to sell them.
>We're not that big of a shop...we can't afford that.
well I guess it just depends on if you really need the extra ports or not..
I think you could sell the HDM for $3.5-4K without much trouble.. Even
if you only got $3.5K, 500 bux/arc ain't to bad to move on.. Lawyers cost
*lots* more than that.. And your time and energy are valuable and could
be spent on marketing and lighting up some extra ports.. :)
>
>>I know I'd be happy to pay $3200 ea for HDM's..
>
>Would have to be $4000 to recoup the full cost of the bundle, and that
>still doesn't address initial expenditures and time and hassle to deal
>with this.
Oh, I was thinking $3.2K for some reason.. Still, we sell/upgrade stuff
all the time. It's not too time consuming.. Just post to this list and
isp-services and stuff.. We sell stuff in minutes sometimes.. Lots quicker
than banging heads with corporate brats and legal council.. IMVHO..
>
>>We now have a dozen or
>>more chassis stripped of HDM's.. I'd really like to just purchase HDM's
>>and I'd even be willing to swap an ARC or two for HDM's..
>
>Well, that bundle was not a bad deal if you wanted to add more
>ports...and indeed we did take advantage of it for that reason (I think
>we're getting 5 of those bundles), but to get a bug fix for the
>NETServers, its just totally unreasonable.
I sure would have liked to have taken advantage of it.. My only real
gripe is spending $6K on our very first ARC... And having some double-
up kits though us into a new $4K blank chassis to house quads.. I
wasted about $12-14K all total looking back.. I figured 3Com would
throw me a bone someday, but it never happened... Instead, we got
a hassle over service contracts.. :-/
>
>>When it comes to USR upgrades, you just have to be a little inventive
>>and imaginative..
>
>I don't *need* an upgrade though. I *need* a bug-fix for MPIP.
I understand and agree.. But if you can compromise your thinking a
little, the end result is the same; fixed MPIP for free or as free
as it's going to get.. Perhaps I'm just cynical that there is little
(affordable) justice in court.. As for working with Corporate types,
I like to try it once or twice.. ;) But time marches on.. I MUST do
what's best for our customers and that's fix problems as cheaply and
quickly as possible.. that usually involves some sort of compromise
or a little spending of money.. But I *DO* avoid the big punches.. :)
And work hard to do so..
>
>>and a little compromising... I was able to upgrade
>>all our netservers to arcs one year ago without too much pain, and there
>>was NO upgrade path at all at that time.. Sure we had to hustle a little,
>>but it sure was worth it to get rid of Quake lag, broke MPIP, etc.. I
>>really don't care which direction the relief comes from as long as
>>it gets there.. :)
>
>Yeah, but to have to pay at least $90,000 for this relief (even with
>recouping some of it), is not relief.
Well, if that doubles your number of ports it might.. However my question
would be if you sold off your hdms (I could have bought them all last week -
we made a $100K purchase), where would you stand?? If it's $5-8K or
something, I can imagine worse.. Now if it's still five figure amounts,
then I agree that bites.. And I'd be pissed too (and have been).. I
*definitely* understand where you are coming from...
>
>>I really fought hard for that upgrade path Jeff, and I didn't even get
>>to take advantage of it myself..
>
>Yeah, and I've been fighting this battle, with some of the same rants
>for almost two months already (Fri. was just the first day I brought it
>to usr-tc), and you know what result I've seen so far? Well, we were
>told about a promotional deal that is just as poorly thought out as all
>the rest have been for this. The idea was to make the upgrade cheaper,
>well, the cheapest way for us to have done this upgrade was the arc+dsp
>bundle fully...even with the new promo bundle. The new promo bundle
>just isn't going to be cost effective for this. We were told that this
>promo bundle was a direct result of our complaints through Tom (not
>blaming Tom here at all), so 3Com comes up with a bundle that makes it
>*more* expensive to get this fix, and discontinues the bundle that's the
>cheapest route. And they *still* are making us *pay* for a bug fix for
>their broken code!
agreed. But I think you could "team up" with another ISP to take the parts
from a bundle that each of you need.. and work out the cost details..
For example if you had purchased the arc+dsp bundle and we paid $3,800
for the dsp's, how would you have come out?.. Perhaps the "partner" could
help with the upfront (float) expense..
>
>>It just hurts a little to see someone
>>less happy and yet better positioned to fix the problem than we were..
>>And if the energy spent banging heads with 3COM corporate types is less
>>than that spent to really *solve the problem*, I'd be surprised..
>
>The problem is, is that it doesn't really solve the problem, its yet
>another workaround really. If we did this bundle purchase to replace
>them all, our problem would then be one of finances, so the problem is
>changed, but not solved.
:) I can appreciate that..
>It also doesn't solve the problem of 3Com's
>apparent "screw the long-time loyal customer" corporate culture. So,
>while this may fix the immediate problem, it will only arise again.
>
yes, but I drew the line based around *this exact moment in time*..
Right now, this second, what are your customers experiencing due to
broke MPIP, Quake Lag, etc.? Our were suffering, and it *really*
sprung me into action.. I brought our customers relief quickly, even if
it took my time and a little money.. Now we dominent market share in
our region and did it in 26 months! We couldn't have done this if I
slowed down and waited on USR/3com... They give me the tools I need to
be a success, but (damn it) I won't depend on them much.. I can't..
They are unreliable and suffer from a credibility problem.. Do I care?
Not until I see my first DOA Hiper product... We have had 100% good luck
thus far.. Obviously, the Hardware design division is in a another
city and drinking from a different municiple water supply than the
software and management teams.. :)
>>Not
>>that I'm against matters of principle, it's just my principles are
>>tempered by an overall lack of time and energy I guess..
>
>Well, my principles are saying to bite the bullet and make the painful
>and costly transition to AS5200's, 5300's and 5800's and work with a
>company that knows how to treat it customers.
well, ok.. plz lemme know how it turns out if you go that route.. I'd
be very interested in your overall experience, your customers reaction,
and the cost effectiveness of your solution.. It's damn bold and gutsy
and I'd love to know what happens... And I agree about Ciscos attitude.
Allen
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Allen Marsalis <am@shreve.net> Date: 1999-02-28 12:51:59
At 10:21 AM 2/28/99 -0500, Mark R. Lindsey wrote:
>
>Jeff, Dan, and other disgruntled TC users:
>
>Let's admit it -- we've been shafted. Between us all, we've tried to use
>every variation of equipment and code that 3Com makes for the ISP biz.
>In many cases, we've been sorely disappointed.
True. And in many cases, we've been greatly advantaged.. Case in point.
We were the first 56K provider in the area and x2 really did work pretty
good.. All the stores sold sportsters and we excelled while kflex never
even got off the ground here.. So it's a firey "love - hate" relationship
I guess.. :)
>
>And I honestly think that our problem hasn't been with the development of
>the platform, which has some great strengths and demonstrates the work
>of a lot of smart people. OUR PROBLEM IS WITH EVERYTHING AT 3COM
>*EXCEPT* THE ENGINEERS.
uh, that's HARDWARE ENGINEERS..
>
>That's why I hate to have to stop using the product of so many
>creative people. But
> * We need answers to questions, and
> * We need the product that was advertised
>and we can't get either, no matter how much we pay. As my boss said on
>occasion, ``We can't even *buy* a break.''.
well, I figure from reading various lists that all NAS gear has
it's "features".. I'd probably feel the same if we owned PM3's..
Overall, I'd have to totally separate low density from high density
hubbage, when you are talking about TC.. As for netservers, yeah
I agree with you guys so much, I dumped em early last year.. But
the Hiper products are good.. maybe even the best.. especially
when dealing with all those POS modems out there..
>
>We've been violated, and it hurts. We've put in hours shuffling through
>mediocre-to-poor documentation, spent countless days on hold, and rue
>the day we heard of Total Control. So it's time to regroup.
It just takes time to learn how to deal with any kludged system.. 3com
is no different.. you have to find the right buttons to push and know
when to push them.. But without this list and a very good admin, I'd
be screwed fer sure... :) but if you *depend* on 3com tech support,
then you probably have chosen the wrong vendor, I agree..
>
>If you want to stay in this business, exercise your resourcefulness and
>make one more hard decision: Stop Supporting 3Com.
>
>Evaluate the PM3, or the PM4, or the AS5300, or the AS5800. And replace
>your current hardware.
I just wish that USR jumped in bed with Cisco and not 3COM.. Can you
imagine a Cisco Palm Pilot? That would have been cool...
>
>Your life will be better. (Mine has.)
>
> You won't hate dialup as much. (We don't.)
>
> Your customers will be more happy. (Ours are.)
>
> You'll be able to get answers to questions. (We do.)
>
> Stop supporting 3Com.
Well it's a mutual support.. or it's supposed to be.. But our life is
pretty good, we definitely don't hate dialup, our customers are very
happy, and we get answers by working hard and reading this list, and
relying on the *Good* people that are at 3COM and there are precious
few and they know who they are... BTW we are 100% Hiper, otherwise,
the above would not be true...
Allen
>
>
>-
> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address. Do not use quotes in your message.
>
>
Allen Marsalis was heard to say:
><dredging up old memories>
>
>Speaking of promises though, whatever happened to OSPF? not on the
>netserver (I'm not completely stupid) but on the ARC? Think we might
>see it this year? (or have I just been out of the loop too long) It
>sure would be nice to use a decent interior routing protocol besides
>RIP...
(I expect I'll get yelled at for talking about this, but...) Yes, OSPF
is coming. It's currently in ALPHA test. It works quite well if you
keep it away from huge route tables. Even in the presence of huge tables,
it works -- just pegs the CPU initializing and printing out the route
table (3Com has to learn to program in scalability sooner or later.)
I don't know what the schedule looks like, but 3Com has been pushing around
ARC 4.2 BETA survey forms. Once they fix a few things, I'd say it's ready
for beta to find all the other weird setups where it may have problems.
For the record, I like it. The last pass of code (not yet public to the
alpha testers as far as I'm aware) has been very stable even under a heavy
load (well, two full hiperDSPs.)
I'm gonna start pushing them for VoIP on the ARC next. :-)
--Ricky
MegaZone was heard to say:
> But originally it was expected that
>Pilgrim would be back ported. And reasonably so.
Maybe they did attempt to port it to the netserver but then saw that it
ran like shit on a 486 (bad code design aside) and halted work on it.
> Many vendors have produced
>software releases for products that have had no new HW development. Even
>Ascend is producing a last TAOS release for the MAX4000 family, and placing
>it on maintenance for security and bug fixes.
Good example... when was the last release for Pipeline 400's? Years ago.
Ascend stopped maintaining code for the P400's a long time ago. We have
P400's all over the place.
> It seems like
>the plan to screw existing customers was in place for quite a while - they
>knowingly developed the HiPer and Pilgrim with no apparent intent to provide
>any option to their existing users.
I don't know about that. Alot could have changed between the USR/3Com merger.
USR may have had the intentions to fix the netserver once and for all and/or
port the Pilgrim code to it -- I was originally told (when Pilgrim was hush-
hush) the code would eventually be run on the netserver as USR was going to
lose access to the ComOS code currenly on the netserver.
The whole situation is a mess and USR being bought by 3Com has only made it
worse. USR has two good platforms if they just had some brite people to
get to work on them with out management sending them in circles. They could
stand to have more agressive internal testing facilities as well.
--Ricky
Dan Hollis was heard to say:
>And as bad as people claim 3com is, most vendors are worse. OSPF support
>is the exception not the rule. Still OSPF is not some magic bullet that
>solves all routing problems although some would try to convince you
>otherwise.
It's a shit-load better than RIP...
>But the next purchase will not be 3com or Livingston but rather Cisco. :-)
God help ya'... Cisco doesn't make any distinction between router and anything.
Everything is a router to them (even their switches are routers.) IOS just
doesn't make for a good terminal server.
>Not that were displeased with 3com Hiper or anything (its nice hardware,
>and I like the interface better than ComOS), just that under months of
>testing Cisco gave our customers more consistent and stable modem
>connections than either Hiper or PM3 and in the end its customer
>satisfaction not admin satisfaction that counts. Whatever magic DSP code
>Cisco has it works and thats all that matters.
That magic DSP hardware is Telebit MicaModem hardware. Telebit still sells
the "micablazer" line of products that use the same DSP technology. Pick up
a Micablazer and see how much you love that critter.
>And please no "run code version XYZ it will give better connects than
>Cisco" because it doesnt. No code versons on either 3com or Livingston
>made appreciably better or worse connections than any other version.
That's not really an issue... interop. problems will always exist. My problem
is with IOS being used as a terminal server. IOS just isn't built for it;
it was never designed for that kind of thing; and it doesn't do as good a
job as traditional "terminal server" type hardware specifically designed
to handle dialin modems.
--Ricky
Jeff Mcadams was heard to say:
>Shoot...it seems like corporate culture there. Have you looked at the
>new Palm IIIx's and V's? Guess what? Absolutely *no* upgrade path for
>existing Palm owners (I have a Pro), so the "screw the long-time, loyal
>customer attitude seems to permeate the company from the biggest product
>lines to the smallest.
Oh my god... have you ever taken a PalmPilot apart? There's one f***ing
chip in there. What kind of upgrade path do you expect, 386->486? There's
nothing _to_ upgrade. You expect them to never move to more modern CPU
hardware? The Palm III ROM code works in the earlier palms because they
have almost identical hardware (sans the IR port.)
Are you going to go bitch at Abit, Asus, SuperMicro, Tyan, Intel, etc.
as they change the designs of their motherboards without some upgrade
path to the new ones?
Super NES to N64, did they give you an upgrade path? Zenith comes out with
a newer 21" TV with CC and PIP, did they give you an upgrade path?
Go take your lithium, NOW! <grin>
--Ricky
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-28 14:57:47
Allen Marsalis was heard to say:
>>And I honestly think that our problem hasn't been with the development of
>>the platform, which has some great strengths and demonstrates the work
>>of a lot of smart people. OUR PROBLEM IS WITH EVERYTHING AT 3COM
>>*EXCEPT* THE ENGINEERS.
>
>uh, that's HARDWARE ENGINEERS..
No, engineers. Management controls what those engineers do. If management
says, "Don't fix XYZ." Then it doesn't get fixed.
Why isn't the USR RADIUS server multithreaded? Answer: Management doesn't
see it as worth devoting coding time on it. (Management is bunch of dumb...)
For someone with any knowledge at all on -mt apps, this is a two day first
run. At most, it's a month or two of fine tuning.
How long did it take to get the idiots to include crypt() support in the
RADIUS server? Over a year. Over a year! to get someone to put half a
dozen lines in three files and type "make." ... even _after_ I gave them
the lines. (It took me mere minutes to actually include the support myself.)
The management in charge of the engineers is just insane -- I'd like some of
their weed...
>>We've been violated, and it hurts. We've put in hours shuffling through
>>mediocre-to-poor documentation, spent countless days on hold, and rue
>>the day we heard of Total Control. So it's time to regroup.
>
>It just takes time to learn how to deal with any kludged system.. 3com
>is no different.. you have to find the right buttons to push and know
>when to push them.. But without this list and a very good admin, I'd
>be screwed fer sure... :) but if you *depend* on 3com tech support,
>then you probably have chosen the wrong vendor, I agree..
True... no matter what hardware you use, you have to learn to use it and get
used to it's quirks. We originally used Microcom modem racks with Netblazers.
We all loved that hardware once we got used to how it worked and how to
manage it. Helpdesk _really_ liked what the netblazer gave them in the
way of troubleshooting. Nothing has ever come close to the netblazer
hardware. (It's just too low of a density for the modern world.)
>>Evaluate the PM3, or the PM4, or the AS5300, or the AS5800. And replace
>>your current hardware.
>
>I just wish that USR jumped in bed with Cisco and not 3COM.. Can you
>imagine a Cisco Palm Pilot? That would have been cool...
Cisco would have destroyed the TC hardware poluting it with IOS...
My watch is not a router; I don't want it running IOS.
--Ricky
At 01:55 PM 2/28/99 -0500, Ricky Beam wrote:
>Allen Marsalis was heard to say:
>(I expect I'll get yelled at for talking about this, but...) Yes, OSPF
>is coming.
That is indeed good to hear..
>
>I'm gonna start pushing them for VoIP on the ARC next. :-)
that would be cool.. we have had dozens of PPC's clocking wasted cycles
for a year now.. perhaps 3COM could get with distributed.net and crack
RSA keys in the mean time.... :)
am
>
>--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) 3Com Problems. (And how to survive) From: Mark R. Lindsey <mark@vielle.datasys.net> Date: 1999-02-28 15:24:49
: Helpdesk _really_ liked what the netblazer gave them in the way
: of troubleshooting. Nothing has ever come close to the netblazer
: hardware. (It's just too low of a density for the modern world.)
Have you seen what an AS5300 with MICA modems will give you? Detailed
link-level modem event accounting, line shapes, &c.
: Cisco would have destroyed the TC hardware poluting it with IOS...
That's what an AS5100 is: USR quad modems and a Cisco 2500. I know
I'm comparing oranges with tangerines here, but the AS5100 includes
c2500 that occupies the same space and power as a Netserver, but can do
RIP, OSPF, BGP, L2F and SGBP (for multichassis multilink PPP) -- that
is, everything that's provided by modern IOS revisions.
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-02-28 15:35:03
Mark R. Lindsey was heard to say:
>: Helpdesk _really_ liked what the netblazer gave them in the way
>: of troubleshooting. Nothing has ever come close to the netblazer
>: hardware. (It's just too low of a density for the modern world.)
>
>Have you seen what an AS5300 with MICA modems will give you? Detailed
>link-level modem event accounting, line shapes, &c.
(Yes, we have 47 5300s. They are much more of a headache than the TCHs.)
Helpdesk doesn't care what's going on inside the modem. You actually expect
them to understand any of that? Helpdesk loved being able to trace the
serial line and see what the nut was entering character by character.
They could also trace the PPP/SLIP framing as well.
>: Cisco would have destroyed the TC hardware poluting it with IOS...
>
>That's what an AS5100 is: USR quad modems and a Cisco 2500. I know
[snip]
I know what a 5100 is. It's just as bad as a 5300. IOS does not make
a good terminal server -- it treats every interface the same from HSSI
down to a 300 baud modem connection; do you want to run OSPF on a 300
baud modem?
--Ricky
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Mark R. Lindsey <mark@vielle.datasys.net> Date: 1999-02-28 15:43:53
: I know what a 5100 is. It's just as bad as a 5300. IOS does not make
: a good terminal server -- it treats every interface the same from HSSI
: down to a 300 baud modem connection; do you want to run OSPF on a 300
: baud modem?
A network interface is a network interface. Regardless of whether it's
Sync or Async, relatively-high-speed or not.
If I have an application in which I *need* to run OSPF over a 300 baud
modem, and my router to which the 300 baud modem is connected can do
OSPF, then I *DO* want to run OSPF on a 300 baud modem.
I cannot have designers making arbitrary decisions about what interfaces
should qualify to do what jobs. It's up to me -- the guy who has to
build these networks -- to understand the consequences of my actions.
Thus spake Ricky Beam
>>But the next purchase will not be 3com or Livingston but rather Cisco. :-)
>God help ya'... Cisco doesn't make any distinction between router and anything.
>Everything is a router to them (even their switches are routers.)
I beg to differ. Cisco switches most definitely *aren't* routers. The
new switches to run from the same code base, but that doesn't make them
routers. Cisco uses IOS, and they use it a lot, but whether something
is a router or a switch, or a access server, is termined by
configuration almost completely. I 7507 can be a switch if you want it
to be and configure it right...it may not be cost effective, but it can
do it. And to take that argument a step further, an access server *IS*
a router, period. Otherwise, we wouldn't be hollering for OSPF, and
other router features on TC stuff.
>IOS just doesn't make for a good terminal server.
The configuration is not as clean...but I doubt it doesn't do it as
well.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake Ricky Beam
>Jeff Mcadams was heard to say:
>>Shoot...it seems like corporate culture there. Have you looked at the
>>new Palm IIIx's and V's? Guess what? Absolutely *no* upgrade path for
>>existing Palm owners (I have a Pro), so the "screw the long-time, loyal
>>customer attitude seems to permeate the company from the biggest product
>>lines to the smallest.
>Oh my god... have you ever taken a PalmPilot apart? There's one f***ing
>chip in there. What kind of upgrade path do you expect, 386->486?
Whoa...wait a minute here. When the Palm III first came out, there
*was* an upgrade available from the Pro to the III (swap out a chip for
a new chip and new door that had the IR port built in), now that the IIx
comes out (which is a III with 4MB RAM rather than 2), there's no
upgrade path for that, AND THE ORIGINAL UPGRADE PATH DISAPPEARED!
Please, I'm not terribly upset about this...it was merely an example of
how 3Com isn't forward thinking. By upgrade path here, I was more
talking about the possibility of a trade-in on my Pro for a III or IIIx.
They don't even have anything in place to do that, which seems quite
reasonable.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Dan Hollis <goemon@sasami.anime.net> Date: 1999-02-28 16:37:11
At 10:21 AM 2/28/99 -0500, Mark R. Lindsey wrote:
>Jeff, Dan, and other disgruntled TC users:
>Let's admit it -- we've been shafted. Between us all, we've tried to use
>every variation of equipment and code that 3Com makes for the ISP biz.
>In many cases, we've been sorely disappointed.
Nah im not disgruntled at all. Sorry.
>We've been violated, and it hurts. We've put in hours shuffling through
>mediocre-to-poor documentation, spent countless days on hold, and rue
>the day we heard of Total Control. So it's time to regroup.
Never had any real issues with the TC.
>Evaluate the PM3, or the PM4, or the AS5300, or the AS5800. And replace
>your current hardware.
We evaluated the PM3 and saw the PM4 fail spectacularly at another site.
As I said before its the end user perception that counts not whether the
CLI gives the admin warm fuzzies. Cisco just gives better connections
thats all. USR Hiper is nice but their DSP code isnt up to Ciscos and
neither is Lucents PM3.
-Dan
Jeff Mcadams was heard to say:
>Whoa...wait a minute here. When the Palm III first came out, there
>*was* an upgrade available from the Pro to the III (swap out a chip for
>a new chip and new door that had the IR port built in), now that the IIx
>comes out (which is a III with 4MB RAM rather than 2), there's no
>upgrade path for that, AND THE ORIGINAL UPGRADE PATH DISAPPEARED!
That "chip" is the memory board. It holds the ROM and RAM for the pilot.
(There's a third party vendor that makes an 8M board for the pilot.)
> By upgrade path here, I was more
>talking about the possibility of a trade-in on my Pro for a III or IIIx.
>They don't even have anything in place to do that, which seems quite
>reasonable.
Why would that be reasonable? Comanpies build new things everyday and
don't offer trade-in's for them. This isn't a Sun E10000, it's a palm
pilot.
Just because there's a new pilot out there doesn't mean your existing one
suddenly doesn't do it's thing. *grin* I still have (and regularly use)
a 486dx50 based PC (as well as a Cy486dx2-66.)
--Ricky
Just wondering if anyone can point me to a reference for ARC filters (and
netserver) ... I just need some syntax to add blocks for some TCP/UDP ports
...
Have a Great Day!
Jamie Orzechowski
RipNET System Admin
Tel.: 613-342-3946 ext 293
Tel.: 800-267-4434 ext 293
Page.: 613-341-0883
EMail.: mhz@ripnet.com
Web.: http://www.ripnet.com
Personal.: http://www.moonchilli.com
On Sun, 28 Feb 1999, Dan Hollis wrote:
> On Sun, 28 Feb 1999, MegaZone wrote:
> > And Nortel (Bay) finally has it in beta for their next revision as well.
> > Looks like both are finally joining the modern routing world.
>
> And as bad as people claim 3com is, most vendors are worse. OSPF support
> is the exception not the rule. Still OSPF is not some magic bullet that
> solves all routing problems although some would try to convince you
> otherwise.
>
> But the next purchase will not be 3com or Livingston but rather Cisco. :-)
Random trivia... Cisco 804's don't have OSPF on them. This was a big
surprise to me when I replaced my Ascend Pipeline 25FX's (barf) with 804's
this week. You'd think that would be included in any build of Cisco IOS
12.0. But the 804 only does RIP1, RIP2, and EIGRP. Bleah!
Fortunately I only needed one default and one static route at each end.
but still...
(They probably do have OSPF in an extra feature build for the 804, maybe
IP Plus or IP/IPX or something... but it's not in the base IP kit.)
And yes, I'm very much looking forward to OSPF on the ARCs. The ARCs are
the only reason there's any RIP2 on our network at all. I should really
just stick our main modem pool behind our Cisco 2611's 2nd ether port...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
On Sun, 28 Feb 1999, Paul M. Oster wrote:
> Ok here's one for you, another example of 3com's deplorable bait and
> switch manuvering... I did buy a Hyper-Arc upgrade (I wanted the DSP
> ports for my Arc chassis) pop the arc in a netserver chassis and 1/2 the
> quad modems quit responding... I call 3com inside my 90 day support
> windows, and I"m told my quad code is not current and I need to upgrade to
> get the modems to work correctly with the Arc. Login to totalservice to
I got bitten by something similar -- all my Quads answered, but PPP never
started up. Turns out I had set them all back to verbal result codes
somehow. The ARC demands numeric result codes. Finding the right
incantation of acceptable numeric result codes took a while (the first
pass made analog work but ISDN still got ignored) but finally I got it
right. Bottom line is the factory default settings on the Quads don't
seem to quite work on an ARC. (I don't know why just looking at carrier
detect isn't good enough for it...)
This is with ARC 4.1.59-1 and the latest (err, the ONLY) v.90 Quad code...
5.10.whatever.
> Maybe to elminate issues like this you should give us 1Arc, and 3dsp's
> for the 3300 bucks and we send back a netserver and 12 quads...
I'd rather keep the few Quads I have -- they work better with the Rockwell
HCF and LT Winmodem crowd.
In fact, I've been considering for a long time adding a PM3 to our modem
pool, just to see if it would make a difference for the "cheap winmodem"
crowd. Yes, I know the real fix is to upgrade the client modem, but try
explaining that to a new customer who just bought a Compaq Presario or an
HP Pavillion at Best Buy... People are so fanatical about PM3's and how
great they are (and we did start out with PM2e's here, and still have
some OR-HS's)...
However I'm also on the PM-Users list, and people say there that they're
having the exact same problems with the exact same modems with even the
latest PM3 code. People there are just as pissed at Lucent for modem code
as people here are for DSP code. Go figure. :)
Still, I'll probably grab a used PM3 next, then once that's running,
probably go back to buying DSP's.
Based on what I've read, I think for compatibility's sake I'd probably be
best off with a ton of Quads, instead of a PM3, Ascend, or Cisco. (I just
replaced my hideous Ascend ISDN bridge at home -- anyone wanna buy two
P25fx's?) Our local competitors use either Cisco or Ascend (no PM3's) and
we get tons of customers defecting from them. (Sprint does AOL's dialup
here and they're using Quads & Netservers.) It's a shame we have no
physical room for all those Quads, not to mention all the amps they pull.
> And the other pet peeve is that the "upgrade" I pay for does not have
> all the features I'm used to on the Netservers... but thats another rant
> entirely....
Like what? (Honest question... don't take that the wrong way.) Idle time
is the only one I'm still missing. I found workarounds for everything
else. MPIP behaves itself a hell of a lot better.
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-28 21:31:50
On Sun, 28 Feb 1999, Mark R. Lindsey wrote:
> : Helpdesk _really_ liked what the netblazer gave them in the way
> : of troubleshooting. Nothing has ever come close to the netblazer
> : hardware. (It's just too low of a density for the modern world.)
>
> Have you seen what an AS5300 with MICA modems will give you? Detailed
> link-level modem event accounting, line shapes, &c.
>
> : Cisco would have destroyed the TC hardware poluting it with IOS...
>
> That's what an AS5100 is: USR quad modems and a Cisco 2500. I know
> I'm comparing oranges with tangerines here, but the AS5100 includes
> c2500 that occupies the same space and power as a Netserver, but can do
> RIP, OSPF, BGP, L2F and SGBP (for multichassis multilink PPP) -- that
> is, everything that's provided by modern IOS revisions.
The AS5100 card is a 2511 on a card, right? I've been toying around with
the idea of finding a used one just to use in place of a 2511 for a remote
pop (not actually run modems off it, but hook the async ports to the NMC,
DSP, and Dual PRI serial ports...) How much flash/dram do they have? If
it's got enough flash and it's really 2500 based, you could still get IOS
11.3 or 12.0 on it...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:Re: (usr-tc) connecting to hdm console or quad/dsp for outbound From: Mike Andrews <mandrews@termfrost.org> Date: 1999-02-28 23:29:11
On Sat, 27 Feb 1999, Tatai SV Krishnan wrote:
> On Fri, 26 Feb 1999, Mike Andrews wrote:
>
> > I've seen some hints in ARC documentation/release notes that say there's a
> > way to connect to an HDM console through the ARC somehow (presumably over
> > the packet bus)... but I can't find the exact syntax anywhere. This
> > would save me a few serial ports...
>
> This is available with the beta code of HDM and the current HiPer arc code.
> You can set a console port on the hiper arc - basically set it up as a
> telnet port and then telnet to that port. The info is available on yadda
> yadda search - http://interproc.ae.usr.com/tkb.html
OK, found it there, thanks.
> > I'm also trying to figure out how to connect to a particular Quad (or DSP)
> > to feed it AT commands. I have a channel on a Quad I suspect is dead and
> > I'm trying to poke at it a bit to see if it's really dead...
> >
>
> You can send at commands to the modems with hiper arc
>
> set swi inter slot:x/mod:y at ati4
> will give you the necessary result.
Great, just what I needed. Now why would a Quad modem get a DSP Interrupt
Timeout when trying to answer a call...
Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
getting beaten by the police, put down the video camera and come help me!"
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-03-01 00:10:18
Dan Hollis was heard to say:
>Never had any real issues with the TC.
I've had a few, but nothing too serious (that was their fault -- SoBell
random "spot" tested a few of our PRIs that locked the chassis into some
telco test mode... long ugly story.)
>We evaluated the PM3 and saw the PM4 fail spectacularly at another site.
Well, I'm more than a little reluctant to put that much dialtone in one
place -- it's like tornados and trailer parks...
>As I said before its the end user perception that counts not whether the
>CLI gives the admin warm fuzzies. Cisco just gives better connections
>thats all. USR Hiper is nice but their DSP code isnt up to Ciscos and
>neither is Lucents PM3.
Well, Cisco didn't design it (at least the first runs.) And Cisco management
doesn't tend to run a code zoo. As a friend of mine (writes windows C++
stuff -- or used to before the JAVA infection) once said... writing software
is an art; you can't rush art. I'd add, you cannot micromanage art either.
--Ricky
Mike Andrews was heard to say:
[snip]
>This is with ARC 4.1.59-1 and the latest (err, the ONLY) v.90 Quad code...
>5.10.whatever.
Odd, I've never had any problems like that. And there was a version or two
prior to 5.10/5.9 that had V.90 as I recall.
>I'd rather keep the few Quads I have -- they work better with the Rockwell
>HCF and LT Winmodem crowd.
Yeah, the quads are rock solid toys. Man, if they could stick 24 of them
on a card...
>In fact, I've been considering for a long time adding a PM3 to our modem
>pool, just to see if it would make a difference for the "cheap winmodem"
>crowd. Yes, I know the real fix is to upgrade the client modem, but try
>explaining that to a new customer who just bought a Compaq Presario or an
>HP Pavillion at Best Buy... People are so fanatical about PM3's and how
>great they are (and we did start out with PM2e's here, and still have
>some OR-HS's)...
Simple, be brutal, tell the idiot to go buy a real f****** modem.
>However I'm also on the PM-Users list, and people say there that they're
>having the exact same problems with the exact same modems with even the
>latest PM3 code. People there are just as pissed at Lucent for modem code
>as people here are for DSP code. Go figure. :)
Everyone has trouble with them things. Even the precious Cisco MICA DSP
code :-)
> -- anyone wanna buy two
>P25fx's?)
Only if you add 50 to it :-) (I've got a few P50's that are actually P75's)
> Our local competitors use either Cisco or Ascend (no PM3's) and
>we get tons of customers defecting from them.
Really? Any ideas why? (specific problems) I know the iMac internal modem
doesn't like most v.90 code including the Cisco DSP code -- of course, the
iMac modem defaults to k56 which works perfectly :-)
--Ricky
Subject:Re: (usr-tc) 3Com Problems. (And how to survive) From: Ricky Beam <jfbeam@enterprise.interpath.net> Date: 1999-03-01 00:25:18
Mike Andrews was heard to say:
>The AS5100 card is a 2511 on a card, right? I've been toying around with
>the idea of finding a used one just to use in place of a 2511 for a remote
>pop (not actually run modems off it, but hook the async ports to the NMC,
>DSP, and Dual PRI serial ports...) How much flash/dram do they have? If
>it's got enough flash and it's really 2500 based, you could still get IOS
>11.3 or 12.0 on it...
Correct... the AS51 card is a 2511 on a card.
Which brings to mind an interesting use for a TCH... 16 2511's in a rack :-)
(Or course, you could do the same thing with the Edge server cards...)
Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack...
--Ricky