On Mon, 30 Jun 1997, Jordyn A. Buchanan wrote:
> I was cruising around on the TotalService web page the other day and
> noticed the Netserver Plus software available there. Since we have a few
> Netserver/16s lying around waiting to be used, I loaded it onto one of them
> and investigated. The old Netserver 8/16s are definitely upgradeable,
> although the process is a little complex. You have to fiddle with the dip
> switches on the back to set the console port speed to 57600 and physically
> power off the Netserver at one point. It's also impossible to upgrade
> boxes over a network (have to have a serial connection) which means it will
> be a real pain to upgrade boxes at remote POPs.
I suppose USR mad enough changes that you can't load 4.0 with the old
code.
> soon. RIP v2 is added and SNMP support is expanded. But I'm still trying
I thought the regular Netserver/8 code had RIPv2. I must be thinking of
the Netserver card for the TC chassis.
>
> >Automatic DNS assignment for Win 95 is not supported, and the RADIUS
> >implementation sends accounting packets to port 1645 instead of 1646 like
> >the RFC calls for.
>
> Did 3.5 support automatic DNS assignment? I certainly never got it to work
> if it did...
I just assumed it did. I didn't think they would mention a problem if
it's always been a problem.
My Portmasters support auto DNS, but I never tell anyone to use it. I had
one person call whose system had been working fine, and now there DNS was
broken. Turns out they had set up auto DNS assignment, and it just quit
working without any changes on our end.
> There are some problems in the old Netserver OS (like idle timeouts not
> working) that appear to be corrected in the new software, and some of the
> features may end up being useful enough to motivate us to migrate to the
I don't remember having idle timeout problems with my Netserver/16.
> 4.0 software. However, I'm really disappointed with the new interface and
> am starting to look at Livingston products again. ComOS is really nice,
> and these days it has so many more features than the Netservers support...
I do have a USR TC chassis, but right now, it looks like we'll be getting
Portmaster 3s for the future.. It's really going to suck when the TC
racks switch to the 4.0 code for the Netserver card.
They'll probably have OSPF in 4.0 finally, but then we'll lose the nice
Livingston interface.
Brian
On Mon, 30 Jun 1997, Jordyn A. Buchanan wrote:
> I was cruising around on the TotalService web page the other day and
> noticed the Netserver Plus software available there. Since we have a few
> Netserver/16s lying around waiting to be used, I loaded it onto one of them
> and investigated. The old Netserver 8/16s are definitely upgradeable,
> although the process is a little complex. You have to fiddle with the dip
> switches on the back to set the console port speed to 57600 and physically
> power off the Netserver at one point. It's also impossible to upgrade
> boxes over a network (have to have a serial connection) which means it will
> be a real pain to upgrade boxes at remote POPs.
I suppose USR mad enough changes that you can't load 4.0 with the old
code.
> soon. RIP v2 is added and SNMP support is expanded. But I'm still trying
I thought the regular Netserver/8 code had RIPv2. I must be thinking of
the Netserver card for the TC chassis.
>
> >Automatic DNS assignment for Win 95 is not supported, and the RADIUS
> >implementation sends accounting packets to port 1645 instead of 1646 like
> >the RFC calls for.
>
> Did 3.5 support automatic DNS assignment? I certainly never got it to work
> if it did...
I just assumed it did. I didn't think they would mention a problem if
it's always been a problem.
My Portmasters support auto DNS, but I never tell anyone to use it. I had
one person call whose system had been working fine, and now there DNS was
broken. Turns out they had set up auto DNS assignment, and it just quit
working without any changes on our end.
> There are some problems in the old Netserver OS (like idle timeouts not
> working) that appear to be corrected in the new software, and some of the
> features may end up being useful enough to motivate us to migrate to the
I don't remember having idle timeout problems with my Netserver/16.
> 4.0 software. However, I'm really disappointed with the new interface and
> am starting to look at Livingston products again. ComOS is really nice,
> and these days it has so many more features than the Netservers support...
I do have a USR TC chassis, but right now, it looks like we'll be getting
Portmaster 3s for the future.. It's really going to suck when the TC
racks switch to the 4.0 code for the Netserver card.
They'll probably have OSPF in 4.0 finally, but then we'll lose the nice
Livingston interface.
Brian
Hi Adam,
let's see if I can clarify this :-).
What I can gather from your last posting is that you're using TCM.
Therefore
you already have the needed MIB files. They should reside in some
subdirectory
named \tcmanager\mibs\. The one you're looking for is mdm.mib.
Fortunately I'm working in an Unix environment. So, what I did is make
a copy
of the mdm.mib and insert the following header to please ucd/cmu-snmp:
RFC1155-SMI DEFINITIONS ::= BEGIN
nullOID OBJECT IDENTIFIER ::= { ccitt 0 }
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
END
MDM-MIB DEFINITIONS ::= BEGIN
[...]
Ok, the final steps are to tell e.g. snmpwalk which MIB file to use:
tcsh$ setenv MIBFILE /some/folder/mdm.mib
And to run snmpwalk, snmpget or whatever:
tcsh$ snmpwalk -v 1 <ip of nmc> <read community> \
.iso.org.dod.internet.private.enterprises.usr.nas.mdm.mdmcs.\
mdmcstable.mdmcsentry.mdmcsfinalrxlinkrate
You'll get something like the following:
enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2001
= bps33K(24)
enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2002
= bps28K(21)
enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2003
= bps21K(18)
enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2004
= bps33K(24)
Hope that helped.
Stefan
Adam Wills (Global 2000) wrote:
>
> Ok, then I must REALLY be missing something here :( I do an SNMPWALK on
> both the Netserver card and the Network Management Card (which should
> contain any and all info for hte quad cards) but none of hte output form
> an entire SNMPWALK shows anything with modems in it.
>
> You state to look at hte usr MIB for mdmCsFinalRxLinkRate OBJECT-TYPE but
> where might I find this MIB? I checked their www site (high and low) and
> its not there. Yes, I CAN see the connect speeds using the Total Control
> manager, so I know hte SMNP info is gotta be there somewhere- but if an
> SNMPWALK doesn't find it I wonder If I am doing something seriously wrong.
>
> #1 Anyone have the full MIB.txt file they can send me?
> #2 What is the exact snmpget command one would use for conenction speeds?
>
> Thanks for any help, I'm gonna dig more through the TCM manual but It
> doesnt talk much about smnp queries from external programs than the TCM
> software its self.
>
> Adam Wills Global 2000 Communications
> Director of Networking Systems 1840 Western Ave.
> sysadmin@global2000.net Albany, NY, 12203
> http://www.global2000.net (518) 452-1465
At 10:38 AM -0500 7/1/97, Brian Elfert wrote:
>It's also impossible to upgrade
>> boxes over a network (have to have a serial connection) which means it will
>> be a real pain to upgrade boxes at remote POPs.
>
>I suppose USR mad enough changes that you can't load 4.0 with the old
>code.
Probably. The part where you have to turn power off and then back on would
make this a bit of a trick anyway.
>> soon. RIP v2 is added and SNMP support is expanded. But I'm still trying
>
>I thought the regular Netserver/8 code had RIPv2. I must be thinking of
>the Netserver card for the TC chassis.
If the Netserver/8 or /16 support RIPv2 it is a carefully undocumented
feature. It's been on the TC chassis for a while, but USR has been less
than agressive about improving the software for the Netserver /8 and /16.
>> There are some problems in the old Netserver OS (like idle timeouts not
>> working) that appear to be corrected in the new software, and some of the
>> features may end up being useful enough to motivate us to migrate to the
>
>I don't remember having idle timeout problems with my Netserver/16.
This wasn't a problem in earlier versions, but when we upgraded to 3.2.5,
idle timers suddenly stopped working (at least on S1, but I think on the
rest of the ports as well). I called USR and they said "ooh, we know about
that" but didn't sound like they were very interested in fixing it.
>> 4.0 software. However, I'm really disappointed with the new interface and
>> am starting to look at Livingston products again. ComOS is really nice,
>> and these days it has so many more features than the Netservers support...
>
>I do have a USR TC chassis, but right now, it looks like we'll be getting
>Portmaster 3s for the future.. It's really going to suck when the TC
>racks switch to the 4.0 code for the Netserver card.
>
>They'll probably have OSPF in 4.0 finally, but then we'll lose the nice
>Livingston interface.
It's really not vaguely economical for us to switch to PM3s (PRIs around
here are about 3x as expensive per channel as POTS lines or BRIs), so our
options are somewhat more limited. Most likely, we'll start buying MP/16s
instead of Netservers/16s, and plug them into Portmaster 2Es, even though
that's substantially less elegant.
I'm really disappointed with USR. We started out liking the Netserver/16s
quite a bit, but it seems like USR has really lost a lot of ground in the
software game over the past year. USR builds great modems, but seem to
have lost site of the importance of software in solutions such as the
Netserver. Or maybe we piddly Netserver/16 users just don't deserve the
good stuff.
Jordyn
|----------------------------------------------------------------|
|Jordyn A. Buchanan mailto:jordyn@bestweb.net |
|Bestweb Corporation http://www.bestweb.net |
|Senior System Administrator +1.914.271.4500 |
|----------------------------------------------------------------|
At 10:38 AM -0500 7/1/97, Brian Elfert wrote:
>It's also impossible to upgrade
>> boxes over a network (have to have a serial connection) which means it will
>> be a real pain to upgrade boxes at remote POPs.
>
>I suppose USR mad enough changes that you can't load 4.0 with the old
>code.
Probably. The part where you have to turn power off and then back on would
make this a bit of a trick anyway.
>> soon. RIP v2 is added and SNMP support is expanded. But I'm still trying
>
>I thought the regular Netserver/8 code had RIPv2. I must be thinking of
>the Netserver card for the TC chassis.
If the Netserver/8 or /16 support RIPv2 it is a carefully undocumented
feature. It's been on the TC chassis for a while, but USR has been less
than agressive about improving the software for the Netserver /8 and /16.
>> There are some problems in the old Netserver OS (like idle timeouts not
>> working) that appear to be corrected in the new software, and some of the
>> features may end up being useful enough to motivate us to migrate to the
>
>I don't remember having idle timeout problems with my Netserver/16.
This wasn't a problem in earlier versions, but when we upgraded to 3.2.5,
idle timers suddenly stopped working (at least on S1, but I think on the
rest of the ports as well). I called USR and they said "ooh, we know about
that" but didn't sound like they were very interested in fixing it.
>> 4.0 software. However, I'm really disappointed with the new interface and
>> am starting to look at Livingston products again. ComOS is really nice,
>> and these days it has so many more features than the Netservers support...
>
>I do have a USR TC chassis, but right now, it looks like we'll be getting
>Portmaster 3s for the future.. It's really going to suck when the TC
>racks switch to the 4.0 code for the Netserver card.
>
>They'll probably have OSPF in 4.0 finally, but then we'll lose the nice
>Livingston interface.
It's really not vaguely economical for us to switch to PM3s (PRIs around
here are about 3x as expensive per channel as POTS lines or BRIs), so our
options are somewhat more limited. Most likely, we'll start buying MP/16s
instead of Netservers/16s, and plug them into Portmaster 2Es, even though
that's substantially less elegant.
I'm really disappointed with USR. We started out liking the Netserver/16s
quite a bit, but it seems like USR has really lost a lot of ground in the
software game over the past year. USR builds great modems, but seem to
have lost site of the importance of software in solutions such as the
Netserver. Or maybe we piddly Netserver/16 users just don't deserve the
good stuff.
Jordyn
|----------------------------------------------------------------|
|Jordyn A. Buchanan mailto:jordyn@bestweb.net |
|Bestweb Corporation http://www.bestweb.net |
|Senior System Administrator +1.914.271.4500 |
|----------------------------------------------------------------|
Was 2.4.23 a beta release? I'm fairly certain I downloaded it from
ftp.merit.edu. I went back there to check for a new release, but only
found the 2.3.x there.
The $2495 price tag for the full edition sounds pretty ridiculous (not to
mention the $10,000 cost for the source) -- what features could this
program possibly have to make it cost that much?
If someone can point me to a GNU or BSD type of licensed package, still
being maintained, I'd appreciate it. There seem to be so many releases of
radius that I wouldn't know where to begin making changes. I'm currently
using the 2.4.23 version (I still have the source) which runs ok.
- lv
Subject:Re: (usr-tc) Upgrading to TCS 2.5.1 From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-01 17:01:00
-> >
-> > The only thing to remember is, that you should upgrade the NMC first. But
-> > that's all.
-> >
->
-> I upgraded the NMC firmware from 4.3.4 to 4.3.8 and my TCM (4.3.0) won't be
-> able to access the NMC anymore. The error message is "Error Opening Device
-> Description File". Did I miss anything? Or do I need to upgrade the TCM
-> also.
->
-> It works again after I downgrade the NMC firmware back to 4.3.4.
Download the TCM version 4.3.6 software and it will work fine then.
Jeff Binkley
ASA Network Computing
I recently turned up my first TC node with RADIUS running under NT. I have two
questions concering USR's implementation of RADIUS. First, I am not seeing the
connect speeds and incoming port information (i.e slot/channel) in the CALLS
table. Now I am running with analog modems but they are going out the packet
bus interface. Our Primary rate ISDN hasn't been installed yet. I'm not sure
if this makes a difference.
Next, I was wondering what it took to move this to an SQL database, most likely
Sybase. In looking at it, it appears all I need to do is build the identical
table structures in Sybase to the current Access tables and then table attach
them with the same names as the current ones (obviously setting up the correct
ODBC name). Then just copy any current information out of Access and back
into Syabse. Am I missing something ?
Lastly, what regular activities are folks performing on RADIUS to maintain it
(i.e. database compression, log file reviews etc..) ?
Thanks in advance,
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) CGI to interface with USR-TC From: Brian <signal@shreve.net> Date: 1997-07-01 19:19:46
I have an idea, to write a CGI, that our users can use from our web site,
that will show them all the statistics for there PPP link.
This would be the same information reported in a "Performance Monitor"
listing of a modem thru TCM..........a COMPLETE listing, # of retrains,
aller id, initial tx/rx rate, current tx/rx rate etc.
I want to do this, using the MIB files from USR, snmpwalk, and perl.
I don't want to invent the wheel. If someone has anything I can use,
please let me know. My final program shouldnt take long, and will do the
following:
authenticate user
look up username to find what port they are on
snmpwalk the port and get all info
output info in html, probably using tables
If anyone has any comments/suggestions before I take the plunge and write
this thing, I'd appreciate it.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) strange ISDN problem From: Brian <signal@shreve.net> Date: 1997-07-01 19:22:17
A user of ours can establish a MultiLink PPP connection (2 ISDN B
channels) no problem on ALL of our hubs but one of them. mp_adv is turned
on on all hubs. All hubs run identicle software.
Anyone know where I can even begin to look? The user uses the SAME radius
entry for whatever hub they happen to land on so I know its not radius.
What settings could disallow MPP on the USR TC hub.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) CGI to interface with USR-TC From: Laszlo Vecsey <master@internexus.net> Date: 1997-07-01 20:51:12
On Tue, 1 Jul 1997, Brian wrote:
> I have an idea, to write a CGI, that our users can use from our web site,
> that will show them all the statistics for there PPP link.
>
[ snip ]
>
> authenticate user
>
> look up username to find what port they are on
>
> snmpwalk the port and get all info
>
> output info in html, probably using tables
>
Is it necessary to authenticate? Much nicer to just use the REMOTE_ADDR
environment variable in cgi-bin to get their IP address, and based on that
find out what port they are on... following the rest of the steps to
return the speed.
Much less trouble for the end user, since they simply have to point their
browser to a URL. Taking it a step further, some .shtml code on your Home
Page could insert their current speed, bandwidth usage so far, etc, and
only display it (again based on REMOTE_ADDR) to people dialed up to the
service.
- lv
Subject:Re: (usr-tc) CGI to interface with USR-TC From: Laszlo Vecsey <master@internexus.net> Date: 1997-07-01 20:51:12
On Tue, 1 Jul 1997, Brian wrote:
> I have an idea, to write a CGI, that our users can use from our web site,
> that will show them all the statistics for there PPP link.
>
[ snip ]
>
> authenticate user
>
> look up username to find what port they are on
>
> snmpwalk the port and get all info
>
> output info in html, probably using tables
>
Is it necessary to authenticate? Much nicer to just use the REMOTE_ADDR
environment variable in cgi-bin to get their IP address, and based on that
find out what port they are on... following the rest of the steps to
return the speed.
Much less trouble for the end user, since they simply have to point their
browser to a URL. Taking it a step further, some .shtml code on your Home
Page could insert their current speed, bandwidth usage so far, etc, and
only display it (again based on REMOTE_ADDR) to people dialed up to the
service.
- lv
On Wed, 2 Jul 1997, King Ho wrote:
> Date: Wed, 2 Jul 1997 04:06:31 +0800 (HKT)
> From: King Ho <ml@glink.net.hk>
> To: usr-tc@mail.xmission.com
> Cc: Holger Koepke <holger@mms.de>
> Subject: Re: (usr-tc) Upgrading to TCS 2.5.1
>
> On Sun, 29 Jun 1997, Holger Koepke wrote:
>
> > On Sun, 29 Jun 1997, Brian Elfert wrote:
> >
> > > My understanding is that you can't just run one piece of TCS 2.5.1. Is
> > > this correct?
> > >
> > > What is the proper procedure for upgrading from TCS 2.5 to 2.5.1?
> > >
> > > The NMC, Netserver, and modems all have to be upgraded. Does this have to
> > > be done in any particular order?
> >
> > The only thing to remember is, that you should upgrade the NMC first. But
> > that's all.
> >
>
> I upgraded the NMC firmware from 4.3.4 to 4.3.8 and my TCM (4.3.0) won't
> be able to access the NMC anymore. The error message is "Error Opening
> Device Description File". Did I miss anything? Or do I need to upgrade the
> TCM also.
>
> It works again after I downgrade the NMC firmware back to 4.3.4.
Maybe you should also upgrade your TCM also, sorry I didn't talk about
that.
So, new steps to go:
1) TCM, which SHOULD allways be backward compatible :-)
2) NMC
3) Applicationcards
Subject:Re: (usr-tc) Upgrading to TCS 2.5.1 From: King Ho <ml@glink.net.hk> Date: 1997-07-02 04:06:31
On Sun, 29 Jun 1997, Holger Koepke wrote:
> On Sun, 29 Jun 1997, Brian Elfert wrote:
>
> > My understanding is that you can't just run one piece of TCS 2.5.1. Is
> > this correct?
> >
> > What is the proper procedure for upgrading from TCS 2.5 to 2.5.1?
> >
> > The NMC, Netserver, and modems all have to be upgraded. Does this have to
> > be done in any particular order?
>
> The only thing to remember is, that you should upgrade the NMC first. But
> that's all.
>
I upgraded the NMC firmware from 4.3.4 to 4.3.8 and my TCM (4.3.0) won't
be able to access the NMC anymore. The error message is "Error Opening
Device Description File". Did I miss anything? Or do I need to upgrade the
TCM also.
It works again after I downgrade the NMC firmware back to 4.3.4.
Best regards,
King Ho
Global Link Information Service Ltd.
Subject:(usr-tc) RADIUS Logins From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-02 08:14:00
I have recently turned up my first USR Total Control node and RADIUS, so
I am somewhat of a novice at this pice of things but am learning fast.
In reviewing my security.log file (I have it turned on until I am
comfortable everyting is working ok) I am seeing instances where a
userid USR_NETS is logging in according to RADIUS. In most instacnes I
can look at the Net Server card and see that someone else is really
logged in but occassionally even the Net Server shows the user as
USR_NETS. Does anyone have an idea why this is happening ? I do see
where on the Net Server card there is a USR_NETS userid specified under
the RADIUS options. I can forward a copy of the RADIUS logs if that
would help.
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
Subject:Re: (usr-tc) CGI to interface with USR-TC From: Holger Koepke <holger@mms.de> Date: 1997-07-02 09:50:06
On Wed, 2 Jul 1997 10:31:34 +0100 (BST), rickp@corp.netcom.net.uk =
couldn't
resist to write:
> Brian writes:
> > I have an idea, to write a CGI, that our users can use from our web =
site,
> > that will show them all the statistics for there PPP link.
>=20
> Yeah - I've written stuff for a tech support people to use.
>=20
> > I want to do this, using the MIB files from USR, snmpwalk, and
> > perl.
>=20
> Yup - that's what I'm doing.
>=20
> > I don't want to invent the wheel. If someone has anything I can =
use,
> > please let me know. My final program shouldnt take long, and will =
do the
> > following:
>=20
> What I've got is fairly proprietary in what it does, but feel free to
> drop me an e-mail for more info. If I get time, I may well try and put
> a tarball together for this.
Here we go. I'm also VERY interested in this funny thing of software.
>=20
> > output info in html, probably using tables
>=20
> Thats what I'm working on next. In fact, you can read the
> mdmCsFreqProbData and mdmCsLevelProbeData and work out a graph of the
> lines attenuation/frequency.
>=20
> The only draw back to that is the graph is only available for V.34
> calls. I would *love* this data to be made available for X2 calls. How
> about it USR?
Wait a minute. Maybe there will be something in TCS 2.5.1. But I'm not =
sure now.
Have a nice day,
Holger Koepke
--=20
I have written this! Not MMS! Got it?
Subject:Re: (usr-tc) Upgrading to TCS 2.5.1 From: Brian Elfert <brian@citilink.com> Date: 1997-07-02 10:14:29
On Wed, 2 Jul 1997, King Ho wrote:
> I upgraded the NMC firmware from 4.3.4 to 4.3.8 and my TCM (4.3.0) won't
> be able to access the NMC anymore. The error message is "Error Opening
> Device Description File". Did I miss anything? Or do I need to upgrade the
> TCM also.
When I upgraded my NMC card, I upgraded my TCM first. The old TCM
probably doesn't recognize some of the new SNMP varaiables.
You should either upgrade your TCM, or copy the new MIB files included
with the NMC upgrade to your mibs subdirectory for TCM.
Brian
Subject:(usr-tc) CGI to interface with USR-TC From: Rick Payne <rickp@corp.netcom.net.uk> Date: 1997-07-02 10:31:34
Brian writes:
> I have an idea, to write a CGI, that our users can use from our web site,
> that will show them all the statistics for there PPP link.
Yeah - I've written stuff for a tech support people to use.
> I want to do this, using the MIB files from USR, snmpwalk, and
> perl.
Yup - that's what I'm doing.
> I don't want to invent the wheel. If someone has anything I can use,
> please let me know. My final program shouldnt take long, and will do the
> following:
What I've got is fairly proprietary in what it does, but feel free to
drop me an e-mail for more info. If I get time, I may well try and put
a tarball together for this.
> output info in html, probably using tables
Thats what I'm working on next. In fact, you can read the
mdmCsFreqProbData and mdmCsLevelProbeData and work out a graph of the
lines attenuation/frequency.
The only draw back to that is the graph is only available for V.34
calls. I would *love* this data to be made available for X2 calls. How
about it USR?
> If anyone has any comments/suggestions before I take the plunge and write
> this thing, I'd appreciate it.
Hashes are your friend when converting SNMP response into English ;)
Rick
--
Rick Payne, Senior Network Admin | Meddle not in the affairs of
NETCOM Internet Ltd. | dragons - for you are crunchy &
rickp@corp.netcom.net.uk | taste great dipped in chocolate.
Subject:RE: (usr-tc) CGI to interface with USR-TC and dynamic IPs From: marc guldimann <mguldima@informatica.com> Date: 1997-07-02 10:59:59
------ =_NextPart_000_01BC86D7.0A3000E0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
We are using a cgi to allow users to change passwords, and admins to add =
dialin accounts. We have all of the users on the Radius server using a =
unix password file, and the cgi just changes that password file. This =
way we can check for unsecure passwords, etc.
Currently we are using static IPs, and the adduser cgi makes a new entry =
in the Radius users file and in the unix password file. (radius server =
and cgi are on the same machine)
We would like to move to dynamic IP's but are having trouble assigning =
the IP's with the USR. If someone that is using dynamic IPs and Merit =
Radius could give me a push in the right direction that would be great. =
(Like posting the entry in the user file for the Default user) In a =
best case scenario we would just have one entry in the users file, which =
would be the default user, defining PPP, netmask, and to use the unix =
password file.
thanks for any help
marc
-----Original Message-----
Sent: Wednesday, July 02, 1997 10:21 AM
we want to do something similiar. Our users should be able to change=20
password, perhaps email-alias, by a perl/CGI-construction. For the =
moment=20
we don't know how that will work together with RADIUS. As the USR-TC=20
doesn't support finger (as I read the last days in this list), it would=20
be interesting to integrate some feaktures like: number of modems =
online,=20
numbers of ISDN-lines etc., but that is not first importance.
Is there anybody who has worked on password-changing by web-formulars =20
------ =_NextPart_000_01BC86D7.0A3000E0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IigRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQmAAQAhAAAAMkZFMTI5M0I3NkYyRDAxMTlGODYwMEEwMjRBNDFB
OEYAEgcBBYADAA4AAADNBwcAAgAKADsAOwADAGABASCAAwAOAAAAzQcHAAIACgA7ADsAAwBgAQEE
kAYA9AEAAAEAAAARAAAAAwAAMAAAAAALAA8OAAAAAAIB/w8BAAAAUQAAAAAAAACBKx+kvqMQGZ1u
AN0BD1QCAAAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAFNNVFAAdXNyLXRjQG1haWwueG1p
c3Npb24uY29tAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAAZAAAAdXNyLXRjQG1haWwu
eG1pc3Npb24uY29tAAAAAAIB9g8BAAAABAAAAAAAAAADABUMAQAAAAIBCzABAAAAHgAAAFNNVFA6
VVNSLVRDQE1BSUwuWE1JU1NJT04uQ09NAAAAHgABMAEAAAAbAAAAJ3Vzci10Y0BtYWlsLnhtaXNz
aW9uLmNvbScAAB4AIDoBAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAALAEA6AQBs
IAMA/g8GAAAAAwAAOQAAAAADAP9fAAAAAAMA/V8BAAAAHgD2XwEAAAAZAAAAdXNyLXRjQG1haWwu
eG1pc3Npb24uY29tAAAAAAIB918BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10
Y0BtYWlsLnhtaXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAwm8BDYAE
AAIAAAACAAIAAQSAAQA6AAAAUkU6ICh1c3ItdGMpIENHSSB0byBpbnRlcmZhY2Ugd2l0aCBVU1It
VEMgYW5kIGR5bmFtaWMgSVBzAKUSAQOQBgDgCQAAJwAAAAMANgAAAAAAAwBIgAggBgAAAAAAwAAA
AAAAAEYAAAAAUoUAALcNAAAeAEmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAA
AwBKgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAEeACCAGAAAAAADAAAAAAAAARgAAAAAD
hQAAAAAAAAsAS4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwBMgAggBgAAAAAAwAAAAAAA
AEYAAAAAEIUAAAAAAAADAE2ACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAT4AIIAYAAAAA
AMAAAAAAAABGAAAAABiFAAAAAAAAHgBQgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAA
AAAAAB4AUYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAFKACCAGAAAAAADA
AAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAAgEJEAEAAABQBQAATAUAAAYIAABMWkZ19qC9tAMA
CgByY3BnMTI1djIA9AH3IAKkA+MCAGOCaArAc2V0MCAHE4cCgwBQD7ZwcnEyELZmfQqACMggOwlv
DjA1swKACoF1YwBQCwNjAEFFC2BuDhAwMzMLpiDYV2UgCsAXMHUAkBYwARdAIGNnaSB0b/0XQGwJ
AAfgF5AEkAQgGFFfEDEWMBcwCrAEEHcFsGQkcywXQG5kF0Bkbe8LgBkjGtAasGQHMQuAF0CKYwWg
dQIwcy4gFxKNEEB2FzEYkCBvZhhAXmgXchkCAiAds1Ia0Gl9F5AgGPEdIAXAF5YcYGnSeBnXIGYD
EGUadB3C/RgSaheQBUAZdBkhEEAFQBMgixyhVGgEACB3Yb55JJAh0QOREDAFkGshAHcFsRxgEHBj
CHAZyxCAY3YuCqIKgEMIcAlwAjBsHyTDF1giUCMgDeAgSVC/GmUdwhtxGOIYAwDAaweR7RfwbgfR
KBFyJMAb8R6ZPxjkIRIagyxlID8kEihynx7rGpIYEhdSHmVzYQeA5ysxEDALgGUpJ3QndBch+Rog
dWwasBvgK2AYQgRgYx0hGFFkeW4yICmDJ/kEIGJ1BUAXUh0BF7IsIM8IYAJgFzEEEGlnAwA2wh8d
0TWzA/AdwB2zVVNS1RyhSR2gcwNwZQIgNGG/IxIkcReUNTgrgRqhTQZx/wVAHtUcQTQBGCAdITIx
F/CecBeQONAsZQUQZ2gFQHsbsAlwYylwHmMjITPUYk8XMAnBIyAcoChMNEJw/m8iUDfWLAsqsy2j
JbIdwrpEARBhM/AFQBjiKTlx3xwBQFEiUhnwMfFjCfAKwP8/cCTSM9QiMx0DOgJCLy2E/RpwdyRg
EDA/+B3CAQFER+8acAEBC4AXslBMIBpwK8DydADAc2shVRhgGOEuX+cjxTLqIwFuay2BBbEAcLMk
wB3QbHAndADAcgDg5zL5CvQb4DM2AUAV0AFAGRIAb3Q/QRFEMTYg+i1Uck8+sQuAB0A8EQQQ/mEZ
sFRzMuZThFNRCxNThmBpLTE0NAFAG+AxHDgwAUAM0FgTYiBG1QNhOgyDYhCgTBBRWVEGZRxgGrBb
U01UUE46C2ADUFqiQGMFIC5LVbBToWgDAGsuTfEt1wSQFhIJ8C4BAF0y5VlALwZgAjBZpxcgZCvA
c2SbJLAacEoz8CTAMDIacBAxOTk3YFAwOjLKMRCwTV3HVG9ZpxeQMnJcMGNAAMADEC541xrwN4EC
IC4FoG1dyDcgxmo/QVmnUmU6L+BidHFE0ENHSRhCC4BToHKPRDBGADiUOTEtVENWH/9XKlLUC7Yy
+UaCAHAFQDUCfxhgOcIdwCkDB3ADEAcwcv0coE8IcBjVPhBAFgGgLcFvGUgndBnmGnBwBJAQQHB1
BCBlYuItG9EZ8BpwYtckwD3RXQEvZlEtBaAAgO8sIBVAP2IcoEZDpQRgB4Ana8FrF2wgbicFQGtu
/xixbkAH4D+0AxADIBohJZAfGFAZsB3BBcA4o1JBRPZJOTAcoEEi4jkTZ+FvtcdsIAeQdXJzdXBB
YAAg9yEBGaEFwCgZ8CmgPqBAsP8hlAtgIlFfgQQgLGMkcRvg/SJQKRpwPFEz1Cd0QGFmw/9FYTaz
ZqQJwCMgMfE50SEAeUCwa3QmQX0yK2BloG7edQbQH4EdkQRibR5CG+EfIUEndIHEHkEdoElTRPxO
LYLycSEnQXHxNhE6Ru91wHqyEGA6cW16ggBwRgD9TxtJeKMXYVCRBuA1MElx/xhgEEAkgXbxCYAe
UhnmcuBPGYIXsnIRJOBiLSWxbS8z8FpCb7USwQCNUAMAJgAAAAAAAwAuAAAAAAALAAIAAQAAAAsA
IwAAAAAACwApAAAAAAAeAHAAAQAAADoAAABSRTogKHVzci10YykgQ0dJIHRvIGludGVyZmFjZSB3
aXRoIFVTUi1UQyBhbmQgZHluYW1pYyBJUHMAAAACAXEAAQAAABYAAAABvIcRtSxjdYjA8v8R0Ixr
AGCXwqR4AAADAIAQ/////0AAOQCyCrzBEYe8AQMA8T8JBAAAHgAeDAEAAAADAAAARVgAAB4AHwwB
AAAAQAAAAC9PPUlORk9STUFUSUNBIENPUlBPUkFUSU9OL09VPUlORk9STUFUSUNBL0NOPVJFQ0lQ
SUVOVFMvQ049TUFSQwACAfk/AQAAAFwAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089
SU5GT1JNQVRJQ0EgQ09SUE9SQVRJT04vT1U9SU5GT1JNQVRJQ0EvQ049UkVDSVBJRU5UUy9DTj1N
QVJDAB4A+D8BAAAADwAAAE1hcmMgR3VsZGltYW5uAAACAfs/AQAAAFwAAAAAAAAA3KdAyMBCEBq0
uQgAKy/hggEAAAAAAAAAL089SU5GT1JNQVRJQ0EgQ09SUE9SQVRJT04vT1U9SU5GT1JNQVRJQ0Ev
Q049UkVDSVBJRU5UUy9DTj1NQVJDAB4A+j8BAAAADwAAAE1hcmMgR3VsZGltYW5uAABAAAcw/kW3
wRGHvAFAAAgwGpTFwRGHvAEDAAYQSCY8/wMABxAYBQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAA
ZQAAAFdFQVJFVVNJTkdBQ0dJVE9BTExPV1VTRVJTVE9DSEFOR0VQQVNTV09SRFMsQU5EQURNSU5T
VE9BRERESUFMSU5BQ0NPVU5UU1dFSEFWRUFMTE9GVEhFVVNFUlNPTlRIRVJBREkAAAAAAwANNP0/
AAACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgA9AAEAAAAFAAAAUkU6IAAAAAAniw==
------ =_NextPart_000_01BC86D7.0A3000E0--
Subject:Re: (usr-tc) CGI to interface with USR-TC From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de> Date: 1997-07-02 14:41:48
On Tue, 1 Jul 1997, Brian wrote:
Hi Brian,
> I have an idea, to write a CGI, that our users can use from our web site,
> that will show them all the statistics for there PPP link.
>
> I want to do this, using the MIB files from USR, snmpwalk, and perl.
we want to do something similiar. Our users should be able to change
password, perhaps email-alias, by a perl/CGI-construction. For the moment
we don't know how that will work together with RADIUS. As the USR-TC
doesn't support finger (as I read the last days in this list), it would
be interesting to integrate some feaktures like: number of modems online,
numbers of ISDN-lines etc., but that is not first importance.
Is there anybody who has worked on password-changing by web-formulars?
Greetings,
Lars
P.S: thanks to all who mailed me for our problem version/memory, it was
very helpful. This stoy will continue, as esterday I tried to upgrade to
16 MB and now my NetServerCard doesn't come up any more, even with the
old SIMM... We are waiting for a replacment by USR...
+-----------------------------------------------------------------+
| Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de |
| FOnLine Buergernetzverein: http://www.forchheim.baynet.de |
| http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html |
+-----------------------------------------------------------------+
Subject:Re: (usr-tc) TC 2.5.1 From: Charles Hill <chill@ionet.net> Date: 1997-07-02 15:54:08
On Wed, 2 Jul 1997, Adam Wills (Global 2000) wrote:
> According to the www page, I need to use either "DS" or "SS" (revisions
> 5.5.6 and 5.6.6 respectively) for the quad cards. OK, dumb question
> (beware), but how does one make SURE remotely (w/o being at the site)?
> The inventory doesnt say "double sided/single sided" etc. Id hate to dl
> the WRONG one and mung things up.
Adam,
The TCM won't let you sdl the wrong code. QF modems take QF code, and QR
modems take QR code. In fact, if you mix types of modems in the same
chassis and try to select them by ctrl-click or from the menu (View |
Select All) it will only let you highlight similar cards.
-CH
I noticed that they still dont have a revised DUAL T1 Channelized 386*
code release (still 4.1.5) which is what we run. I see all the other ones
(dual PRI T1, E1 and DUAL E1/CAS) are availible as new.
Anyone know if/when a new Chan T1 release is due?
Also, i have "USR Quad v.34 Digital Modem NAC hardware 3.0.0 and Softwre
5.1.7".
According to the www page, I need to use either "DS" or "SS" (revisions
5.5.6 and 5.6.6 respectively) for the quad cards. OK, dumb question
(beware), but how does one make SURE remotely (w/o being at the site)?
The inventory doesnt say "double sided/single sided" etc. Id hate to dl
the WRONG one and mung things up.
Adam Wills Global 2000 Communications
Director of Networking Systems 1840 Western Ave.
sysadmin@global2000.net Albany, NY, 12203
http://www.global2000.net (518) 452-1465
Subject:Re: (usr-tc) TC 2.5.1 From: Brian <signal@shreve.net> Date: 1997-07-02 19:30:20
On Wed, 2 Jul 1997, Adam Wills (Global 2000) wrote:
> I noticed that they still dont have a revised DUAL T1 Channelized 386*
> code release (still 4.1.5) which is what we run. I see all the other ones
> (dual PRI T1, E1 and DUAL E1/CAS) are availible as new.
>
> Anyone know if/when a new Chan T1 release is due?
>
> Also, i have "USR Quad v.34 Digital Modem NAC hardware 3.0.0 and Softwre
> 5.1.7".
>
> According to the www page, I need to use either "DS" or "SS" (revisions
> 5.5.6 and 5.6.6 respectively) for the quad cards. OK, dumb question
> (beware), but how does one make SURE remotely (w/o being at the site)?
> The inventory doesnt say "double sided/single sided" etc. Id hate to dl
> the WRONG one and mung things up.
you pull a quad modem out and look at the circuit board to see if its
double or single sided.
Brian
>
> Adam Wills Global 2000 Communications
> Director of Networking Systems 1840 Western Ave.
> sysadmin@global2000.net Albany, NY, 12203
> http://www.global2000.net (518) 452-1465
>
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian <signal@shreve.net> writes:
> you pull a quad modem out and look at the circuit board to see if its
> double or single sided.
Definitely works if you're physically there and don't mind disrupting
usage of the card, but if not, I'd just check through the NMC. The
module type (uchasSlotModuleType) for the original dual sided card
will be one of:
uchasQuadV34DigModemNAC
uchasQuadV34AnlModemNAC
uchasQuadV34DigAnlModemNAC
depending on what configuration of digital/analog you are using.
For the newer, single sided cards, it will be one of:
uchasQuadV34DigitalG2NAC
uchasQuadV34AnalogG2NAC
uchasQuadV34DigAnlgG2NAC
(note the trend... e.g., look for the "G2" :-))
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Hi All,
Has anyone had problems with users connecting with Boca or Zoom modems?
A couple of users have reported problems connecting to the USR's with these modems. They say that they hear the modem pick up, but it never connects (They just hear the carrier and I guess their modems don't??)
If anyone has had experience with this problem I would appreciate any help I can get before I have to go at it with USR tech supp.
Thanks
Elio Fuentes
emf@agetech.net
Subject:(usr-tc) New software and PMCOM From: System Administrator <root@wingnet.net> Date: 1997-07-03 09:31:45
If I upgrade my dual PRI chassis to the newer code, will it prevent
me from using PMCOM and PMWHO to query the NetServer card?
I've read where the OS was changing.
If it will affect it, what are the benefits to upgrading? And anyone
out there writing any equivalents to PMCOM and PMWHO if they no
longer work?
TIA.
WingNET System Administrator
423-559-LINK (v)
423-559-5444 (f)
What does
...occassionally even the Net Server shows the user as USR_NETS
mean? A local login?
Are users supposed to always get forwarded to RADIUS? If so, delete that
USR_NETS login, and see what happens.
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Wed, 2 Jul 1997, Jeff Binkley wrote:
>
>
> I have recently turned up my first USR Total Control node and RADIUS, so
> I am somewhat of a novice at this pice of things but am learning fast.
> In reviewing my security.log file (I have it turned on until I am
> comfortable everyting is working ok) I am seeing instances where a
> userid USR_NETS is logging in according to RADIUS. In most instacnes I
> can look at the Net Server card and see that someone else is really
> logged in but occassionally even the Net Server shows the user as
> USR_NETS. Does anyone have an idea why this is happening ? I do see
> where on the Net Server card there is a USR_NETS userid specified under
> the RADIUS options. I can forward a copy of the RADIUS logs if that
> would help.
>
>
> Jeff Binkley
> ASA Network Computing
>
> CMPQwk 1.42 9999
>
>
> I upgraded the NMC firmware from 4.3.4 to 4.3.8 and my TCM (4.3.0) won't
> be able to access the NMC anymore. The error message is "Error Opening
> Device Description File". Did I miss anything? Or do I need to upgrade the
> TCM also.
>
> It works again after I downgrade the NMC firmware back to 4.3.4.
If you check out NMC card (through TCM), in NMC identification group
there's entry "Software Compatibility Version". For NMC 4.3.8 it has
value 4.3.5 which likely means that TCM must have directory NM040305
(in TCM_DAT).
Maybe adding this dir with its content would help, but the best idea
is to upgrade TCM as whole.
Kamil Kukura
U N I C O M (authorized distributor of U.S.Robotics)
Usti nad Labem, Czech Republic
Subject:RE: (usr-tc) CGI to interface with USR-TC and dynamic IPs From: Kamil Kukura <kamil@nw3.unicom.cz> Date: 1997-07-03 11:38:53
> We would like to move to dynamic IP's but are having trouble assigning =
> the IP's with the USR. If someone that is using dynamic IPs and Merit =
> Radius could give me a push in the right direction that would be great. =
> (Like posting the entry in the user file for the Default user) In a =
> best case scenario we would just have one entry in the users file, which =
> would be the default user, defining PPP, netmask, and to use the unix =
> password file.
If you need simple dynamic IP you can use Netserver for doing that.
For example I have 4 modems so I set up the IP address pool:
set assigned 194.108.48.65
set limit 3
In RADIUS config, you simply omit Framed-IP-Address in DEFAULT user
entry.
> thanks for any help
> marc
>
Kamil Kukura
U N I C O M (authorized distributor of U.S.Robotics)
Usti nad Labem, Czech Republic
> On Wed, 2 Jul 1997, Adam Wills (Global 2000) wrote:
>
> > 5.5.6 and 5.6.6 respectively) for the quad cards. OK, dumb question
> > (beware), but how does one make SURE remotely (w/o being at the site)?
On Wed, 2 Jul 1997, Brian wrote:
> you pull a quad modem out and look at the circuit board to see if its
> double or single sided.
NOTICE I said "w/o bneing AT THE SITE", i'd love to drive 200 miles and do
that too, BUT :)
Adam Wills Global 2000 Communications
Director of Networking Systems 1840 Western Ave.
sysadmin@global2000.net Albany, NY, 12203
http://www.global2000.net (518) 452-1465
-> What does
->
-> ....occassionally even the Net Server shows the user as USR_NETS
->
-> mean? A local login?
->
-> Are users supposed to always get forwarded to RADIUS? If so, delete that
-> USR_NETS login, and see what happens.
No, they are actual user logins but it shows it as USR_NETS on the port status
on the Net Server. I believe the problem happens right after a bad login and
the next good user shows up as USR_NETS. Delete the USR_NETS from where ? The
netserver RADIUS settings or from the RADIUS database ?
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) usr-tc "cloning" of components From: William M Sheeler Sr <tcra@talon.net> Date: 1997-07-03 22:51:43
I am new at this USR-TC Stuff. I know I was shown once, but alas, I forgot
to write instructions down and my brain went into thermal meltdown, I forgot.
How do I go about cloning a good modem setup to all of the other modems and
also to or from another TC Rack?
TTFN
Bill
William M Sheeler, Sr www.talon.net
ceo
TCRA Computers and voice 610.670.6491
TALON Network Services, Inc voice 610.670.4923
Fax for both fax 610.670.6495
( Total Area Linked Online Nationwide Network Services, Inc)
" Live with Passion "
" It's in your moments of decision that your destiny is shaped "
ANTHONY ROBBINS
Subject:Re: (usr-tc) usr-tc "cloning" of components From: Rick <rallan@monmouth.com> Date: 1997-07-03 23:56:28
William M Sheeler Sr wrote:
>
> I am new at this USR-TC Stuff. I know I was shown once, but alas, I forgot
> to write instructions down and my brain went into thermal meltdown, I forgot.
>
> How do I go about cloning a good modem setup to all of the other modems and
> also to or from another TC Rack?
>
> TTFN
>
> Bill
>
> William M Sheeler, Sr www.talon.net
> ceo
> TCRA Computers and voice 610.670.6491
> TALON Network Services, Inc voice 610.670.4923
> Fax for both fax 610.670.6495
>
> ( Total Area Linked Online Nationwide Network Services, Inc)
>
> " Live with Passion "
>
> " It's in your moments of decision that your destiny is shaped "
> ANTHONY ROBBINS
If using the tcm software you would bring up the box you want to copy
too and highlight the modems you want to update. Then click on either
the configure or fault header (depending on which area you want to
update) choose the first sub header and then you can click load from and
it will ask you the IP of the box you want to update from...
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rick---* http://www.monmouth.com | Serving the Central
Monmouth Internet Engineer | New Jersey Area
Operations and Technical Support | Phone: 732-224-8624
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject:(usr-tc) Framed-route From: Brian Elfert <brian@citilink.com> Date: 1997-07-04 14:49:11
Does anyone have Framed-route working with a Netserver card? Code release
3.5.34 is supposed to fix it, but it's made things worse for me. The
Netserver not only doesn't add the routes, but it screws up routing as
soon as a user with a framed-route calls in.
When anyone with a framed-route calls in, my unix boxes can no longer ping
the Netserver, and any telnet sessions to the Netserver freeze up. I can
ping the Netserver from another win 95 box, but it can't establish a
telnet session to the Netserver. The problems vanish the second the the
user hangs up.
USR tech support was on the line with me yesterday while I made test calls
to the TC rack. He could still access the Netserver, but I couldn't.
Tech support verified that the routes aren't being added.
Here is the Radius entry if that will help. This Radius entry works with
a Portmaster 2E on the same /24 as the Netserver.
Pcoax Auth-Type = System, Prefix = "P"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-Address = 206.11.209.5,
Framed-Route = "206.11.209.200 206.11.209.5 1",
Framed-Route = "206.11.209.201 206.11.209.5 1",
Framed-Netmask = 255.255.255.255,
Framed-Routing = None,
Framed-MTU = 1500
Brian
On Fri, 4 Jul 1997, Brian Elfert wrote:
> Does anyone have Framed-route working with a Netserver card? Code release
> 3.5.34 is supposed to fix it, but it's made things worse for me. The
> Netserver not only doesn't add the routes, but it screws up routing as
> soon as a user with a framed-route calls in.
>
> When anyone with a framed-route calls in, my unix boxes can no longer ping
> the Netserver, and any telnet sessions to the Netserver freeze up. I can
> ping the Netserver from another win 95 box, but it can't establish a
> telnet session to the Netserver. The problems vanish the second the the
> user hangs up.
>
> USR tech support was on the line with me yesterday while I made test calls
> to the TC rack. He could still access the Netserver, but I couldn't.
> Tech support verified that the routes aren't being added.
>
> Here is the Radius entry if that will help. This Radius entry works with
> a Portmaster 2E on the same /24 as the Netserver.
>
> Pcoax Auth-Type = System, Prefix = "P"
> Service-Type = Framed-User,
> Framed-Protocol = PPP,
> Framed-Address = 206.11.209.5,
> Framed-Route = "206.11.209.200 206.11.209.5 1",
> Framed-Route = "206.11.209.201 206.11.209.5 1",
> Framed-Netmask = 255.255.255.255,
> Framed-Routing = None,
> Framed-MTU = 1500
>
> Brian
Your Framed-Route should have the netmask with it.
so your framed route entry should look like
Framed-Route = "206.11.209.200/32 206.11.209.5 1"
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
Subject:(usr-tc) Total Control RADIUS question From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-05 13:32:00
Well one week into installing our first Total Control node and RADIUS, I feel I
know more about it than a man ought to. Anyway, now onto my next challenge. I
am trying to figure out why RADIUS doesn't appear to be getting the
Final_Tx_Link_Data_Rate field in the CALLS table isn't getting populated. I've
turned on verbose debugging but it doesn't appear the NetServer client is
passing the info. Now I did find out that I could add certain fields to the
CALLS table and restart RADIUS to get info which wasn't being passed (i.e.
Client_Port_Id, Framed_Address etc..) before that I wanted. However, since
Final_Tx_Link_Data_Rate doesn't appear in the verbose output and the column
already exists in the CALLS table, I am stumped right now. Of course the
next question is going to be distinguishing ISDN calls from analog calls
and then Initial_Tx_Link_Data_Rate. Thanks in advance.
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) MPP update From: Brian <signal@shreve.net> Date: 1997-07-05 15:32:30
I have a user who is dialing in, and connecting with ISDN on one of our TC
hubs using tcs2.5.1
He is settting up a ISDN Async v120 call. What is the purpose/differnces
in v120 and v110 over regular syncronous?
Is MPP possible with v120? Most of our users dial in and show:
64k-sync
he shows:
56k-v120
I think he is doing something wierd and obsure that he probably doesnt
want to be doing. He is using a 3com impact iq. He wants to do MPP but
claims its not letting him.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Hello
Sometimes I have the problem, that I cannot change the Modemport in
Netserver from inactive to active.
If I say 'set modem sx-sy active' they chage for a while to A A P and some
seconds later back to I I P.
I saw this problem so far with all firmware Versions up to TCS 2.5.1.
Sometimes it is enough to Hardware reset the Modem and/or the Netserver.
Sometimes it helps to redownload the Firmware on Modem, Netserver or PRI.
Sometimes the only way to bring it back is changing the Netserver Hardware.
It happens, that the same Netserver works again in another Chassis.
I cannot believe in an real hardware problem.
Has anyone the same pronblems or does anyone know were the problem is
locatet? I thought, I kwnow this hareware a little bit, but at the moment
I'm desperate.
so long
Ralf
Subject:(usr-tc) Field Report 216 From: Brian <signal@shreve.net> Date: 1997-07-06 10:47:29
Does anyone know if there is a solution underway with Field Report 216
(PRI T1 card places DS0's OOS). This occurs when the pri is removed then
placed back in service on a dms-100. The result is your ds0's are placed
OOS, and the only way to get them back is to MANUALLY place them back in
service.......this is a nightmare. Something about the DMS100 not sending
the command to the pri t1 card to "resync".
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Quake Lag From: Brian <signal@shreve.net> Date: 1997-07-06 10:49:55
Looking thru the Field Reports I noticed #2135 which is the one on the
Quake Lag situation. It claims the descrepency in 3.4.23 and 3.5.31 and
the fixed version is 3.5.93.
Actually however, I think Quake lag problem was since 3.3.28, and was
actually fixed as early as 3.5.33. The current TCS 2.5.1 (netserver
3.5.34) seems to be just fine. We run quite a popular Quake server and
haven't had any lag problems since going to netserver 3.5.33 (we currently
run 3.5.34).
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) 24 port modem cards From: Brian <signal@shreve.net> Date: 1997-07-06 10:52:49
Anyone know the status of the 24 modem cards? It's time for us to
purchase yet another hub, and I was kinda holding off hoping these would
be released.
Also does anyone know how they work? Does each card have a 10bT port on
them? I would think they would have too, or there would have to be a
100bT Netserver card, because otherwise you would saturate 10bt with a
fully loaded chasis with 24modem cards.
Aside from the 24modem cards, does anyone know of any other high density
cards coming out? netserver? nmc?
It will be alot nicer to manage a chasis with 24*16 modems in it, than
several hubs. Hopefully the price is right.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) ISDN Problem From: Brian <signal@shreve.net> Date: 1997-07-06 18:39:46
I have a user that cannot establish a 64k-sync ISDN connection to TC HUB
#1 of ours, but can to all the rest of the hubs. I found this parameter
on the Quad modems to be different for TC HUB #1:
Under "ISDN Modem Call Control Options"
Set Originate Analog Modem/Fax Data is set to analogModemFax
yet on the other hubs it looks like:
Set Originate Analog Modem/Fax Data is set to none
does anyone know if this parameter would indeed preclude users from
getting synchronous ISDN. Now they CAN get 56k-v120, which is a async
protocol, and can't do MPP. I want them to be able to do 64k-sync, but am
not sure that parameter is whats causing it.
I could just "change" the parameter and find out, but I dont want to have
to drop 48 users to find out, so I am trying to rely on someone else who
may know more about the setting than I do.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Multilink is not possible with V.120
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Sat, 5 Jul 1997, Brian wrote:
> I have a user who is dialing in, and connecting with ISDN on one of our TC
> hubs using tcs2.5.1
>
> He is settting up a ISDN Async v120 call. What is the purpose/differnces
> in v120 and v110 over regular syncronous?
>
> Is MPP possible with v120? Most of our users dial in and show:
>
> 64k-sync
>
> he shows:
>
> 56k-v120
>
> I think he is doing something wierd and obsure that he probably doesnt
> want to be doing. He is using a 3com impact iq. He wants to do MPP but
> claims its not letting him.
>
> Brian
>
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
Also a point to see in this chassis is how isdngloba is set as
type show isdng and see if you have sync-ppp enabled - If not enable that.
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Sun, 6 Jul 1997, Brian wrote:
>
> I have a user that cannot establish a 64k-sync ISDN connection to TC HUB
> #1 of ours, but can to all the rest of the hubs. I found this parameter
> on the Quad modems to be different for TC HUB #1:
>
> Under "ISDN Modem Call Control Options"
>
> Set Originate Analog Modem/Fax Data is set to analogModemFax
>
> yet on the other hubs it looks like:
>
> Set Originate Analog Modem/Fax Data is set to none
>
>
> does anyone know if this parameter would indeed preclude users from
> getting synchronous ISDN. Now they CAN get 56k-v120, which is a async
> protocol, and can't do MPP. I want them to be able to do 64k-sync, but am
> not sure that parameter is whats causing it.
>
> I could just "change" the parameter and find out, but I dont want to have
> to drop 48 users to find out, so I am trying to rely on someone else who
> may know more about the setting than I do.
>
> Brian
>
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
Subject:Re: (usr-tc) ISDN Problem From: Brian <signal@shreve.net> Date: 1997-07-06 20:47:30
On Sun, 6 Jul 1997, Tatai SV Krishnan wrote:
> Also a point to see in this chassis is how isdngloba is set as
>
> type show isdng and see if you have sync-ppp enabled - If not enable that.
>
> krish
Krish,
very interesting. On the hub I am having troubles with I get this:
login: !root
Password:
Command> sh isdngl
Protocol Status
-------- --------
V.110 enabled
V.120 enabled
Sync-PPP enabled
X.75 enabled
Use LLCIE if present: yes
ISDN protocol autodetect: enabled
V.110 autodetect: enabled
Default service profile: default-v.120
On the hub that is working fine I get this:
login: !root
Password:
Command> sh isdngl
Protocol Status
-------- --------
V.110 enabled
V.120 enabled
Sync-PPP enabled
X.75 enabled
Use LLCIE if present: yes
ISDN protocol autodetect: enabled
V.110 autodetect: enabled
Default service profile: <NONE>
how can I change the default service profile?
Brian
> -----------------------------------------
> \ T.S.V. Krishnan \
> \ Network System Engineer \ ( : - : )
> \ 3Com ............ \
> ----------------------------------------------/
> tkrishna@bubba.ae.usr.com
> ----------------------------/ http://interproc.ae.usr.com ----/
> -------------------------------------------------------------------------\
> Any Sufficiently advanced bug is indistinguishable for a feature.
> - Rick Kulawiec
> -------------------------------------------------------------------------/
>
> On Sun, 6 Jul 1997, Brian wrote:
>
> >
> > I have a user that cannot establish a 64k-sync ISDN connection to TC HUB
> > #1 of ours, but can to all the rest of the hubs. I found this parameter
> > on the Quad modems to be different for TC HUB #1:
> >
> > Under "ISDN Modem Call Control Options"
> >
> > Set Originate Analog Modem/Fax Data is set to analogModemFax
> >
> > yet on the other hubs it looks like:
> >
> > Set Originate Analog Modem/Fax Data is set to none
> >
> >
> > does anyone know if this parameter would indeed preclude users from
> > getting synchronous ISDN. Now they CAN get 56k-v120, which is a async
> > protocol, and can't do MPP. I want them to be able to do 64k-sync, but am
> > not sure that parameter is whats causing it.
> >
> > I could just "change" the parameter and find out, but I dont want to have
> > to drop 48 users to find out, so I am trying to rely on someone else who
> > may know more about the setting than I do.
> >
> > Brian
> >
> >
> >
> > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> >
> >
> >
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Upgrade to TCS 2.5.1 breaks analog dialin on PRI Chassis From: Marshall Morgan <marshall@netdoor.com> Date: 1997-07-06 20:49:28
I upgraded (2) chassis to 2.5.1 (NMC, PRI, Modems, then NETserver PRI) for
testing and reset the box.
The PRI card shows QBCH-I_MDM instead of QBCH-MDM after the reboot. When the
chassis
attempts to take calls, analog modems never sync up. Setting the modems to
QBCH-MDM and then
disabling chassis awareness on the PRI card seems to make the modems function
properly.
Unfortunately, the PRI card will not save the diabled awareness setting, thus a
power outage will
"break" the temporary fix. Of course the TCM software cannot issue this
command and a console
session will be needed ... TCM is great isn't it!
After talking to USR Tech Support it seems as though this may be a bug or an
"undocumented"
feature. We tried setting the modems to defaults, issuing a HW flow control
template, save to NRAM,
and then reset the modems then the PRI card to no avail. A trouble ticket has
been assigned and
level 2-3 support managers are looking into it. Will post any information
gathered from USR
(opps ... 3COM) tomorrow.
Just wanted to ensure everyone knows about it and to call USR if you believe
you are experiencing
the same problem.
BTW: Speaking of 3COM/USR. I hope the color of the chassis and modems do not
change to some
sort of 3COM type color scheme. I have had a black modem on my desk and office
for over 10 years.
.... just a thought ....
Marshall Morgan
Internet Doorway, Inc.
http://www.netdoor.com
601.969.1434 | 800.952.1570 | 601.969.3838 Fax
Subject:(usr-tc) MPIP From: Brian <signal@shreve.net> Date: 1997-07-06 22:03:51
to do MPIP across 2 chasis is this what I do?
on chasis #1
set mpipserver on
on chasis #2
set mpipserver ipaddress.of.server1/5912 ""
is that it? or do I have to do for server#1
set mpipclient ipaddress.of.server2 ""
I tried to do a mpipclient but it says not found or something.
what commands do i have to do to do mpip over to hubs, i want ot make hub
1 the mpipserver.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
set isdng default default-sync - for setting default-sync ppp
set isdng default default-v.120 - for v.120
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Sun, 6 Jul 1997, Brian wrote:
> On Sun, 6 Jul 1997, Tatai SV Krishnan wrote:
>
> > Also a point to see in this chassis is how isdngloba is set as
> >
> > type show isdng and see if you have sync-ppp enabled - If not enable that.
> >
> > krish
>
> Krish,
>
>
> very interesting. On the hub I am having troubles with I get this:
>
> login: !root
> Password:
> Command> sh isdngl
> Protocol Status
> -------- --------
> V.110 enabled
> V.120 enabled
> Sync-PPP enabled
> X.75 enabled
>
> Use LLCIE if present: yes
>
> ISDN protocol autodetect: enabled
> V.110 autodetect: enabled
>
> Default service profile: default-v.120
>
>
>
> On the hub that is working fine I get this:
>
>
> login: !root
> Password:
> Command> sh isdngl
> Protocol Status
> -------- --------
> V.110 enabled
> V.120 enabled
> Sync-PPP enabled
> X.75 enabled
>
> Use LLCIE if present: yes
>
> ISDN protocol autodetect: enabled
> V.110 autodetect: enabled
>
> Default service profile: <NONE>
>
>
>
>
>
> how can I change the default service profile?
>
> Brian
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > -----------------------------------------
> > \ T.S.V. Krishnan \
> > \ Network System Engineer \ ( : - : )
> > \ 3Com ............ \
> > ----------------------------------------------/
> > tkrishna@bubba.ae.usr.com
> > ----------------------------/ http://interproc.ae.usr.com ----/
> > -------------------------------------------------------------------------\
> > Any Sufficiently advanced bug is indistinguishable for a feature.
> > - Rick Kulawiec
> > -------------------------------------------------------------------------/
> >
> > On Sun, 6 Jul 1997, Brian wrote:
> >
> > >
> > > I have a user that cannot establish a 64k-sync ISDN connection to TC HUB
> > > #1 of ours, but can to all the rest of the hubs. I found this parameter
> > > on the Quad modems to be different for TC HUB #1:
> > >
> > > Under "ISDN Modem Call Control Options"
> > >
> > > Set Originate Analog Modem/Fax Data is set to analogModemFax
> > >
> > > yet on the other hubs it looks like:
> > >
> > > Set Originate Analog Modem/Fax Data is set to none
> > >
> > >
> > > does anyone know if this parameter would indeed preclude users from
> > > getting synchronous ISDN. Now they CAN get 56k-v120, which is a async
> > > protocol, and can't do MPP. I want them to be able to do 64k-sync, but am
> > > not sure that parameter is whats causing it.
> > >
> > > I could just "change" the parameter and find out, but I dont want to have
> > > to drop 48 users to find out, so I am trying to rely on someone else who
> > > may know more about the setting than I do.
> > >
> > > Brian
> > >
> > >
> > >
> > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > >
> > >
> > >
> >
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
Here is how you do MPIP, this is also shown in the release notes for
3.4.x NETServer code.
On one NETServer which will be Mpip Client do the following
set mpipserver off
set mpipserver ipaddr(of the NETServer which will be MPIPserver)/port
secret - The secret key that you are going to use
set time <ip of a NTP server>
reset time
On the NETServer which will be MpipServer
set mpipserver on
set mpipserver 1 ipaddr(of this NETServer)/port secret
set mpipclient <ip of this NETServer> secret
set mpipclient <ip of the other client NETServer> secret
set time <ip of a NTP server>
reset time
Make sure the Time server is up and the time on both NETServer's are sync.
MPIP will now work
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Sun, 6 Jul 1997, Brian wrote:
>
> to do MPIP across 2 chasis is this what I do?
>
> on chasis #1
>
> set mpipserver on
>
> on chasis #2
>
> set mpipserver ipaddress.of.server1/5912 ""
>
> is that it? or do I have to do for server#1
>
> set mpipclient ipaddress.of.server2 ""
>
> I tried to do a mpipclient but it says not found or something.
>
> what commands do i have to do to do mpip over to hubs, i want ot make hub
> 1 the mpipserver.
>
> Brian
>
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
Hi all,
I sent this message a few days ago but never saw it come up. I guess
I might have sent it to the wrong place. Anyway I'm an ISP in South
Florida and I'm in the process of converting my modems to
USR-TotalControl. The main problem I'm having is that a few of my users
can't connect to the new modems. They do however connect to the old
modems fine which by the way are USR Sportsters/ Couriers.
What most of them have told me is that they hear my modem pick up but
their modem never attempts to connect it just stays there playing my
modem's carrier on its speaker.
I had another customer just last night call me saying that he would
connect and then be dropped of within 10 seconds. We tried this about 6
times on different modems on the rack and it kept happening. When he
tried the old number it worked fine.
If anyone has had similiar problems I would appreciate any info you
can throw my way. I'm running all the modems on the factory settings so
maybe there are a couple of settings I should mess with?
Anyway, any help would be appreciated
Thanks,
Elio Fuentes
emf@agetech.net
Subject:(usr-tc) Error Message From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-07 14:47:00
Below is a copy of an error message I am receivingin my verbose Radius error
log for our Total Control node. I have not been able to identify what a 0x9023
attribute is. Any ideas ?
Accounting Event - Event Log
Code = 4
PacketID = 143
Length = 215
Authen = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Attrb: Acct_Session_Id
Value: 080000D4
Attrb: User_Name
Value: User:sgates
Attrb: Client_Id
Value: 199.178.136.18
Attrb: Client_Port_Id
Value: Port#33
Attrb: Acct_Status_Type
Value: Acct-Status-Type=1
Attrb: Acct_Authentic
Value: RADIUS
Attrb: Error: Unknown Attribute (USRNMC) 0x9023
Value:
Attrb: Modulation_Type
Value: v32Terbo
Attrb: Simplified_MNP_Levels
Value: 3
Attrb: Simplified_V42bis_Usage
Value: 1
Attrb: Chassis_Call_Slot
Value: 0
Attrb: Chassis_Call_Span
Value: 0
Attrb: Chassis_Call_Channel
Value: 0
Attrb: Unauthenticated_Time
Value: 19
Attrb: NAS_Identifier
Value: netserver
Attrb: NAS_Port_Type
Value: 0
Attrb: User_Service_Type
Value: Framed_User
Attrb: Framed_Protocol
Value: PPP
Attrb: Framed_Address
Value: 199.178.136.60
Attrb: Acct_Delay_Time
Value: 0
Attrb: Acct_Delay_Time
Value: 868293146
Thanks in advance,
Jeff Binkley
ASA Network Computing
jeff.binkley@asacomp.com
Subject:(usr-tc) Zmodem hangups? From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-07 15:27:41
Does anyone know if this latest release has the same problem that 3.4.X had
with "sz" hanging up the terminal session? I want to upgrade, but not if
this problem hasn't been resolved.
--
Pete
XMission
On Mon, 7 Jul 1997, Jeff Binkley wrote:
>
> Below is a copy of an error message I am receivingin my verbose Radius error
> log for our Total Control node. I have not been able to identify what a 0x9023
> attribute is. Any ideas ?
>
> Accounting Event - Event Log
> Code = 4
> PacketID = 143
> Length = 215
> Authen = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Attrb: Acct_Session_Id
> Value: 080000D4
> Attrb: User_Name
> Value: User:sgates
> Attrb: Client_Id
> Value: 199.178.136.18
> Attrb: Client_Port_Id
> Value: Port#33
> Attrb: Acct_Status_Type
> Value: Acct-Status-Type=1
> Attrb: Acct_Authentic
> Value: RADIUS
> Attrb: Error: Unknown Attribute (USRNMC) 0x9023
This is the Connect-Rate attribute. This will inform what is the modem
connect rate say 56k, 19200 etc. This is a vendor specific attribute.
krish
> Value:
> Attrb: Modulation_Type
> Value: v32Terbo
> Attrb: Simplified_MNP_Levels
> Value: 3
> Attrb: Simplified_V42bis_Usage
> Value: 1
> Attrb: Chassis_Call_Slot
> Value: 0
> Attrb: Chassis_Call_Span
> Value: 0
> Attrb: Chassis_Call_Channel
> Value: 0
> Attrb: Unauthenticated_Time
> Value: 19
> Attrb: NAS_Identifier
> Value: netserver
> Attrb: NAS_Port_Type
> Value: 0
> Attrb: User_Service_Type
> Value: Framed_User
> Attrb: Framed_Protocol
> Value: PPP
> Attrb: Framed_Address
> Value: 199.178.136.60
> Attrb: Acct_Delay_Time
> Value: 0
> Attrb: Acct_Delay_Time
> Value: 868293146
>
> Thanks in advance,
>
> Jeff Binkley
> ASA Network Computing
> jeff.binkley@asacomp.com
>
Subject:(usr-tc) New USR TC user having trouble From: Gregory Gulik <greg@wwa.com> Date: 1997-07-07 17:15:12
We're installing our first Total Control rack and we're having trouble
getting it to talk to the PRI lines. The switch is a DMS-100
The basic config is as follows:
Chassis Slot Device Configuration Status
Current Configuration Status
Device Device
Slot# Type Slot# Type
1 Dual-PRI 9 NONE
2 NONE 10 NONE
3 NONE 11 NONE
4 NONE 12 NONE
5 NONE 13 NONE
6 NONE 14 NONE
7 NONE 15 NONE
8 NONE 16 ISDN-GW
Assign device types to chassis slot numbers given the format below:
DEVICE_TYPE#:S#[,S#,S#-S#]
Where,
DEVICE_TYPE# -> q - QBCH-MDM,g - ISDN-GW,n - NONE (no ISDN Device in Slot)
i - QBCH-I_MDM,S# -> Chassis Slot# (1-16)
Example: q:4,5 assigns the QBCH-MDM NAC device type to slots 4 and 5.
Slots 2-13 are actually the quad modem cards, but that setting doesn't
seem to keep.
What's happening now is that you get a regular busy signal when calling
one of the phone numbers.
What should we be looking at?
The phone company says the switch is configured properly as they
have other customers with these boxes and our PRIs are supposedly
configured the same way.
USR tech support hasn't been much use so far.
Please help! We'd like to get this thing running already!
Gregory Gulik Email: greg@wwa.com
WorldWide Access Info: info@wwa.com
Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
At 10:14 AM 6/26/97 -0400, Dave Mitton wrote:
> I'm curious; What vendors _DO_ have finger support?
>
>I don't believe that Livingston, Ascend, nor we do. But I could be wrong.
Cisco and Telebit both have finger.
Both can be disabled if you don't want them.
Gregory Gulik Email: greg@wwa.com
WorldWide Access Info: info@wwa.com
Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
-> >
-> > Below is a copy of an error message I am receivingin my verbose Radius
-> error > log for our Total Control node. I have not been able to identify
-> what a 0x9023
-> > attribute is. Any ideas ?
-> >
-> > Accounting Event - Event Log
-> > Code = 4
-> > PacketID = 143
-> > Length = 215
-> > Authen = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-> > Attrb: Acct_Session_Id
-> > Value: 080000D4
-> > Attrb: User_Name
-> > Value: User:sgates
-> > Attrb: Client_Id
-> > Value: 199.178.136.18
-> > Attrb: Client_Port_Id
-> > Value: Port#33
-> > Attrb: Acct_Status_Type
-> > Value: Acct-Status-Type=1
-> > Attrb: Acct_Authentic
-> > Value: RADIUS
-> > Attrb: Error: Unknown Attribute (USRNMC) 0x9023
->
-> This is the Connect-Rate attribute. This will inform what is the modem
-> connect rate say 56k, 19200 etc. This is a vendor specific attribute.
Ok, that explains why I am not seeing the connect speeds in the calls table now
any idea on how to fix it ?? I guess I should call USRobotics. THis is right
out of the box so I am sure I am not the only one having the problem.
Jeff Binkley
ASA Network Computing
On Mon, 7 Jul 1997, Jeff Binkley wrote:
> -> >
> -> > Below is a copy of an error message I am receivingin my verbose Radius
> -> error > log for our Total Control node. I have not been able to identify
> -> what a 0x9023
> -> > attribute is. Any ideas ?
> -> >
> -> > Accounting Event - Event Log
> -> > Code = 4
> -> > PacketID = 143
> -> > Length = 215
> -> > Authen = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> -> > Attrb: Acct_Session_Id
> -> > Value: 080000D4
> -> > Attrb: User_Name
> -> > Value: User:sgates
> -> > Attrb: Client_Id
> -> > Value: 199.178.136.18
> -> > Attrb: Client_Port_Id
> -> > Value: Port#33
> -> > Attrb: Acct_Status_Type
> -> > Value: Acct-Status-Type=1
> -> > Attrb: Acct_Authentic
> -> > Value: RADIUS
> -> > Attrb: Error: Unknown Attribute (USRNMC) 0x9023
> ->
> -> This is the Connect-Rate attribute. This will inform what is the modem
> -> connect rate say 56k, 19200 etc. This is a vendor specific attribute.
>
> Ok, that explains why I am not seeing the connect speeds in the calls table now
> any idea on how to fix it ?? I guess I should call USRobotics. THis is right
> out of the box so I am sure I am not the only one having the problem.
This does not mean that you will not see the connect speeds. USR chassis
has two ways of reporting modem connect speeds. The NMC reports them to
the radius/accounting server and with the new version of NETServer and
Radius code you can have the NETServer report the connect speed.
In your case the NETServer is sending this vendor specific attribute,
this attribute will show up if it is declared and understood by Radius
server. As far as I remember this value is not yet added to the Current
4.3 USR radius server.
The NMC also send initial/final connect rate, this will be sent to the
loggin server. If you are using USR Radius server then you will see that
in the Radius/accounting log. If you are not seeing the same then it is
a configuration issue.
For attribute 9023 which is NETServer specific you have to add this to
the dictionary file in your radius and make sure that your radius server
supports vendor specific attributes
krish
>
> Jeff Binkley
> ASA Network Computing
>
Subject:Re: (usr-tc) New software and PMCOM From: Brian Elfert <brian@citilink.com> Date: 1997-07-07 20:10:15
On Thu, 3 Jul 1997, System Administrator wrote:
> If I upgrade my dual PRI chassis to the newer code, will it prevent
> me from using PMCOM and PMWHO to query the NetServer card?
>
> I've read where the OS was changing.
Version 4.0 of the Netserver card OS will no longer be Livingston based.
Version 4.0 isn't out yet, so your pmwho and pmcom will still work for
now. 3.5.34 is the latest released version. Version 4.0 is out for the
Netserver/8 and /16, and my first impression is that it sucks.
Brian
Subject:Re: (usr-tc) New USR TC user having trouble From: David Bolen <db3l@ans.net> Date: 1997-07-07 20:41:21
Gregory Gulik <greg@wwa.com> writes:
> Slots 2-13 are actually the quad modem cards, but that setting doesn't
> seem to keep.
>
> What's happening now is that you get a regular busy signal when calling
> one of the phone numbers.
>
> What should we be looking at?
Try verifing that the modems are configured to use the "priTdm"
connection as source for the line interface - that will allow the
modems to automatically communicate with the PRI card and they should
also become available on the PRI configuration screen.
The other setting for the modems is "t1Tdm" when you are using a
channelized T1 configuration (or "nic" for analog setups). If set
incorrectly for the card in use they won't communicate properly or
accept calls.
I'm not positive of where the setting is under TCM (it should be
available when a modem is selected under line interface settings), but
the MIB object is "mdmLiSrc".
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) New USR TC user having trouble From: Brian <signal@shreve.net> Date: 1997-07-07 21:29:12
On Mon, 7 Jul 1997, Gregory Gulik wrote:
>
> We're installing our first Total Control rack and we're having trouble
> getting it to talk to the PRI lines. The switch is a DMS-100
>
> The basic config is as follows:
>
> Chassis Slot Device Configuration Status
>
> Current Configuration Status
> Device Device
> Slot# Type Slot# Type
> 1 Dual-PRI 9 NONE
> 2 NONE 10 NONE
> 3 NONE 11 NONE
> 4 NONE 12 NONE
> 5 NONE 13 NONE
> 6 NONE 14 NONE
> 7 NONE 15 NONE
> 8 NONE 16 ISDN-GW
> Assign device types to chassis slot numbers given the format below:
> DEVICE_TYPE#:S#[,S#,S#-S#]
> Where,
> DEVICE_TYPE# -> q - QBCH-MDM,g - ISDN-GW,n - NONE (no ISDN Device in Slot)
> i - QBCH-I_MDM,S# -> Chassis Slot# (1-16)
> Example: q:4,5 assigns the QBCH-MDM NAC device type to slots 4 and 5.
>
>
> Slots 2-13 are actually the quad modem cards, but that setting doesn't
> seem to keep.
do q:2,3,4,5,6,7,8,9,10,11,12,13
then go into TCM, highlight the NMC and goto ACTION/COMMAND "Save Chasis
to NVRAM"
>
> What's happening now is that you get a regular busy signal when calling
> one of the phone numbers.
>
> What should we be looking at?
>
> The phone company says the switch is configured properly as they
> have other customers with these boxes and our PRIs are supposedly
> configured the same way.
>
> USR tech support hasn't been much use so far.
>
> Please help! We'd like to get this thing running already!
>
>
> ----------------------------------------------------------------------------
> Gregory Gulik Email: greg@wwa.com
> WorldWide Access Info: info@wwa.com
> Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
On Mon, 7 Jul 1997, Tatai SV Krishnan wrote:
> For attribute 9023 which is NETServer specific you have to add this to
> the dictionary file in your radius and make sure that your radius server
> supports vendor specific attributes
>
> krish
>
Is the latest dictionary file with all the ATTRIB_NMC and other USRobotic
specific entries available on the net somewhere? If someone would be so
kind to post it again to the list (latest version) I would appreciate it.
- lv
Subject:Re: (usr-tc) Modem Connection Problems From: Mark R. Lindsey <mark@vielle.datasys.net> Date: 1997-07-07 23:39:03
: What most of them have told me is that they hear my modem pick up but
: their modem never attempts to connect it just stays there playing my
: modem's carrier on its speaker.
:
: I had another customer just last night call me saying that he would
: connect and then be dropped of within 10 seconds.
Let us know the firmware version and anything interesting you're doing
with them, such as X2 or PRI.
On Mon, 7 Jul 1997, Laszlo Vecsey wrote:
> On Mon, 7 Jul 1997, Tatai SV Krishnan wrote:
>
> > For attribute 9023 which is NETServer specific you have to add this to
> > the dictionary file in your radius and make sure that your radius server
> > supports vendor specific attributes
> >
> > krish
> >
>
> Is the latest dictionary file with all the ATTRIB_NMC and other USRobotic
> specific entries available on the net somewhere? If someone would be so
> kind to post it again to the list (latest version) I would appreciate it.
>
> - lv
>
>
For which radius you are looking for? The USR radius next version will
include these attributes. I am working on the dictionary file for other
Radius servers - will send it as soon as I finish that. Also please note
that the Radius servers should support Vendor specific attributes in
order to see this value.
krish
-> > What most of them have told me is that they hear my modem pick up but >
-> their modem never attempts to connect it just stays there playing my >
-> modem's carrier on its speaker.
-> >
-> > I had another customer just last night call me saying that he would >
-> connect and then be dropped of within 10 seconds. We tried this about 6 >
-> times on different modems on the rack and it kept happening. When he
-> we still have similiar Modem Problems with our Quad Modem Cards (which do
-> you have?) Can you send us a Modem Status Report so that I can compare it
-> with ours? ("show s5" for example)
We had the same problem until we went through and initialized each modem with a
typical init string. Also you may want to check the Signal Converter
Settings-> Link Rate Speed Select option (it's the same as a &N in an init
string). It defaults to 300 baud and should be set to variable. Hope this
helps.
Jeff Binkley
ASA Network Computing
Looking for new or used Total Control Hub Modems (Dual V.34's, V.34
upgrade kits, Quad Digital or Analog) need both NIC's and NAC's
---
GSTek Corporation *Kenneth Scott Bethke* Ezy.Net Corporation
Sun/Networking/ISP Stuff -- BUY/SELL/TRADE -- FAX: 410-742-1381
Email:kbethke@ezy.net Voice:410-742-1610 Web:http://www.ezy.net/gstek
Subject:Re: (usr-tc) New USR TC user having trouble From: Kamil Kukura <kamil@nw3.unicom.cz> Date: 1997-07-08 11:10:13
> Slots 2-13 are actually the quad modem cards, but that setting doesn't
> seem to keep.
>
> What's happening now is that you get a regular busy signal when calling
> one of the phone numbers.
>
> What should we be looking at?
I'm working on beta tests of E1-CAS (not ISDN) and I'm getting the
same problem. You can go to debug menu (CTRL+D from main menu). There
should some menu like "chassis awerness table". Check this out...
> ----------------------------------------------------------------------------
> Gregory Gulik Email: greg@wwa.com
> WorldWide Access Info: info@wwa.com
Kamil Kukura
U N I C O M (authorized distributor of U.S.Robotics)
Usti nad Labem, Czech Republic
On Mon, 7 Jul 1997, Elio M. Fuentes wrote:
Hi,
> What most of them have told me is that they hear my modem pick up but
> their modem never attempts to connect it just stays there playing my
> modem's carrier on its speaker.
>
> I had another customer just last night call me saying that he would
> connect and then be dropped of within 10 seconds. We tried this about 6
> times on different modems on the rack and it kept happening. When he
we still have similiar Modem Problems with our Quad Modem Cards (which do
you have?) Can you send us a Modem Status Report so that I can compare it
with ours? ("show s5" for example)
Bye,
Lars
+-----------------------------------------------------------------+
| Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de |
| FOnLine Buergernetzverein: http://www.forchheim.baynet.de |
| http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html |
+-----------------------------------------------------------------+
I whent through what you recomended, but to no avail :( I think its a
simple error in my snmp's compatibility, but i'm unsure. I loaded the mib
file from the USR Mdm.mib file, but now get (when just typing snmpget or
snmpwalk, with or without any paramaters):
Should be ACCESS((): On or around line 150
Bad parse of objecttype: On or around line 150
Mib table is bad. Exiting
I tried adding your header, as well as the standard header used in the
main mib.txt file provided for the linux source distribution, but it
always did the same thing.. Line 150 looks like:
142 ACCESS read-only
143 STATUS mandatory
144 DESCRIPTION
145 "This object identifies the country or countries that this
146 modem is designed for use in."
147 ::= { mdmIDEntry 3 }
148
149 mdmIDHardwareSerNum OBJECT-TYPE
150 SYNTAX DisplayString (SIZE(0..16))
151 ACCESS read-only
152 STATUS mandatory
153 DESCRIPTION
154 "The modem's hardware serial number as stored in EEPROM."
155 ::= { mdmIDEntry 4 }
156
157 mdmIDHardwareRev OBJECT-TYPE
158 SYNTAX DisplayString (SIZE(0..11))
159 ACCESS read-only
160 STATUS mandatory
Ther USR mdm.mib info: MIB File Generated on 11-Feb-1997 at 10:55:55
I run cmu-snmp-linux-3.3 that I compiled cleanly myself.
Out of curiousity, which flavor of unix did you use?
Adam Wills Global 2000 Communications
Director of Networking Systems 1840 Western Ave.
sysadmin@global2000.net Albany, NY, 12203
http://www.global2000.net (518) 452-1465
On Tue, 1 Jul 1997, Stefan Virsik wrote:
> Hi Adam,
>
> let's see if I can clarify this :-).
> What I can gather from your last posting is that you're using TCM.
> Therefore
> you already have the needed MIB files. They should reside in some
> subdirectory
> named \tcmanager\mibs\. The one you're looking for is mdm.mib.
>
> Fortunately I'm working in an Unix environment. So, what I did is make
> a copy
> of the mdm.mib and insert the following header to please ucd/cmu-snmp:
>
> ----------------------------------
> RFC1155-SMI DEFINITIONS ::= BEGIN
> nullOID OBJECT IDENTIFIER ::= { ccitt 0 }
> internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
> directory OBJECT IDENTIFIER ::= { internet 1 }
> mgmt OBJECT IDENTIFIER ::= { internet 2 }
> experimental OBJECT IDENTIFIER ::= { internet 3 }
> private OBJECT IDENTIFIER ::= { internet 4 }
> enterprises OBJECT IDENTIFIER ::= { private 1 }
> END
>
> MDM-MIB DEFINITIONS ::= BEGIN
> [...]
> ----------------------------------
>
> Ok, the final steps are to tell e.g. snmpwalk which MIB file to use:
> tcsh$ setenv MIBFILE /some/folder/mdm.mib
> And to run snmpwalk, snmpget or whatever:
> tcsh$ snmpwalk -v 1 <ip of nmc> <read community> \
>
> .iso.org.dod.internet.private.enterprises.usr.nas.mdm.mdmcs.\
> mdmcstable.mdmcsentry.mdmcsfinalrxlinkrate
>
> You'll get something like the following:
> enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2001
> = bps33K(24)
> enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2002
> = bps28K(21)
> enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2003
> = bps21K(18)
> enterprises.usr.nas.mdm.mdmCs.mdmCsTable.mdmCsEntry.mdmCsFinalRxLinkRate.2004
> = bps33K(24)
>
> Hope that helped.
>
> Stefan
>
>
>
> Adam Wills (Global 2000) wrote:
> >
> > Ok, then I must REALLY be missing something here :( I do an SNMPWALK on
> > both the Netserver card and the Network Management Card (which should
> > contain any and all info for hte quad cards) but none of hte output form
> > an entire SNMPWALK shows anything with modems in it.
> >
> > You state to look at hte usr MIB for mdmCsFinalRxLinkRate OBJECT-TYPE but
> > where might I find this MIB? I checked their www site (high and low) and
> > its not there. Yes, I CAN see the connect speeds using the Total Control
> > manager, so I know hte SMNP info is gotta be there somewhere- but if an
> > SNMPWALK doesn't find it I wonder If I am doing something seriously wrong.
> >
> > #1 Anyone have the full MIB.txt file they can send me?
> > #2 What is the exact snmpget command one would use for conenction speeds?
> >
> > Thanks for any help, I'm gonna dig more through the TCM manual but It
> > doesnt talk much about smnp queries from external programs than the TCM
> > software its self.
> >
> > Adam Wills Global 2000 Communications
> > Director of Networking Systems 1840 Western Ave.
> > sysadmin@global2000.net Albany, NY, 12203
> > http://www.global2000.net (518) 452-1465
>
Subject:(usr-tc) Flash PRI card with Channelized T1 code? From: Jaye Mathisen <mrcpu@cdsnet.net> Date: 1997-07-08 16:48:00
Somehow I ended up with a TC rack that was supposed to be chan T1 but
instead has a PRI card. Can I flash the PRI card with the chan T1
firmware? I heard it was possible, but wanted to confirm it before I
thrash the card... :)
Subject:Re: (usr-tc) Modem Connection Problems From: William M Sheeler Sr <tcra@talon.net> Date: 1997-07-08 16:50:57
At 07:50 AM 7/8/97 -0500, you wrote:
>-> > What most of them have told me is that they hear my modem pick up
but >
>-> their modem never attempts to connect it just stays there playing my >
>-> modem's carrier on its speaker.
>-> >
>-> > I had another customer just last night call me saying that he would >
>-> connect and then be dropped of within 10 seconds. We tried this about 6 >
>-> times on different modems on the rack and it kept happening. When he
>-> we still have similiar Modem Problems with our Quad Modem Cards (which do
>-> you have?) Can you send us a Modem Status Report so that I can compare it
>-> with ours? ("show s5" for example)
>
>We had the same problem until we went through and initialized each modem
with a
>typical init string. Also you may want to check the Signal Converter
>Settings-> Link Rate Speed Select option (it's the same as a &N in an init
>string). It defaults to 300 baud and should be set to variable. Hope this
>helps.
>
> Jeff Binkley
> ASA Network Computing
>
>
>
Jeff:
What do you use for a typical init string for these USR quad modems (x2)?
TTFN
Bill
William M Sheeler, Sr www.talon.net
ceo
TCRA Computers and voice 610.670.6491
TALON Network Services, Inc voice 610.670.4923
Fax for both fax 610.670.6495
( Total Area Linked Online Nationwide Network Services, Inc)
" Live with Passion "
" It's in your moments of decision that your destiny is shaped "
ANTHONY ROBBINS
Subject:Re: (usr-tc) Flash PRI card with Channelized T1 code? From: David Bolen <db3l@ans.net> Date: 1997-07-08 19:54:08
Jaye Mathisen <mrcpu@cdsnet.net> writes:
> Somehow I ended up with a TC rack that was supposed to be chan T1 but
> instead has a PRI card. Can I flash the PRI card with the chan T1
> firmware? I heard it was possible, but wanted to confirm it before I
> thrash the card... :)
Yes, the "PRI" card is actually a general purpose 386-based card that
is used for both channelized (T1 and E1) and PRI (T1 and E1)
configurations. You actually want to use it instead of the older dual
T1 card because USR really stopped developing the code for the older
card a while back, and the channelized T1 code for the PRI card has
more features.
The latest channelized T1 code for the card is version 4.1.5 I believe.
You can get it from the USR TotalService site
(http://totalservice.usr.com). Follow the links to the software
download, select the total control hubs and grab the Dual T1
channelized-386 code. It appears to be available even with guest
access, although a registered account can get to more of the other
component code.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) Total Control Hub Reboots From: Cindy Smith <cindyo@ktc.com> Date: 1997-07-08 22:04:50
------ =_NextPart_000_01BC8BEA.F6F9B7A0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
We are currently running 3 total control hubs. For some reason, they =
seem to be rebooting for no apparant reason. What could be a possible =
cause for this?
We also seemed to have developed a problem with our radius log files =
growing by about 3 gigabytes in a matter of hours. They normally only =
grow about 10 meg/day. This is a sporadic problem. The file will grow =
normally for a few days and them all of the sudden in a matter of hours, =
it has completely filled the hard drive.
Any help/advice would be greatly appreciated.
Thanks in advance,
--Cindy Smith
Kerrville Telephone Company
cindyo@ktc.com
------ =_NextPart_000_01BC8BEA.F6F9B7A0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IjYDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht
aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P
BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT
TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA
AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np
b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAaAAAAVG90YWwg
Q29udHJvbCBIdWIgUmVib290cwBCCQEFgAMADgAAAM0HBwAIABYABAAyAAIAMQEBIIADAA4AAADN
BwcACAAVADkAKQACAFwBAQmAAQAhAAAANUREMTQ1NzJDRUY3RDAxMUJGQ0EwMEEwMjREMUY4OTYA
QAcBA5AGAHwFAAAhAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMA
NgAAAAAAQAA5ALAt5d0UjLwBHgBwAAEAAAAaAAAAVG90YWwgQ29udHJvbCBIdWIgUmVib290cwAA
AAIBcQABAAAAFgAAAAG8jBTdpHJF0V73zhHQv8oAoCTR+JYAAB4AHgwBAAAABQAAAFNNVFAAAAAA
HgAfDAEAAAAPAAAAY2luZHlvQGt0Yy5jb20AAAMABhDfs2QZAwAHEOcBAAAeAAgQAQAAAGUAAABX
RUFSRUNVUlJFTlRMWVJVTk5JTkczVE9UQUxDT05UUk9MSFVCU0ZPUlNPTUVSRUFTT04sVEhFWVNF
RU1UT0JFUkVCT09USU5HRk9STk9BUFBBUkFOVFJFQVNPTldIQVRDT1VMAAAAAAIBCRABAAAAaAIA
AGQCAAAWAwAATFpGdaKqGWZ3AAoBAwH3IAKkA+MCAGOCaArAc2V0MCAHE00CgH0KgAjIIDsJbzLM
NTUCgAqBdWMAUAsDBmMAQQtgbmcxMDPCMwumIFdlIArAFOAOYwhwCXACMGx5IHIMdW4DABPgIDMg
dH5vAZADIAWgAjADYAMgaEB1YnMuIEYFsXOXA3AU4AlwYRgAbiwWcExoZRXAD7BlbRZxIH5iGDIG
4BaQFiICEAXAbvkZgGFwCrEAcAVAGFQXoI5XD4AFQAWgdWxkGZLQYSBwbwQQaQJgFSG8YXUPsBpj
GNAEAD8KovcKhAqAFNJsGAAZEwmAGWK9D4B2FOABACBwCQBwH/G/HNEDYB1BGVAD8BjQIAhh0RXQ
YWRpHaAgCQAaUbcDEAeRCcBvA/AWMWIVwI8BoAhgBUAWYGdpZwGg/Hl0B5ELgBzBAMACQASQ3SIg
ZhdQCGEXkVQY4hqw+nIAwGwVsQIgFbEjgiQlAxQAJZBlZy9kYXnfJpIEACVABCAc0HMc8CJy/mMh
ViaTIxMh0SdQJ9QnB7sachzQZgfRKQEpsW4gAT8Y4BlQJ0EmAhjRF/B1ZP8BAAOgJV8mYRiwIfAg
QQQg/QWgbQtQD8Ag0CyxK7Ef8rcrIQ+BHIBkBRAgcC4edIxBbhXAGOBscC8igP52KlAU4CHQHFYJ
wRwQFbHbGuEJcGMHMCUQZDNFHnR7JrAAcGslNDRQAHA0gCxRHnotLUMLgGQVwFPWbSHxHnRLBJBy
NGAyEdMmoCDQZXAmQG4U4AhQOzFgAHB5HnQ2IDlxb0Bwa3RjLjFBHnoQcQABPlADABAQAAAAAAMA
ERAAAAAAAwCAEP////9AAAcwsHmp3ROMvAFAAAgwsHmp3ROMvAELAACACCAGAAAAAADAAAAAAAAA
RgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAA
wAAAAAAAAEYAAAAAUoUAALcNAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4
LjAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAA
AAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAA
AAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAA
HgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAA
AABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAEAAAAAAAAAAwANNP03AAC9Mg==
------ =_NextPart_000_01BC8BEA.F6F9B7A0--
Subject:Re: (usr-tc) Total Control Hub Reboots From: David Bolen <db3l@ans.net> Date: 1997-07-08 23:10:18
Cindy Smith <cindyo@ktc.com> writes:
> We are currently running 3 total control hubs. For some reason, they =
> seem to be rebooting for no apparant reason. What could be a possible =
> cause for this?
When you say the hubs are rebooting are you talking about the
NETServer, the NMC or one of the other cards such as the T1/PRI or
modems? I'm assuming you are talking about the NETServer...
> We also seemed to have developed a problem with our radius log files =
> growing by about 3 gigabytes in a matter of hours. They normally only =
> grow about 10 meg/day. This is a sporadic problem. The file will grow =
> normally for a few days and them all of the sudden in a matter of hours, =
> it has completely filled the hard drive.
Are you running current releases of all of the software, and is there
any common theme to the log entries when the log starts to grow
dramatically?
There was a bug in some previous revisions of NETServer code (it's
definitely in 3.2.x but I think it was fixed in 3.3.x) where if you
tried to telnet to the NETServer and log in as something other than
root and were using RADIUS, that the NETServer would spit out a
continuous stream of authentication requests (and lose memory in the
process). Eventually the loss of memory would cause a crash. The
request cycle continues as long as the telnet session attempting
authentication is live or until the NETServer crashes.
Even if this isn't the root cause of the crash, you may wish to
monitor your NETServer memory ("show mem") as there may be something
else burning memory which eventually causes the crash.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Total Control Hub Reboots From: Rick <rallan@monmouth.com> Date: 1997-07-08 23:12:13
Cindy, we had the same problem with one of our TC hubs. It was traced to
a faulty fc3 chip on the netserver pri card. We were lucky in that only
one of our TC hubs had this chipset and all our other netserver pri
cards have the fc2 chip. The fc3 chip will cause reset after reset of
your netserver pri card for ISDN connections. We ran the box fine for
over 2 months with only X2 analog connections. Once we accepted isdn on
the box it started the hourly rebooting. USR tech confirmed they know
about this problem which affects only fc3 chip sets....
Cindy Smith wrote:
> We are currently running 3 total control hubs. For some reason, they
> seem to be rebooting for no apparant reason. What could be a possible
> cause for this?
>
> We also seemed to have developed a problem with our radius log files
> growing by about 3 gigabytes in a matter of hours. They normally only
> grow about 10 meg/day. This is a sporadic problem. The file will grow
> normally for a few days and them all of the sudden in a matter of
> hours, it has completely filled the hard drive.
> Any help/advice would be greatly appreciated.
>
> Thanks in advance,
>
> --Cindy Smith
> Kerrville Telephone Company
> cindyo@ktc.com
>
>
> -------------------------------------------------------------------------------------------------------------
>
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rick---* http://www.monmouth.com | Serving the Central
Monmouth Internet Engineer | New Jersey Area
Operations and Technical Support | Phone: 732-224-8624
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject:RE: (usr-tc) Total Control Hub Reboots From: Cindy Smith <cindyo@ktc.com> Date: 1997-07-08 23:21:46
------ =_NextPart_000_01BC8BF7.35184FE0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
When you say the hubs are rebooting are you talking about the
NETServer, the NMC or one of the other cards such as the T1/PRI or
modems? I'm assuming you are talking about the NETServer...
=20
[Cindy Smith] The Entire modem hub is resetting. If I telnet in and =
"show uptime" it indicates the system has only been operational for a =
few hours. If you do a "show sessions" no one has been logged on more =
than the indicated uptime (this would not be the case for some of our =
users, they would stay connected for days if we let them). This tells me =
the entire system is resetting.
We have one other TC and one Netserver that has been "up" for over 21 =
and 81 days respectively.
Are you running current releases of all of the software, and is there
any common theme to the log entries when the log starts to grow
dramatically?
[Cindy Smith] This is what we are running on all three hubs
***************
Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.3.28
Build date: Dec 13 1996
Build time: 13:54:59
****************
We have been monitoring the log files. Nothing seems unusual except =
those annoying "unknow attribute" entries. We rotate the logs almost =
daily. Unfortunately, the file gets big very fast, without warning. When =
this happens, we are unable to even look at, we can only delete it.
There was a bug in some previous revisions of NETServer code (it's
definitely in 3.2.x but I think it was fixed in 3.3.x) where if you
tried to telnet to the NETServer and log in as something other than
root and were using RADIUS, that the NETServer would spit out a
continuous stream of authentication requests (and lose memory in the
process). Eventually the loss of memory would cause a crash. The
request cycle continues as long as the telnet session attempting
authentication is live or until the NETServer crashes.
[Cindy Smith] =20
Although we are using the 3.3.28 code, perhaps a user or users is =
sending a continous stream of autheitication request that might be =
overloading the system. Would this be possible? It has been observed =
that in the radius error log, there was a contiuous stream of garbage =
logins that lasted around 10 minutes.
Even if this isn't the root cause of the crash, you may wish to
monitor your NETServer memory ("show mem") as there may be something
else burning memory which eventually causes the crash.
[Cindy Smith] =20
A spot check of the memory revealed this info
****************
System memory 4295023 bytes - 4224752 used, 70271 available
Free blocks (block_size:count): 32:591 48:0 80:21 128:6 160:0 176:7 =
192:10 224:2
9 1168:0 2048:12 4176:0 20384:0
Real Available Memory: 125855
System nbufs 8000 - 70 used, 7930 available=20
****************
This does not look like it leaves a lot of memory available. I will =
monitor the memory during busy times and see if I can determine how low =
it is going. Thanks for the tip...
I appreciate your help with this,
Thanks,
--Cindy
------ =_NextPart_000_01BC8BF7.35184FE0
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IiAEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht
aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P
BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT
TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA
AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np
b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAnAAAAUkU6ICh1
c3ItdGMpIFRvdGFsIENvbnRyb2wgSHViIFJlYm9vdHMAAg0BBYADAA4AAADNBwcACAAXABUALgAC
AD8BASCAAwAOAAAAzQcHAAgAFgAqAAQAAgApAQEJgAEAIQAAADY5RDE0NTcyQ0VGN0QwMTFCRkNB
MDBBMDI0RDFGODk2ADYHAQOQBgB0CwAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAA
AAAAAwAuAAAAAAADADYAAAAAAEAAOQAAfgedH4y8AR4AcAABAAAAJwAAAFJFOiAodXNyLXRjKSBU
b3RhbCBDb250cm9sIEh1YiBSZWJvb3RzAAACAXEAAQAAABYAAAABvIwfnHdyRdFr984R0L/KAKAk
0fiWAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAADwAAAGNpbmR5b0BrdGMuY29tAAADAAYQ
A0HctgMABxAwCQAAHgAIEAEAAABlAAAAV0hFTllPVVNBWVRIRUhVQlNBUkVSRUJPT1RJTkdBUkVZ
T1VUQUxLSU5HQUJPVVRUSEVORVRTRVJWRVIsVEhFTk1DT1JPTkVPRlRIRU9USEVSQ0FSRFNTVUNI
QVNUSEVUMS9QUgAAAAACAQkQAQAAAE8IAABLCAAAJw4AAExaRnWgWgRQdwAKAQMB9yACpAPjAgBj
gmgKwHNldDAgBxNNAoB9CoAIyCA7CW8yzDU1AoAKgXVjAFALAwZjAEELYG5nMTAzPjMLpwqxCoQK
hAswbGm8MzYBQBOAFLEDYHQFkJJ0FMRXaAnwIHkIYEAgc2F5IHQXYCD4aHViBCAKwBhACXAG4DsW
oAuAZxijF6IBkGxrOxlTBuB1BUAYIRTETkUqVAZhdgSQLBgTTk2cQyAFsQIgGEBvZhgTtxagF2AF
wGMLEQQgcxLwDmgYoAQgGCJUMS9QHFJJHKEUxARibXM/YCAgSSdtHpEeUG2/GVIXohiyGh8HsBuW
LiOQvxTFE4IMMhaFD+ADMGIBQI5pJSIVOQwxIFtDC4BeZBgABgAhEBggXSVHVHUYMUUCMGkYwSAD
GFIg7wQAGOEPsRlCLiCAHTAfYH0WsGwc8AVAC4AYoCcAINAic2hvB+B1BTAHceYiKYArEmRpHfAW
sB60eHN5cxawKTEeoQIgbG0YAGIJ4RygcASQLQBp2wIgB0AgAhAFwGEvkAfRmyvACHBzKlMXomRv
L9GvK6QPsAQQL0FzLGBuMTDPHOIuAi6TCQBnZwmAHNH/KOEhsg+AA6AYIiy2K4AsBKwgKBggKZF3
CGBsK4B/MnAFQC6QGBMd8A+wL5Nz/wNwHQMIYSvwD7APoBwTGADvNmQtsBfxBaBuHPAW0DOxfS+i
ZBfwBCAGkDZQGEBs8ysBGCFtKSpQKEApkSrB/mwEIDXRGCIJ8CijLZUpm70UylcywhvgHNQdo1Qc
kPcrYhziB8B0ONEb4TRSBUBdMuciLAAsYC+ib0IyMvoxK1M4REA7EynBLvAW0P5pG+AuYD85Fc8W
1hTEBxDZGbRydTpQGVJjCHAJcP8CMBjhO8A3gS4hHTAHQAMg9x0lOAABgHcYsRwQK2I8ku8dsRsV
AHA6Em0EYDSTPSL/MTAYIjNxPYIIgTZBF2JOdn854QAgHrExMAnAK9AUxGSfLxAAwBlAHfA84Hk/
FMz/JMUK9RaVJD8m3yfmKZE2Mv9CgjuRGLNJFTPhSsIYIAnR2xhTFMQqWjwUxFQWoC9x/whQTwEG
8DXxPDAi+FvQCxEAIFYuMzQvSVPMRE42UCdxIEZRkRhAJlIq0BfxVjNdsC4y5jgUxCBwQnUDECuA
OxARFrA6IEQFkCAxM/FhMDk5Nl/MLCJg4GFA6Do1NGMQOVnfWtlGWn8/uy6TTaEncAWwGVJOdmb3
AxAHkCpQTh2RGVIPsCAxFSvwbjjAdS9xZXhjdmUFMRggbzeRAHAycHnzGVJDUG5rMnAH4C0ATxH+
YhrALFFO9SpQQAEWkS0B+05mGJFsBGAtsDsBAxBF0OggVW4voXRJEC0BLmDfHBRoQlDQQeEugGkZ
cBvh9RgAZh6gdBwQXkIaskux30kybRFPhCmRD4BwLvAAgN9x4Vfkb6ECYE4jZRvgM1L8b2tr4XQj
HfAuwS5SAQD7O8E00XQ/OyPHFmcoMhjB90uwGJEugHUZcCsxOAMWgP91UC9AOMAY4XswMgMdEly4
7wWgAQA18CdwJ1nFAQELgM8ncEWxKyJfgS54ejEFQL8qoWjhddAsgXniaEB4M7H7frNfYHhckE9x
GME7YReh/xTETxJicU5RKtRORVy4K2L/TrIrMh4xOBFo1B2UNGIUxH8DYDbRK2I7kHSCAJAZYVLg
QURJVVMcEkKRg8ztOYVwLIEasmEUxDoxGUH+dXtSLbAJcFGgSoMawBdhd1HSLzIY4XEKUC2wBCAo
/4SkN5EHgDQRfpMa9xaBajD/BBA8QShwdWFvkFICTmUEEf8dIY7lNmQd8DjBL9EFAB6gPmiQkShB
hsWNxB3geWP/cJGLdQeRHqEJABliHrQqxf8x1WviIDAsERPgTNWM3CmR/0awQFI4oSiRWRKD6pOD
aHGfI89TSAqAVZ8lekFsciL+Zx6AdEaIExgiX2R88xwQ/y7xc7F6AjjCmlM40imCD7D/LMEZYpVl
i+8XYCdwjT1CZN8hEKBQNuND4gkAYaRDLVjvbRE2czYTNwFwkcFsMDvA9SBgSUKpbxiAG8KqAkKR
/49UGOCooXthBJADYAXAM3EvHBN5t4tzi91nCsBiYf8zoDNiC4AeskKRC2AtsSuA/wrACGArcRQA
p6FpoC0Rd4yfRx+QwjtSNhMEAG4nIqT/hyOTBB0lk4McEBeiAMA5Yf8EAB6ATkAfpmczF5IFwFy4
7Y7lKCukjuEiXJAepCjC/xfxNwGFhxTEKtA3kWxAcqP/kic2IB5xdVKRBZMDHrSThH+cX51vnn+f
hophtrIXYGP/ddAdJY7lexFKMDvAqgULgD8CEGN/WtkGsC2zjuU0MpA5NTAyYVBieS0Sgi3KcTI0
NzUyOLKqZBwQN8rAN0RBdm7hv3TSFMRekFlhAmCQMGuOIXXOA18AkHpg0AWgmpEpGWDgMzJjQURA
NDg6UQ/gODA6RDExX6A6DjZhMEbg0EExNzY6fjdhYc/AspHLkdCQFMQ5/2Ew0TDQMgHQ0CHQ0Mpw
0ZJ504IzOGMwFLVe8C9xQd/M1gXQjvNi0RJwOBKAyUv+bmxAA9DQYdhwy1HMYMv2/DkzD+DMxyXJ
yC9bFjYi3zEgB5E2wnWjRrBrd0I7sf9AQXoCCQCKoZIXzMcqUV4x90rRuXbGGWQIcRlhbEAtkP9i
gxiRK3FpMTtSH2B2YgEA/RawciERGEEr0QkAB+AsgvkEIGdvKiMoQABwzkEvon+WwwUgI5gU0x9g
c8EJcGPPBzBtobnzF2BscF40NhLOLBTK5gTqGy0tw1OzrxdHuxTKEHEA72AAAwAQEAAAAAADABEQ
AAAAAAMAgBD/////QAAHMOCmHBEajLwBQAAIMOCmHBEajLwBCwAAgAggBgAAAAAAwAAAAAAAAEYA
AAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAA
AAAAAABGAAAAAFKFAAC3DQAAHgAlgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4w
AAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAA
DoUAAAAAAAADADCACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAA
AABGAAAAABiFAAAAAAAAHgBBgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4A
QoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAEOACCAGAAAAAADAAAAAAAAA
RgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAAFAAAAUkU6IAAAAAADAA00/TcAAGl3
------ =_NextPart_000_01BC8BF7.35184FE0--
Subject:RE: (usr-tc) Total Control Hub Reboots From: Cindy Smith <cindyo@ktc.com> Date: 1997-07-08 23:31:16
------ =_NextPart_000_01BC8BF7.38CA3450
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Thanks for the info. We are using the T1 cards and do not run ISDN or X2 =
on these particular modems. I will however check on the chip set info.
We are running IDSN on a Netserver 16. That one has it's own little =
quirks. On occasion when a customer is trying to connect on both =
channels, he will only get an established connection on one channel. The =
other channel just says "connecting" and never makes the connection. The =
only way we have been able to fix this is by resetting the modems, =
removing the detail file for billing and restarting radius. Fortunately =
this only happens occasionally. Having the Netserver reboot every hour =
would be a real nightmare...
Thanks for the info,
--Cindy
Cindy, we had the same problem with one of our TC hubs. It was traced to
a faulty fc3 chip on the netserver pri card. We were lucky in that only
one of our TC hubs had this chipset and all our other netserver pri
cards have the fc2 chip. The fc3 chip will cause reset after reset of
your netserver pri card for ISDN connections. We ran the box fine for
over 2 months with only X2 analog connections. Once we accepted isdn on
the box it started the hourly rebooting. USR tech confirmed they know
about this problem which affects only fc3 chip sets....
Cindy Smith wrote:
------ =_NextPart_000_01BC8BF7.38CA3450
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IiYEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht
aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P
BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT
TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA
AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np
b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAnAAAAUkU6ICh1
c3ItdGMpIFRvdGFsIENvbnRyb2wgSHViIFJlYm9vdHMAAg0BBYADAA4AAADNBwcACAAXAB8AEAAC
ACsBASCAAwAOAAAAzQcHAAgAFwAWACkAAgA7AQEJgAEAIQAAADZFRDE0NTcyQ0VGN0QwMTFCRkNB
MDBBMDI0RDFGODk2AEIHAQOQBgAkBwAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAA
AAAAAwAuAAAAAAADADYAAAAAAEAAOQAg1/LwIIy8AR4AcAABAAAAJwAAAFJFOiAodXNyLXRjKSBU
b3RhbCBDb250cm9sIEh1YiBSZWJvb3RzAAACAXEAAQAAABYAAAABvIwg8LtyRdFv984R0L/KAKAk
0fiWAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAADwAAAGNpbmR5b0BrdGMuY29tAAADAAYQ
wHSCaQMABxDuAwAAHgAIEAEAAABlAAAAVEhBTktTRk9SVEhFSU5GT1dFQVJFVVNJTkdUSEVUMUNB
UkRTQU5ERE9OT1RSVU5JU0ROT1JYMk9OVEhFU0VQQVJUSUNVTEFSTU9ERU1TSVdJTExIT1dFVkVS
Q0hFQ0tPTlRIRQAAAAACAQkQAQAAAP0DAAD5AwAA7AUAAExaRnVw/GJOdwAKAQMB9yACpAPjAgBj
gmgKwHNldDAgBxNNAoB9CoAIyCA7CW8yzDU1AoAKgXVjAFALA9BsaTM2AUBjAEELYEBuZzEwMzML
piByVA+AbmsEIAIQBcB0GGhlIAuAAhAuIFd3FgAKwBYAdQCQFEAV01Q4MSBjCxEEIABwZCAgZG8g
bm8FQHJ1QQOgSVNETiAFsVheMhlQA6AV4Q+wIAqxdDhpY3ULYAXABGJtcykWYEkgA/BsAyBobzh3
ZXYEkBewFfBja/cZtRxhBSAgD7EWFAqiCoQfCoAWhRjRAwAXIUlEU6sZQQOgYQexdA+wchwy/DE2
FmAVMQVAAiAWAA+A8QQgaXQnBCAcAAOgE4CFAkBsFgBxdWlyFXDlFmBPA6BvYxfAAJAZwc53FfAg
Mhqgc3QDcBxB8wQAFdByeRcTGHAFoB9w+wWQIYIgBuAV4BxhAHAhsHhscywb4BYAG6MCIGz4eSBn
HaEDkQeQAZETgP5zFfAYQCY1JCIqUx0iJ1OfITIWACbxHEMnUyBqJOFpHYBheQQgIinWFEAi7xgT
IbAcMgDAaweRHQMp5/srZShidy0AG5AhwhwwJtAfCeEWoAJgFgAmAWZpePcV0SVhJWFiKIAJcA+x
LbLfFdMbBCewCXAEYHYXFgEA3wGQAxEyMCLxFaJiG7EXEh8YIjMhAZAacRchcmFk9mkW8BZgRgkR
GOAhcCeAzyiAMnMoUw+AcHAJ8CJR7yPlB0AocBZgSDEgFxYgeP8JcAbgGKEcIjmBCGEbkAhgfmwY
QDFgIEEJcAdAGIBp2GdodADACXAuPwAeKosVPwIQLB4qLS1DC4DcZHkeKhPRAUBwA2A4sP8mgB4k
QhMnsDDjGEAV4izw7weAGkADYDHBbRuRJwEhokxvZhlQPUFUQxvgdf5iG1IFQDCgJXIA0CmhJQDT
HiQgUGZhGrB0KIAPYL4zHTQc1SGwIJZDcGkXs/8WYxwQFsEKQBygKIALgBXR/yFzKHAeJEaPBCBE
5CVhHUL/HZIYIjqhRuMrxEq7HiQXxP8xExXiD2AZoB1CK2RJtxuj/xfAFvAfMTMyFqABgDwjHZL7
RsAeJHk9Mkq/GEAVohkT/ynYG1EWgTfAHOQG4DJQMjB/IbEVoU2VHDIZoARgAjBovwQgRjUocRmR
AHAHQG8XMP9ZSyOgSGAw0gDQSGAFMCmh/QQAZCpiHiRahiIgHYA3Qn9IchXxPSIocTxUFxEWYFV8
U1IV0AWQJxECIDIwctcHgEUDKIBrGJB3SMUG4H51BUAyc0W3HVBjoVXwZv8mcTk1SbcPsRtQPwdC
EwYA6m1GQndDgjpCax4zEHECAGuwAAAAAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMMAqnb0f
jLwBQAAIMMAqnb0fjLwBCwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAA
AADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAC3DQAAHgAl
gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4wAAMAJoAIIAYAAAAAAMAAAAAAAABG
AAAAAAGFAAAAAAAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCACCAGAAAAAADA
AAAAAAAARgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBBgAgg
BgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AQoAIIAYAAAAAAMAAAAAAAABGAAAA
ADeFAAABAAAAAQAAAAAAAAAeAEOACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAA
HgA9AAEAAAAFAAAAUkU6IAAAAAADAA00/TcAAOe3
------ =_NextPart_000_01BC8BF7.38CA3450--
Subject:RE: (usr-tc) Total Control Hub Reboots From: David Bolen <db3l@ans.net> Date: 1997-07-09 00:51:21
Cindy Smith <cindyo@ktc.com> writes:
> [Cindy Smith] The Entire modem hub is resetting. If I telnet in and =
> "show uptime" it indicates the system has only been operational for a =
> few hours. (...)
> This tells me =
> the entire system is resetting.
Ok.. this is just the NETServer though (what you telnet'd in to) as
opposed to the entire total control chassis - e.g., the other cards in
the hub (which operate independently).
> Although we are using the 3.3.28 code, perhaps a user or users is =
> sending a continous stream of autheitication request that might be =
> overloading the system. Would this be possible? It has been observed =
> that in the radius error log, there was a contiuous stream of garbage =
> logins that lasted around 10 minutes.
Perhaps, but I have a hard time believing that a dialup user or users
can generate requests fast enough to overload a log like you describe,
since they are limited realistically both in terms of the rate they
can generate requests as well as the fact that after only about 3
refusals they will be disconnected.
I can't recall offhand if there were any other issues with 3.3 that
resulted in cycling RADIUS requests.
I'd definitely suggest seeing if you can do something with the log,
even if you have to copy it to some other machine to work with it.
Depending on which platform you are running the server on you can
probably find a utility that can view the file without having to load
it into memory, or show you the tail end of it (something like a
'less' or 'more' utility or 'tail' under Unix).
> A spot check of the memory revealed this info
> ****************
> System memory 4295023 bytes - 4224752 used, 70271 available
> Free blocks (block_size:count): 32:591 48:0 80:21 128:6 160:0 176:7 =
> 192:10 224:2
> 9 1168:0 2048:12 4176:0 20384:0
> Real Available Memory: 125855
> System nbufs 8000 - 70 used, 7930 available=20
>
> ****************
> This does not look like it leaves a lot of memory available. I will =
> monitor the memory during busy times and see if I can determine how low =
> it is going. Thanks for the tip...
This is definitely getting low, albeit it's partially just
fragmentation as opposed to actual loss (the Real available memory is
an aggregate of all free pools, whereas the 70K on the system memory
line is the pool that has never been allocated). However, having only
125K real available memory does seem like you're actually losing some
too.
This looks like an 8MB NETServer - you should typically start with
several hundred K available, so it does appear as if some is being
lost. The next time you reboot you might want to grab this early on
so you can get an idea of your starting point from which you can
compare later figures.
Ever since running into the problem with 3.2, we monitor our
NETServers and generate alerts when any one drops below 50K, and
schedule it for a reboot. It's kind of an arbitrary value, but a
scheduled reboot is easier than an unscheduled one :-)
It didn't help with the telnet RADIUS mess-up since that memory leak
was fast and could drop a hundred K in a few seconds, but it helps
with any gradual stuff. I've seen even 3.3 (at least the 4MB version)
slowly lose memory such that a heavy use PPP node needs a kick every
month or so.
Also, if you think that it might be a memory issue leading to the
reboot, check your syslog for the NETServer... for some period of time
leading up to the reboot you'll probably be getting "alloc" errors in
your syslog as the NETServer fails to allocate memory for various
operations. It can actually survive in that mode for a while before
dying.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Well, we finally got our Total Control rack running. Grr...
I disconnected my connection at home from our AS5200s to the Total Control.
Everything was working fine until I was doing some e-mail with Eudora Pro.
Retreiving E-mail was fine, but sending E-mail always hung at the end
of sending a message. It's like the acknowledgement from the SMTP server
wasn't getting back to Eudora.
I dropped the connection and redialed in our AS5200s and was able
to deliver E-mail without any trouble.
I'm using a Cisco 766 ISDN router at home.
The Total Control is running with dual-PRIs and the Net Server is
running:
U.S. Robotics
Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.4.23
Build date: Mar 6 1997
Build time: 10:12:26
Network Interface Card: Ethernet & Frame Relay Combination (26)
ISDN Interface Card : MUNICH32 (4)
Packet Bus Circuit : Standard
Licensed for 60 ports.
Any ideas?
Gregory Gulik Email: greg@wwa.com
WorldWide Access Info: info@wwa.com
Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
Subject:(usr-tc) ZModem hangup problems in 3.5.34 From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-09 03:38:23
I'm still having ZModem hangup problems with the latest version of the
code. For some reason, "sz" is sending a signal that the Netserver is
interpreting as "disconnect the session" after "sz" completes. Even just a
simple "sz -T" for a character test will give this result.
I am running Solaris 2.5.1 with a custom version of rlogind (but not THAT
custom) on port 813.
Here is some syslog output which displays the problem in action:
From 3.5.34:
Jul 9 03:15:46 slc3-tc.xmission.com MODEM: S44: CALL_REF >0x000001bd< PRI_SLOT >0< TS >23< SPAN >0< B_CH >3<
Jul 9 03:15:46 slc3-tc.xmission.com acct 000001bd dial: S44 call arrived.
Jul 9 03:15:46 slc3-tc.xmission.com sent out answer incoming call for S44.
Jul 9 03:16:00 slc3-tc.xmission.com acct 000001bd dial: S44 answered the phone using handle 48.
Jul 9 03:16:08 slc3-tc.xmission.com NetS: port S44 Login succeeded for pashdown@shell
Jul 9 03:16:08 slc3-tc.xmission.com S44 TCP port 1014 to 198.60.22.2 port 813 connection established
Jul 9 03:16:28 slc3-tc.xmission.com S44 to 198.60.22.2 port 813 terminated(4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 9 03:16:28 slc3-tc.xmission.com NetS: port S44 session disconnected user pashdown@shell
Jul 9 03:16:29 slc3-tc.xmission.com acct 000001bd dial: S44 hung up the phone. Call duration 0:0:43.
From 3.3.28:
Jul 9 03:19:40 slc1-tc.xmission.com MODEM: S39: CALL_REF >0x0000c81f< PRI_SLOT >0< TS >24< SPAN >0< B_CH >15<
Jul 9 03:19:40 slc1-tc.xmission.com acct 0000c81f dial: S39 call arrived.
Jul 9 03:19:40 slc1-tc.xmission.com sent out answer incoming call for S39.
Jul 9 03:19:54 slc1-tc.xmission.com acct 0000c81f dial: S39 answered the phone using handle 39.
Jul 9 03:20:03 slc1-tc.xmission.com NetS: port S39 Login succeeded for pashdown@shell
Jul 9 03:20:03 slc1-tc.xmission.com S39 TCP port 737 to 198.60.22.2 port 813 connection established
Both sessions were me running the "sz -T" command, but as you can see,
3.3.28 did not hang up. Note the "terminated" line from 3.5.34, what does
the (4) mean?
Is there any command in the Netserver that I can set to get around this? I
have downgraded to 3.3.28 (again) because of this problem.
--
Pete
XMission
Subject:Re: (usr-tc) ZModem hangup problems in 3.5.34 From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-09 03:49:10
David Bolen said once upon a time:
>Pete Ashdown <pashdown@xmission.com> writes:
>
>> Both sessions were me running the "sz -T" command, but as you can see,
>> 3.3.28 did not hang up. Note the "terminated" line from 3.5.34, what does
>> the (4) mean?
>
>I don't know why your use of 'sz' is specifically causing it but the
>termination cause of (4) indicates that the NETServer was in the
>process of doing a read from the TCP connection when it determined
>that the connection was closed. Another typical case would be a (5)
>which is during a write.
So this is looking more like a bug than a feature, since the problem didn't
happen on 3.3.28?
Subject:Re: (usr-tc) ZModem hangup problems in 3.5.34 From: David Bolen <db3l@ans.net> Date: 1997-07-09 05:44:11
Pete Ashdown <pashdown@xmission.com> writes:
> Both sessions were me running the "sz -T" command, but as you can see,
> 3.3.28 did not hang up. Note the "terminated" line from 3.5.34, what does
> the (4) mean?
I don't know why your use of 'sz' is specifically causing it but the
termination cause of (4) indicates that the NETServer was in the
process of doing a read from the TCP connection when it determined
that the connection was closed. Another typical case would be a (5)
which is during a write.
Unfortunately, I'm not sure that the cause codes are distinctive
enough to have much of a specific relationship with which end of the
connection decided to close the socket, as I've seen both in cases
where both the NETServer shut down a session (due to modem hangup) as
well as the host terminating a session.
-- David
Subject:Re: (usr-tc) ZModem hangup problems in 3.5.34 From: David Bolen <db3l@ans.net> Date: 1997-07-09 06:03:55
Pete Ashdown <pashdown@xmission.com> writes:
> So this is looking more like a bug than a feature, since the problem didn't
> happen on 3.3.28?
I guess, although as far as I know very little has been done with the
pure TCP code on the NETServer for a while so it's hard to see where
the disconnect is coming from. The termination causes (e.g., 4/5)
have been in the NETServer since mid-late '95 (3.0.x or perhaps
earlier) and haven't really changed.
It might be interesting if you could get a tcpdump from the host
machine for the two cases (3.3.28 versus 3.5.34) and see if there is
any noticeable difference in packet sizes, contents or whatever. At
the very least it might also give an idea as to just which side of the
connection is tearing it down by the TCP header information.
-- David
On Tue, 8 Jul 1997, Tatai SV Krishnan wrote:
>
> On Mon, 7 Jul 1997, Laszlo Vecsey wrote:
>
> > On Mon, 7 Jul 1997, Tatai SV Krishnan wrote:
> >
> > > For attribute 9023 which is NETServer specific you have to add this to
> > > the dictionary file in your radius and make sure that your radius server
> > > supports vendor specific attributes
> > >
> > > krish
> > >
> >
> > Is the latest dictionary file with all the ATTRIB_NMC and other USRobotic
> > specific entries available on the net somewhere? If someone would be so
> > kind to post it again to the list (latest version) I would appreciate it.
> >
> > - lv
> >
> >
> For which radius you are looking for? The USR radius next version will
> include these attributes. I am working on the dictionary file for other
> Radius servers - will send it as soon as I finish that. Also please note
> that the Radius servers should support Vendor specific attributes in
> order to see this value.
>
> krish
>
Is there a version for UNIX besides the USR version of radius that
supports Vendor Specific Attributes?
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
u>At 07:50 AM 7/8/97 -0500, you wrote:
u>>-> > What most of them have told me is that they hear my modem
u>pick up but >
u>>-> their modem never attempts to connect it just stays there playing
u>>-> my > modem's carrier on its speaker.
u>>-> >
u>>-> > I had another customer just last night call me saying that he
u>>-> would > connect and then be dropped of within 10 seconds. We
u>>-> tried this about 6 > times on different modems on the rack and it
u>>-> kept happening. When he we still have similiar Modem Problems
u>>-> with our Quad Modem Cards (which do you have?) Can you send us a
u>>-> Modem Status Report so that I can compare it with ours? ("show s5"
u>for example) >
u>>We had the same problem until we went through and initialized each
u>modem with a
u>>typical init string. Also you may want to check the Signal Converter
u>>Settings-> Link Rate Speed Select option (it's the same as a &N in an
u>init >string). It defaults to 300 baud and should be set to variable.
u>Hope this >helps.
u>>
u>> Jeff Binkley
u>> ASA Network Computing
u>>
u>>
u>>
u>Jeff:
u>What do you use for a typical init string for these USR quad modems
u>(x2)?
u>TTFN
Here's is what I'd use:
&B1 &H1 &R2 &N0 &C1 &D2 .
I also set the DTE interface speed fixed to 115.2kbs
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
Subject:Re: (usr-tc) Total Control Hub Reboots From: Brian Elfert <brian@citilink.com> Date: 1997-07-09 09:11:35
On Tue, 8 Jul 1997, Rick wrote:
> Cindy, we had the same problem with one of our TC hubs. It was traced to
> a faulty fc3 chip on the netserver pri card. We were lucky in that only
> one of our TC hubs had this chipset and all our other netserver pri
> cards have the fc2 chip. The fc3 chip will cause reset after reset of
> your netserver pri card for ISDN connections. We ran the box fine for
> over 2 months with only X2 analog connections. Once we accepted isdn on
> the box it started the hourly rebooting. USR tech confirmed they know
> about this problem which affects only fc3 chip sets....
Did USR offer to replace the Netserver PRI card with a working one?
Brian
At 06:25 AM 7/9/97 -0500, Brian wrote:
>Is there a version for UNIX besides the USR version of radius that
>supports Vendor Specific Attributes?
The Merit server supports Vendor Specific Attributes. The USR version
is most likely based off of it.
Go to http://www.merit/edu/radius/ for more info.
Gregory Gulik Email: greg@wwa.com
WorldWide Access Info: info@wwa.com
Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
Subject:Re: (usr-tc) Total Control Hub Reboots From: Rick <rallan@monmouth.com> Date: 1997-07-09 12:11:10
Joachim Nerz wrote:
>
> On Wed, 9 Jul 1997, Brian Elfert wrote:
>
> Where can I see if I got a fc2 or fc3 Chipset ?
>
> TIA
> Joachim Nerz
You have to pull the netserver PRI card out and you will see a square
chip about 2-5cm . It will state on the chip if it is fc2 or fc3......If
you have an un-jumpered fc3 (they have fixed some fc3's by jumping them)
you may need it replaced.
--
Rick
Subject:Re: (usr-tc) Total Control Hub Reboots From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de> Date: 1997-07-09 14:21:16
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
------ =_NextPart_000_01BC8BEA.F6F9B7A0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
On Tue, 8 Jul 1997, Cindy Smith wrote:
Hi Cindy,
> We are currently running 3 total control hubs. For some reason, they seem to be rebooting for no apparant reason. What could be a possible cause for this?
we hat the same problem until monday. We had reboots every 5 oder 10
hours. With more than 6 users online, our USR rebooted every hour. Now we
fixed it: we had only 4 MB of RAM, and every firmware release > 5.3 (i
think so) need 6 MB. Since we plugged in our 16 MB NON EDO SIMM, it works
fine...
Nevertheless, we still have the problem that our modem-connects are <
30min., the problem can be reproduced by USR and they'll try to fix it
the next days.
Bye,
Lars
+-----------------------------------------------------------------+
| Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de |
| FOnLine Buergernetzverein: http://www.forchheim.baynet.de |
| http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html |
+-----------------------------------------------------------------+
------ =_NextPart_000_01BC8BEA.F6F9B7A0--
Subject:Re: (usr-tc) Total Control Hub Reboots From: Joachim Nerz <nerz@ipx2.rz.uni-mannheim.de> Date: 1997-07-09 14:37:23
On Wed, 9 Jul 1997, Lars Freund wrote:
> On Tue, 8 Jul 1997, Cindy Smith wrote:
>
> Hi Cindy,
>
> > We are currently running 3 total control hubs. For some reason, they seem to be rebooting for no apparant reason. What could be a possible cause for this?
>
> we hat the same problem until monday. We had reboots every 5 oder 10
> hours. With more than 6 users online, our USR rebooted every hour. Now we
> fixed it: we had only 4 MB of RAM, and every firmware release > 5.3 (i
> think so) need 6 MB. Since we plugged in our 16 MB NON EDO SIMM, it works
> fine...
I have the same Problem, but the 16 MB did not help :-(
System memory 17301504 bytes - 6372080 used, 10929424 available
Should be enough, I think...
An Upgrade From 3.5.31 to 3.5.34 did`t help too.
Any sugestions ?
TIA
Joachim Nerz
Subject:Re: (usr-tc) Total Control Hub Reboots From: Joachim Nerz <nerz@ipx2.rz.uni-mannheim.de> Date: 1997-07-09 16:32:15
On Wed, 9 Jul 1997, Brian Elfert wrote:
>
>
> On Tue, 8 Jul 1997, Rick wrote:
>
> > Cindy, we had the same problem with one of our TC hubs. It was traced to
> > a faulty fc3 chip on the netserver pri card. We were lucky in that only
> > one of our TC hubs had this chipset and all our other netserver pri
> > cards have the fc2 chip. The fc3 chip will cause reset after reset of
> > your netserver pri card for ISDN connections. We ran the box fine for
> > over 2 months with only X2 analog connections. Once we accepted isdn on
> > the box it started the hourly rebooting. USR tech confirmed they know
> > about this problem which affects only fc3 chip sets....
>
> Did USR offer to replace the Netserver PRI card with a working one?
Yes, I just a new One.
Where can I see if I got a fc2 or fc3 Chipset ?
TIA
Joachim Nerz
I assume there are USR Vendor Specific RADIUS attributes.
If so, where are they documented?
We're running the Merit RADIUS server.
Gregory Gulik Email: greg@wwa.com
WorldWide Access Info: info@wwa.com
Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
> > On Mon, 7 Jul 1997, Tatai SV Krishnan wrote:
> >
> For which radius you are looking for? The USR radius next version will
> include these attributes. I am working on the dictionary file for other
> Radius servers - will send it as soon as I finish that. Also please note
> that the Radius servers should support Vendor specific attributes in
> order to see this value.
>
> krish
I'm using Merit Radius 2.4.23c, from ftp.merit.edu/radius/releases
The dictionary file is currently the last one that was posted to this
mailing list.. perhaps I need a different one? There are eight blank
"Vendor-Specific =" lines that are logged with each start/stop entry.
- lv
Subject:(usr-tc) Netserver ippool From: Charles Hill <chill@ionet.net> Date: 1997-07-10 10:07:14
I have noticed a new feature in Netserver 3.5.34. If I enter the command
"show ippool" it reveals a table. I want to implement the use of separate
ip pools based on DNIS. If this feature is fully implemented, how do I
make this work? Does it require the use of 3Com RADIUS?
Regards,
Charles Hill
At 04:41 AM 7/10/97 -0400, Laszlo Vecsey wrote:
>I'm using Merit Radius 2.4.23c, from ftp.merit.edu/radius/releases
>
>The dictionary file is currently the last one that was posted to this
>mailing list.. perhaps I need a different one? There are eight blank
>"Vendor-Specific =" lines that are logged with each start/stop entry.
I have the same problem.
How does one fix that?
Gregory Gulik Email: greg@wwa.com
WorldWide Access Info: info@wwa.com
Voice: +1 312 803 WWA1 Fax: +1 312 803 WWAF Support: support@wwa.com
Subject:RE: (usr-tc) Total Control Hub Reboots From: Cindy Smith <cindyo@ktc.com> Date: 1997-07-10 14:01:43
------ =_NextPart_000_01BC8D3B.7F117A50
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Did USR offer to replace the Netserver PRI card with a working one?
Brian
[Cindy Smith] =20
Thanks for all the help with the reboot problem. I have contacted USR =
and they are going to send me some new PRI cards. They are going to =
replace them. I think we also might have some type of service contract =
with them. That might make a difference.
Thanks again,
--Cindy Smith=20
------ =_NextPart_000_01BC8D3B.7F117A50
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IjUTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht
aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P
BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT
TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA
AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np
b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAnAAAAUkU6ICh1
c3ItdGMpIFRvdGFsIENvbnRyb2wgSHViIFJlYm9vdHMAAg0BBYADAA4AAADNBwcACgAOAAEAKwAE
ACMBASCAAwAOAAAAzQcHAAoADQA6ACwABABcAQEJgAEAIQAAAERDODBFRDA4MjZGOUQwMTFCRkNB
MDBBMDI0RDFGODk2AEIHAQOQBgDkBAAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAA
AAAAAwAuAAAAAAADADYAAAAAAEAAOQDAAga1Y428AR4AcAABAAAAJwAAAFJFOiAodXNyLXRjKSBU
b3RhbCBDb250cm9sIEh1YiBSZWJvb3RzAAACAXEAAQAAABYAAAABvI1jtNAI7YDd+SYR0L/KAKAk
0fiWAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAADwAAAGNpbmR5b0BrdGMuY29tAAADAAYQ
TMiDjwMABxAjAQAAHgAIEAEAAABlAAAARElEVVNST0ZGRVJUT1JFUExBQ0VUSEVORVRTRVJWRVJQ
UklDQVJEV0lUSEFXT1JLSU5HT05FP0JSSUFOQ0lORFlTTUlUSFRIQU5LU0ZPUkFMTFRIRUhFTFBX
SVRIVEhFUkVCTwAAAAACAQkQAQAAAMABAAC8AQAAgwIAAExaRnUCCzhAdwAKAQMB9yACpAPjAgBj
gmgKwHNldDAgBxNNAoB9CoAIyCA7CW8yzDU1AoAKgXVjAFALAzBsaTM2AUALYG5nsDEwMzMKoANg
dAWQDnQLpwqxCoBEaWQgYFVTUiBvASAEkCCYdG8gCXALUWNlFpCWaBcwB8B0D7BydhZxoFBSSSBj
CxEgA/BZF1AgYRiwBbBrC4BnsRYwbmU/FWQVZEIHIX8LkBoJCNAAQQwyFHUP4FuiQwuAZHkgBgBt
GNHqXQMwYgFAaQ/gCuMKgPJUD4BuawQgAhAFwAdA5wMgF1IXYGxwGLQXUglwGwbgFJAgFHECYGVt
Lv4gGFAPgBfwGGACIQDQFKB/FeQAcBXgF1EdMArAFzBn/m8ZchahD7AjIQeAJGADcO8XMBnAB+AY
NnMhoB6wI37vFtkhkxdQC4BrGLAXMAdA4yTwJLBpZ2gFQCHjJPN4dHlwFzAWQCRhF+Bp+xchIjJy
InEgJyGQG8EVUf8UhB1AHjEb0hxXHrEFQCk0ySSwYWsowSBkBpAWYZ8J8BcgLFAaCR61YWcLcfIs
GfotLRz0HWMsbBn6BRBxADUgAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMMBQCkpjjbwBQAAI
MMBQCkpjjbwBCwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAA
AAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAC3DQAAHgAlgAggBgAA
AAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4wAAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAAAGF
AAAAAAAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCACCAGAAAAAADAAAAAAAAA
RgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBBgAggBgAAAAAA
wAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AQoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAAB
AAAAAQAAAAAAAAAeAEOACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEA
AAAFAAAAUkU6IAAAAAADAA00/TcAAE/+
------ =_NextPart_000_01BC8D3B.7F117A50--
Subject:(usr-tc) Stats? From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-10 14:38:23
What are people using for stats? I'd like a simple stats program that
would generate the following information:
daily/weekly/monthly tabulation of:
min/max/average of:
time online | connect rates of:
DS0 channels
modems
accounts
isdn usage
analog usage
overall utilization:
per PRI/DSS
per chassis
per chassis group
It would really make me weep if I could get this information into HTML. I
really hate the way TCM works stats wise.
Subject:(usr-tc) RADIUS packet storms from NETServer? From: David Carmean <dlc@avtel.net> Date: 1997-07-10 17:15:59
Has anyone else had problems with RADIUS packet storms from a
NETServer running 3.2.5 or earlier? If I telnet to one of my
NERServers, and enter either a username with a space, or the
string "!rot", after entering a password the box starts sending
RADIUS queries approximately every five milliseconds, or 200
per second.
Needless to say, this makes the RADIUS server completely
useless; I have to kill the server, reboot the NETServer,
and restart RADIUS.
The USR support person I spoke with claims that he's heard of
this problem, but that it doesn't happen with USR's RADIUS
code. But IMO, if he'd seen a tcpdump of the behavior,
he'd realize that it has nothing to do with the server code.
He's sending me version 3.2.96 of the O/S. Are there any
gotchas with this version?
Thanks.
--
David Carmean <dlc@avtel.net>
Avtel Communications, Santa Barbara, CA +1-805-730-7740
Opinions herein are those of the author only, unless otherwise noted
"Are you now, or have you ever been?"
Subject:Re: (usr-tc) RADIUS packet storms from NETServer? From: David Carmean <dlc@avtel.net> Date: 1997-07-10 17:19:41
'Doh! That's 3.2.5.96, not 3.2.96.
--
David Carmean <dlc@avtel.net>
Avtel Communications, Santa Barbara, CA +1-805-730-7740
Opinions herein are those of the author only, unless otherwise noted
"Are you now, or have you ever been?"
Subject:Re: (usr-tc) RADIUS packet storms from NETServer? From: David Carmean <dlc@avtel.net> Date: 1997-07-10 17:33:25
On Thu, Jul 10, 1997 at 08:29:39PM -0500, David Bolen wrote:
> David Carmean <dlc@avtel.net> writes:
>
> > 'Doh! That's 3.2.5.96, not 3.2.96.
>
> Actually you were correct the first time - it'll be 3.2.96. Versions
> are only 3 octets, with engineering releases working from 99 down.
>
> There are some other typical arrangements (like the 4MB releases start
> at x.y.0 whereas the 8/16MB releases start at x.y.20) at least for
> stuff up through 3.3.x which supported both platforms.
>
> -- David
I was not aware that there was a 3.3, but if so, I wonder why
they're not just sending me the latest working non-4.0 code
for the NETServer/16?
--
David Carmean <dlc@avtel.net>
Avtel Communications, Santa Barbara, CA +1-805-730-7740
Opinions herein are those of the author only, unless otherwise noted
"Are you now, or have you ever been?"
Subject:Re: (usr-tc) RADIUS packet storms from NETServer? From: David Bolen <db3l@ans.net> Date: 1997-07-10 20:27:53
David Carmean <dlc@avtel.net> writes:
> Has anyone else had problems with RADIUS packet storms from a
> NETServer running 3.2.5 or earlier? If I telnet to one of my
> NERServers, and enter either a username with a space, or the
> string "!rot", after entering a password the box starts sending
> RADIUS queries approximately every five milliseconds, or 200
> per second.
Yes, this is a known bug (see a previous message from me to this list
regarding memory). It was actually introduced somewhere in the 3.2
cycle, so it's not something I've run into with earlier releases.
You're also loosing big chunks of memory when this is happening, so
just having it in this state for a short time (it will stop when you
terminate the TCP connection) can exhaust a NETServer, particularly a
4MB one.
This is fixed in the NETServer 3.3.x code or later.
> The USR support person I spoke with claims that he's heard of
> this problem, but that it doesn't happen with USR's RADIUS
> code. But IMO, if he'd seen a tcpdump of the behavior,
> he'd realize that it has nothing to do with the server code.
Yes, it has nothing to do with the server code.
> He's sending me version 3.2.96 of the O/S. Are there any
> gotchas with this version?
It's hard to tell with the engineering numbers - this isn't one that
I'm familiar with.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) RADIUS packet storms from NETServer? From: David Bolen <db3l@ans.net> Date: 1997-07-10 20:29:39
David Carmean <dlc@avtel.net> writes:
> 'Doh! That's 3.2.5.96, not 3.2.96.
Actually you were correct the first time - it'll be 3.2.96. Versions
are only 3 octets, with engineering releases working from 99 down.
There are some other typical arrangements (like the 4MB releases start
at x.y.0 whereas the 8/16MB releases start at x.y.20) at least for
stuff up through 3.3.x which supported both platforms.
-- David
Subject:Re: (usr-tc) RADIUS packet storms from NETServer? From: David Bolen <db3l@ans.net> Date: 1997-07-10 20:40:53
David Carmean <dlc@avtel.net> writes:
> I was not aware that there was a 3.3, but if so, I wonder why
> they're not just sending me the latest working non-4.0 code
> for the NETServer/16?
Oh sorry - you didn't mention in your first note that this was for a
NETServer/16, and I had just (incorrectly) assumed you were working
with a total control hub.
While there is some relationship, I'm not sure how closely the hub and
/16 code development parallels, so it may be that there isn't anything
in between 3.2.x and 4.x for the /16. I don't have a lot of
experience with the /16s.
Then again, USR may just be suggesting that they provide you with an
engineering release that is as close as possible to the release you
are currently running, while fixing the problem you have. That's
normally the purpose behind any of the engineering releases, and as a
matter of not making too many changes to solve your problem, isn't
really a bad idea. You could always check if a later pre-4.0 release
does exist though.
-- David
Subject:Re: (usr-tc) RADIUS packet storms from NETServer? From: Brian Elfert <brian@citilink.com> Date: 1997-07-10 21:46:58
On Thu, 10 Jul 1997, David Carmean wrote:
> On Thu, Jul 10, 1997 at 08:29:39PM -0500, David Bolen wrote:
>
> > David Carmean <dlc@avtel.net> writes:
> >
> > > 'Doh! That's 3.2.5.96, not 3.2.96.
> >
> > Actually you were correct the first time - it'll be 3.2.96. Versions
> > are only 3 octets, with engineering releases working from 99 down.
> >
> > There are some other typical arrangements (like the 4MB releases start
> > at x.y.0 whereas the 8/16MB releases start at x.y.20) at least for
> > stuff up through 3.3.x which supported both platforms.
> >
> > -- David
>
>
> I was not aware that there was a 3.3, but if so, I wonder why
> they're not just sending me the latest working non-4.0 code
> for the NETServer/16?
There are two different Netservers from USR. One is the Netserver/8 or
/16 that has modems and a terminal server in a sealed box. The other is
the Netserver card that acts as a terminal server for the Total Control
chassis.
I think it's generally assumed that you are talking about the Netserver
card for the Total Control chassis unless you mention otherwise.
The Netserver card OS is now at 3.5.34. 3.2.5 for the Netserver card
would be quite old. 3.2.5 for the Netserver/8 /16 would be fairly new.
Brian
On Tue, 8 Jul 1997, Adam Wills (Global 2000) wrote:
> I whent through what you recomended, but to no avail :( I think its a
> simple error in my snmp's compatibility, but i'm unsure. I loaded the mib
> file from the USR Mdm.mib file, but now get (when just typing snmpget or
> snmpwalk, with or without any paramaters):
>
> Should be ACCESS((): On or around line 150
> Bad parse of objecttype: On or around line 150
> Mib table is bad. Exiting
>
> I tried adding your header, as well as the standard header used in the
> main mib.txt file provided for the linux source distribution, but it
> always did the same thing.. Line 150 looks like:
>
> 142 ACCESS read-only
> 143 STATUS mandatory
> 144 DESCRIPTION
> 145 "This object identifies the country or countries that this
> 146 modem is designed for use in."
> 147 ::= { mdmIDEntry 3 }
> 148
> 149 mdmIDHardwareSerNum OBJECT-TYPE
> 150 SYNTAX DisplayString (SIZE(0..16))
> 151 ACCESS read-only
> 152 STATUS mandatory
> 153 DESCRIPTION
> 154 "The modem's hardware serial number as stored in EEPROM."
> 155 ::= { mdmIDEntry 4 }
> 156
> 157 mdmIDHardwareRev OBJECT-TYPE
> 158 SYNTAX DisplayString (SIZE(0..11))
> 159 ACCESS read-only
> 160 STATUS mandatory
>
> Ther USR mdm.mib info: MIB File Generated on 11-Feb-1997 at 10:55:55
>
> I run cmu-snmp-linux-3.3 that I compiled cleanly myself.
>
> Out of curiousity, which flavor of unix did you use?
>
> Adam Wills Global 2000 Communications
> Director of Networking Systems 1840 Western Ave.
> sysadmin@global2000.net Albany, NY, 12203
> http://www.global2000.net (518) 452-1465
Could someone post (or email me directly) a working cmu-compatible mib.txt
file? I am getting the exact same errors no matter what I try.
Thanks.
Jim MacKenzie
tomservo@erie.net
System Administrator
ErieNet, Inc.
Subject:Re: (usr-tc) Stats? From: David Bolen <db3l@ans.net> Date: 1997-07-11 17:03:01
Pete Ashdown <pashdown@xmission.com> writes:
> What are people using for stats?
For ourselves, we use internally developed tools for statistics
gathering and reporting - nothing out there really deals well with the
scale of our environment.
For what it's worth I can describe how we go about handling our
collection and analysis as an overview of data flow and possibly to
give some suggestions for a setup, but if what you're really looking
for is a pointer to available code or something, feel free to skip by
the rest of this message :-)
We operate with a local Unix workstation as a management point for
each "rack" of gear we deploy. In our case a rack typically contains
4 USR hubs for processing user sessions, so about 192-224 (T1/E1)
modems per manager (at least with existing density stuff).
Among other things, the manager runs a statistics gathering daemon
whose primary goal in life is to create call records, and to compute
certain other aggregate data points about the callers in its local
rack. As input to the daemon, we enable all possible traps on each
USR hub, and also process all syslog messages from any NETServers.
There are some other input sources such as our authentication daemon
and such that also feed information to the statistics daemon.
The daemon uses those traps/syslogs to trigger other queries to the
modems involved in order to query the statistics table from the modem
via NMC (the mdmCs table). Some objects from the table are queried at
the beginning of the call (such as modulation type), some at the end
(such as characters transmitted) and some at both points (such as link
rates). Once a call has completed on a particular channel, a call
record for that call gets written to a local database.
The statistics daemon also manages local aggregates for its rack, such
as tracking total port usage in real time, and in 15-minute intervals,
breakdown by user/customer, and by target/assigned address. Access to
the statistics daemon is by SNMP, so we can run real-time queries
across the backbone for summarization or to just check a particular
site if necessary.
The call record contains everything we can think of pertaining to that
call such as:
* Identification information (entity in system, type of call)
* User information (realm/id, authentication info, etc..)
* Event timestamps (arrival, train, TCP setup, teardown, hangup, etc..)
and duration information.
* Modem statistics (mdmCs MIB table) when appropriate.
The local manager holds onto about a month of call records for its
local rack. So if we have a failure on the central polling machine we
can always restore from the remote managers. It also allows us to do
trend analysis over time locally on the manager when troubleshooting
problems. Raw logs of all events (traps, syslogs, etc..) exist for a
week in order to allow post-mortems and troubleshooting based on the
actual information received from the USR gear.
The call records are retrieved continuously by a central statistics
machine and injected into a commercial database. Due to polling cycle
times and the amount of data involved, data on the central machine
tends to be about 15 minutes delayed, but still usable for semi-real
time analysis.
We have a variety of reporting tools and engineering analysis tools..
Since we're a Unix shop a lot of stuff is done with scripts, as well
as custom binaries.
Most that has to do with the sort of stuff you are looking for (usage,
utilization, etc.) runs off of these call records. Several tools are
geared for real time use (triaging problems, checking usage) and can
run locally on the management machines off of the local database.
The bulk of our daily or higher order reports run from the central
database, and can view the system however they like for the purpose of
reporting.
> It would really make me weep if I could get this information into HTML. I
> really hate the way TCM works stats wise.
We've found ourselves much better served by directly interacting with
the NMC card and chassis directly with our own tools and utilities
(including for general management functions and not just statistics
gathering). That's not to say that TCM isn't useful in many ways, but
just that when you start trying to incorporate data and perform large
scale analysis of a system of more than a few hubs it just isn't
really built for it.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) Netserver Memory Specs From: Tom Bilan <tom@tdi.net> Date: 1997-07-12 18:34:01
I'm running old code (?) with just the 4MB SIMM in the Netserver
card. I am seriously thinking about upgrading to the 2.5.1 suite
and I know I need more memory.
Is it FP or EDO? Parity or Non-Parity?
Also, if anyone would like to put in their .02, what is the best
(safest) order to upgrade the chassis?
modem, t1 then netserver etc.?
and
What's the deal with USR's FTP site? I can loan them a 486 so
they can have totalservice2.usr.com so people can download. sheesh.
"FTP Error
Could not login to FTP server
We're sorry. The maximum number of FTP users have been reached.
Please try again later."
Thanks,
Tom Bilan
Subject:(usr-tc) USR Radius & SQL Server From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-13 11:10:00
Has anyone running USRobotics Total Control product and their RADIUS software
gotten it to run under SQL server ? If so, what process did you go through.
I've been attempting to do it by exporting the tables from Access but when I
got to the SYSTEM table it gave me an ODBC error stating that 30 characters was
the maximum field definition length and many of the field names here are more
than 30 characters.
Thanks,
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) ZModem hangup problem workaround From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-13 15:58:45
After opening a ticket with USR, #7053006, I essentially got nowhere with
their technicians. One tried to replicate the problem in their lab, but
couldn't. I suspect she wasn't using rlogin as a service, because the
problem isn't present on telnet.
So bugfixing was once again handed back to me. I decided to rummage
through the ZModem code to see if I could find the problem. This is rzsz
3.34 on Solaris 2.51, via rlogin from a Netserver running 3.5.34. In the
code, there is a routine named "mode" which sets different termio modes.
It seemed that whenever the code set the mode to 0, the Netserver would
thusly hangup. I tracked the problem further down to this line in rbsb.c:
(void) ioctl(Tty, TCFLSH, 1); /* Flush input queue */
I don't know if Forsberg made a mistake, but to flush the input queue,
ioctl requires an argument of "0". "1" flushes the output queue. So
instead of trying to second guess the author, I simply commented out this
line. Rzsz seems to work fine without it, yet it still disturbs me that
something like flushing a queue could cause a terminate(4) on the
Netserver. I'm presuming that if there is nothing in the queue, and the
Netserver gets a call to flush it, then that is where the error happens.
However, I was unable to duplicate the problem with code of my own.
Subject:(usr-tc) PRI Card error From: Brian <signal@shreve.net> Date: 1997-07-13 22:44:33
Do you know what this error means, on the PRI card:
ERR:ucc_gen_error,ucc_go_t_d_disc,pb_dg_send,error:-3
ERR:ucc_gen_error,ucc_setup_in_call,pb_dg_send,eroor:-3
Users call and complain it just rings and rings, I think it may be telco
related.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) archive From: Tim Tsai <tim@futuresouth.com> Date: 1997-07-14 01:26:37
Is there a searchable archive of this list anywhere?
Also, we're looking for MRTG extensions for TC Hub's. Any pointers?
Thanks,
Tim
On Sun, 13 Jul 1997, Brian wrote:
> Do you know what this error means, on the PRI card:
>
> ERR:ucc_gen_error,ucc_go_t_d_disc,pb_dg_send,error:-3
> ERR:ucc_gen_error,ucc_setup_in_call,pb_dg_send,eroor:-3
>
> Users call and complain it just rings and rings, I think it may be telco
> related.
This looks like a telco disconnect, ucc_go_telco_disc, What are the
error messages previous to this message?
krish
>
> Brian
>
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
Hi all.
Being new to this list, could anyone please let me know if there is an
archive of older posts?
I am considering the purchase of a NAS and the TC is high on my short
list.
Thanks.
> Colin McFadyen
> Carleton University CCS
> 409 Robertson Hall (520-2600 ext. 3721)
>
tom@tdi.net (Tom Bilan) writes:
> Also, if anyone would like to put in their .02, what is the best
> (safest) order to upgrade the chassis?
There's really no special order that you _must_ follow, although
there are a few suggestions I would have:
* Do the NMC first since if there are any code download fixes
implemented in the newer version you'll take advantage of them
with the other cards. This also gives you an NMC version that
will fully support any other card updates, in case you are going
to be sending settings or something following the updates.
One caution though - after doing the NMC, ensure that you wait
long enough for the NMC to rediscover the contents of the chassis
and make management connections to the components - trying to
start another download too quickly can sometimes overburden things
and cause transient errors.
* If you are doing both modem and NETServer, doing the NETServer
second will allow the NETServer to re-establish connections to the
modems "naturally" during its reboot. If you do the reverse,
you'll need to manually reset the NETServer ports after the modem
download to open up the packet bus connections.
For my own purposes, my download utility does the NMC first, and then
does any T1, modem and NETServer cards in that order.
Oh, and I've also taken to resetting all cards I'm going to be
downloading if they have been operational for a long time (say many
months) just to ensure a clean start for the downloads. I don't
really have an empirical evidence that this improves things but I used
to run into some strange behavior during downloads that this seems to
lessen.
-- David
Subject:Re: (usr-tc) ZModem hangup problem workaround From: David Bolen <db3l@ans.net> Date: 1997-07-14 15:49:07
Pete Ashdown <pashdown@xmission.com> writes:
> Rzsz seems to work fine without it, yet it still disturbs me that
> something like flushing a queue could cause a terminate(4) on the
> Netserver. I'm presuming that if there is nothing in the queue, and the
> Netserver gets a call to flush it, then that is where the error happens.
> However, I was unable to duplicate the problem with code of my own.
Well, it's not really like the local flush operation is passed on to
the NETServer. The ioctl() is for a local file handle and will ensure
that any pending data is processed, but from the perspective of the
other end on an output flush, it's just more data.
About the only thing I think that the system could do locally that
might make its way to the NETServer is to do something like set the
urgent bit to ensure that the data is processed on the receiving end,
or some such thing.
If you were able to catch a tcpdump of the final stages of a session,
it would be interesting to see what the TCP flags showed.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Archive? From: Lars Freund <lafreund@cip.e-technik.uni-erlangen.de> Date: 1997-07-14 15:50:57
On Mon, 14 Jul 1997, Colin_McFadyen wrote:
Hi,
> Being new to this list, could anyone please let me know if there is an
> archive of older posts?
Yes!
ftp://ftp.xmission.com/pub/lists/usr-tc/
Bye,
Lars
+-----------------------------------------------------------------+
| Lars Freund Email: lafreund@cip.e-technik.uni-erlangen.de |
| FOnLine Buergernetzverein: http://www.forchheim.baynet.de |
| http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html |
+-----------------------------------------------------------------+
Subject:(usr-tc) No Handshake From: Mark Wilson <mrw@netdirect.net> Date: 1997-07-14 17:58:37
I'm a first time poster, long time listener. :)
I've got a new TC rack installed. Just upgraded all cards to the latest
revs. x2 key installed. When I try calling the TC with an analog modem one
of the quad modems answers but doesn't complete the handshake. It starts to
handshake but just before it would get to the v.34 'bong, bong' it stops.
It doesn't hang up, just stops. I've tried this with many different modems
(v.34) and computers with the same results. The only difference is that a
Megahertz xj2288 did connect ONCE at 2400bps.
Any ideas?
Thanks,
mrw@netdirect.net
Lars Freund <lafreund@cip.e-technik.uni-erlangen.de> writes:
> By using this software, I already made an
> upgrade of the Netserver Pri Card by putting the RS232-cable in the
> Netserver-NIC. But how can I connect to my modem cards without having
> Modem-NICs or a Network Management Card?
In order to flash new code onto a quad modem card, you either have to
have an RS-232 NIC or an NMC card in the chassis. If you don't run
with them normally and don't have an NMC, you could technically just
plug a NIC in for the purposes of the download and then remove it.
If you want to use PCSDL, you have to have a serial connection to the
device, so with the modem you'll need the RS232-NIC. You also get to
do a single device at a time.
If you have the NMC, then you can use the TCM software (or any other
software written to access the NMC) to do the download, and you can do
it to all like cards simultaneously, although it takes some linear
ratio of the cards involved in terms of time.
> I think there should be a solution by setting a modem to direct telnet
> access, but then....?
As far as I know the modem will not respond to the flash download
commands when observed over a packet bus connection (which is the
reverse telnet from the NETServer), and I would expect that even if it
did, once the modem reverted to flash download mode it would stop
handling packet bus traffic so you wouldn't be able to actually send
the flash code.
Personally, I wouldn't recommend running a total control chassis
without an NMC card - it's not that much extra cost compared to the
rest of the chassis and it really does increase functionality.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) No Handshake From: David Bolen <db3l@ans.net> Date: 1997-07-14 19:04:50
Mark Wilson <mrw@netdirect.net> writes:
> Any ideas?
Hmm, one thing to try first would be to issue the command to all of
the modems to restore to factory hardware defaults and then save to
NVRAM. You can then restore any special settings you may run with.
Depending on the code you were updating from there may be some
registers with strange values (used in the new code but not the old)
or something that is interfering with training.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) Re: PRI Card error From: Brian <signal@shreve.net> Date: 1997-07-14 19:13:33
On Mon, 14 Jul 1997, Tatai SV Krishnan wrote:
>
> On Sun, 13 Jul 1997, Brian wrote:
>
> > Do you know what this error means, on the PRI card:
> >
> > ERR:ucc_gen_error,ucc_go_t_d_disc,pb_dg_send,error:-3
> > ERR:ucc_gen_error,ucc_setup_in_call,pb_dg_send,eroor:-3
> >
> > Users call and complain it just rings and rings, I think it may be telco
> > related.
>
> This looks like a telco disconnect, ucc_go_telco_disc, What are the
> error messages previous to this message?
>
> krish
>
those are the only errors I am seeing. are you saying this is caused from
telco?
Brian
>
>
>
> >
> > Brian
> >
> >
> >
> > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> >
> >
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Re: PRI Card error From: Brian <signal@shreve.net> Date: 1997-07-14 19:25:00
On Mon, 14 Jul 1997, Brian wrote:
> On Mon, 14 Jul 1997, Tatai SV Krishnan wrote:
>
> >
> > On Sun, 13 Jul 1997, Brian wrote:
> >
> > > Do you know what this error means, on the PRI card:
> > >
> > > ERR:ucc_gen_error,ucc_go_t_d_disc,pb_dg_send,error:-3
> > > ERR:ucc_gen_error,ucc_setup_in_call,pb_dg_send,eroor:-3
> > >
> > > Users call and complain it just rings and rings, I think it may be telco
> > > related.
> >
> > This looks like a telco disconnect, ucc_go_telco_disc, What are the
> > error messages previous to this message?
> >
> > krish
> >
>
here are the errors that happen upon reboot and previous to the above:
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccpbus_closed_cb: handle >0< being closed is invalid.
ERROR uccpbus_closed_cb: handle >1< being closed is invalid.
ERROR uccpbus_closed_cb: handle >2< being closed is invalid.
ERROR uccpbus_closed_cb: handle >3< being closed is invalid.
ERROR uccpbus_opened_cb: handle >49< already up OR not pending.
ERROR uccpbus_opened_cb: handle >50< already up OR not pending.
ERROR uccpbus_opened_cb: handle >51< already up OR not pending.
ERROR uccpbus_opened_cb: handle >52< already up OR not pending.
ERROR uccpbus_closed_cb: handle >4< being closed is invalid.
ERROR uccpbus_closed_cb: handle >5< being closed is invalid.
ERROR uccpbus_closed_cb: handle >6< being closed is invalid.
ERROR uccpbus_closed_cb: handle >7< being closed is invalid.
ERROR uccpbus_opened_cb: handle >53< already up OR not pending.
ERROR uccpbus_opened_cb: handle >54< already up OR not pending.
ERROR uccpbus_opened_cb: handle >55< already up OR not pending.
ERROR uccpbus_opened_cb: handle >56< already up OR not pending.
ERROR uccpbus_closed_cb: handle >8< being closed is invalid.
ERROR uccpbus_closed_cb: handle >9< being closed is invalid.
ERROR uccpbus_closed_cb: handle >10< being closed is invalid.
ERROR uccpbus_closed_cb: handle >11< being closed is invalid.
ERROR uccpbus_opened_cb: handle >57< already up OR not pending.
ERROR uccpbus_opened_cb: handle >58< already up OR not pending.
ERROR uccpbus_opened_cb: handle >59< already up OR not pending.
ERROR uccpbus_opened_cb: handle >60< already up OR not pending.
ERROR uccpbus_closed_cb: handle >12< being closed is invalid.
ERROR uccpbus_closed_cb: handle >13< being closed is invalid.
ERROR uccpbus_closed_cb: handle >14< being closed is invalid.
ERROR uccpbus_closed_cb: handle >15< being closed is invalid.
ERROR uccpbus_opened_cb: handle >61< already up OR not pending.
ERROR uccpbus_opened_cb: handle >62< already up OR not pending.
ERROR uccpbus_opened_cb: handle >63< already up OR not pending.
ERROR uccpbus_closed_cb: handle >16< being closed is invalid.
ERROR uccpbus_closed_cb: handle >17< being closed is invalid.
ERROR uccpbus_closed_cb: handle >18< being closed is invalid.
ERROR uccpbus_closed_cb: handle >19< being closed is invalid.
ERROR uccpbus_closed_cb: handle >20< being closed is invalid.
ERROR uccpbus_closed_cb: handle >21< being closed is invalid.
ERROR uccpbus_closed_cb: handle >22< being closed is invalid.
ERROR uccpbus_closed_cb: handle >23< being closed is invalid.
ERROR uccpbus_closed_cb: handle >24< being closed is invalid.
ERROR uccpbus_closed_cb: handle >25< being closed is invalid.
ERROR uccpbus_closed_cb: handle >26< being closed is invalid.
ERROR uccpbus_closed_cb: handle >27< being closed is invalid.
ERROR uccpbus_closed_cb: handle >28< being closed is invalid.
ERROR uccpbus_closed_cb: handle >29< being closed is invalid.
ERROR uccpbus_closed_cb: handle >30< being closed is invalid.
ERROR uccpbus_closed_cb: handle >31< being closed is invalid.
ERROR uccpbus_closed_cb: handle >32< being closed is invalid.
ERROR uccpbus_closed_cb: handle >33< being closed is invalid.
ERROR uccpbus_closed_cb: handle >34< being closed is invalid.
ERROR uccpbus_closed_cb: handle >35< being closed is invalid.
ERROR uccpbus_closed_cb: handle >36< being closed is invalid.
ERROR uccpbus_closed_cb: handle >37< being closed is invalid.
ERROR uccpbus_closed_cb: handle >38< being closed is invalid.
ERROR uccpbus_closed_cb: handle >39< being closed is invalid.
ERROR uccpbus_closed_cb: handle >40< being closed is invalid.
ERROR uccpbus_closed_cb: handle >41< being closed is invalid.
ERROR uccpbus_closed_cb: handle >42< being closed is invalid.
ERROR uccpbus_closed_cb: handle >43< being closed is invalid.
ERROR uccpbus_closed_cb: handle >44< being closed is invalid.
ERROR uccpbus_closed_cb: handle >45< being closed is invalid.
ERROR uccpbus_closed_cb: handle >46< being closed is invalid.
ERROR uccpbus_closed_cb: handle >47< being closed is invalid.
>
>
> >
> >
> >
> > >
> > > Brian
> > >
> > >
> > >
> > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > >
> > >
> >
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Re: PRI Card error From: Brian <signal@shreve.net> Date: 1997-07-14 19:25:00
On Mon, 14 Jul 1997, Brian wrote:
> On Mon, 14 Jul 1997, Tatai SV Krishnan wrote:
>
> >
> > On Sun, 13 Jul 1997, Brian wrote:
> >
> > > Do you know what this error means, on the PRI card:
> > >
> > > ERR:ucc_gen_error,ucc_go_t_d_disc,pb_dg_send,error:-3
> > > ERR:ucc_gen_error,ucc_setup_in_call,pb_dg_send,eroor:-3
> > >
> > > Users call and complain it just rings and rings, I think it may be telco
> > > related.
> >
> > This looks like a telco disconnect, ucc_go_telco_disc, What are the
> > error messages previous to this message?
> >
> > krish
> >
>
here are the errors that happen upon reboot and previous to the above:
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERR:ucc_gen_error,ucc_null,bad event:,err:3
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
ERROR uccpbus_closed_cb: handle >0< being closed is invalid.
ERROR uccpbus_closed_cb: handle >1< being closed is invalid.
ERROR uccpbus_closed_cb: handle >2< being closed is invalid.
ERROR uccpbus_closed_cb: handle >3< being closed is invalid.
ERROR uccpbus_opened_cb: handle >49< already up OR not pending.
ERROR uccpbus_opened_cb: handle >50< already up OR not pending.
ERROR uccpbus_opened_cb: handle >51< already up OR not pending.
ERROR uccpbus_opened_cb: handle >52< already up OR not pending.
ERROR uccpbus_closed_cb: handle >4< being closed is invalid.
ERROR uccpbus_closed_cb: handle >5< being closed is invalid.
ERROR uccpbus_closed_cb: handle >6< being closed is invalid.
ERROR uccpbus_closed_cb: handle >7< being closed is invalid.
ERROR uccpbus_opened_cb: handle >53< already up OR not pending.
ERROR uccpbus_opened_cb: handle >54< already up OR not pending.
ERROR uccpbus_opened_cb: handle >55< already up OR not pending.
ERROR uccpbus_opened_cb: handle >56< already up OR not pending.
ERROR uccpbus_closed_cb: handle >8< being closed is invalid.
ERROR uccpbus_closed_cb: handle >9< being closed is invalid.
ERROR uccpbus_closed_cb: handle >10< being closed is invalid.
ERROR uccpbus_closed_cb: handle >11< being closed is invalid.
ERROR uccpbus_opened_cb: handle >57< already up OR not pending.
ERROR uccpbus_opened_cb: handle >58< already up OR not pending.
ERROR uccpbus_opened_cb: handle >59< already up OR not pending.
ERROR uccpbus_opened_cb: handle >60< already up OR not pending.
ERROR uccpbus_closed_cb: handle >12< being closed is invalid.
ERROR uccpbus_closed_cb: handle >13< being closed is invalid.
ERROR uccpbus_closed_cb: handle >14< being closed is invalid.
ERROR uccpbus_closed_cb: handle >15< being closed is invalid.
ERROR uccpbus_opened_cb: handle >61< already up OR not pending.
ERROR uccpbus_opened_cb: handle >62< already up OR not pending.
ERROR uccpbus_opened_cb: handle >63< already up OR not pending.
ERROR uccpbus_closed_cb: handle >16< being closed is invalid.
ERROR uccpbus_closed_cb: handle >17< being closed is invalid.
ERROR uccpbus_closed_cb: handle >18< being closed is invalid.
ERROR uccpbus_closed_cb: handle >19< being closed is invalid.
ERROR uccpbus_closed_cb: handle >20< being closed is invalid.
ERROR uccpbus_closed_cb: handle >21< being closed is invalid.
ERROR uccpbus_closed_cb: handle >22< being closed is invalid.
ERROR uccpbus_closed_cb: handle >23< being closed is invalid.
ERROR uccpbus_closed_cb: handle >24< being closed is invalid.
ERROR uccpbus_closed_cb: handle >25< being closed is invalid.
ERROR uccpbus_closed_cb: handle >26< being closed is invalid.
ERROR uccpbus_closed_cb: handle >27< being closed is invalid.
ERROR uccpbus_closed_cb: handle >28< being closed is invalid.
ERROR uccpbus_closed_cb: handle >29< being closed is invalid.
ERROR uccpbus_closed_cb: handle >30< being closed is invalid.
ERROR uccpbus_closed_cb: handle >31< being closed is invalid.
ERROR uccpbus_closed_cb: handle >32< being closed is invalid.
ERROR uccpbus_closed_cb: handle >33< being closed is invalid.
ERROR uccpbus_closed_cb: handle >34< being closed is invalid.
ERROR uccpbus_closed_cb: handle >35< being closed is invalid.
ERROR uccpbus_closed_cb: handle >36< being closed is invalid.
ERROR uccpbus_closed_cb: handle >37< being closed is invalid.
ERROR uccpbus_closed_cb: handle >38< being closed is invalid.
ERROR uccpbus_closed_cb: handle >39< being closed is invalid.
ERROR uccpbus_closed_cb: handle >40< being closed is invalid.
ERROR uccpbus_closed_cb: handle >41< being closed is invalid.
ERROR uccpbus_closed_cb: handle >42< being closed is invalid.
ERROR uccpbus_closed_cb: handle >43< being closed is invalid.
ERROR uccpbus_closed_cb: handle >44< being closed is invalid.
ERROR uccpbus_closed_cb: handle >45< being closed is invalid.
ERROR uccpbus_closed_cb: handle >46< being closed is invalid.
ERROR uccpbus_closed_cb: handle >47< being closed is invalid.
>
>
> >
> >
> >
> > >
> > > Brian
> > >
> > >
> > >
> > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> > >
> > >
> >
>
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Re: PRI Card error From: Brian <signal@shreve.net> Date: 1997-07-14 19:57:46
On Mon, 14 Jul 1997, David Bolen wrote:
> Brian <signal@shreve.net> writes:
>
> > here are the errors that happen upon reboot and previous to the above:
>
> It sounds like the PRI card is having problems talking to the modems
> via the packet bus connection. I'd try verifying that the modems were
> all set to have their "line source" set to "priTdm", and if that looks
> ok, try resetting the modem slots once for good measure. :-)
line interface settings are set to priTdm, DTE is PacketBus, and Call
control options are set to packet bus answer only.
Brian
>
> -- David
>
> /-----------------------------------------------------------------------\
> \ David Bolen \ Internet: db3l@ans.net /
> | ANS Communications, Inc. \ Phone: (914) 789-5327 |
> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
> \-----------------------------------------------------------------------/
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Re: PRI Card error From: David Bolen <db3l@ans.net> Date: 1997-07-14 20:28:36
Brian <signal@shreve.net> writes:
> here are the errors that happen upon reboot and previous to the above:
It sounds like the PRI card is having problems talking to the modems
via the packet bus connection. I'd try verifying that the modems were
all set to have their "line source" set to "priTdm", and if that looks
ok, try resetting the modem slots once for good measure. :-)
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Re: PRI Card error From: Brian <signal@shreve.net> Date: 1997-07-14 21:05:13
On Mon, 14 Jul 1997, David Bolen wrote:
> > it doesnt seem like there is any kind of pattern, other than that chasis.
>
> I guess what I meant was that you're getting those errors, and yet all
> of your available modems are taking calls at some point in time?
>
> -- David
>
I did a reset to factory default on the PRI card. Then set b8zs, esf,
dms100...........just like they WERE before I did the reset. And now all
is well...................I have talked to others that have seen munging
or some sort of corruption after code upgrades.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Re: PRI Card error From: Marshall Morgan <marshall@netdoor.com> Date: 1997-07-14 21:29:51
On Monday, July 14, 1997 7:25 PM, Brian [SMTP:signal@shreve.net] wrote:
> On Mon, 14 Jul 1997, Brian wrote:
>
> > On Mon, 14 Jul 1997, Tatai SV Krishnan wrote:
> >
> > >
> > > On Sun, 13 Jul 1997, Brian wrote:
> > >
> > > > Do you know what this error means, on the PRI card:
> > > >
> > > > ERR:ucc_gen_error,ucc_go_t_d_disc,pb_dg_send,error:-3
> > > > ERR:ucc_gen_error,ucc_setup_in_call,pb_dg_send,eroor:-3
> > > >
> > > > Users call and complain it just rings and rings, I think it may be telco
> > > > related.
> > >
> > > This looks like a telco disconnect, ucc_go_telco_disc, What are the
> > > error messages previous to this message?
> > >
> > > krish
> > >
> >
>
> here are the errors that happen upon reboot and previous to the above:
>
>
> ERR:ucc_gen_error,ucc_null,bad event:,err:3
> ERR:ucc_gen_error,ucc_null,bad event:,err:3
> ERR:ucc_gen_error,ucc_null,bad event:,err:3
> ERR:ucc_gen_error,ucc_null,bad event:,err:3
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
> ERROR uccpbus_closed_cb: handle >0< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >1< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >2< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >3< being closed is invalid.
> ERROR uccpbus_opened_cb: handle >49< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >50< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >51< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >52< already up OR not pending.
> ERROR uccpbus_closed_cb: handle >4< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >5< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >6< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >7< being closed is invalid.
> ERROR uccpbus_opened_cb: handle >53< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >54< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >55< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >56< already up OR not pending.
> ERROR uccpbus_closed_cb: handle >8< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >9< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >10< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >11< being closed is invalid.
> ERROR uccpbus_opened_cb: handle >57< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >58< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >59< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >60< already up OR not pending.
> ERROR uccpbus_closed_cb: handle >12< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >13< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >14< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >15< being closed is invalid.
> ERROR uccpbus_opened_cb: handle >61< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >62< already up OR not pending.
> ERROR uccpbus_opened_cb: handle >63< already up OR not pending.
> ERROR uccpbus_closed_cb: handle >16< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >17< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >18< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >19< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >20< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >21< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >22< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >23< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >24< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >25< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >26< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >27< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >28< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >29< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >30< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >31< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >32< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >33< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >34< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >35< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >36< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >37< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >38< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >39< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >40< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >41< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >42< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >43< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >44< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >45< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >46< being closed is invalid.
> ERROR uccpbus_closed_cb: handle >47< being closed is invalid.
>
Symptoms:
Upgrade a Chassis to 2.5.1 and reset the box. The PRI card shows QBCH-I_MDM
instead of QBCH-MDM. When the chassis attempts to take calls, analog modems
never sync. Setting the modems to QBCH-MDM and going into debug and turning
chassis awareness seems to make the chassis work if you have console access.
Problem is ... when resetting the PRI Card or power loss ... problem comes back up.
Fix:
Upgrade to TCS 2.5.1. On the modems, set fact defaults, set HW flow Template,
save NRAM,
go to ISDN Modem Call Control Options:
CHANGE:
Set Data Mode of Modem (*V2=x) autodetect
TO:
Set Data Mode of Modem (*V2=x) modemOrFaxOnly
Save to NRAM.
Marshall Morgan
Internet Doorway, Inc.
http://www.netdoor.com
601.969.1434 | 800.952.1570 | 601.969.3838 Fax
Subject:(usr-tc) No Handshake From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-14 22:34:00
-> I'm a first time poster, long time listener. :)
->
-> I've got a new TC rack installed. Just upgraded all cards to the latest
-> revs. x2 key installed. When I try calling the TC with an analog modem one
-> of the quad modems answers but doesn't complete the handshake. It starts to
-> handshake but just before it would get to the v.34 'bong, bong' it stops. It
-> doesn't hang up, just stops. I've tried this with many different modems
-> (v.34) and computers with the same results. The only difference is that a
-> Megahertz xj2288 did connect ONCE at 2400bps.
I suspect an init string problem. I went through the same issues. Take a
look at what you were running previously as an init string and program it into
your TC modems.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) No Handshake From: Brian <signal@shreve.net> Date: 1997-07-14 23:21:49
On Mon, 14 Jul 1997, Jeff Binkley wrote:
> -> I'm a first time poster, long time listener. :)
> ->
> -> I've got a new TC rack installed. Just upgraded all cards to the latest
> -> revs. x2 key installed. When I try calling the TC with an analog modem one
> -> of the quad modems answers but doesn't complete the handshake. It starts to
> -> handshake but just before it would get to the v.34 'bong, bong' it stops. It
> -> doesn't hang up, just stops. I've tried this with many different modems
> -> (v.34) and computers with the same results. The only difference is that a
> -> Megahertz xj2288 did connect ONCE at 2400bps.
>
>
> I suspect an init string problem. I went through the same issues. Take a
> look at what you were running previously as an init string and program it into
> your TC modems.
>
Check the modem is not set to 300baud, had this problem on one of ours. A
300 baud carrier just stops also, thats what it is suppose to do.
Brian
> Jeff Binkley
> ASA Network Computing
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Hi,
I've got a new version for my Quad Modem Cards. It came with the
MS-DOS-program pcsdl.exe. By using this software, I already made an
upgrade of the Netserver Pri Card by putting the RS232-cable in the
Netserver-NIC. But how can I connect to my modem cards without having
Modem-NICs or a Network Management Card?
I think there should be a solution by setting a modem to direct telnet
access, but then....?
Thanks for any help,
bye,
Lars
--
+-----------------------------------------------------------------+
| Lars Freund lars@forchheim.com |
| FOnLine Buergernetzverein: http://www.forchheim.baynet.de |
| http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html |
+-----------------------------------------------------------------+
Subject:Re: (usr-tc) No Handshake From: Mark Wilson <mrw@netdirect.net> Date: 1997-07-15 09:23:48
>-> I'm a first time poster, long time listener. :)
>->
>-> I've got a new TC rack installed. Just upgraded all cards to the latest
>-> revs. x2 key installed. When I try calling the TC with an analog modem one
>-> of the quad modems answers but doesn't complete the handshake. It starts to
>-> handshake but just before it would get to the v.34 'bong, bong' it
>stops. It
>-> doesn't hang up, just stops. I've tried this with many different modems
>-> (v.34) and computers with the same results. The only difference is that a
>-> Megahertz xj2288 did connect ONCE at 2400bps.
>
>
>I suspect an init string problem. I went through the same issues. Take a
>look at what you were running previously as an init string and program it into
>your TC modems.
>
> Jeff Binkley
> ASA Network Computing
I restored from default and then saved to NVRAM and it fixed it.
Thanks,
mrw@netdirect.net
Subject:Re: (usr-tc) No Handshake From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-15 10:52:00
u>On Mon, 14 Jul 1997, Jeff Binkley wrote:
u>> -> I'm a first time poster, long time listener. :)
u>> -> I've got a new TC rack installed. Just upgraded all cards to the
u>> -> latest revs. x2 key installed. When I try calling the TC with an
u>analog modem one
u>> -> of the quad modems answers but doesn't complete the handshake. It
u>starts to
u>> -> handshake but just before it would get to the v.34 'bong, bong'
u>it stops. It
u>> -> doesn't hang up, just stops. I've tried this with many different
u>> -> modems (v.34) and computers with the same results. The only
u>> -> difference is that a Megahertz xj2288 did connect ONCE at
u>> 2400bps.
u>> I suspect an init string problem. I went through the same issues.
u>> Take a look at what you were running previously as an init string
u>and program it into
u>> your TC modems.
u>Check the modem is not set to 300baud, had this problem on one of
u>ours. A 300 baud carrier just stops also, thats what it is suppose to
u>do.
Yep. An &N0 in the init string will do the same thing as setting the
parameter to variable.
Jeff Binkley
ASA Network Computing
CMPQwk 1.42 9999
Subject:Re: (usr-tc) Total Control Hub Reboots From: King Ho <ml@glink.net.hk> Date: 1997-07-15 12:19:41
On Wed, 9 Jul 1997, Joachim Nerz wrote:
> On Wed, 9 Jul 1997, Lars Freund wrote:
>
> > On Tue, 8 Jul 1997, Cindy Smith wrote:
> >
> > Hi Cindy,
> >
> > > We are currently running 3 total control hubs. For some reason, they seem to be rebooting for no apparant reason. What could be a possible cause for this?
> >
> > we hat the same problem until monday. We had reboots every 5 oder 10
> > hours. With more than 6 users online, our USR rebooted every hour. Now we
> > fixed it: we had only 4 MB of RAM, and every firmware release > 5.3 (i
> > think so) need 6 MB. Since we plugged in our 16 MB NON EDO SIMM, it works
> > fine...
> I have the same Problem, but the 16 MB did not help :-(
>
> System memory 17301504 bytes - 6372080 used, 10929424 available
> Should be enough, I think...
>
> An Upgrade From 3.5.31 to 3.5.34 did`t help too.
>
> Any sugestions ?
>
Same here! We have 18M and 3.5.34. I checked the card and it does have
a fc3. Should I called USR and have RMA the card?
Thanks.
Best regards,
King Ho
Global Link Information Services Ltd.
Subject:Re: (usr-tc) No Handshake From: Brian Elfert <brian@citilink.com> Date: 1997-07-15 17:10:02
On Mon, 14 Jul 1997, Mark Wilson wrote:
> I'm a first time poster, long time listener. :)
>
> I've got a new TC rack installed. Just upgraded all cards to the latest
> revs. x2 key installed. When I try calling the TC with an analog modem one
> of the quad modems answers but doesn't complete the handshake. It starts to
> handshake but just before it would get to the v.34 'bong, bong' it stops.
> It doesn't hang up, just stops. I've tried this with many different modems
> (v.34) and computers with the same results. The only difference is that a
> Megahertz xj2288 did connect ONCE at 2400bps.
Does an X2 modem connect? There is supposedly an open issue with V.34
modems not connecting after a flash upgrade of the modems.
Here's what happened to me when I upgraded my modems to 5.6.6.
At the time, I had 24 modems hooked to POTS, and 24 hooked to a CT1.
All of the DS0s on my T1 said they were dialing out, and they wouldn't
take calls obviously. After the upgrade, none of the modems connected to
POTS would finish the handshake, and would just time out.
I ended up calling USR, and they said that the NVRAM was corrupted, and it
took them over an hour to get the thing half way working again.
Brian
Subject:Re: (usr-tc) No Handshake From: David Bolen <db3l@ans.net> Date: 1997-07-15 18:23:40
Brian Elfert <brian@citilink.com> writes:
> Does an X2 modem connect? There is supposedly an open issue with V.34
> modems not connecting after a flash upgrade of the modems.
I believe the net of the issue is that the upgrade doesn't always
leave the NVRAM settings in a good state. Restoring the modems to
factory defaults following the update and moving forward from there
should resolve problems. Of course, you shouldn't have to do that,
but...
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) ZModem hangup problem workaround From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-16 13:22:35
David Bolen said once upon a time:
>If you were able to catch a tcpdump of the final stages of a session,
>it would be interesting to see what the TCP flags showed.
I've got a snoop output, but there doesn't seem to be any smoking guns in
it. If there is something I can do via snoop to show it, let me know. I
did a raw capture.
Subject:Re: (usr-tc) Quake Lag From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-16 13:34:07
Brian said once upon a time:
>Actually however, I think Quake lag problem was since 3.3.28, and was
>actually fixed as early as 3.5.33. The current TCS 2.5.1 (netserver
>3.5.34) seems to be just fine. We run quite a popular Quake server and
>haven't had any lag problems since going to netserver 3.5.33 (we currently
>run 3.5.34).
Don't speak for everyone. We're on 3.5.34 and still seeing a few
problems. I'm not sure it is isolated to the Netservers yet though.
Subject:(usr-tc) Netserver questions From: Mark Miller <lumm@lehigh.edu> Date: 1997-07-16 13:58:18
We've recently installed a USR TC hub with Netserver. Two questions i
hope this list can help with:
1) By looking at the radius detail files, how can we tell if the hub
has been rebooted? Is there a special Acct-Session-Id reserved for
this purpose?
2) How do people assign IPX addresses? We have over 8,000 users so
its impossible to assign per user. Is there a pooling option like that
used for IP addresses?
thanks,
mark
Mark Miller
Lead Network Analyst lumm@Lehigh.EDU
183 Computing Center, Bldg #8B lumm@spot.CC.Lehigh.EDU
Lehigh University
Bethlehem, PA 18015
Subject:Re: (usr-tc) Quake Lag From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-16 15:02:09
Rick said once upon a time:
>Has anyone tried to see if setting the global parameter 'ppp in modem'
>helps any with the quake lag. We have recently upgraded to the new
>3.5.34 netserver code but since I have not been following the 'quake
>server bug' closely I cannot give any insight as to if the new netserver
>code has improved quake lag or not.
I use "ppp in modem" exclusively, and it seems to have no effect, either on
or off.
Subject:Re: (usr-tc) Quake Lag From: Rick <rallan@monmouth.com> Date: 1997-07-16 15:56:14
Pete Ashdown wrote:
>
> Brian said once upon a time:
>
> >Actually however, I think Quake lag problem was since 3.3.28, and was
> >actually fixed as early as 3.5.33. The current TCS 2.5.1 (netserver
> >3.5.34) seems to be just fine. We run quite a popular Quake server and
> >haven't had any lag problems since going to netserver 3.5.33 (we currently
> >run 3.5.34).
>
> Don't speak for everyone. We're on 3.5.34 and still seeing a few
> problems. I'm not sure it is isolated to the Netservers yet though.
Has anyone tried to see if setting the global parameter 'ppp in modem'
helps any with the quake lag. We have recently upgraded to the new
3.5.34 netserver code but since I have not been following the 'quake
server bug' closely I cannot give any insight as to if the new netserver
code has improved quake lag or not.
--
Rick
Subject:Re: (usr-tc) Quake Lag From: Brian <signal@shreve.net> Date: 1997-07-16 16:51:31
On Wed, 16 Jul 1997, Rick wrote:
> Pete Ashdown wrote:
> >
> > Brian said once upon a time:
> >
> > >Actually however, I think Quake lag problem was since 3.3.28, and was
> > >actually fixed as early as 3.5.33. The current TCS 2.5.1 (netserver
> > >3.5.34) seems to be just fine. We run quite a popular Quake server and
> > >haven't had any lag problems since going to netserver 3.5.33 (we currently
> > >run 3.5.34).
> >
> > Don't speak for everyone. We're on 3.5.34 and still seeing a few
> > problems. I'm not sure it is isolated to the Netservers yet though.
>
> Has anyone tried to see if setting the global parameter 'ppp in modem'
> helps any with the quake lag. We have recently upgraded to the new
> 3.5.34 netserver code but since I have not been following the 'quake
> server bug' closely I cannot give any insight as to if the new netserver
> code has improved quake lag or not.
I have mine set to ppp_in_modem, however I don't know if there was an
improvment or not in the quake lag situation with respect to that change.
It makes sense though to have the PPP serviced from the modem, rather than
all from the netserver, more load distribution.
Is anyone servicing ISDN from the modem instead of the Netserver card?
Brian
> --
> Rick
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Re: Question on usr-tc From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-16 16:52:00
Deepak Vaidya said once upon a time:
>
>Hello,
>
>I just joined the list today and have a question. Is it ok to post for
>sale request to the list. We are upgrading our analog cards to digital
>and have analog cards for sale.
I don't have a problem with for-sale items, just as long as they are
relevant to the list. That is, USR TC stuff is good, but ethernet hubs and
routers should find another avenue.
Subject:(usr-tc) Radius logs -> msql db From: Brian <signal@shreve.net> Date: 1997-07-16 16:59:25
Has anyone written any utilities to read in radius logs and put them in a
msql database?
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
On Wed, 16 Jul 1997 16:51:31 -0500 (CDT), Brian <signal@shreve.net>
wrote:
>It makes sense though to have the PPP serviced from the modem, rather =
than
>all from the netserver, more load distribution.
I agree it makes more sense, but is it correct? Is there a documented
speed/latency advantage with running 'PPP in modem' rather than 'PPP
in NETServer'?
Best regards,
Russ
Subject:Re: (usr-tc) Quake Lag From: David Bolen <db3l@ans.net> Date: 1997-07-16 22:25:25
rpanula@dacmail.net (Russ Panula) write:
> I agree it makes more sense, but is it correct?
I assume that depends on your definition of "correct" :-)
> Is there a documented
> speed/latency advantage with running 'PPP in modem' rather than 'PPP
> in NETServer'?
My testing has shown something in the neighborhood of at least a
10-15ms gain in latency for normal PPP session traffic (I can't speak
specific for Quake) with the PPP packet processing going on in the
modem.
As for system throughput, I expect that you'll find the maximum system
throughput through a chassis as a whole is obtained with PPP
processing in the modems as well (I'm pretty sure that's the way
3Com/USR configures them when running their own benchmarks).
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
On Wed, 16 Jul 97 22:25:25 EDT, David Bolen <db3l@ans.net> wrote:
>rpanula@dacmail.net (Russ Panula) write:
>
>> I agree it makes more sense, but is it correct?
>
>I assume that depends on your definition of "correct" :-)
I suppose in this situation I would define it as being the best way of
obtaining the highest performing system.
Of course, you could always take the BOFH approach... i.e. the
"correct" way to get drunk is to drink fast, plenty, and without
regard for others :p
(Note to BOFHers, add to list of slow system reasons: "PPP processing
was mistakenly configured in the NETserver rather than the
modem"--that should buy you enough time for lunch)=20
>My testing has shown something in the neighborhood of at least a
>10-15ms gain in latency for normal PPP session traffic (I can't speak
>specific for Quake) with the PPP packet processing going on in the
>modem.
>
>As for system throughput, I expect that you'll find the maximum system
>throughput through a chassis as a whole is obtained with PPP
>processing in the modems as well (I'm pretty sure that's the way
>3Com/USR configures them when running their own benchmarks).
I do trust your testing, even without the specifics. However, I'm
still uneasy about this. Why have 'PPP in NETserver' as an option if
all it does is drag performance down? Is there some application where
it would make sense to configure the modems this way?
Or, pardon my lack of knowledge of the history of this platform, was
there a time when PPP processing was always done in the NETserver?
Regards,
Russ
Subject:Re: (usr-tc) Quake Lag From: David Bolen <db3l@ans.net> Date: 1997-07-17 00:47:19
rpanula@dacmail.net (Russ Panula) writes:
> I do trust your testing, even without the specifics. However, I'm
> still uneasy about this. Why have 'PPP in NETserver' as an option if
> all it does is drag performance down? Is there some application where
> it would make sense to configure the modems this way?
>
> Or, pardon my lack of knowledge of the history of this platform, was
> there a time when PPP processing was always done in the NETserver?
Exactly. Support for handling the PPP (and SLIP) framing in the modem
was a fairly recent addition to the modem code (say perhaps around the
TCS 1.5 days back somewhere around early '96), so prior to that there
was no choice. And like many new features, back then with some of the
earliest releases it wasn't always as "safe" to use it in the modem as
the modem framing support was still getting some of the kinks out.
I'm a big fan of knobs, so I still like having the configurability,
but our standard configuration for some time now has always been to
configure that to the 'on' state as part of our standard NETServer
configuration process for any new equipment. But there are still
times I'll turn it off during lab testing of new releases in order to
switch the point of framing processing in order to help potentially
diagnose new problems as being on the modem or NETServer side.
As to whether there are other configurations where running with the
framing in the NETServer is still a better idea, I'm not sure. I
don't personally use any that way, but I believe I've seen some other
messages that might have noted different behavior for other locations.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) 6 Quad Analog card for sale From: Brian <signal@shreve.net> Date: 1997-07-17 07:29:16
On Thu, 17 Jul 1997, Deepak Vaidya wrote:
> Hello,
>
> We are upgrading over analog cards to digital cards and have 6 cards for
> sale. They are about 18months old. Would like to get $900 for them.
> If I am way overboard, I am sure the list will let me know :-).
>
> Please, email me or call.
There is actually an analog modem card? I knew there was Quad Modems with
NICs in the back, but thought that was just a normal quad with a nic.
Brian
>
> Thank You
> - Deepak
> --
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> + Deepak Vaidya dvaid@ctp.com + email: dvaid@ctp.com +
> + CTP, Inc. (617) 374 8413 + phone: (617) 374 8413 +
> + 304 Vassar St. Camb. MA 02139 + +
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) 6 Quad Analog card for sale From: Brian <signal@shreve.net> Date: 1997-07-17 07:29:16
On Thu, 17 Jul 1997, Deepak Vaidya wrote:
> Hello,
>
> We are upgrading over analog cards to digital cards and have 6 cards for
> sale. They are about 18months old. Would like to get $900 for them.
> If I am way overboard, I am sure the list will let me know :-).
>
> Please, email me or call.
There is actually an analog modem card? I knew there was Quad Modems with
NICs in the back, but thought that was just a normal quad with a nic.
Brian
>
> Thank You
> - Deepak
> --
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> + Deepak Vaidya dvaid@ctp.com + email: dvaid@ctp.com +
> + CTP, Inc. (617) 374 8413 + phone: (617) 374 8413 +
> + 304 Vassar St. Camb. MA 02139 + +
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) 6 Quad Analog card for sale From: Deepak Vaidya <dvaid@ctp.com> Date: 1997-07-17 07:39:45
Hello,
We are upgrading over analog cards to digital cards and have 6 cards for
sale. They are about 18months old. Would like to get $900 for them.
If I am way overboard, I am sure the list will let me know :-).
Please, email me or call.
Thank You
- Deepak
--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+ Deepak Vaidya dvaid@ctp.com + email: dvaid@ctp.com +
+ CTP, Inc. (617) 374 8413 + phone: (617) 374 8413 +
+ 304 Vassar St. Camb. MA 02139 + +
Subject:Re: (usr-tc) Quake Lag From: Brian Elfert <brian@citilink.com> Date: 1997-07-17 10:29:11
On Wed, 16 Jul 1997, David Bolen wrote:
> My testing has shown something in the neighborhood of at least a
> 10-15ms gain in latency for normal PPP session traffic (I can't speak
> specific for Quake) with the PPP packet processing going on in the
> modem.
Does 'gain' mean the latency goes down or up?
Brian
Good day to everybody!
A couple of years ago I've set up an ISP company for which I'm now acting
as a consultant.
At that time I decided to use US-Robotics TCH (with NMC) hooked to the
telco via POTS and to cisco 2511 access routers via RS-232 NICs.
The rationale was to have the best and more flexible solution available at
that time and I think we made the right move: everything has worked
perfectly until now.
Now, with increasing demand for ISDN access, we've set up another (parallel
to the first one) access network based on cisco 2511 and ZyXel 2864-I T.A.
The first network is using cisco proprietary (Tacacs) authentication
method, while the new one uses Radius (RadiusNT server). This new access
network has some problems: the ZyXel T.A. sometimes got stuck and don't
answer ISDN calls anymore (they do answer V.34 calls anyway, strange
enough...). Power cycling needed to reset, ATZ doesn't work.
This two-faced access networks is anyway causing (obviously!) management
problems and I'm about to propose to merge the two.
What I would like to do is to get rid of the 2511s and the ZyXel, buy
Netserver and PRI cards for the TCH, move to Radius as the authentication
and accounting protocol using Emerald (from IEA) to manage the accounts.
Anyway there are a couple of questions which I must answer to myself before
taking this decision and here I am seeking help from my fellow colleagues
on the net:
Question N.1:
One of the service we are offering is Dial-On-Demand from the network. When
an IP calls arrives for customers who have subscribed this service our 2511
places a call to the customer set up a PPP connection to them and activate
routing to their subnet (possibly applying IP filters). It is unclear to me
if such functionality would be available using the USR NetServer card
instead of the cisco 2511.
Question N.2:
Will I be able to differentiate ISDN from V.34 calls and allow or not
access based on the customer profile?
Question N.3:
Will I be able to upgrade my two years old Quad Analog/Digital cards (don't
have Rev. at hand right now but could provide if needed) to the latest TCS
or they will need hardware upgrades?
Question N.4:
Will I still need the NMC cards or will SNMP management be handled by the
NetServer cards?
Question N.5:
There isn't one right now but if I'm missing (or messing) something I would
really apreciate any comment.
This mail has been cross-posted to the RadiusNT and usr-tc mailing lists.
Many thanks in advance to everybody.
Sergio Manzi
========================
Internet Consultant
E-Mail: smz@gpnet.it
Phone: +39 (335) 6368427
========================
Subject:Re: (usr-tc) USR TCH, RadiusNT, Emerlad, Dial-On-Demand, Etc. From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-17 11:24:08
Sergio Manzi said once upon a time:
>Question N.1:
>One of the service we are offering is Dial-On-Demand from the network. When
>an IP calls arrives for customers who have subscribed this service our 2511
>places a call to the customer set up a PPP connection to them and activate
>routing to their subnet (possibly applying IP filters). It is unclear to me
>if such functionality would be available using the USR NetServer card
>instead of the cisco 2511.
When I purchased our TC's back in December, the technicians at USR claimed
this was an upcoming feature. It hasn't happened yet though.
>Question N.2:
>Will I be able to differentiate ISDN from V.34 calls and allow or not
>access based on the customer profile?
This was previously discussed on the list. I believe you can and the
answer is in the archives.
>Question N.3:
>Will I be able to upgrade my two years old Quad Analog/Digital cards (don't
>have Rev. at hand right now but could provide if needed) to the latest TCS
>or they will need hardware upgrades?
Don't know on this one.
>Question N.4:
>Will I still need the NMC cards or will SNMP management be handled by the
>NetServer cards?
No, the SNMP management of the chassis as a whole is handled by the NMC
card.
Once upon a time Pete Ashdown shaped the electrons to say...
>When I purchased our TC's back in December, the technicians at USR claimed
>this was an upcoming feature. It hasn't happened yet though.
Odd - ComOS has had that for a long time now. I didn't think they actually
removed features from 3.1.4 when they modified it.
*shrug*
-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com <http://www.livingston.com/>
Snail mail: 4464 Willow Road, Pleasanton, CA 94588
Subject:(usr-tc) MRTG From: Tim Tsai <tim@futuresouth.com> Date: 1997-07-17 16:18:30
Does anybody have SNMP monitoring scripts that works with MRTG? This
is for the TC Hub with NMC.
Thanks,
Tim
Subject:Re: (usr-tc) Quake Lag From: David Bolen <db3l@ans.net> Date: 1997-07-17 16:21:10
Brian Elfert <brian@citilink.com> writes:
> Does 'gain' mean the latency goes down or up?
Whoops - definite ambiguity in that statement, sorry. Gain in this
context was meant to imply improvement, or the recovery of 10-15ms, so
the actual latency decreases.
-- David
Subject:Re: (usr-tc) 6 Quad Analog card for sale From: David Bolen <db3l@ans.net> Date: 1997-07-17 16:24:47
Brian <signal@shreve.net> writes:
> There is actually an analog modem card? I knew there was Quad Modems with
> NICs in the back, but thought that was just a normal quad with a nic.
I'm not sure if they still sell all variants (although checking a
fairly recent rack of ours I did find both an analog only and a dual
card, which we use for OOBA), but you used to be able to get either a
digital, analog, or dual modem card.
All types support working with a NIC (and in fact with either the
RS-232 only or RS-232 plus analog jack NICs, since the RS-232 hardware
is identical on each), but only those cards with the analog hardware
can support processing calls via the RJ11 jacks on the NIC.
-- David
Subject:Re: (usr-tc) 6 Quad Analog card for sale From: Brian Elfert <brian@citilink.com> Date: 1997-07-17 16:27:58
On Thu, 17 Jul 1997, Brian wrote:
> There is actually an analog modem card? I knew there was Quad Modems with
> NICs in the back, but thought that was just a normal quad with a nic.
Out of curiosity, I pulled a digital card and a analog/digital card out of
my chassis.
The circuit boards themselves look identical. The only difference I see
is about a dozen additional integrated circuits.
Brian
Subject:Re: (usr-tc) 6 Quad Analog card for sale From: Brian Elfert <brian@citilink.com> Date: 1997-07-17 16:27:58
On Thu, 17 Jul 1997, Brian wrote:
> There is actually an analog modem card? I knew there was Quad Modems with
> NICs in the back, but thought that was just a normal quad with a nic.
Out of curiosity, I pulled a digital card and a analog/digital card out of
my chassis.
The circuit boards themselves look identical. The only difference I see
is about a dozen additional integrated circuits.
Brian
Subject:Re: (usr-tc) USR TCH, RadiusNT, Emerlad, Dial-On-Demand, Etc. From: David Bolen <db3l@ans.net> Date: 1997-07-17 16:48:41
Sergio Manzi <smz@gpnet.it> writes:
> Question N.1:
> One of the service we are offering is Dial-On-Demand from the network. When
> an IP calls arrives for customers who have subscribed this service our 2511
> places a call to the customer set up a PPP connection to them and activate
> routing to their subnet (possibly applying IP filters). It is unclear to me
> if such functionality would be available using the USR NetServer card
> instead of the cisco 2511.
If you are talking about using dial on demand based on actual packet
flow (e.g., "IP calls arrives" means the receipt of a packet for the
target destination network) then yes, in theory you should be able to
do this although I haven't tested it much myself.
To do so, you need to define your remote location on the NETServer
(add location) and define it as an on_demand, set up the various
parameters such as target address (required for on_demand) and
protocol information and a script to do the login. The requirement
for a remote target address (so you can point the static route
somewhere) does make this problematic if you are dialing into a hunt
group and you're not sure just which gear you will hit.
Then define some static routes that point to the target address
configured into the on_demand destination and you should be set. You
can configure idle timeouts as well as values when the NETServer
should open multiple connections for additional bandwidth.
3Com/USR generally refers to this as a LAN to LAN configuration setup
in their NETServer documentation.
As I mentioned above though, other than some lab experimentation a few
years ago I don't use this feature myself so others may have more
information as to how well (or if at all) it works.
> Question N.2:
> Will I be able to differentiate ISDN from V.34 calls and allow or not
> access based on the customer profile?
If you are talking about within your RADIUS server, then yes, you will
receive a "NAS-Port-Type" attribute (61) in the authentication
request, which would be Async (0) for modem dialup, or one of several
ISDN values (2-4) for ISDN.
If you are interested in modem modulation information, the more recent
NETServer releases also include vendor specific attributes in the
request to let you know the modulation in use (e.g., V.32, V.34, x2),
connect speed, error control and compression type.
As to how well you can control access based on that information,
that's a question of functionality for the RADIUS server you use.
> Question N.3:
> Will I be able to upgrade my two years old Quad Analog/Digital cards (don't
> have Rev. at hand right now but could provide if needed) to the latest TCS
> or they will need hardware upgrades?
If they are V.34 cards you should be fine. I have some of the first
V.34 cards off of the assembly line still in service and have been
upgrading them since '94 all the way up to TCS 2.5.1 and x2. :-)
> Question N.4:
> Will I still need the NMC cards or will SNMP management be handled by the
> NetServer cards?
The NETServer does support working as an SNMP agent, but the only
thing it supports is MIB-II and thus it is very limited for actual
management of how the NETServer works within the chassis (and
certainly not for other components in the chassis).
You always want an NMC card with a total control chassis, no question
about it. This is probably one spot where USR messed up a little back
in the beginning - at least in my opinion they shouldn't have even
made it an optional component, and they should have provided
redundancy - over time the NMC has just become more and more important.
> This mail has been cross-posted to the RadiusNT and usr-tc mailing lists.
Hmm - just FYI, but the copy I received was only to usr-tc...
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) Quad analog cards From: Tim Tsai <tim@futuresouth.com> Date: 1997-07-17 17:15:36
Does anybody know if there's an upgrade policy for quad analog cards and
an older TC Hub (the one without a fan)? USR said no but their sales rep
have been clueless before. A friend seems to think he's read it on their
webpage somewhere but I can't find any references. We've gone digital
and I am not sure what to do with this analog stuff.
Thanks,
Tim
Subject:Re[2]: (usr-tc) 6 Quad Analog card for sale From: mmahan@usr.com Date: 1997-07-17 17:21:52
--IMA.Boundary.057971968
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Analog only modem does not have the Packet Bus / or TDM
bus IC chips populated on the PCB. The NIC accompanying the Analog
modem includes a DAA (plug in PCB via header pin connection) for the
phone line interface circuitry.
Mark Mahan
On Thu, 17 Jul 1997, Brian wrote:
> There is actually an analog modem card? I knew there was Quad Modems with
> NICs in the back, but thought that was just a normal quad with a nic.
Out of curiosity, I pulled a digital card and a analog/digital card out of
my chassis.
The circuit boards themselves look identical. The only difference I see
is about a dozen additional integrated circuits.
Brian
--IMA.Boundary.057971968
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: attachment; filename="RFC822 message headers"
Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP
(IMA Internet Exchange 2.02 Enterprise) id 3CE918E0; Thu, 17 Jul 97 16:41:34
-0500
Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics)
id QAA05298; Thu, 17 Jul 1997 16:19:02 -0500 (CDT)
Received: from domo by mail.xmission.com with local (Exim 1.62 #3)
id 0woy5m-0002MX-00; Thu, 17 Jul 1997 15:28:06 -0600
Received: from homebase.citilink.com [206.11.208.3] (root)
by mail.xmission.com with smtp (Exim 1.62 #3)
id 0woy5j-0002MD-00; Thu, 17 Jul 1997 15:28:03 -0600
Received: from homebase (brian@homebase [206.11.208.3]) by homebase.citilink.com
(8.8.5/8.7.5) with SMTP id QAA14231; Thu, 17 Jul 1997 16:27:59 -0500 (CDT)
Posted-Date: Thu, 17 Jul 1997 16:27:59 -0500 (CDT)
X-Sender: brian@homebase
cc: usr-tc@mail.xmission.com, usr-tc@xmission.com
In-Reply-To: <Pine.LNX.3.93.970717072834.7276B-100000@www.shreve.net>
Message-ID: <Pine.GSO.3.96.970717162632.1603G-100000@homebase>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-usr-tc@xmission.com
Precedence: bulk
Reply-To: usr-tc@mail.xmission.com
--IMA.Boundary.057971968--
Subject:Re[2]: (usr-tc) 6 Quad Analog card for sale From: mmahan@usr.com Date: 1997-07-17 17:21:52
--IMA.Boundary.057971968
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Analog only modem does not have the Packet Bus / or TDM
bus IC chips populated on the PCB. The NIC accompanying the Analog
modem includes a DAA (plug in PCB via header pin connection) for the
phone line interface circuitry.
Mark Mahan
On Thu, 17 Jul 1997, Brian wrote:
> There is actually an analog modem card? I knew there was Quad Modems with
> NICs in the back, but thought that was just a normal quad with a nic.
Out of curiosity, I pulled a digital card and a analog/digital card out of
my chassis.
The circuit boards themselves look identical. The only difference I see
is about a dozen additional integrated circuits.
Brian
--IMA.Boundary.057971968
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: attachment; filename="RFC822 message headers"
Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP
(IMA Internet Exchange 2.02 Enterprise) id 3CE918E0; Thu, 17 Jul 97 16:41:34
-0500
Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics)
id QAA05298; Thu, 17 Jul 1997 16:19:02 -0500 (CDT)
Received: from domo by mail.xmission.com with local (Exim 1.62 #3)
id 0woy5m-0002MX-00; Thu, 17 Jul 1997 15:28:06 -0600
Received: from homebase.citilink.com [206.11.208.3] (root)
by mail.xmission.com with smtp (Exim 1.62 #3)
id 0woy5j-0002MD-00; Thu, 17 Jul 1997 15:28:03 -0600
Received: from homebase (brian@homebase [206.11.208.3]) by homebase.citilink.com
(8.8.5/8.7.5) with SMTP id QAA14231; Thu, 17 Jul 1997 16:27:59 -0500 (CDT)
Posted-Date: Thu, 17 Jul 1997 16:27:59 -0500 (CDT)
X-Sender: brian@homebase
cc: usr-tc@mail.xmission.com, usr-tc@xmission.com
In-Reply-To: <Pine.LNX.3.93.970717072834.7276B-100000@www.shreve.net>
Message-ID: <Pine.GSO.3.96.970717162632.1603G-100000@homebase>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-usr-tc@xmission.com
Precedence: bulk
Reply-To: usr-tc@mail.xmission.com
--IMA.Boundary.057971968--
On Thu, 17 Jul 1997, David Bolen wrote:
> All types support working with a NIC (and in fact with either the
> RS-232 only or RS-232 plus analog jack NICs, since the RS-232 hardware
> is identical on each), but only those cards with the analog hardware
> can support processing calls via the RJ11 jacks on the NIC.
Can a digital only modem card use the NIC card, even if the RJ-11s won't
work? I'd like to use just the serial port. I asked somebody about this
before, and they said NICs only worked on analog/digital cards.
I'm been sorta thinking about replacing my netserver card with two PM25s
so I can support OSPF, and some other cool stuff USR doesn't have.
Brian
Subject:Re: (usr-tc) 6 Quad Analog card for sale From: David Bolen <db3l@ans.net> Date: 1997-07-17 17:58:36
Brian <signal@shreve.net> writes:
> The circuit boards themselves look identical.
Yes, the layout for the hardware to drive the analog interface
remains, it's just that the components aren't installed. At least
that's how it used to be (the newer single sided cards might have more
of an optimization on the purely-digital cards, I'm not sure).
-- David
Subject:(usr-tc) FS:USR Modem Rack From: Brian <signal@shreve.net> Date: 1997-07-17 18:22:34
We have 12 USR Sportster 33.6 modems for sale, with a Clear-To-Send modem
rack, which holds 12 modems. This allows for a nice clean installation
for terminal servers that use serial boards etc. The rack uses a single
power supply to power all the modems, and is very nicely constructed.
$1500 obo
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Elfert <brian@citilink.com> writes:
> Can a digital only modem card use the NIC card, even if the RJ-11s won't
> work? I'd like to use just the serial port. I asked somebody about this
> before, and they said NICs only worked on analog/digital cards.
Yes, it should work fine. The "digital" versus "analog" really refers
to the "line" interface for the modem (either from a circuit card in
the chassis over the TDM bus, or from the RJ11 on an analog NIC), but
the DTE interface of all of the modem cards can either be on the
packet bus or out the NIC. They all default to using the NIC, until
actually connected to over the packet bus by another card, such as a
NETServer or EdgeServer.
> I'm been sorta thinking about replacing my netserver card with two PM25s
> so I can support OSPF, and some other cool stuff USR doesn't have.
Should work fine. If you already have the dual-function NICs (both
RS-232 and RJ11) they can be used, but if you are going to purchase
NICs, you can also purchase RS-232 only NICs. The fanout cables will
then give you 4 DB25s per NIC that you can interconnect with whatever
other serial device you want.
-- David
Thus spake Brian Elfert
>Can a digital only modem card use the NIC card, even if the RJ-11s won't
>work?
Workin' like a charm here.
>I'd like to use just the serial port. I asked somebody about this
>before, and they said NICs only worked on analog/digital cards.
They're wrong. :)
--
Jeff McAdams Email: jeffm@iglou.com
Senior Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
On Thu, 17 Jul 1997 10:31:55 +0200, Sergio Manzi <smz@gpnet.it> wrote:
>Question N.2:
>Will I be able to differentiate ISDN from V.34 calls and allow or not=20
>access based on the customer profile?
You can differentiate the two types of calls by using DNIS if your
telco supports it. Use TCM to edit your DNIS configuration on your
PRI/T1 card.
However, using RADIUS is probably a more flexible solution.
Regards,
Russ
Subject:(usr-tc) <CR> in Message Promp From: Steve Coleman <scoleman@csi2.csolutions.net> Date: 1997-07-18 13:54:38
How do you enter carriage returns for the message prompt feature on a
Netserver Imodem/8.
We want it to say.
Hello, welcome to whatever.
City, St,
Ph #.
Using the "set switched interface mod:1 message" command. What
character can I use to signify a carriage return?
Thanks
Steve
Subject:(usr-tc) MPIP scenerio From: Brian <signal@shreve.net> Date: 1997-07-18 15:13:05
If I have 3 USR TC hubs, can I set up MPIP as follows:
make hub #1 mpipserver, add hubs 1,2,3 to its clients table
make hubs #1 and #2 use #1 as there mpip server
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Radius logs -> msql db From: Tom Bilan <tom@tdi.net> Date: 1997-07-18 20:31:03
RadiusNT logs to my MS SQL6.5 server, I authenticate via
SQL too. The only problem is that USR uses a non-standard hex code
something-or-other that incorrectly logs the actual disconnect reason
BUT the acctsessionID and acctsessiontime are correct and that's what
I care about the most.
www.emerald.iea.com
Tom
At 04:59 PM 7/16/97 -0500, you wrote:
>Has anyone written any utilities to read in radius logs and put them in a
>msql database?
>
>Brian
>
>
>
>oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
>UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
>signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
>oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
>
Subject:Re: (usr-tc) Radius logs -> msql db From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-19 07:29:00
-> RadiusNT logs to my MS SQL6.5 server, I authenticate via
-> SQL too. The only problem is that USR uses a non-standard hex code
-> something-or-other that incorrectly logs the actual disconnect reason BUT
-> the acctsessionID and acctsessiontime are correct and that's what I care
-> about the most.
->
-> www.emerald.iea.com
->
-> Tom
Tom,
Can you use filters with RadiusNT and static IP addresses for users ? Those
are the two things keeping me from swihtcing from the USR provided software to
RadiusNT.
Jeff Binkley
ASA Network COmputing
Hi David Bolen,
> In order to flash new code onto a quad modem card, you either have to
> have an RS-232 NIC or an NMC card in the chassis. If you don't run
> with them normally and don't have an NMC, you could technically just
> plug a NIC in for the purposes of the download and then remove it.
thanks for your help. We had an USR Technician on site with an NMC card
who did the updgrade. He spent 8 hours on our USR TC, but the PPP
connections still last only some minutes. I guess it's a hardware
problem; USR tries to find out more.
Bye,
Lars
--
+-----------------------------------------------------------------+
| Lars Freund lars@forchheim.com |
| FOnLine Buergernetzverein: http://www.forchheim.baynet.de |
| http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html |
+-----------------------------------------------------------------+
Subject:Re: (usr-tc) Radius logs -> msql db From: Jim Hrdy <jhrdy@greensoft.com> Date: 1997-07-21 08:27:23
I know you can use static IP's, thats not a problem. It would depend
on what you are wanting to filter.
> -> RadiusNT logs to my MS SQL6.5 server, I authenticate via
> -> SQL too. The only problem is that USR uses a non-standard hex
> code -> something-or-other that incorrectly logs the actual
> disconnect reason BUT -> the acctsessionID and acctsessiontime are
> correct and that's what I care -> about the most. -> ->
> www.emerald.iea.com -> -> Tom
>
> Tom,
>
> Can you use filters with RadiusNT and static IP addresses for users
> ? Those are the two things keeping me from swihtcing from the USR
> provided software to RadiusNT.
>
> Jeff Binkley
> ASA Network COmputing
>
James B. Hrdy | email: jhrdy@greensoft.com
| web: http://www.greensoft.com
GreenSoft Solutions, Inc. | Voice: 913.843.8683
1617 St. Andrews Drive Suite 212 | Fax: 913.832.8234
Lawrence, Ks.
United States of America
Subject:(usr-tc) Can't get it to save... From: System Administrator <root@wingnet.net> Date: 1997-07-21 13:32:27
I've downloaded the new TC firmware and have so far upgraded my NMC
card and 3 modem cards.
The problem I'm running into (which I've run into several times) is
that I can't get changes on the card to "keep."
On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
several times with no success.
I select the entire modem card.
I change the setting on each channel of the card.
I click on the "Set" button.
I click on the "OK" button.
I go up to the "Actions/Commands" menu and choose "Save to NVRAM" and
execute the command.
I choose a "Software Reset" and execute the command.
When I go back into the modem card, my DTE Interface Source is
happily back to 'nic' with no evidence that it ever was changed.
I've mixed and matched the order of things above and have even exited
the software, choosing 'yes' to the save changes option. Still
nothing.
What am I missing?
WingNET System Administrator
423-559-LINK (v)
423-559-5444 (f)
Subject:Re: (usr-tc) Can't get it to save... From: Charles Hill <chill@ionet.net> Date: 1997-07-21 17:41:39
Enter these netserver commands:
set modem S5-S52 active
save all
reset s5-s52
That puts the modems on the packet bus.
-CH
On Mon, 21 Jul 1997, System Administrator wrote:
>
> I've downloaded the new TC firmware and have so far upgraded my NMC
> card and 3 modem cards.
>
> The problem I'm running into (which I've run into several times) is
> that I can't get changes on the card to "keep."
>
> On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
> several times with no success.
>
> I select the entire modem card.
> I change the setting on each channel of the card.
> I click on the "Set" button.
> I click on the "OK" button.
> I go up to the "Actions/Commands" menu and choose "Save to NVRAM" and
> execute the command.
> I choose a "Software Reset" and execute the command.
>
> When I go back into the modem card, my DTE Interface Source is
> happily back to 'nic' with no evidence that it ever was changed.
>
> I've mixed and matched the order of things above and have even exited
> the software, choosing 'yes' to the save changes option. Still
> nothing.
>
> What am I missing?
>
>
> WingNET System Administrator
> 423-559-LINK (v)
> 423-559-5444 (f)
>
>
Subject:(usr-tc) Can't get it to save... From: System Administrator <root@wingnet.net> Date: 1997-07-21 18:17:30
I've downloaded the new TC firmware and have so far upgraded my NMC
card and 3 modem cards.
The problem I'm running into (which I've run into several times) is
that I can't get changes on the card to "keep."
On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
several times with no success.
I select the entire modem card.
I change the setting on each channel of the card.
I click on the "Set" button.
I click on the "OK" button.
I go up to the "Actions/Commands" menu and choose "Save to NVRAM" and
execute the command.
I choose a "Software Reset" and execute the command.
When I go back into the modem card, my DTE Interface Source is
happily back to 'nic' with no evidence that it ever was changed.
I've mixed and matched the order of things above and have even exited
the software, choosing 'yes' to the save changes option. Still
nothing.
What am I missing?
WingNET System Administrator
423-559-LINK (v)
423-559-5444 (f)
Subject:(usr-tc) Can't get it to save... From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-21 18:55:00
-> I've downloaded the new TC firmware and have so far upgraded my NMC card and
-> 3 modem cards.
->
-> The problem I'm running into (which I've run into several times) is that I
-> can't get changes on the card to "keep."
->
-> On slot 13, I have changed the "DTE Interface Source" to 'packetbus' several
-> times with no success.
->
-> I select the entire modem card.
-> I change the setting on each channel of the card.
-> I click on the "Set" button.
-> I click on the "OK" button.
-> I go up to the "Actions/Commands" menu and choose "Save to NVRAM" and
-> execute the command.
-> I choose a "Software Reset" and execute the command.
->
-> When I go back into the modem card, my DTE Interface Source is
-> happily back to 'nic' with no evidence that it ever was changed.
-> I've mixed and matched the order of things above and have even exited the
-> software, choosing 'yes' to the save changes option. Still nothing.
->
-> What am I missing?
I had the same problem until I reset the PRI card and the Netserver.
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) MAJOR lag in USR hub From: Brian <signal@shreve.net> Date: 1997-07-21 21:43:22
One of our USR hubs all the sudden became VERY lagged. It took about 15
seconds to telnet into it, and was virtually unpingable ( I am talking
about the netserver card). I did a reset on the netserver card and now
all seems well.
Did anyone every see anything like this? (tcs 2.5.1).
Also is there anything along the lines of SYN floods and other Denial of
Service attacks that may work with the USR? If so, does anyone have any
Cisco filters that they can suggest to me.........
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Can't get it to save... From: Jeff Mcadams <jeffm@iglou.com> Date: 1997-07-21 22:07:31
Thus spake System Administrator
>I've downloaded the new TC firmware and have so far upgraded my NMC
>card and 3 modem cards.
>The problem I'm running into (which I've run into several times) is
>that I can't get changes on the card to "keep."
>On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
>several times with no success.
Uhm...telnet to the netserver, log in as !root and issue the command:
set modem s??-s?? active
save all
reset s??-s??
and your modems will be set to packetbus.
Yes, this is counter-intuitive.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
1: Is it possible to have more than 64 characters in the welcome
message? Can you make it display a text file, or call a subroutine for
a more detailed menu/login?
2: This is good: I can't get any USRobotics Sportster 33.6k modems to
connect to the Netserver. AT&T's work, Supra's Work, Couriers even
work. Does anyone know of an issue between Sportsters and Netserver
Imodem's? I am sure it's an init string. Should I change the default
init string on the Netserver, or do I need a special init for
Sportsters?
Any suggestions would be greatly appreciated.
Thanks
Steve Coleman
Computer Solutions
On Tue, 22 Jul 1997, Philip Diller wrote:
> After running a period of time our TC boxes allow users to log in, but boot
> them of after being on line for only about six seconds. The condition is
> remedied by rebooting the TC box. Then the condition will reoccur after a
> few hours or days.
>
> The chasses are full of quad modems running v1.5.10. Our users login with
> PAP over PPP. We authenticate with Merit Radius 2.4.23C and have recently
> enabled SNMP.
>
> The air temperature in our wiring closet is maintained at 16C and the air
> coming out of the chasses fans is around 25C.
>
> Any pointers on where to start hunting down this problem would be appreciated.
>
> Philip Diller
>
> usr-tc@xmission.comAt 10:07 PM 7/21/97 -0400, you wrote:
> >Thus spake System Administrator
> >>I've downloaded the new TC firmware and have so far upgraded my NMC
> >>card and 3 modem cards.
> >
> >>The problem I'm running into (which I've run into several times) is
> >>that I can't get changes on the card to "keep."
> >
> >>On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
> >>several times with no success.
> >
> >Uhm...telnet to the netserver, log in as !root and issue the command:
> >set modem s??-s?? active
> >save all
> >reset s??-s??
> >
> >and your modems will be set to packetbus.
> >
> >Yes, this is counter-intuitive.
> >--
> >Jeff McAdams Email: jeffm@iglou.com
> >Head Network Administrator Voice: (502) 966-3848
> >IgLou Internet Services (800) 436-4456
> >
> >
>
>
Phillip,
What version of code do you have on your NETServer? Your modem code is
old. USR releases TCS releases - the current version of code is
TCS 2.5.1 which includes NETServer 3.5.34, modem 5.6.6 etc. There is a
problem with old NETServer code and SNMP - which could cause the
NETServer to reboot. Let me know the version of code on your NETServer.
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Tue, 22 Jul 1997, Philip Diller wrote:
> Krish,
>
> I don't know how to lookup the TCS version.
> Our OS versions are 3.0.22 and 3.1.7
These are old versions of code. 3.1.7 NETServer was used on a 4 meg
NETServer.B
>
> I have read some of the list's archives, and sense that the problem may be
> due to short memory.
> sh memory reports 1296500.
> That seems to be an odd number. Does that mean there is only 1 MB on board?
> Would it help to add a 16MB SIMM?
>
The problem is not just memory, you have to upgrade to new code which
fixes the problem with snmp. Adding memory will not help. First you
have upgrade the card with new code. If you have a 4 meg NETServer which
it looks like - you must upgrade that NETServer with 3.3.x code - I
believe the code that fixes the problem with snmp is 3.3.42 - Please do
check with support at USR. Also if you want ot upgrade you card with
more memory, - say you want to use the 8 meg ISDN version of code - which
is 3.5.x which will also fix problems for you, you need to make sure that
your card is of proper hardware type and that all the necessary hardware
upgrades on your card is done. This can be done for you by USR support.
> The first stage of the problem is that the TCP layer dies, i.e we can no
> longer telnet to the NEtserver or get SNMP data. Then, in the second stage
> users are booted off after six seconds and we have to reboot to remedy.
>
This is a memory issue you are loosing memory. For now make sure that
you disable SNMP and do save all and reboot the card. That way you will
stop loosing memory.
> What is the code upgrade procedure?
>
Code can be upgraded using snmp or tcp. You can use the snmp manager (
TCM ) to logon to the NMC card and software download the code to the
NETServer. Alternatively you can also use the NETServer manager to logon
to the NETServer and download the code. The latest version of code is
available on the total service site. http://totalservice.usr.com
krish
> Philip
>
> At 05:24 AM 7/22/97 -0500, you wrote:
> >On Tue, 22 Jul 1997, Philip Diller wrote:
> >
> >> After running a period of time our TC boxes allow users to log in, but boot
> >> them of after being on line for only about six seconds. The condition is
> >> remedied by rebooting the TC box. Then the condition will reoccur after a
> >> few hours or days.
> >>
> >> The chasses are full of quad modems running v1.5.10. Our users login with
> >> PAP over PPP. We authenticate with Merit Radius 2.4.23C and have recently
> >> enabled SNMP.
> >>
> >> The air temperature in our wiring closet is maintained at 16C and the air
> >> coming out of the chasses fans is around 25C.
> >>
> >> Any pointers on where to start hunting down this problem would be
> appreciated.
> >>
> >> Philip Diller
> >>
> >> usr-tc@xmission.comAt 10:07 PM 7/21/97 -0400, you wrote:
> >>
> >>
> >Phillip,
> >
> >What version of code do you have on your NETServer? Your modem code is
> >old. USR releases TCS releases - the current version of code is
> >TCS 2.5.1 which includes NETServer 3.5.34, modem 5.6.6 etc. There is a
> >problem with old NETServer code and SNMP - which could cause the
> >NETServer to reboot. Let me know the version of code on your NETServer.
> >
> >
> >krish
> >-----------------------------------------
> > \ T.S.V. Krishnan \
> > \ Network System Engineer \ ( : - : )
> > \ 3Com ............ \
> > ----------------------------------------------/
> >tkrishna@bubba.ae.usr.com
> >----------------------------/ http://interproc.ae.usr.com ----/
> >-------------------------------------------------------------------------\
> > Any Sufficiently advanced bug is indistinguishable for a feature.
> > - Rick Kulawiec
> >-------------------------------------------------------------------------/
> >
> >
> >
>
>
On Tue, 22 Jul 1997, Jeff Binkley wrote:
>
>
> I've left this message before and haven't gotten a reply from anyone,
> including a 3com/USR person so I thought I'd try again one more time.
> Does anyone have instructions for moving the currect RADIUS software
> shipped with the TC product, part of the 2.5.1 suite of software, to an
> SQL backend ? I've seen mothing on the USR website or in any of the
> documentation. I am sure their larger customerss are doing this
> already. Do I need to get a 3rd party version of RADIUS ?
>
> Thanks in advance,
>
> Jeff Binkley
> ASA Network Computing
>
> (almost completely satisfied TC customer)
>
> CMPQwk 1.42 9999
>
3com/USR has Radius in two different OS. NT/WIN95 and UNIX (Solaris/HP)
based. The NT/Win95 use Access Data base. The unix version can uses
flat files or Postgress database - depending upon how you configure it.
Which one are you using? Also its not clear from this email when you say
SQL backend. Please give us more information.
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
Subject:(usr-tc) RADIUS SQL Support From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-22 08:10:00
I've left this message before and haven't gotten a reply from anyone,
including a 3com/USR person so I thought I'd try again one more time.
Does anyone have instructions for moving the currect RADIUS software
shipped with the TC product, part of the 2.5.1 suite of software, to an
SQL backend ? I've seen mothing on the USR website or in any of the
documentation. I am sure their larger customerss are doing this
already. Do I need to get a 3rd party version of RADIUS ?
Thanks in advance,
Jeff Binkley
ASA Network Computing
(almost completely satisfied TC customer)
CMPQwk 1.42 9999
Subject:Re: (usr-tc) Can't get it to save... From: Brian <signal@shreve.net> Date: 1997-07-22 09:37:29
On Mon, 21 Jul 1997, System Administrator wrote:
>
> I've downloaded the new TC firmware and have so far upgraded my NMC
> card and 3 modem cards.
>
> The problem I'm running into (which I've run into several times) is
> that I can't get changes on the card to "keep."
>
> On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
> several times with no success.
>
> I select the entire modem card.
> I change the setting on each channel of the card.
> I click on the "Set" button.
> I click on the "OK" button.
> I go up to the "Actions/Commands" menu and choose "Save to NVRAM" and
> execute the command.
> I choose a "Software Reset" and execute the command.
>
> When I go back into the modem card, my DTE Interface Source is
> happily back to 'nic' with no evidence that it ever was changed.
>
> I've mixed and matched the order of things above and have even exited
> the software, choosing 'yes' to the save changes option. Still
> nothing.
>
> What am I missing?
go into the NETSERVER card, and set the modems active. Doing this makes
them packetbus. Do not use TCM to set "packetbus", do this in the
netserver card by making the modems active.........
Brian
>
>
> WingNET System Administrator
> 423-559-LINK (v)
> 423-559-5444 (f)
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) RADIUS SQL Support From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-22 11:19:00
-> >
-> > I've left this message before and haven't gotten a reply from anyone, >
-> including a 3com/USR person so I thought I'd try again one more time. > Does
-> anyone have instructions for moving the currect RADIUS software > shipped
-> with the TC product, part of the 2.5.1 suite of software, to an > SQL
-> backend ? I've seen mothing on the USR website or in any of the >
-> documentation. I am sure their larger customerss are doing this > already.
-> Do I need to get a 3rd party version of RADIUS ?
-> >
-> > Thanks in advance,
-> >
-> > Jeff Binkley
-> > ASA Network Computing
-> >
-> > (almost completely satisfied TC customer)
-> >
-> > CMPQwk 1.42 9999
-> >
-> 3com/USR has Radius in two different OS. NT/WIN95 and UNIX (Solaris/HP)
-> based. The NT/Win95 use Access Data base. The unix version can uses flat
-> files or Postgress database - depending upon how you configure it. Which one
-> are you using? Also its not clear from this email when you say SQL backend.
-> Please give us more information.
->
-> krish
Ok. To be more specific. I am running WIndows NT 4.0 and would prefer not to
use Access 7.0 as the database since it doesn't scale well and makes remote
administration very difficult. I'd prefer to move the backend to MS SQL
Server or Sybase 11. I know there are third party RADIUS packages which do
this. I was wondering what 3Com/USR recommended. I've been looking at the
Access upsizing toolkit as one possible option.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) RADIUS SQL Support From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-22 11:19:00
-> >
-> > I've left this message before and haven't gotten a reply from anyone, >
-> including a 3com/USR person so I thought I'd try again one more time. > Does
-> anyone have instructions for moving the currect RADIUS software > shipped
-> with the TC product, part of the 2.5.1 suite of software, to an > SQL
-> backend ? I've seen mothing on the USR website or in any of the >
-> documentation. I am sure their larger customerss are doing this > already.
-> Do I need to get a 3rd party version of RADIUS ?
-> >
-> > Thanks in advance,
-> >
-> > Jeff Binkley
-> > ASA Network Computing
-> >
-> > (almost completely satisfied TC customer)
-> >
-> > CMPQwk 1.42 9999
-> >
-> 3com/USR has Radius in two different OS. NT/WIN95 and UNIX (Solaris/HP)
-> based. The NT/Win95 use Access Data base. The unix version can uses flat
-> files or Postgress database - depending upon how you configure it. Which one
-> are you using? Also its not clear from this email when you say SQL backend.
-> Please give us more information.
->
-> krish
Ok. To be more specific. I am running WIndows NT 4.0 and would prefer not to
use Access 7.0 as the database since it doesn't scale well and makes remote
administration very difficult. I'd prefer to move the backend to MS SQL
Server or Sybase 11. I know there are third party RADIUS packages which do
this. I was wondering what 3Com/USR recommended. I've been looking at the
Access upsizing toolkit as one possible option.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) Can't get it to save... From: Brian Elfert <brian@citilink.com> Date: 1997-07-22 11:47:44
On Mon, 21 Jul 1997, System Administrator wrote:
>
> I've downloaded the new TC firmware and have so far upgraded my NMC
> card and 3 modem cards.
>
> The problem I'm running into (which I've run into several times) is
> that I can't get changes on the card to "keep."
>
> On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
> several times with no success.
Go into the Netserver and set the modems to active. They should then
appear in TCM with packetbus enabled. I had this problem when I first got
my TC rack.
Brian
This is a multi-part message in MIME format.
--------------BC05EB3CA5FE8B378213811F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------BC05EB3CA5FE8B378213811F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <33D43475.4EF9243D@csolutions.net>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
1: Is it possible to have more than 64 characters in the welcome
message? Can you make it display a text file, or call a subroutine for
a more detailed menu/login?
2: This is good: I can't get any USRobotics Sportster 33.6k modems to
connect to the Netserver. AT&T's work, Supra's Work, Couriers even
work. Does anyone know of an issue between Sportsters and Netserver
Imodem's? I am sure it's an init string. Should I change the default
init string on the Netserver, or do I need a special init for
Sportsters?
Any suggestions would be greatly appreciated.
Thanks
Steve Coleman
Computer Solutions
--------------BC05EB3CA5FE8B378213811F--
Subject:(usr-tc) Users booted off From: Philip Diller <pdiller@asiaonline.net.tw> Date: 1997-07-22 13:47:37
After running a period of time our TC boxes allow users to log in, but boot
them of after being on line for only about six seconds. The condition is
remedied by rebooting the TC box. Then the condition will reoccur after a
few hours or days.
The chasses are full of quad modems running v1.5.10. Our users login with
PAP over PPP. We authenticate with Merit Radius 2.4.23C and have recently
enabled SNMP.
The air temperature in our wiring closet is maintained at 16C and the air
coming out of the chasses fans is around 25C.
Any pointers on where to start hunting down this problem would be appreciated.
Philip Diller
usr-tc@xmission.comAt 10:07 PM 7/21/97 -0400, you wrote:
>Thus spake System Administrator
>>I've downloaded the new TC firmware and have so far upgraded my NMC
>>card and 3 modem cards.
>
>>The problem I'm running into (which I've run into several times) is
>>that I can't get changes on the card to "keep."
>
>>On slot 13, I have changed the "DTE Interface Source" to 'packetbus'
>>several times with no success.
>
>Uhm...telnet to the netserver, log in as !root and issue the command:
>set modem s??-s?? active
>save all
>reset s??-s??
>
>and your modems will be set to packetbus.
>
>Yes, this is counter-intuitive.
>--
>Jeff McAdams Email: jeffm@iglou.com
>Head Network Administrator Voice: (502) 966-3848
>IgLou Internet Services (800) 436-4456
>
>
Subject:Re: (usr-tc) Radius logs -> msql db From: Tom Bilan <tom@tdi.net> Date: 1997-07-22 15:44:09
If you run Emerald then yes, you can assign any radius attributes to a
particular Login name. It's even smart enough to make sure someone isn't
logged already before it lets them in. (user using 2 lines...)
I'm not the one who designed it or anything, I run it here and I'm in
the middle of setting it up. It's a small company that makes the software
so support is kinda tough but over all I love it.
Tom
At 07:29 AM 7/19/97 -0500, you wrote:
>-> RadiusNT logs to my MS SQL6.5 server, I authenticate via
>-> SQL too. The only problem is that USR uses a non-standard hex code
>-> something-or-other that incorrectly logs the actual disconnect reason BUT
>-> the acctsessionID and acctsessiontime are correct and that's what I care
>-> about the most.
>->
>-> www.emerald.iea.com
>->
>-> Tom
>
>Tom,
>
>Can you use filters with RadiusNT and static IP addresses for users ? Those
>are the two things keeping me from swihtcing from the USR provided
software to
>RadiusNT.
>
> Jeff Binkley
> ASA Network COmputing
>
>
Use carats (shift 6) for carriage return, as in the following command
used for a Netserver in a TCM box-
set s62 message Welcome to Cybergate!^^^tspsl3 port=62
will appear as
Welcome to Cybergate!
tspsl3 port=62
On Fri, 18 Jul 1997, Steve Coleman wrote:
> How do you enter carriage returns for the message prompt feature on a
> Netserver Imodem/8.
>
> We want it to say.
>
> Hello, welcome to whatever.
>
> City, St,
>
> Ph #.
>
> Using the "set switched interface mod:1 message" command. What
> character can I use to signify a carriage return?
>
> Thanks
>
> Steve
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Casey Cook * CyberGate Operations * caseyc@gate.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject:(usr-tc) 3.5.34 makes my netserver ethernet lockup From: Tom Bilan <tom@tdi.net> Date: 1997-07-22 16:32:19
It can take 4 hours or 4 days but eventually the one ENH I upgraded
to 3.5.34 will lock out the ethernet port. I can still get access to
it via console but it won't ping in/out or telnet etc.
ENH3 Command> ver
U.S. Robotics
Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34
Build date: Jun 19 1997
Build time: 14:02:28
Network Interface Card: Ethernet & Frame Relay Combination (26)
ISDN Interface Card : MUNICH32 (4)
Packet Bus Circuit : Standard
Licensed for 60 ports.
ENH3 Command> show mem
Total physical RAM: 20480 kb
Total physical FLASH: 2048 kb
System memory 17429139 bytes - 6250160 used, 11178979 available
Free blocks (block_size:count): 32:15 48:0 80:0 128:0 144:0 160:0 176:0
240:1 27
2:1 1984:0
Real Available Memory: 11179971
System nbufs 1000 - 11 used, 989 available
ENH3 Command>
I always have a ton of memory available so I don't know what the problem is.
Anyone else seen this phenomenon?
Thanks,
Tom Bilan
Subject:Re: (usr-tc) Users booted off From: Philip Diller <pdiller@asiaonline.net.tw> Date: 1997-07-22 18:49:13
Krish,
I don't know how to lookup the TCS version.
Our OS versions are 3.0.22 and 3.1.7
I have read some of the list's archives, and sense that the problem may be
due to short memory.
sh memory reports 1296500.
That seems to be an odd number. Does that mean there is only 1 MB on board?
Would it help to add a 16MB SIMM?
The first stage of the problem is that the TCP layer dies, i.e we can no
longer telnet to the NEtserver or get SNMP data. Then, in the second stage
users are booted off after six seconds and we have to reboot to remedy.
What is the code upgrade procedure?
Philip
At 05:24 AM 7/22/97 -0500, you wrote:
>On Tue, 22 Jul 1997, Philip Diller wrote:
>
>> After running a period of time our TC boxes allow users to log in, but boot
>> them of after being on line for only about six seconds. The condition is
>> remedied by rebooting the TC box. Then the condition will reoccur after a
>> few hours or days.
>>
>> The chasses are full of quad modems running v1.5.10. Our users login with
>> PAP over PPP. We authenticate with Merit Radius 2.4.23C and have recently
>> enabled SNMP.
>>
>> The air temperature in our wiring closet is maintained at 16C and the air
>> coming out of the chasses fans is around 25C.
>>
>> Any pointers on where to start hunting down this problem would be
appreciated.
>>
>> Philip Diller
>>
>> usr-tc@xmission.comAt 10:07 PM 7/21/97 -0400, you wrote:
>>
>>
>Phillip,
>
>What version of code do you have on your NETServer? Your modem code is
>old. USR releases TCS releases - the current version of code is
>TCS 2.5.1 which includes NETServer 3.5.34, modem 5.6.6 etc. There is a
>problem with old NETServer code and SNMP - which could cause the
>NETServer to reboot. Let me know the version of code on your NETServer.
>
>
>krish
>-----------------------------------------
> \ T.S.V. Krishnan \
> \ Network System Engineer \ ( : - : )
> \ 3Com ............ \
> ----------------------------------------------/
>tkrishna@bubba.ae.usr.com
>----------------------------/ http://interproc.ae.usr.com ----/
>-------------------------------------------------------------------------\
> Any Sufficiently advanced bug is indistinguishable for a feature.
> - Rick Kulawiec
>-------------------------------------------------------------------------/
>
>
>
Subject:(usr-tc) TC From: Tim Buchalka <tim@newave.net.au> Date: 1997-07-22 19:57:00
I have a perplexing problem with our x2 enabled TC Chassis.
We had Quad Analog modems, with Dual PRI card, Edgeserver card, and
Netserver card.
On a seemingly random basis, either a busy signal is returned or worse,
'nothing at all' (and the call does not connect).
Sometimes take 5-6 re-tries before I get a connection.
Any ideas please?
Am running PRI version 2.5.90
Quad Digital/Analog version 5.5.6
NMC Version 4.3.8
TIA
Tim Buchalka
Subject:(usr-tc) Freezing ethernets From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-23 16:39:09
Two of my TC's have exhibited similar behavior with 3.5.34 on the
Netservers. The ethernet will freeze, but not the server itself. You can
still talk to the server via a modem or the console. It takes a reboot of
the Netserver to fix the problem, "reset net0" does nothing.
Subject:(usr-tc) ISDN on Quad Modems From: root@artoo.agetech.net Date: 1997-07-23 21:10:55
Can the ISDN calls be moved to the quad modems? I noticed today that if I set the ISDN-GW to 0 on the PRI
card it works. However a few users had problems. I noticed there are some settings on the modems for this.
Is there any reason not to do this? What settings can I use on the modems to make them more compatible? Will it be better to just leave it on the PRI card?
Just wondering..
Elio Fuentes
emf@agetech.net
(I kind of like the fact that the modems light turn on when the ISDN calls are in that way you can see quickly
how many people are on)
Subject:(usr-tc) alive From: Brian <signal@shreve.net> Date: 1997-07-24 08:35:57
is anyone still on this list?
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) List nukage and ethernet blockage From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-24 11:27:40
Majordomo has an unfortunate side-effect of eating mailing lists, and
usr-tc got hit on the 22nd. Because of this, I make nightly backups, but I
just barely realized what happened today. The list has been restored.
Here's a couple of messages that people may have missed:
>From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
On Tue, 22 Jul 1997, Jeff Binkley wrote:
>
>
> I've left this message before and haven't gotten a reply from anyone,
> including a 3com/USR person so I thought I'd try again one more time.
> Does anyone have instructions for moving the currect RADIUS software
> shipped with the TC product, part of the 2.5.1 suite of software, to an
> SQL backend ? I've seen mothing on the USR website or in any of the
> documentation. I am sure their larger customerss are doing this
> already. Do I need to get a 3rd party version of RADIUS ?
>
> Thanks in advance,
>
> Jeff Binkley
> ASA Network Computing
>
> (almost completely satisfied TC customer)
>
> CMPQwk 1.42 9999
>
3com/USR has Radius in two different OS. NT/WIN95 and UNIX (Solaris/HP)
based. The NT/Win95 use Access Data base. The unix version can uses
flat files or Postgress database - depending upon how you configure it.
Which one are you using? Also its not clear from this email when you say
SQL backend. Please give us more information.
>From: Pete Ashdown <pashdown@xmission.com>
Two of my TC's have exhibited similar behavior with 3.5.34 on the
Netservers. The ethernet will freeze, but not the server itself. You can
still talk to the server via a modem or the console. It takes a reboot of
the Netserver to fix the problem, "reset net0" does nothing.
Subject:(usr-tc) USR Radius 4.3 - help From: Steve Coleman <scoleman@csolutions.net> Date: 1997-07-24 13:18:04
I can't get USR's RADIUS 4.3 for NT to generate any accounting reports.
We are using Netserver's as Radius clients. Whenever I try and generate
an accounting report (such as calls by port) it generates a report with
a bunch of "#ERROR" messages where there should be data. This is a
fresh installation and no changes have been made to the database. Some
of the call activity reports do work. Any ideas?
Steve
Subject:Re: (usr-tc) TC From: Brian <signal@shreve.net> Date: 1997-07-24 13:38:37
On Tue, 22 Jul 1997, Tim Buchalka wrote:
> I have a perplexing problem with our x2 enabled TC Chassis.
>
> We had Quad Analog modems, with Dual PRI card, Edgeserver card, and
> Netserver card.
>
> On a seemingly random basis, either a busy signal is returned or worse,
> 'nothing at all' (and the call does not connect).
>
> Sometimes take 5-6 re-tries before I get a connection.
>
> Any ideas please?
>
> Am running PRI version 2.5.90
> Quad Digital/Analog version 5.5.6
> NMC Version 4.3.8
make sure that line interface is priTdm on all modems.
make sure DTE settings have "packetbus" and not "nic"
make sure Call Control options have "packet bus answer only" enable
make sure all modems are set active in netserver
Brian
>
> TIA
>
>
> Tim Buchalka
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
On Tue, 22 Jul 1997, Jeff Binkley wrote:
> -> >
> -> > I've left this message before and haven't gotten a reply from anyone, >
> -> including a 3com/USR person so I thought I'd try again one more time. > Does
> -> anyone have instructions for moving the currect RADIUS software > shipped
> -> with the TC product, part of the 2.5.1 suite of software, to an > SQL
> -> backend ? I've seen mothing on the USR website or in any of the >
> -> documentation. I am sure their larger customerss are doing this > already.
> -> Do I need to get a 3rd party version of RADIUS ?
> -> >
> -> > Thanks in advance,
> -> >
> -> > Jeff Binkley
> -> > ASA Network Computing
> -> >
> -> > (almost completely satisfied TC customer)
> -> >
> -> > CMPQwk 1.42 9999
> -> >
> -> 3com/USR has Radius in two different OS. NT/WIN95 and UNIX (Solaris/HP)
> -> based. The NT/Win95 use Access Data base. The unix version can uses flat
> -> files or Postgress database - depending upon how you configure it. Which one
> -> are you using? Also its not clear from this email when you say SQL backend.
> -> Please give us more information.
> ->
> -> krish
>
> Ok. To be more specific. I am running WIndows NT 4.0 and would prefer not to
> use Access 7.0 as the database since it doesn't scale well and makes remote
> administration very difficult. I'd prefer to move the backend to MS SQL
> Server or Sybase 11. I know there are third party RADIUS packages which do
> this. I was wondering what 3Com/USR recommended. I've been looking at the
> Access upsizing toolkit as one possible option.
>
> Jeff Binkley
> ASA Network Computing
Currently the only data base we support on this platform is Access.
We have been working on moving to other databases like Oracle which
should be a near thing in the future. We prefer that you use our Radius
Server - but that is upto you on what Radius Server you want to use.
We do not recommend any other Radius than our Radius server.
However personally I would prefer either Oracle or Sybase than MS SQL.
krish
>
Subject:Re: (usr-tc) TC From: David Bolen <db3l@ans.net> Date: 1997-07-24 16:42:23
"Tim Buchalka" <tim@newave.net.au> writes:
> Any ideas please?
I would suggest enabling the call event traps on your PRI card if you
haven't already and observing them. There are traps for call arrival,
connection to a modem or gateway device, failure to connect to the
same, and call termination.
Log those traps (with TCM or whatever you want) and analyze them
during a period of time when you are having a failure. If the problem
is external to your equipment you won't see any failure to deliver
calls within the hub and you can go talk to your telco about their
inter-office trunking or something :-)
If the problem is within the hub, you'll see "callArriveEvent" traps
from the card, followed by a "callTermFailedEvent" event (as opposed
to a "callConnectEvent" and "callTermNormalEvent" event pair).
The callTermFailedEvent will contain objects in the variable bindings
that provide some additional information, such as if the failure was
due to the unavailability of modems, some communication problem with
an internal device, etc..
This won't necessarily go all the way to exactly where the problem is
but it's a good first order division of where it is showing up.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) List nukage and ethernet blockage From: David Bolen <db3l@ans.net> Date: 1997-07-24 17:31:31
Pete Ashdown <pashdown@xmission.com> writes:
> Two of my TC's have exhibited similar behavior with 3.5.34 on the
> Netservers. The ethernet will freeze, but not the server itself. You can
> still talk to the server via a modem or the console. It takes a reboot of
> the Netserver to fix the problem, "reset net0" does nothing.
I have seen this behavior (along with some reboots) but only on 8MB
older ("Rev I") cards .. are those the type of cards that you are
encountering this problem on? I haven't seen any difficulties on the
newer EPB cards.
I think there may be something going on with the ethernet driver -
since the NIC hardware is the same in both cases it may be related to
the amount of memory, but it's not clear yet.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Can't get it to save... From: Laurel Mitro <laurel@drfast.net> Date: 1997-07-24 17:57:46
This is a multi-part message in MIME format.
------=_NextPart_000_01BC985B.177C4FC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
BTW did you do a system reset/reboot from TC manager? Will knock current =
sessions off but does seem to "burn" the code into the cards
Which firmware update? Is it the new 3.5.xx Netserver code? I was told =
once by a USR/3com tech that the upgrade would help many speed related =
issues.(First ping allways timing out, lattency with quake etc.) I =
download the PDF file but it would'nt read right with the Adobe that =
came shiped with the TC CD-documentation.
What does the upgrade actually do, and is it safe.
Mike, AE
DrFast.Net
----
I've downloaded the new TC firmware and have so far upgraded my NMC
card and 3 modem cards.
The problem I'm running into (which I've run into several times) is
that I can't get changes on the card to "keep."
WingNET System Administrator
423-559-LINK (v)
423-559-5444 (f)
------=_NextPart_000_01BC985B.177C4FC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
<HTML>
<HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR>
</HEAD>
<BODY><FONT face=3DArial size=3D2>
<P>BTW did you do a system reset/reboot from TC manager? Will knock =
current=20
sessions off but does seem to "burn" the code into the =
cards</P>
<P>Which firmware update? Is it the new 3.5.xx Netserver code? I was =
told once=20
by a USR/3com tech that the upgrade would help many speed related =
issues.(First=20
ping allways timing out, lattency with quake etc.) I download the PDF =
file but=20
it would'nt read right with the Adobe that came shiped with the TC=20
CD-documentation.
<P>What does the upgrade actually do, and is it safe.
<P>Mike, AE
<P>DrFast.Net
<P>
<P> </P>
----<BR>
<B>From: </B>System Administrator <root@wingnet.net><BR>
<B>To: </B>usr-tc@mail.xmission.com<BR>
<B>Date: </B>Thursday, July 24, 1997 9:38 AM<BR>
<B>Subject: </B>(usr-tc) Can't get it to save...<BR>
<BR>
<HTML><BODY><FONT size=3D2><BR>
I've downloaded the new TC firmware and have so far upgraded my NMC<BR>
card and 3 modem cards.<BR>
<BR>
The problem I'm running into (which I've run into several times) is<BR>
that I can't get changes on the card to "keep."<BR>
<BR>
WingNET System Administrator<BR>
423-559-LINK (v)<BR>
423-559-5444 (f)<BR>
<BR>
</FONT></FONT>
</BODY></HTML>
------=_NextPart_000_01BC985B.177C4FC0--
Subject:Re: (usr-tc) List nukage and ethernet blockage From: Charles Hill <chill@ionet.net> Date: 1997-07-25 10:23:57
> Pete Ashdown <pashdown@xmission.com> writes:
> I have seen this behavior (along with some reboots) but only on 8MB
> older ("Rev I") cards .. are those the type of cards that you are
> encountering this problem on? I haven't seen any difficulties on the
> newer EPB cards.
>
> I think there may be something going on with the ethernet driver -
> since the NIC hardware is the same in both cases it may be related to
> the amount of memory, but it's not clear yet.
I have also seen this behavior and the card revision is definitely part of
it. The offending cards always have the FC-3 chip. The 3.5.x netserver
code is also a common thread.
-CH
Subject:Re: (usr-tc) List nukage and ethernet blockage From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-25 13:03:54
David Bolen said once upon a time:
>Pete Ashdown <pashdown@xmission.com> writes:
>
>> Two of my TC's have exhibited similar behavior with 3.5.34 on the
>> Netservers. The ethernet will freeze, but not the server itself. You can
>> still talk to the server via a modem or the console. It takes a reboot of
>> the Netserver to fix the problem, "reset net0" does nothing.
>
>I have seen this behavior (along with some reboots) but only on 8MB
>older ("Rev I") cards .. are those the type of cards that you are
>encountering this problem on? I haven't seen any difficulties on the
>newer EPB cards.
Nope. These are 16 meg. Here's a "version" from one that has problems:
U.S. Robotics
Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34
Build date: Jun 19 1997
Build time: 14:02:28
Network Interface Card: Ethernet & Frame Relay Combination (26)
ISDN Interface Card : MUNICH32 (4)
Packet Bus Circuit : Standard
Total physical RAM: 20480 kb
Total physical FLASH: 2048 kb
Subject:Re: (usr-tc) MAJOR lag in USR hub From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-25 13:07:51
Brian said once upon a time:
>
>One of our USR hubs all the sudden became VERY lagged. It took about 15
>seconds to telnet into it, and was virtually unpingable ( I am talking
>about the netserver card). I did a reset on the netserver card and now
>all seems well.
>
>Did anyone every see anything like this? (tcs 2.5.1).
I've seen it happen as well. I wonder what USR calls beta testing. The
ethernet freezing and the lag problem happened in the first two weeks of
running 2.5.1. I'm just about to go back to 3.3.34.
Subject:(usr-tc) Memory on Netserver card From: Brian Elfert <brian@citilink.com> Date: 1997-07-25 14:18:03
I have a PRI Netserver card here that is supposed to have 16 megs of RAM
on it.
When I do a show mem, it shows a total of 8 megs, and system memory of 4
megs. Should I be worried that I didn't really get a 16MB netserver card?
I'm runnng 3.5.34 is that matters.
Brian
Subject:Re: (usr-tc) List nukage and ethernet blockage From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-25 16:43:09
David Bolen said once upon a time:
>Hmm, but although it's got the added memory, it is an older card:
>
>> Packet Bus Circuit : Standard
I thought there was some discussion about this earlier this year. I bought
these cards in January. A USR person on the list said that there wasn't
anything really different between the Standard and the Advanced packet-bus
circuits.
>For now I've also backed off of 3.5 on such cards.
I'm about to do that as well.
Subject:Re: (usr-tc) List nukage and ethernet blockage From: David Bolen <db3l@ans.net> Date: 1997-07-25 18:13:34
Pete Ashdown <pashdown@xmission.com> writes:
> Nope. These are 16 meg. Here's a "version" from one that has problems:
Hmm, but although it's got the added memory, it is an older card:
> Packet Bus Circuit : Standard
This was the same card type I had problems with although mine had the
original 8MB instead of the 16MB SIMM.
The card itself isn't a guarantee of failure (I've a number that have
run fine for long durations) but when I did have failures, it was on
this platform.
For now I've also backed off of 3.5 on such cards.
-- David
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Brian <signal@shreve.net> Date: 1997-07-25 19:10:10
On Tue, 22 Jul 1997, Tom Bilan wrote:
> It can take 4 hours or 4 days but eventually the one ENH I upgraded
> to 3.5.34 will lock out the ethernet port. I can still get access to
> it via console but it won't ping in/out or telnet etc.
>
> ENH3 Command> ver
> U.S. Robotics
> Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34
> Build date: Jun 19 1997
> Build time: 14:02:28
>
> Network Interface Card: Ethernet & Frame Relay Combination (26)
> ISDN Interface Card : MUNICH32 (4)
> Packet Bus Circuit : Standard
>
> Licensed for 60 ports.
> ENH3 Command> show mem
> Total physical RAM: 20480 kb
> Total physical FLASH: 2048 kb
>
> System memory 17429139 bytes - 6250160 used, 11178979 available
> Free blocks (block_size:count): 32:15 48:0 80:0 128:0 144:0 160:0 176:0
> 240:1 27
> 2:1 1984:0
> Real Available Memory: 11179971
> System nbufs 1000 - 11 used, 989 available
> ENH3 Command>
>
> I always have a ton of memory available so I don't know what the problem is.
>
> Anyone else seen this phenomenon?
happens to us too..............ever since tcs 2.5.1
>
> Thanks,
> Tom Bilan
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) List nukage and ethernet blockage From: Brian <signal@shreve.net> Date: 1997-07-25 19:13:03
On Fri, 25 Jul 1997, Pete Ashdown wrote:
> David Bolen said once upon a time:
>
> >Pete Ashdown <pashdown@xmission.com> writes:
> >
> >> Two of my TC's have exhibited similar behavior with 3.5.34 on the
> >> Netservers. The ethernet will freeze, but not the server itself. You can
> >> still talk to the server via a modem or the console. It takes a reboot of
> >> the Netserver to fix the problem, "reset net0" does nothing.
> >
> >I have seen this behavior (along with some reboots) but only on 8MB
> >older ("Rev I") cards .. are those the type of cards that you are
> >encountering this problem on? I haven't seen any difficulties on the
> >newer EPB cards.
>
> Nope. These are 16 meg. Here's a "version" from one that has problems:
I think its safe to say there is a serious problem with netserver code
3.5.34, since this has happened to several on this list since upgrading
and never before.
Brian
>
> U.S. Robotics
> Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34
> Build date: Jun 19 1997
> Build time: 14:02:28
>
> Network Interface Card: Ethernet & Frame Relay Combination (26)
> ISDN Interface Card : MUNICH32 (4)
> Packet Bus Circuit : Standard
>
> Total physical RAM: 20480 kb
> Total physical FLASH: 2048 kb
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) MAJOR lag in USR hub From: Brian <signal@shreve.net> Date: 1997-07-25 19:13:54
On Fri, 25 Jul 1997, Pete Ashdown wrote:
> Brian said once upon a time:
> >
> >One of our USR hubs all the sudden became VERY lagged. It took about 15
> >seconds to telnet into it, and was virtually unpingable ( I am talking
> >about the netserver card). I did a reset on the netserver card and now
> >all seems well.
> >
> >Did anyone every see anything like this? (tcs 2.5.1).
>
> I've seen it happen as well. I wonder what USR calls beta testing. The
> ethernet freezing and the lag problem happened in the first two weeks of
> running 2.5.1. I'm just about to go back to 3.3.34.
>
They need this fixed asap, we don't spend hundreds of thousands of dollars
for this...............
This is a NEW problem and needs priority treatment.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) List nukage and ethernet blockage From: David Bolen <db3l@ans.net> Date: 1997-07-25 20:31:55
Brian <signal@shreve.net> writes:
> I think its safe to say there is a serious problem with netserver code
> 3.5.34, since this has happened to several on this list since upgrading
> and never before.
Well, I do think it depends on your environment, and may be a
combination of things going on, or something that 3.5 is just now
bringing to light.
I've had no real issues with 3.5.34 running as part of a TCS 2.5.1
installation that involved EPB NETServers (and that's for a few
thousand cards). I have however, definitely seem some issues with
3.5.34 on the older card platform - enough so that I backed out to
3.3.x (I chose not to run 3.4.x in general, but the cards have 8MB
anyway so that's not even an option).
It's not entirely clear what is going on because even those earlier
releases of the 8MB code (back to 3.2.x, which had been running find
on the same cards for months) present some new problems (such as
rebooting) when run in a chassis with the rest of TCS 2.5.1. Now in
my case I wasn't running TCS 2.0 or 2.5 modem code in these chassis'
so it may be that the stress of the newer higher performing modem code
is just exacerbating some issues that would have shown up eventually.
I think it's safe to say that there is some interdependency going on,
but the tricky part is to figure out just what it is, and if something
pre-existing is now just being tickled, or if it's something new.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) List nukage and ethernet blockage From: David Bolen <db3l@ans.net> Date: 1997-07-25 20:40:54
Pete Ashdown <pashdown@xmission.com> writes:
> I thought there was some discussion about this earlier this year. I bought
> these cards in January. A USR person on the list said that there wasn't
> anything really different between the Standard and the Advanced packet-bus
> circuits.
It depends on what you mean by "different". If you mean in terms of
performance, then no, there really isn't anything particularly
"enhanced" about the enhanced packet bus in terms of aggregate system
throughput or anything.
But if you mean in terms of the hardware, then definitely - the EPB
card is a new design (the same base card is also used for the
EdgeServer), and is in effect a new generation of a slot based PC
platform, so in many ways its cleaner.
There's nothing inherently wrong with the older card platform though
(I've used an awful lot of them for years now) but depending on their
age (January seems pretty recent) they do tend to need some
engineering fixes to keep up with newer system code releases, so over
time I've had a reasonable churn of cards that fail for some reason,
go back to USR and they apply changes as part of the fix process.
I have seen problems in the past that affected one type of card over
the other. I guess there's more related to the older cards (although
there have also been EPB specific issues) but overall its probably a wash.
The EPBs were just coming online at the start of this year, which is
probably why they weren't quite available in quantity yet at the time
you got your cards.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) List nukage and ethernet blockage From: Bob Purdon <bobp@southcom.com.au> Date: 1997-07-26 10:58:02
> I think its safe to say there is a serious problem with netserver code
> 3.5.34, since this has happened to several on this list since upgrading
> and never before.
Must be 3.5.34 specific as we're running 3.5.33 on two of our servers,
both with the "Standard" packet bus, and no problems so far (after several
weeks).
Regards,
Bob Purdon,
Technical Manager,
Southern Internet Services.
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: William M Sheeler Sr <tcra@talon.net> Date: 1997-07-26 12:10:14
At 07:10 PM 7/25/97 -0500, you wrote:
>On Tue, 22 Jul 1997, Tom Bilan wrote:
>
>> It can take 4 hours or 4 days but eventually the one ENH I upgraded
>> to 3.5.34 will lock out the ethernet port. I can still get access to
>> it via console but it won't ping in/out or telnet etc.
>>
>> ENH3 Command> ver
>> U.S. Robotics
>> Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34
>> Build date: Jun 19 1997
>> Build time: 14:02:28
>>
>> Network Interface Card: Ethernet & Frame Relay Combination (26)
>> ISDN Interface Card : MUNICH32 (4)
>> Packet Bus Circuit : Standard
>>
>> Licensed for 60 ports.
>> ENH3 Command> show mem
>> Total physical RAM: 20480 kb
>> Total physical FLASH: 2048 kb
>>
>> System memory 17429139 bytes - 6250160 used, 11178979 available
>> Free blocks (block_size:count): 32:15 48:0 80:0 128:0 144:0 160:0 176:0
>> 240:1 27
>> 2:1 1984:0
>> Real Available Memory: 11179971
>> System nbufs 1000 - 11 used, 989 available
>> ENH3 Command>
>>
>> I always have a ton of memory available so I don't know what the problem
is.
>>
>> Anyone else seen this phenomenon?
>happens to us too..............ever since tcs 2.5.1
>
>
Brian:
My Racks have been up for 9days 4+hours with No problems.
Hardware ver Card Software ver DRAM Flash
4.0 PRI 2.5.3 4096 1024
3.0 Modems 5.6.6
7.0.0 Netserver 3.5.34 20480 2048
3.0 NMC 4.3.8 4096 2048
Both working fine (knock on wood). These are new units, purchased 6/97
Been running and operational for about 2weeks now. Lots of users coming in
and hammering, with no ill effects.
I have experienced no lost of ethernet at all.
Are your conditions the same as mine?
Let me know
TTFN
Bill
>>
>> Thanks,
>> Tom Bilan
>>
>
>
>oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
>UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
>signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
>oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
>
>
William M Sheeler, Sr www.talon.net
ceo
TCRA Computers and voice 610.670.6491
TALON Network Services, Inc voice 610.670.4923
Fax for both fax 610.670.6495
( Total Area Linked Online Nationwide Network Services, Inc)
" Live with Passion "
" It's in your moments of decision that your destiny is shaped "
ANTHONY ROBBINS
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Brian Elfert <brian@citilink.com> Date: 1997-07-26 15:16:12
On Sat, 26 Jul 1997, William M Sheeler Sr wrote:
> Both working fine (knock on wood). These are new units, purchased 6/97
>
> Been running and operational for about 2weeks now. Lots of users coming in
> and hammering, with no ill effects.
>
> I have experienced no lost of ethernet at all.
>
> Are your conditions the same as mine?
You may have the newer 'enhanced packet bus' Netserver card which doesn't
have the problem. Also, I have the slightly older 'standard packet bus'
Netserver card purchased 4/97, and I don't have the problem. Somebody
mentioned that there have been many revs of the hardware for the older
Netserver card, and that the most recent cards might not see the problem.
I think you'll be fine.
Brian
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Brian <signal@shreve.net> Date: 1997-07-26 19:09:25
On Sat, 26 Jul 1997, Brian Elfert wrote:
>
>
> On Sat, 26 Jul 1997, William M Sheeler Sr wrote:
>
> > Both working fine (knock on wood). These are new units, purchased 6/97
> >
> > Been running and operational for about 2weeks now. Lots of users coming in
> > and hammering, with no ill effects.
> >
> > I have experienced no lost of ethernet at all.
> >
> > Are your conditions the same as mine?
>
> You may have the newer 'enhanced packet bus' Netserver card which doesn't
> have the problem. Also, I have the slightly older 'standard packet bus'
> Netserver card purchased 4/97, and I don't have the problem. Somebody
> mentioned that there have been many revs of the hardware for the older
> Netserver card, and that the most recent cards might not see the problem.
>
> I think you'll be fine.
>
> Brian
>
>
Most of the hubs here ARE Standard packet bus's, and we DO see the problem
(on Standard pb units).
This is totally unacceptable. Users dial in, and cant get PPP, takes me
30 min before I am notified, and able to reboot the unit, this has been
going on now since the upgrade to 2.5.1. My users are pissed, and I am
starting to get a bad rap.
USR gets a bad rap also, because its there x2 modems my users will be
blaming the problem on.
Does Anyone know the status of this? Is this problem officially
acknowledged by USR? I think we have done all the "field testing" to show
that Standard packet bus netservers nics lock up with this new code.
I hope this gets priority treatment, and we see a fix REAL soon.
What are you all doing about this? Did you fall back to a older code rev?
If so, what is safe to fallback too? (Framed-Route is very important too
us, and I don't need 500 users complaining of Quake lag either if it can
be avoided).
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) snmpwalk mib examples From: Brian <signal@shreve.net> Date: 1997-07-28 09:39:37
I have the latest version of the cmu-snmp utils, and i also have all the
nmc mib files on my unix box.
Can someone give me a quick example of how to get snmpwalk to use the
usr mibs when reading nmc info? I thought you would just set MIBFILE to
the path of where the mibs are and snmpwalk hostname string
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
This is a multi-part message in MIME format.
------=_NextPart_000_01BC9B50.994ED2A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
We've been running a PRI based TC since June 6th on the same subnet that =
our Livingston is connected to. When you ping any site via a modem or =
ISDN connection from the USR TC the first ping times out. This doesn't =
happen on our PM3.=20
It seems that there is always a noticeable delay before the request =
finds it's way from the modem out to the default gateway. Am I missing =
something in the setup?=20
USR Tech support has been rather weak, they only recommended flashing to =
3.5.34 but after reading all of the things here, I don't think its worth =
it unless it does fix somthing tangible.
Any Ideas?
Thanks Mike Hamrich, AE
DrFast.Net
------=_NextPart_000_01BC9B50.994ED2A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR>
</HEAD>
<BODY>
<P><FONT face=3DArial size=3D2>We've been running a PRI based TC since =
June 6th on=20
the same subnet that our Livingston is connected to. When you ping any =
site via=20
a modem or ISDN connection from the USR TC the first ping times out. =
This=20
does</FONT><FONT face=3DArial size=3D2>n't happen on our PM3. </FONT>
<P><FONT face=3DArial size=3D2>It seems that there is always a =
noticeable delay=20
before the request finds it's way from the modem out to the default =
gateway. Am=20
I missing something in the setup? </FONT>
<P><FONT face=3DArial size=3D2>USR Tech support has been rather weak, =
they only=20
recommended flashing to 3.5.34 but after reading all of the things here, =
I don't=20
think its worth it unless it does fix somthing tangible.</FONT>
<P><FONT face=3DArial size=3D2>Any Ideas?</FONT>
<P><FONT face=3DArial size=3D2>Thanks Mike Hamrich, AE</FONT>
<P><FONT face=3DArial size=3D2>DrFast.Net</FONT></P>
</BODY></HTML>
------=_NextPart_000_01BC9B50.994ED2A0--
Hello everyone,
I have a USR MP/16 I-modem attached to a Livingston PM2E30. All the X2
modem code has been succesfully flashed into the USR modems. When a
customer connects using the X2 protocol, the transfer rate starts at
around 5.0Kb/s, then drops lower and lower eventually down to 2.0Kb/s or
lower. However, when connecting without using X2, say at 28.8k or 31.2k,
the throughput is around 3-3.5Kb/s, which is to say normal.
Has anyone had a similar problem and is there anything to do about this.
Tried calling the USR tech support, but they blamed it on "the number of
internet hops" even though I test by downloading from a local ftp server.
Thanks in advance.
Sincerely,
Thomas Tsai
Subject:(usr-tc) SNMP: Netserver vs. NMC response time From: Laszlo Vecsey <master@internexus.net> Date: 1997-07-28 17:33:23
The NMC is considerably slower in returing snmp responses
(snmpget/snmpwalk), is there a hardwrae reason for this or can I change a
delay somewhere?
Subject:Re: (usr-tc) SNMP: Netserver vs. NMC response time From: David Bolen <db3l@ans.net> Date: 1997-07-28 18:24:42
Laszlo Vecsey <master@internexus.net> writes:
> The NMC is considerably slower in returing snmp responses
> (snmpget/snmpwalk), is there a hardwrae reason for this or can I change a
> delay somewhere?
It depends on what you are querying. Generally the NMC should return
pretty fast responses if you are asking it something that it itself
knows (e.g., chassis contents, trap settings, location configuration,
etc..). Of course, "pretty fast" is somewhat of a biased viewpoint
and I'm probably affected by host fast it has historically answered
queries, so I don't know how to represent it in absolute terms.
However, if you ask an NMC about something else in the chassis, then
the overall timing will be gated by how long that device itself
answers the NMCs internal management query. In such cases the NMC is
a proxy agent for the other device, and overall response time is the
sum of the NMC overhead plus internal management and device overhead.
Some devices, like modems, tend to be quite fast in responding (in
other words, the response is very close to when you ask the NMC about
something it knows about itself), while others (such as the T1/PRI
card) can be much slower. I think the slowest part of the MIB is
asking for DS0 status (although the newer bulk objects help negate
this issue).
There isn't a whole lot you can do about this timing. If you've got a
fairly old NMC they were originally 386 based and yes, changing to the
more recent 486 based NMC it does respond a bit faster. But in the
case of some stuff (like the DS0 querying above) the NMC isn't the
bottleneck so it really won't help that much.
I ran a quick comparison of some NMCs versus NETServers, doing two
dump of the MIB-II interfaces table, and then rating the device at
average objects/second (to take into account the differing table sizes
between NETServers and NMCs). The devices were otherwise idle
and the source of the query was kept constant as a local machine. It
does appear that the newer NETServer responds much faster, although it
appears to be an aspect of the code rather than the hardware platform
(both standard and EPB NETServers are 486dx4-100 based, although older
NETServers can be 486sx based):
Objects/sec
NMC 486 8.99
386 6.47
NETServer Std (3.3.x) 4.16
EPB (3.3.x) 4.09
(3.5.x) 44.66
So it does appear that the newer NETServer code responds to SNMP much
faster than previously, but that the NMC code was faster up until the
most recent code. I didn't actually expect this myself, but then
again I haven't checked recently since MIB-II isn't all that helpful
for most of my needs, so I don't query the NETServers directly very
often.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) SNMP: Netserver vs. NMC response time From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> Date: 1997-07-28 21:09:26
The NMC will respond fast if what you are quering is something within the
NMC. If you are doing an snmpget to get modem info while the modem is
busy you will get a slow response.
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Mon, 28 Jul 1997, Laszlo Vecsey wrote:
> The NMC is considerably slower in returing snmp responses
> (snmpget/snmpwalk), is there a hardwrae reason for this or can I change a
> delay somewhere?
>
>
>
>
>
Subject:(usr-tc) Real Time users On Line From: William M Sheeler Sr <tcra@talon.net> Date: 1997-07-29 12:45:25
Well, finally got the USR TC's running like clockwork and the Analog line
shutdown.
What I can not seem to do now is see Real Time logon usage by client like I
could under Unix (w | more showed me who port IP and time on line).
I am running Radius 2.0.1 on a BSDI 3.0 server. I have this huge detail
file on each of the TC's, but I don't know how to get info out of it very
well, especially Real Time Log info.
Any assistance would be appreciated.
TTFN
Bill
William M Sheeler, Sr www.talon.net
ceo
TCRA Computers and voice 610.670.6491
TALON Network Services, Inc voice 610.670.4923
Fax for both fax 610.670.6495
( Total Area Linked Online Nationwide Network Services, Inc)
" Live with Passion "
" It's in your moments of decision that your destiny is shaped "
ANTHONY ROBBINS
Subject:Re: (usr-tc) Unable to execute netsrvr.exe From: Brian <signal@shreve.net> Date: 1997-07-29 13:54:37
On Tue, 29 Jul 1997, System Administrator wrote:
> I want to be able to launch netsrvr.exe from the TC software. I've
> installed it in the default c:\usrsuite directory, but it still gives
> the error above.
>
> Anyone know the trick for getting this to interoperate?
>
> Thanks,
>
> WingNET System Administrator
> 423-559-LINK (v)
> 423-559-5444 (f)
>
Ours does this also........
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Unable to execute netsrvr.exe From: Brian <signal@shreve.net> Date: 1997-07-29 13:54:37
On Tue, 29 Jul 1997, System Administrator wrote:
> I want to be able to launch netsrvr.exe from the TC software. I've
> installed it in the default c:\usrsuite directory, but it still gives
> the error above.
>
> Anyone know the trick for getting this to interoperate?
>
> Thanks,
>
> WingNET System Administrator
> 423-559-LINK (v)
> 423-559-5444 (f)
>
Ours does this also........
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Unable to execute netsrvr.exe From: System Administrator <root@wingnet.net> Date: 1997-07-29 14:56:03
I want to be able to launch netsrvr.exe from the TC software. I've
installed it in the default c:\usrsuite directory, but it still gives
the error above.
Anyone know the trick for getting this to interoperate?
Thanks,
WingNET System Administrator
423-559-LINK (v)
423-559-5444 (f)
Subject:Re: (usr-tc) Can't get it to save... From: System Administrator <root@wingnet.net> Date: 1997-07-29 15:13:10
> BTW did you do a system reset/reboot from TC manager? Will knock current sessions off but does seem to "burn" the code into the cards
> Which firmware update? Is it the new 3.5.xx Netserver code? I was told once by a USR/3com tech that the upgrade would help many speed related issues.(First ping allways timing out, lattency with quak> What does the upgrade actually do, and is it safe.
> Mike, AE
Well, we've upgraded the NMC and all modem cards now. Will get to
the PRI and Netserver cards later. Safe? Don't know what to say.
We've had several users call in the past few days (and we seldom do
otherwise) saying they are having trouble making connections. We
haven't figured out what the problem is yet.
WingNET System Administrator
423-559-LINK (v)
423-559-5444 (f)
Subject:Re: (usr-tc) List nukage and ethernet blockage From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-29 16:21:13
David Bolen said once upon a time:
>There's nothing inherently wrong with the older card platform though
>(I've used an awful lot of them for years now) but depending on their
>age (January seems pretty recent) they do tend to need some
>engineering fixes to keep up with newer system code releases, so over
>time I've had a reasonable churn of cards that fail for some reason,
>go back to USR and they apply changes as part of the fix process.
Is this under your service contract? It makes me kind of upset that I buy
the latest and greatest from USR in January, and by July it is out of date,
to the point of being unusable with the latest code.
Subject:Re: (usr-tc) Certification From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-29 17:11:11
Brian said once upon a time:
>
>
>I heard somewhere that there is a certification program, maybe offered
>through DRAKE, where you can test on your knowledge of USR TC hub, and
>then even bypass level 1 tech support at USR........anyone know anything
>about this?
I would LOVE this.
Subject:(usr-tc) Certification From: Brian <signal@shreve.net> Date: 1997-07-29 17:46:49
I heard somewhere that there is a certification program, maybe offered
through DRAKE, where you can test on your knowledge of USR TC hub, and
then even bypass level 1 tech support at USR........anyone know anything
about this?
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Real Time users On Line From: Brian <signal@shreve.net> Date: 1997-07-29 18:04:20
On Tue, 29 Jul 1997, David Bolen wrote:
> William M Sheeler Sr <tcra@talon.net> writes:
>
> > What I can not seem to do now is see Real Time logon usage by client like I
> > could under Unix (w | more showed me who port IP and time on line).
>
> Since that shows you live users as of the time you ran it, how about
> using the "show session" command on the NETServer itself?
>
> The RADIUS accounting logs can also be used, but that would be more
> appropriate for a post-mortem sort of information rather than instantaneous.
Unles you modify radius to write to a database, such as msql, then it
wouldnt be so hard to get instantaneous info, something I am hopefully
going to work on one day.......
Brian
>
> -- David
>
> /-----------------------------------------------------------------------\
> \ David Bolen \ Internet: db3l@ans.net /
> | ANS Communications, Inc. \ Phone: (914) 789-5327 |
> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
> \-----------------------------------------------------------------------/
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Unable to execute netsrvr.exe From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-29 18:08:00
-> I want to be able to launch netsrvr.exe from the TC software. I've
-> installed it in the default c:\usrsuite directory, but it still gives the
-> error above.
->
-> Anyone know the trick for getting this to interoperate?
Yes, copy it to the c:\usrsuite\tcm\ directory.
Jeff Binkley
ASA Network Computing
Subject:Re: (usr-tc) List nukage and ethernet blockage From: David Bolen <db3l@ans.net> Date: 1997-07-29 18:36:29
Pete Ashdown <pashdown@xmission.com> writes:
> Is this under your service contract? It makes me kind of upset that I buy
> the latest and greatest from USR in January, and by July it is out of date,
> to the point of being unusable with the latest code.
Well, we're definitely still at the supposition phase as far as just
where the problem lies (although I do think it's reasonably clear at
least some of the requirements in terms of hardware that tend to
tickle it). Hopefully this will turn out to be a software fix and
something available in the near term.
As for buying something in January that is no longer the latest and
greatest (design, code, function, etc..) by July - isn't this a
wonderful industry to be in? That sort of thing seems to happen to me
all the time :-)
However, to answer your question, yes, the return of cards that are
failing for us does, I expect, fall under the service contract. But
we don't generally make proactive ECOs - as with many types of
equipment, what tends to happen is if a problem is encountered that is
identified as being related to an outstanding ECO, then the change can
be applied. But if you aren't being impacted by such a fix, then the
fix isn't automatically applied to all outstanding cards.
And in cases like this, the first thing I tend to do is try to gather
data to see if the implication is hardware or software, since hardware
replacements are much more intrusive than a software (workaround or
fix). I think the jury is still out on this one - some of my own
experiences would tend to point at the hardware, while other tests
would indicate software. I've backed off the code on the affected
hardware while testing continues, but haven't immediately scheduled
any replacements or anything until the issue gets worked through some
more.
I'd hang on for a bit more before immediately suspecting the hardware.
A particular hardware platform may be a necessary pre-requisite for
the issue to arise, but it may not be the root cause of the problem.
-- David
Subject:Re: (usr-tc) Real Time users On Line From: David Bolen <db3l@ans.net> Date: 1997-07-29 18:44:20
William M Sheeler Sr <tcra@talon.net> writes:
> What I can not seem to do now is see Real Time logon usage by client like I
> could under Unix (w | more showed me who port IP and time on line).
Since that shows you live users as of the time you ran it, how about
using the "show session" command on the NETServer itself?
The RADIUS accounting logs can also be used, but that would be more
appropriate for a post-mortem sort of information rather than instantaneous.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Tom Bilan <tom@tdi.net> Date: 1997-07-29 20:29:07
Mine locked up on me again last night. I talked to someone at USR and they
said to set SW5 to nuke the config and then retype the config in because
when upgrading it may mess up the config conversion.
Sounds like a load of crap to me but I'm going to try it ONCE. After I type
in all 700 set commands and it locks up 3 days later I'm going to be all
over USR like white on rice.
BTW: What's everyone's opinion on the last STABLE release of non quake lag
code?
Tom
At 07:09 PM 7/26/97 -0500, you wrote:
>On Sat, 26 Jul 1997, Brian Elfert wrote:
>
>>
>>
>> On Sat, 26 Jul 1997, William M Sheeler Sr wrote:
>>
>> > Both working fine (knock on wood). These are new units, purchased 6/97
>> >
>> > Been running and operational for about 2weeks now. Lots of users
coming in
>> > and hammering, with no ill effects.
>> >
>> > I have experienced no lost of ethernet at all.
>> >
>> > Are your conditions the same as mine?
>>
>> You may have the newer 'enhanced packet bus' Netserver card which doesn't
>> have the problem. Also, I have the slightly older 'standard packet bus'
>> Netserver card purchased 4/97, and I don't have the problem. Somebody
>> mentioned that there have been many revs of the hardware for the older
>> Netserver card, and that the most recent cards might not see the problem.
>>
>> I think you'll be fine.
>>
>> Brian
>>
>>
>
>
>Most of the hubs here ARE Standard packet bus's, and we DO see the problem
>(on Standard pb units).
>
>This is totally unacceptable. Users dial in, and cant get PPP, takes me
>30 min before I am notified, and able to reboot the unit, this has been
>going on now since the upgrade to 2.5.1. My users are pissed, and I am
>starting to get a bad rap.
>
>USR gets a bad rap also, because its there x2 modems my users will be
>blaming the problem on.
>
>Does Anyone know the status of this? Is this problem officially
>acknowledged by USR? I think we have done all the "field testing" to show
>that Standard packet bus netservers nics lock up with this new code.
>
>I hope this gets priority treatment, and we see a fix REAL soon.
>
>What are you all doing about this? Did you fall back to a older code rev?
>If so, what is safe to fallback too? (Framed-Route is very important too
>us, and I don't need 500 users complaining of Quake lag either if it can
>be avoided).
>
>Brian
>
>
>
>oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
>UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
>signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
>oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
>
>
>
>
Brian <signal@shreve.net> writes:
> Can someone give me a quick example of how to get snmpwalk to use the
> usr mibs when reading nmc info? I thought you would just set MIBFILE to
> the path of where the mibs are and snmpwalk hostname string
The CMU library expects to load a single MIB file (in the order of
MIBFILE environment variable, "mib.txt" or "/etc/mib.txt" I believe)
when its MIB routines are initialized, which should be an ASN.1 format
file containing the MIBs you want to reference. For the most part,
just concatenate the individual MIB files that USR provides together
into a single file - order doesn't matter. Oh, but don't include the
chs_trap.mib file since the CMU stuff doesn't parse the TRAP-TYPE macro.
Then, set the MIBFILE environment variable to point to the file unless
you've called it mib.txt and it's in the current directory or /etc.
In order to satisfy the requirements of knowing the standard SMI
definitions as well as having the DisplayString textual convention
that is imported from MIB-II by all the USR MIBs (even though they
only provide MIB-1 for the NMC), prefix the following to the file:
- - - - - - - - - - - - - - - - - - - - - - - - -
RFC1155-SMI DEFINITIONS ::= BEGIN ;
nullOID OBJECT IDENTIFIER ::= { ccitt 0 }
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
END
RFC1213-MIB DEFINITIONS ::= BEGIN ;
DisplayString ::= OCTET STRING
END
- - - - - - - - - - - - - - - - - - - - - - - - -
and you should be set. Alternatively, you can drop the MIB1 file from
USR and just stick in an actual copy of MIB-II (RFC1213). Technically
this contains some invalid objects for the NMC, but it's appropriate
for the NETServer so it's a tradeoff. You could try including both,
but the ambiguity of the forward reference for node names can
sometimes be confusing, although it's less so with the stock CMU
library since you always reference everything hierarchically and never
directly by leaf object label.
If you don't include the SMI definitions, the CMU library will
complain about all sorts of inconsistencies because without them it
can't chain the USR MIBs (which fall beneath the "enterprises" tree)
up to the root ("iso") of the tree.
If you don't include the DisplayString textual convention, then the
library won't know when parsing the USR MIB files that it is supposed
to treat a syntax of DisplayString just like "OCTET STR" and won't
skip over the optional size information allowed for such object types
(shown as "(SIZE(#..##))" after the syntax). Then, whatever happens
to be the first such qualified object the parser hits, you'll get the
somewhat less than intuitive error message about:
Should be ACCESS((): On or around line xxx
Bad parse of objecttype: On or around line xxx
which is really saying that it expected to see the token "ACCESS" but
instead got a left parenthesis (show inside parentheses in the error)
which is because it didn't know to parse through the size value since
it didn't know that DisplayString was a synonym for octet string.
Now, once you have a working mib.txt file (e.g., you can run any of
the utilities without getting any warnings, but just the usage
statements), then you're almost set.
Depending on how you want to reference objects, I would suggest
setting your PREFIX environment variable to ".1.3.6.1.4.1.429" (or"
".iso.org.dod.internet.private.enterprises.usr" although the numeric
version is a tad faster and you only define the variable once). That
will make the root assumed by the CMU library to be at the "usr" tree.
So objects that you specify will have to be relative to that location,
for example "snmpwalk -v 1 <host> <comm> nas.nmc.nmcCmd" to walk the
NMC command table.
You can still reference locations from elsewhere that isn't beneath
your prefix by giving a full path and starting the specification with
the leading ".". Or if you know you'll be doing stuff in one part of
the tree you can set a more limiting PREFIX to help avoid too much
typing.
Hope this helps.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) Netserver error From: Brian <signal@shreve.net> Date: 1997-07-29 23:59:12
I noticed the following error logged to the console of one of my netserver
cards:
pw_recvd: Mismatched digest
pw_recvd: Mismatched digest
pw_recvd: Mismatched digest
pw_recvd: Mismatched digest
pw_recvd: Mismatched digest
anyone know what that means?
Also, I can't for the life of me get syslog logging to work on the
netserver.
I set the syslog host, I have the /etc/syslog.conf file direct auth.info
to /var/log/authlog. The file exists, I restart syslog, and still
nothing. And yes the /etc/hosts lists the netserver.
Does logging have to be enabled on the NMC for this to work? Anyone else
having problems with netserver logging?
Netserver logging doesnt just log authentication from the netserver right?
It logs errors, reboots, etc right?
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian <signal@shreve.net> writes:
> I noticed the following error logged to the console of one of my netserver
> cards:
>
> pw_recvd: Mismatched digest
I'm not absolutely positive, but it sounds like a warning that you are
receiving an answer from a RADIUS server where the authentication
field (which is an MD5 digest of the packet and shared secret) isn't
correct. My guess is the NETServer is dropping the response.
This can either be due to a bug in computation, or more likely,
mismatched RADIUS secrets between the NETServer and RADIUS server.
Not really sure why it spits the message out to the console, but...
> Also, I can't for the life of me get syslog logging to work on the
> netserver.
>
> I set the syslog host, I have the /etc/syslog.conf file direct auth.info
> to /var/log/authlog. The file exists, I restart syslog, and still
> nothing. And yes the /etc/hosts lists the netserver.
Just for the sake of argument, use "logger -p auth.info <msg>" on the
local host and verify that <msg> shows up in the log you expect. It's
not exactly the same as a network packet, but if it doesn't work, then
there's definitely something still wrong locally. Also, it's
sometimes helpful to add a "*.debug" setting just to catch everything
while trying to troubleshoot syslog stuff.
Next, if you can, try rebooting the NETServer. There have been some
problems over time with changing syslog destinations not taking effect
until after a reboot, although I thought that was working in the last
few releases. It should certainly work if the old setting used to be
0.0.0.0, but if you're changing it from another (even if bad) address,
then it's more questionable.
If you want to verify if the NETServer is actually sending any traffic
you could try tracing incoming traffic on your box (e.g., tcpdump, or
appropriate tool). I was going to suggest ptracing on the NETServer
itself but I just tried it and it doesn't seem to pick up the UDP
syslog datagrams - not sure if it's something with UDP entries in a
trace filter or not.
Depending on where the target syslog machine is with respect to the
NETServer (from a network topology viewpoint) you might want to verify
that there aren't any router filters along the way preventing a remote
syslog packet from getting to your logging machine.
> Does logging have to be enabled on the NMC for this to work? Anyone else
> having problems with netserver logging?
No, there's nothing that you need to adjust on the NMC - syslog
generation by the NETServer is completely independent. Other than the
issue with changing NETServer log targets (and an older issue with the
NETServer not properly updating the source address in syslogs if you
changed the ethernet configuration and didn't reboot that should also
be cleaned up now), I've never had a problem, and I depend extremely
heavily on the NETServer syslogs, as we use them for a lot of our call
tracking (since they pre-date useful RADIUS accounting).
> Netserver logging doesnt just log authentication from the netserver right?
> It logs errors, reboots, etc right?
Yes.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Netserver error From: Brian <signal@shreve.net> Date: 1997-07-30 09:10:14
>
> > Also, I can't for the life of me get syslog logging to work on the
> > netserver.
> >
> > I set the syslog host, I have the /etc/syslog.conf file direct auth.info
> > to /var/log/authlog. The file exists, I restart syslog, and still
> > nothing. And yes the /etc/hosts lists the netserver.
>
> Just for the sake of argument, use "logger -p auth.info <msg>" on the
> local host and verify that <msg> shows up in the log you expect. It's
> not exactly the same as a network packet, but if it doesn't work, then
> there's definitely something still wrong locally. Also, it's
> sometimes helpful to add a "*.debug" setting just to catch everything
> while trying to troubleshoot syslog stuff.
>
David,
Thanks for the info. I have found the root of my syslogging woes :)
Hope this info helps anyone else having troubles:
From the sysklogd 1.3 Documentation:
Very important information before using version 1.3
The included version of syslogd behaves in a slightly different manner
to the one in former releases. Please review the following important
differences:
* By default the syslog daemon doesn't accept any message from the
syslog/udp port. To enable this add "-r" to the command-line
arguments. You _have to_ add this on every host that should run as a
centralized network log server.
Brian
>
> Yes.
>
> -- David
>
> /-----------------------------------------------------------------------\
> \ David Bolen \ Internet: db3l@ans.net /
> | ANS Communications, Inc. \ Phone: (914) 789-5327 |
> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
> \-----------------------------------------------------------------------/
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Netserver error From: Brian <signal@shreve.net> Date: 1997-07-30 09:10:14
>
> > Also, I can't for the life of me get syslog logging to work on the
> > netserver.
> >
> > I set the syslog host, I have the /etc/syslog.conf file direct auth.info
> > to /var/log/authlog. The file exists, I restart syslog, and still
> > nothing. And yes the /etc/hosts lists the netserver.
>
> Just for the sake of argument, use "logger -p auth.info <msg>" on the
> local host and verify that <msg> shows up in the log you expect. It's
> not exactly the same as a network packet, but if it doesn't work, then
> there's definitely something still wrong locally. Also, it's
> sometimes helpful to add a "*.debug" setting just to catch everything
> while trying to troubleshoot syslog stuff.
>
David,
Thanks for the info. I have found the root of my syslogging woes :)
Hope this info helps anyone else having troubles:
>From the sysklogd 1.3 Documentation:
Very important information before using version 1.3
The included version of syslogd behaves in a slightly different manner
to the one in former releases. Please review the following important
differences:
* By default the syslog daemon doesn't accept any message from the
syslog/udp port. To enable this add "-r" to the command-line
arguments. You _have to_ add this on every host that should run as a
centralized network log server.
Brian
>
> Yes.
>
> -- David
>
> /-----------------------------------------------------------------------\
> \ David Bolen \ Internet: db3l@ans.net /
> | ANS Communications, Inc. \ Phone: (914) 789-5327 |
> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
> \-----------------------------------------------------------------------/
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Two of my modem cards went to inactive status in my Netserver for some
reason. This busied out the DS0s because the modems were no longer
available.
I hadn't touched the rack for like a week. Is it normal for modems to
just go inactive like this? Setting the modems active in the Netserver
fixed every right up again. I'm running TCS 2.5.1 in all components, if
that matters.
Brian
Subject:Re: (usr-tc) HiPer From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-30 10:01:34
Robert Sanders said once upon a time:
>It looks as though much of USR's
>development manpower has been channeled into the new HiPer Access
>Router Card, leaving the current NETserver code base to twist in the
>wind.
Which isn't that much of a bad thing. I just got the specs on the new
HiPer 24 port modem card and the Access Router. Very cool. Has anyone
heard if there if there will be an upgrade plan?
Brian Elfert <brian@citilink.com> writes:
> Two of my modem cards went to inactive status in my Netserver for some
> reason. This busied out the DS0s because the modems were no longer
> available.
At least your chassis busies itself out. We're using round-robin
assignment with PRIs. When our modems go inactive, our hunt groups
break. :-(
> I hadn't touched the rack for like a week. Is it normal for modems to
> just go inactive like this? Setting the modems active in the Netserver
> fixed every right up again.
It happens to us quite frequently with both 3.4.79 and, more recently,
3.5.34. Usually a "reset S1-S64" clears it up. We've reported this
bug to USR a handful of times. It looks as though much of USR's
development manpower has been channeled into the new HiPer Access
Router Card, leaving the current NETserver code base to twist in the
wind.
-- Robert
Thus spake Brian Elfert
>Two of my modem cards went to inactive status in my Netserver for some
>reason. This busied out the DS0s because the modems were no longer
>available.
>I hadn't touched the rack for like a week. Is it normal for modems to
>just go inactive like this? Setting the modems active in the Netserver
>fixed every right up again. I'm running TCS 2.5.1 in all components, if
>that matters.
Just to throw my $.03 in, I had this happen to a modem card here as
well...same situation...TCS 2.5.1 across the whole chassis...newer enhanced
chassis. Set them back to active in the netserver, save all, reset those
ports and they were functioning perfectly again.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Thus spake Robert Sanders
>Brian Elfert <brian@citilink.com> writes:
>> Two of my modem cards went to inactive status in my Netserver for some
>> reason. This busied out the DS0s because the modems were no longer
>> available.
>At least your chassis busies itself out. We're using round-robin
>assignment with PRIs. When our modems go inactive, our hunt groups
>break. :-(
aye....at the time, we were on first available hunting on the pri's and
first available hunting on the PRI card for modem assignment....this was
the *first* card in the chassis, first chassis in the hunt group...at least
the PRI card went ahead and skipped those modems and filled the rest of the
chassis...but then the PRI card would take the call, try to hand it off to
the modem card which wouldn't take it (since it had no "DTE" connection),
so the call would "timeout" as far as the telco switch was concerned and
give a fast busy after 10 seconds. Basically chopped our hunt group down
to 44 lines when we have several chassis' full of lines in that
location....it wasn't a pretty site. :)
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) HiPer From: Brian <signal@shreve.net> Date: 1997-07-30 11:28:54
On Wed, 30 Jul 1997, Pete Ashdown wrote:
> Robert Sanders said once upon a time:
>
> >It looks as though much of USR's
> >development manpower has been channeled into the new HiPer Access
> >Router Card, leaving the current NETserver code base to twist in the
> >wind.
>
> Which isn't that much of a bad thing. I just got the specs on the new
> HiPer 24 port modem card and the Access Router. Very cool. Has anyone
> heard if there if there will be an upgrade plan?
>
24port modem cards will work in the Packet Bus clocking TC Hubs. You will
need to replace the netserver or nmc card I believe.
Also 24 port cards will work in the non packet bus clocking chasis, but
only 2 24 port cards can be used in those hubs. The new nmc/netserver
cards will be different for packet bus clocking and non-packet bus
clocking.
I don't have all the facts I admit, but I do know that 24port cards will
work. This is why the packet bus clocking chasis have high density
backplanes
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
On 30 Jul 1997, Robert Sanders wrote:
> > Two of my modem cards went to inactive status in my Netserver for some
> > reason. This busied out the DS0s because the modems were no longer
> > available.
>
> At least your chassis busies itself out. We're using round-robin
> assignment with PRIs. When our modems go inactive, our hunt groups
> break. :-(
Hmm. I've loaded my PRI NAC with the T1 code, and there is a setting for
auto busyout. With this set, any modems not ready to take calls will busy
out the respective DS0.
I never looked at the PRI settings, so I don't know if there is an
equivalent setting for PRI.
> It happens to us quite frequently with both 3.4.79 and, more recently,
> 3.5.34. Usually a "reset S1-S64" clears it up. We've reported this
3.4.79 was beta, wasn't it? I did set modem s? active before I reset the
modems, so I don't know if just a reset would have fixed things, or not.
> bug to USR a handful of times. It looks as though much of USR's
> development manpower has been channeled into the new HiPer Access
> Router Card, leaving the current NETserver code base to twist in the
> wind.
Is this new card going to be the card used with the new 24 modem cards?
I'd think development for the Netserver is going to have to continue, or
USR will break their license with Livingston. They've also promised us
OSPF. I'd be mighty upset if they didn't bring out OSPF for the
Netserver.
Brian
Subject:Re: (usr-tc) HiPer From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-30 12:31:41
Brian said once upon a time:
>24port modem cards will work in the Packet Bus clocking TC Hubs. You will
>need to replace the netserver or nmc card I believe.
I'm not wondering about upgrading my chassis, I'm wondering whether I can
send six 4 port modem cards back and get a 24 HiPer card as a replacement.
Subject:Re: (usr-tc) RFC1877 From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-30 13:44:57
Peter Evans said once upon a time:
>
>Ricardo Rizzi wrote:
>
>| Is possible to configure the netserver card to send DNS in a PPP conection
>| (RFC1877)???
>
> aka: M$ dns?
>
> I believe USR fixed it to do that for us.
Can you elaborate?
Subject:Re: (usr-tc) OSPF From: David Carmean <dlc@avtel.net> Date: 1997-07-30 14:10:38
On Wed, Jul 30, 1997 at 04:46:22PM -0400, Robert Sanders wrote:
> Jeff Mcadams <jeffm@iglou.com> writes:
>
> > >If I have to buy a new card to get OSPF, I think I'll buy two PM25s and
> > >hook them up instead.
> >
> > Speaking as someone who came from PM25s to the Netservers....you'll be
> > sorry.
>
> Seconded. We're moving our PM25s off the network as quickly as
> possible. Although the degree and quality of integration between the
> various TC components leaves something to be desired, it's universal
> nirvanic consciousness compared to what you get through a serial
> cable.
>
> You may also find that a 115200 bps DTE rate is a bottleneck for your
> luckier internal x2 modem users.
Have you tested this? It's reported that the PM2s at least will
run 230 Kbps. I presume the PM25 uses the same chipset. It's not
"supported", but Livingston folks have said in public that "it
works".
I haven't run a TC chassis, but *every* *single* *one* of the
NETServer/16s that I've come in contact with have had at least
one modem fail within six months, usually more. Great idea,
lousy implementation.
--
David Carmean <dlc@avtel.net>
Avtel Communications, Santa Barbara, CA +1-805-730-7740
Opinions herein are those of the author only, unless otherwise noted
"Are you now, or have you ever been?"
--George Lucas, THX-1138
Subject:(usr-tc) ISDN problem From: Brian <signal@shreve.net> Date: 1997-07-30 14:17:15
Our first chasis is giving busy signals for isdn calls. Analog calls work
fine. We have no span or ds0 blocking enabled.
The netserver is setup to take the isdn calls, and its configured in the
pri as the isdn-gw.
The ONLY difference between the first chassis, which isnt working, and the
other chassis's we have which do work is this:
ISDN Call Control Options:
Set Originate Analog Modem/Fax Data = analogModemFax
yet on our hubs that do work its:
Set Originate Analog Modem/Fax Data = none
I thought that "ISDN Call Control Options" on the Netserver, would have NO
effect whatsoever, unless you were using the I-Modems to actually service
the ISDN, instead of the Netserver.......
Anyone know if this is causing the problem? Any ideas as to what can
cause the problem?
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) OSPF From: Brian Elfert <brian@citilink.com> Date: 1997-07-30 14:35:04
On 30 Jul 1997, Robert Sanders wrote:
> Nothing I've heard has led me to believe that the Livingston-based
> NETserver would ever support OSPF. If you need classless dynamic
> routing in TCS2.x, you have to use RIPv2. The HiPer ARC -- will
> somebody *please* fix USR's sticky shift key? -- will eventually
> support OSPF, but not at FCS.
Hmm.. Various sales people at USR have told me that they will support
OSPF. I'm not sure if they meant they would or would not support OSPF on
current equipment. I'll be pissed if I have to buy a new terminal server
card to so do.
If I have to buy a new card to get OSPF, I think I'll buy two PM25s and
hook them up instead.
Brian
3.5.34 - NETServer code
set nasdns_info on
will do this for you
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
On Wed, 30 Jul 1997, Ricardo Rizzi wrote:
> Is possible to configure the netserver card to send DNS in a PPP conection
> (RFC1877)???
> _________________________________________________________________________
> "Centertap, acelerando o tempo, diminuindo distancias"
> _________________________________________________________________________
> Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br
> Departamento Tecnico web: http://www.centertap.com.br
> Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323
> 05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313
> _________________________________________________________________________
>
>
Brian Elfert <brian@citilink.com> writes:
> I hadn't touched the rack for like a week. Is it normal for modems to
> just go inactive like this? Setting the modems active in the Netserver
> fixed every right up again. I'm running TCS 2.5.1 in all components, if
> that matters.
It's not "normal" per se, but occasionally something can go wrong with
packet bus communication that can cause this.
(Note that if it's an entire quad card, then any physical reseat of
the card, or download of new code can also cause this. Normally a
remote reset through the NMC won't - it's fast enough that the
NETServer will reconnect. Of course, any of these options imply some
intervention with the rack)
I don't know if you got your syslogging up before this happened, but
any packet bus issues that result in a link being taken down from the
NETServer side will leave a trace in the syslog file.
Just grep for "packet" - normally the only messages you'll get will be
for the opening and closing (and errors) of packet bus link stuff,
which under normal circumstances should be no messages. Obviously if
the NETServer restarts you'll see a ton of them when it opens up the
links, and if there's something surviveable (like a reset of the modem
card) you'll see the error, close and then reopen a few seconds later.
An egrep string you might want to use when looking through a NETServer
syslog file for anomolous messages is "packet|pb_|pbx_|readbuf|dmsg|alloc".
You can also enable traps on the modem side relating to packet bus
issues - the "mdmTePbActive" and "mdmTePbLost" traps will reflect
packet bus establishment and breakage from the modem perspective, and
"mdmTePbClockLossEvent" and "mdmTePbClockRestoreEvent" relate to the
packet bus clock.
It is true however, that there are cases where the packet bus
connection will appear to be lost from one side but not necessarily
the other, so it's always good to have both view (syslog and traps).
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
On Wed, 30 Jul 1997, David Bolen wrote:
> It's not "normal" per se, but occasionally something can go wrong with
> packet bus communication that can cause this.
>
> (Note that if it's an entire quad card, then any physical reseat of
> the card, or download of new code can also cause this. Normally a
> remote reset through the NMC won't - it's fast enough that the
> NETServer will reconnect. Of course, any of these options imply some
> intervention with the rack)
I hadn't done any resets of the modem cards or anything like that when
this happened. It does seem strange that the Netserver card doesn't
automatically reattach to the modems.
> I don't know if you got your syslogging up before this happened, but
> any packet bus issues that result in a link being taken down from the
> NETServer side will leave a trace in the syslog file.
That was a different Brian having syslog problems. I don't have
syslogging enabled at this time.
Brian
On Wed, 30 Jul 1997, David Bolen wrote:
> It's not "normal" per se, but occasionally something can go wrong with
> packet bus communication that can cause this.
>
> (Note that if it's an entire quad card, then any physical reseat of
> the card, or download of new code can also cause this. Normally a
> remote reset through the NMC won't - it's fast enough that the
> NETServer will reconnect. Of course, any of these options imply some
> intervention with the rack)
I hadn't done any resets of the modem cards or anything like that when
this happened. It does seem strange that the Netserver card doesn't
automatically reattach to the modems.
> I don't know if you got your syslogging up before this happened, but
> any packet bus issues that result in a link being taken down from the
> NETServer side will leave a trace in the syslog file.
That was a different Brian having syslog problems. I don't have
syslogging enabled at this time.
Brian
Robert Sanders <rsanders@mindspring.net> writes:
> At least your chassis busies itself out. We're using round-robin
> assignment with PRIs. When our modems go inactive, our hunt groups
> break. :-(
That's more an issue with a poorly designed (IMO) signaling for any
PRI circuit (e.g., no clean way under Q.931 to instruct the telco to
move to another piece of gear) versus the hub. But there are a few
options even in a PRI case.
When your modem goes inactive, it will refuse to accept new calls (as
long as you've got the "mdmCcNoPbNoConnEna" object set). Now true, on
a channelized T1 configuration that means it puts a busy pattern on
the TDM and if your T1 card is configured to auto busy it will put a
busy pattern on the DS0. But in a PRI configuration, that modem will
still refuse any new calls and the PRI card will skip over it.
You still run into a headache when you fill up your hunt group,
because there's no good way to signal back to the telco that while you
have free B channels you don't have equipment to service them. But if
you are on a T1 span site you can survive losing two modems before you
have a problem since you've only got 46 B channels (assuming no shared
D channel).
If you are in a PRI configuration (4ESS/5ESS/DMSxxx in custom mode)
with the latest code you can manually take some channels out of
service to ensure you don't have too many input B channels for the
modems in question, but it's hard to do proactively. Or, if you've
locked down the B channel to modem mapping, then it will out of
service itself automatically just like a T1 case.
I've been toying with various release codes and haven't found anything
good to force the telco to skip over a hub in a hunt group in such a
case with PRI signaling. I did hear a suggestion from one telco that
perhaps using a congestion release code might do it, but I haven't had
a chance to test it. If true, then configuring the PRI card to return
that when it couldn't find a modem might let the user hunt to another hub.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) OSPF From: Brian Elfert <brian@citilink.com> Date: 1997-07-30 15:17:51
On 30 Jul 1997, Robert Sanders wrote:
> I heard an unsubstantiated rumor that USR might eventually backport
> the HiPer ARC software from the new PowerPC hardware to the current
> 486 hardware. If you find out something more definite, please post it
> here.
Why wouldn't they use the same 4.0 OS now used on the Netserver/16? The
hardware in the Netserver/16 is similiar to a Netserver card. Of course,
the 4.0 OS for the Netserver/16 doesn't support OSPF, so who knows?
Brian
Brian Elfert <brian@citilink.com> writes:
> Hmm. I've loaded my PRI NAC with the T1 code, and there is a setting for
> auto busyout. With this set, any modems not ready to take calls will busy
> out the respective DS0.
>
> I never looked at the PRI settings, so I don't know if there is an
> equivalent setting for PRI.
There is a "change DS0 state on Quad Modem NAC action" option, but it
doesn't seem to do anything.
> 3.4.79 was beta, wasn't it?
Post-release engineering load that fixed some packet bus and NMC
accounting issues.
> Is this new card going to be the card used with the new 24 modem cards?
Yes, but it's not required. They're also enhancing the current
NETserver to support 96 simultaneous connections so that you can add
two 24-port modem cards to an existing 48-port chassis.
> USR will break their license with Livingston. They've also promised us
> OSPF. I'd be mighty upset if they didn't bring out OSPF for the
> Netserver.
Nothing I've heard has led me to believe that the Livingston-based
NETserver would ever support OSPF. If you need classless dynamic
routing in TCS2.x, you have to use RIPv2. The HiPer ARC -- will
somebody *please* fix USR's sticky shift key? -- will eventually
support OSPF, but not at FCS.
-- Robert
Thus spake David Bolen
>I've been toying with various release codes and haven't found anything
>good to force the telco to skip over a hub in a hunt group in such a
>case with PRI signaling. I did hear a suggestion from one telco that
>perhaps using a congestion release code might do it, but I haven't had
>a chance to test it. If true, then configuring the PRI card to return
>that when it couldn't find a modem might let the user hunt to another hub.
I spoke with GTE ISDN tech support, and the guy I spoke to said that
basically, once the switch decides on a B channel and span line to send it
down, no release code that you send will send the call on to another B
channel or span line. You need to proactively take the channel out of
service (and yes, Local Out Of Service) does skip over and doesn't break a
hunt group.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
David Bolen <db3l@ans.net> writes:
> Robert Sanders <rsanders@mindspring.net> writes:
>
> > At least your chassis busies itself out. We're using round-robin
> > assignment with PRIs. When our modems go inactive, our hunt groups
> > break. :-(
>
> That's more an issue with a poorly designed (IMO) signaling for any
> PRI circuit (e.g., no clean way under Q.931 to instruct the telco to
> move to another piece of gear) versus the hub.
Indeed. Finding a solution to this has been our holy grail for a long
time now. Exacerbating the problem is the apparent inability of our
telcos to provide us PRI service in anything but a top-down
configuration.
> busy pattern on the DS0. But in a PRI configuration, that modem will
> still refuse any new calls and the PRI card will skip over it.
True, but as modems usually go inactive a card at a time, that's only
really useful if I have extra cards in the chassis.
> If you are in a PRI configuration (4ESS/5ESS/DMSxxx in custom mode)
> with the latest code you can manually take some channels out of
> service to ensure you don't have too many input B channels for the
> modems in question, but it's hard to do proactively. Or, if you've
> locked down the B channel to modem mapping, then it will out of
> service itself automatically just like a T1 case.
We do the former when servicing or upgrading modems; it works well.
It's even clever enough to act like the "soft busy-out" feature of the
T1 software that would leave connections live but take the
corresponding DS0 out of service after normal disconnection. If I
understand our NOC correctly, one quirk in the implementation of this
feature is that upgrading the PRI card will bump the B channels back
into service at the most inopportune moment.
Unfortunately, when I've tried the latter it hasn't worked. All I did
was set the modem routing to fixed, assigned DS0s to modems, and set
"change DS0 state on quad modem NAC action" to enabled. Are there any
other necessary incancations?
> I've been toying with various release codes and haven't found anything
> good to force the telco to skip over a hub in a hunt group in such a
> case with PRI signaling. I did hear a suggestion from one telco that
> perhaps using a congestion release code might do it, but I haven't had
> a chance to test it.
Every telco of our acquaintance has vehemently denied that such a
thing can be done with DMS100s. According to the Ascend Max 4.6B (?)
release notes, 5ESS switches running AT&T custom software can skip to
the next PRI when given a certain cause code, and if there aren't
enough of the appropriate kind of facilities in the Max it will do
so. However, the vast majority of our trunks are connected to DMS100
or DMS250 switches.
We've asked USR for a switch instructing the PRI card to put B
channels into local OOS so that there are no more in-service B
channels than there are active modem ports. ISDN users, put your
hands down :-) In an mixed ISDN/analog chassis, we still have 48
modems, and in a pure ISDN chassis, we'd simply flip the switch off.
-- Robert
Subject:Re: (usr-tc) OSPF From: Jeff Mcadams <jeffm@iglou.com> Date: 1997-07-30 15:40:50
Thus spake Brian Elfert
>On 30 Jul 1997, Robert Sanders wrote:
>> Nothing I've heard has led me to believe that the Livingston-based
>> NETserver would ever support OSPF. If you need classless dynamic
>> routing in TCS2.x, you have to use RIPv2. The HiPer ARC -- will
>> somebody *please* fix USR's sticky shift key? -- will eventually
>> support OSPF, but not at FCS.
>Hmm.. Various sales people at USR have told me that they will support
>OSPF. I'm not sure if they meant they would or would not support OSPF on
>current equipment. I'll be pissed if I have to buy a new terminal server
>card to so do.
>If I have to buy a new card to get OSPF, I think I'll buy two PM25s and
>hook them up instead.
Speaking as someone who came from PM25s to the Netservers....you'll be
sorry.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) OSPF From: Robert Sanders <rsanders@mindspring.net> Date: 1997-07-30 15:42:14
Brian Elfert <brian@citilink.com> writes:
> Hmm.. Various sales people at USR have told me that they will support
> OSPF. I'm not sure if they meant they would or would not support OSPF on
> current equipment. I'll be pissed if I have to buy a new terminal server
> card to so do.
I heard an unsubstantiated rumor that USR might eventually backport
the HiPer ARC software from the new PowerPC hardware to the current
486 hardware. If you find out something more definite, please post it
here.
-- Robert
Subject:Re: (usr-tc) RFC1877 From: Robert Sanders <rsanders@mindspring.net> Date: 1997-07-30 15:47:26
Ricardo Rizzi <ricardo.rizzi@centertap.com.br> writes:
> Is possible to configure the netserver card to send DNS in a PPP conection
> (RFC1877)???
Set. With current NETserver software, just configure your DNS servers
via "set nameserver..." and then "set nasdns_info on".
You can also control RFC1877 DNS nameserver assignment through the
Primary-DNS-Server (0x900f) and Secondary-DNS-Server (0x9010)
attributes. USR's RADIUS server supports those, but if you're using
the Livingston-based server you'll need to hack in support for USR
style vendor-specific attributes.
-- Robert
Robert Sanders <rsanders@mindspring.net> writes:
> There is a "change DS0 state on Quad Modem NAC action" option, but it
> doesn't seem to do anything.
It only takes effect if you've locked down the channel to modem
mapping on the PRI card I believe.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Robert Sanders <rsanders@mindspring.net> writes:
> There is a "change DS0 state on Quad Modem NAC action" option, but it
> doesn't seem to do anything.
It only takes effect if you've locked down the channel to modem
mapping on the PRI card I believe.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) ISDN problem From: Brian <signal@shreve.net> Date: 1997-07-30 16:07:32
> Hmm, I believe the call control option you note above is actually a
> modem setting and not a NETServer setting (e.g., it sounds like it's
> the "imdmCcStartU3" MIB object). That said I'm not sure why it would
> affect servicing of digital calls since unlike the imdmCcStartV2
> object which can prevent the modem from servicing digital calls, U3
> should be outbound stuff..
in TCM what option is imdmCcStartV2 and what should it be set for?
>
> Two dumb thoughts (which you've probably already checked)...
>
> Are you positive that it's the NETServer in the other racks taking
> calls directly (since the PRI will fall back to the modems if the
> isdn-gw fails for some reason), so that perhaps it's a refusal of the
> modems in the first rack that actually causes the problem, and in
> reality all NETServers are not taking digital calls?
>
Yes, because on those chassis, on the PRI card, you can show the DS0's and
it will show ISDN-GW as whats handling the call, rather than QUAD-I-MODEM
> Also, do you have a non-zero number of maximum B channels supported
> configured on the first NETServer?
>
max b channels should be set at 46
> > Anyone know if this is causing the problem? Any ideas as to what can
> > cause the problem?
>
> One thing you could do is enable the call event traps (if you haven't
> already) on the PRI card. Look for the callTermFailedEvent trap that
> you'll receive when you fail to deliver a digital call. It will have
> a cause code included in the trap which might give an extra hint as to
> why the call wasn't delivered, which is one of the enumerations
> defined for the dt1StatCallEventCode object - I'll include the list
> below just for simplicity.
>
> notSupported(1), setup(2), usrSetup(3), telcoDisconnect(4),
> usrDisconnect(5), noFreeModem(6), modemsNotAllowed(7),
> modemsRejectCall(8), modemSetupTimeout(9), noFreeIGW(10),
> igwRejectCall(11), igwSetupTimeout(12), noFreeTdmts(13),
> bcReject(14), ieReject(15), chidReject(16), progReject(17),
> callingPartyReject(18), calledPartyReject(19), blocked(20),
> analogBlocked(21), digitalBlocked(22), outOfService(23), busy(24),
> congestion(25), protocolError(26), noFreeBchannel(27),
> inOutCallCollision(28), inCallArrival(29), outCallArrival(30),
> inCallConnect(31), outCallConnect(32)
>
> -- David
>
> /-----------------------------------------------------------------------\
> \ David Bolen \ Internet: db3l@ans.net /
> | ANS Communications, Inc. \ Phone: (914) 789-5327 |
> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
> \-----------------------------------------------------------------------/
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) OSPF From: David Carmean <dlc@avtel.net> Date: 1997-07-30 16:14:21
On Wed, Jul 30, 1997 at 06:48:11PM -0400, Robert Sanders wrote:
> Brian Elfert <brian@citilink.com> writes:
>
> > Why wouldn't they use the same 4.0 OS now used on the Netserver/16? The
>
> Good point; I've never seen a NETserver/16. Does the command line
> look more like a Portmaster or a USR LANLinker?
I haven't loaded 4.0 on a /16 yet. The earlier versions *were*
Portmaster code. Just
--
David Carmean <dlc@avtel.net>
Avtel Communications, Santa Barbara, CA +1-805-730-7740
Opinions herein are those of the author only, unless otherwise noted
"Are you now, or have you ever been?"
--George Lucas, THX-1138
Jeff Mcadams <jeffm@iglou.com> writes:
> I spoke with GTE ISDN tech support, and the guy I spoke to said that
> basically, once the switch decides on a B channel and span line to send it
> down, no release code that you send will send the call on to another B
> channel or span line.
As a general comment that is true, and no switch would be forced to
move to another channel or span based on release code. However, it
might be that some switches (my discussion at the time was with an
AT&T technician) might have the capability of trying to reroute a call
around problem areas (such as network congestion) and so returning a
congestion code might trigger the kind of behavior desired in certain
configurations. Of course I still haven't tested this.
> You need to proactively take the channel out of
> service (and yes, Local Out Of Service) does skip over and doesn't break a
> hunt group.
Except for the fact that service messages are not part of the NI-2
standard (why not, I have absolutely no idea - the only thing it
supports is initially bringing a channel into service, but not
affecting it past that point), and are thus only available on
particular switches when run in custom configuration (e.g., you can't
use NI-2, which kind of defeats the purpose of a nice standardized
signaling interface, eh?)
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Jeff Mcadams <jeffm@iglou.com> writes:
> I spoke with GTE ISDN tech support, and the guy I spoke to said that
> basically, once the switch decides on a B channel and span line to send it
> down, no release code that you send will send the call on to another B
> channel or span line.
As a general comment that is true, and no switch would be forced to
move to another channel or span based on release code. However, it
might be that some switches (my discussion at the time was with an
AT&T technician) might have the capability of trying to reroute a call
around problem areas (such as network congestion) and so returning a
congestion code might trigger the kind of behavior desired in certain
configurations. Of course I still haven't tested this.
> You need to proactively take the channel out of
> service (and yes, Local Out Of Service) does skip over and doesn't break a
> hunt group.
Except for the fact that service messages are not part of the NI-2
standard (why not, I have absolutely no idea - the only thing it
supports is initially bringing a channel into service, but not
affecting it past that point), and are thus only available on
particular switches when run in custom configuration (e.g., you can't
use NI-2, which kind of defeats the purpose of a nice standardized
signaling interface, eh?)
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) Total Control User Count via SNMP From: Bosco Tsang <bosco@ipoline.com> Date: 1997-07-30 16:16:49
Is it possible for me to get a user count for USR Total Control via SNMP,
so that I can plot it out via MRTG? What are the OIDs?
Thanks and regards,
Bosco Tsang
InterPacific Online
bosco@ipoline.com
Is possible to configure the netserver card to send DNS in a PPP conection
(RFC1877)???
_________________________________________________________________________
"Centertap, acelerando o tempo, diminuindo distancias"
_________________________________________________________________________
Ricardo Rizzi e-mail: ricardo.rizzi@centertap.com.br
Departamento Tecnico web: http://www.centertap.com.br
Av. Francisco Matarazzo, 404 13 andar tel: (+55-11) 862-4323
05001-100 - Sao Paulo - SP - Brasil fax: (+55-11) 862-4313
_________________________________________________________________________
Robert Sanders <rsanders@mindspring.net> writes:
> We do the former when servicing or upgrading modems; it works well.
> It's even clever enough to act like the "soft busy-out" feature of the
> T1 software that would leave connections live but take the
> corresponding DS0 out of service after normal disconnection.
(Can't resist)
You're welcome :-)
(Let's say it didn't start out that way :-))
> If I
> understand our NOC correctly, one quirk in the implementation of this
> feature is that upgrading the PRI card will bump the B channels back
> into service at the most inopportune moment.
One suggestion would be that after your users have idled off but
before you actually download the code, set the DS0 configuration (not
the transient command table but the actual configuration) to out of
service, and then save the T1 configuration. That way when it reboots
it'll immediately place them out of service. You have to fix the
configuration afterwards, but...
> Unfortunately, when I've tried the latter it hasn't worked. All I did
> was set the modem routing to fixed, assigned DS0s to modems, and set
> "change DS0 state on quad modem NAC action" to enabled. Are there any
> other necessary incancations?
Hmm, I didn't think so - I'll have to retry with the latest release of
stuff.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) RFC1877 From: David Bolen <db3l@ans.net> Date: 1997-07-30 16:28:41
Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> writes:
> 3.5.34 - NETServer code
>
> set nasdns_info on
>
> will do this for you
Well, to clarify a bit, enabling this setting (which is on by default)
will have the NETServer transmit it's local configuration DNS
information (e.g., it's own DNS server info) to the client using
RFC1877 PPP options. The setting shows up in a "show global" output
in the setting table as "Send DNS info".
If however you want to have a finger grain control over what the
client gets you can use the USR vendor specific attributes for Primary
and Secondary DNS server to include DNS information in a RADIUS
authentication response which will then be transmitted to the client
using the 1877 options.
Working on conjunction, any information in a RADIUS response will take
precedence and be sent in lieu of local information should the
nasdns_info setting be enable.d
The configurability is available in 3.5.x, but earlier releases back
as far as 3.3.x I believe implemented the local transmission in the
absence of RADIUS information by default (thus breaking compatibility
with releases 3.2.x and earlier, which annoyed me to no end), and were
not configurable to disable this.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Brian Elfert <brian@citilink.com> writes:
> I hadn't done any resets of the modem cards or anything like that when
> this happened. It does seem strange that the Netserver card doesn't
> automatically reattach to the modems.
It does try to, but it gives up after a period of time (which is
normally long enough to cover basic modem resets - whether manually
triggered or the modem crashing) but not normally long enough to
handle physical movement of the cards, or something like a
multi-minute code download.
> That was a different Brian having syslog problems. I don't have
> syslogging enabled at this time.
Oh, darn - my apologies, I should have checked more closely... well,
if it reoccurs perhaps you could enable syslogging? :-)
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Brian,
>
>I hadn't touched the rack for like a week. Is it normal for modems to
>just go inactive like this? Setting the modems active in the Netserver
>fixed every right up again. I'm running TCS 2.5.1 in all components, if
>that matters.
>
>Brian
>
There are some possible reasons:
If you only have these two Cards in your Rack or connectet to the Packed
Bus you can be sure the Netserver is defect.
If there are more than these Modems installed and the others have no
Problems check the following settings:
Modem connectet to PB (at%D2) ?
Are these Modems recognized by PRI (or T1) Card?
May be one off the Card lost its NVRam!
If these settings are OK : Change the Modems.
so long
Ralf
---
Ralf Reinartz Vobis Microcomputer AG
mailto:reinartz@vobis.de Carlo Schmidt Str. 12
http://www.vobis.de D-52146 Wuerselen
Phone: +49-2405-4444561 Fax: +49-2405-4444271
Subject:Re: (usr-tc) ISDN problem From: David Bolen <db3l@ans.net> Date: 1997-07-30 16:44:42
Brian <signal@shreve.net> writes:
> The netserver is setup to take the isdn calls, and its configured in the
> pri as the isdn-gw.
>
> The ONLY difference between the first chassis, which isnt working, and the
> other chassis's we have which do work is this:
>
> ISDN Call Control Options:
>
> Set Originate Analog Modem/Fax Data = analogModemFax
>
> yet on our hubs that do work its:
>
> Set Originate Analog Modem/Fax Data = none
>
>
> I thought that "ISDN Call Control Options" on the Netserver, would have NO
> effect whatsoever, unless you were using the I-Modems to actually service
> the ISDN, instead of the Netserver.......
Hmm, I believe the call control option you note above is actually a
modem setting and not a NETServer setting (e.g., it sounds like it's
the "imdmCcStartU3" MIB object). That said I'm not sure why it would
affect servicing of digital calls since unlike the imdmCcStartV2
object which can prevent the modem from servicing digital calls, U3
should be outbound stuff..
Two dumb thoughts (which you've probably already checked)...
Are you positive that it's the NETServer in the other racks taking
calls directly (since the PRI will fall back to the modems if the
isdn-gw fails for some reason), so that perhaps it's a refusal of the
modems in the first rack that actually causes the problem, and in
reality all NETServers are not taking digital calls?
Also, do you have a non-zero number of maximum B channels supported
configured on the first NETServer?
> Anyone know if this is causing the problem? Any ideas as to what can
> cause the problem?
One thing you could do is enable the call event traps (if you haven't
already) on the PRI card. Look for the callTermFailedEvent trap that
you'll receive when you fail to deliver a digital call. It will have
a cause code included in the trap which might give an extra hint as to
why the call wasn't delivered, which is one of the enumerations
defined for the dt1StatCallEventCode object - I'll include the list
below just for simplicity.
notSupported(1), setup(2), usrSetup(3), telcoDisconnect(4),
usrDisconnect(5), noFreeModem(6), modemsNotAllowed(7),
modemsRejectCall(8), modemSetupTimeout(9), noFreeIGW(10),
igwRejectCall(11), igwSetupTimeout(12), noFreeTdmts(13),
bcReject(14), ieReject(15), chidReject(16), progReject(17),
callingPartyReject(18), calledPartyReject(19), blocked(20),
analogBlocked(21), digitalBlocked(22), outOfService(23), busy(24),
congestion(25), protocolError(26), noFreeBchannel(27),
inOutCallCollision(28), inCallArrival(29), outCallArrival(30),
inCallConnect(31), outCallConnect(32)
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:(usr-tc) OSPF From: Brian Elfert <brian@citilink.com> Date: 1997-07-30 16:45:04
On Wed, 30 Jul 1997, Jeff Mcadams wrote:
> Yeah, but if they couldn't handle 16 14.4's and 8 28.8's on a PM-5, how are
> they gonna handle 24 x2's on a single PM-25...I just think the box is gonna
> fall over trying to push that much data around. Again, my knowledge is a
I have a PM2E-30 with 30 33.6 USR MP/16 modems on it.
I never see any throughput problems on it when all the modems are in use.
> little dated, but the PM-25's that we have run a single 386 processor...the
> netservers use 486's...and they're not doing all the framing (or don't have
USR only needs the 486 processor because they've bloated the OS so much.
ComOS on a Livingston box still runs in 1MB of RAM. The modified ComOS on
the USR requires 8MB of RAM these days.
Brian
Subject:Re: (usr-tc) OSPF From: Robert Sanders <rsanders@mindspring.net> Date: 1997-07-30 16:46:22
Jeff Mcadams <jeffm@iglou.com> writes:
> >If I have to buy a new card to get OSPF, I think I'll buy two PM25s and
> >hook them up instead.
>
> Speaking as someone who came from PM25s to the Netservers....you'll be
> sorry.
Seconded. We're moving our PM25s off the network as quickly as
possible. Although the degree and quality of integration between the
various TC components leaves something to be desired, it's universal
nirvanic consciousness compared to what you get through a serial
cable.
You may also find that a 115200 bps DTE rate is a bottleneck for your
luckier internal x2 modem users.
-- Robert
Subject:Re: (usr-tc) RFC1877 From: Robert Sanders <rsanders@mindspring.net> Date: 1997-07-30 16:47:58
David Bolen <db3l@ans.net> writes:
> Working on conjunction, any information in a RADIUS response will take
> precedence and be sent in lieu of local information should the
> nasdns_info setting be enable.d
And if I remember correctly, the RADIUS attributes will enable RFC1877
for the corresponding session even if nasdns_info is set to off.
-- Robert
Subject:Re: (usr-tc) OSPF From: David Bolen <db3l@ans.net> Date: 1997-07-30 16:49:02
Robert Sanders <rsanders@mindspring.net> writes:
> You may also find that a 115200 bps DTE rate is a bottleneck for your
> luckier internal x2 modem users.
Or external 25MHz courier or I-Modem users (who can run at 230K) :-)
(particularly since the I-Modem users can get a symmetric 64K clean
link)
-- David
Subject:Re: (usr-tc) RFC1877 From: David Bolen <db3l@ans.net> Date: 1997-07-30 16:50:17
Robert Sanders <rsanders@mindspring.net> writes:
> And if I remember correctly, the RADIUS attributes will enable RFC1877
> for the corresponding session even if nasdns_info is set to off.
Yes. When the setting is disabled (which IMO should have been the
default and what was done in the earlier releases) then the RADIUS
attributes strictly control the use of the DNS information and RFC1877
support.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Thus spake David Bolen
>As a general comment that is true, and no switch would be forced to
>move to another channel or span based on release code. However, it
>might be that some switches (my discussion at the time was with an
>AT&T technician) might have the capability of trying to reroute a call
>around problem areas (such as network congestion) and so returning a
>congestion code might trigger the kind of behavior desired in certain
>configurations. Of course I still haven't tested this.
Alright...that was just the fruit of my discussion with GTE that I thought
I'd share with you kind folks. :)
>> You need to proactively take the channel out of
>> service (and yes, Local Out Of Service) does skip over and doesn't break a
>> hunt group.
>Except for the fact that service messages are not part of the NI-2
>standard (why not, I have absolutely no idea - the only thing it
>supports is initially bringing a channel into service, but not
>affecting it past that point), and are thus only available on
>particular switches when run in custom configuration (e.g., you can't
>use NI-2, which kind of defeats the purpose of a nice standardized
>signaling interface, eh?)
Hrmm....these PRI's are indeed 5ESS custom, but NI-2 doesn't have the
concept of putting a channel Local Out Of Service and having the switch
skip over it? That sucks.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
David Bolen <db3l@ans.net> writes:
> > We do the former when servicing or upgrading modems; it works well.
> > It's even clever enough to act like the "soft busy-out" feature of the
...
> You're welcome :-)
Don't be so sure you were the only voice crying out in the
wilderness. :-) We tested some of the first PRI cards, and after the
crying fits in our NOC subsided, we put together quite a laundry list
for USR. It would be interesting to know how many features and fixes
are requested in near-simultaneity by USR's customers.
> One suggestion would be that after your users have idled off but
> before you actually download the code, set the DS0 configuration (not
> the transient command table but the actual configuration) to out of
Good idea. I believe that's SOP. Like I said, I'm hearing this
secondhand from the hands-on people around here, but apparently
there's still a fairly significant window during which calls fall into
the ether.
-- Robert
Subject:Re: (usr-tc) OSPF From: Jeff Mcadams <jeffm@iglou.com> Date: 1997-07-30 17:31:48
Thus spake David Carmean
>Have you tested this? It's reported that the PM2s at least will
>run 230 Kbps. I presume the PM25 uses the same chipset. It's not
>"supported", but Livingston folks have said in public that "it
>works".
Yeah, but if they couldn't handle 16 14.4's and 8 28.8's on a PM-5, how are
they gonna handle 24 x2's on a single PM-25...I just think the box is gonna
fall over trying to push that much data around. Again, my knowledge is a
little dated, but the PM-25's that we have run a single 386 processor...the
netservers use 486's...and they're not doing all the framing (or don't have
to with ppp in modem setting), for some reason, I think the netservers are
going to be able to handle it just a tad bit better...part of this is
looking at what the respective systems are doing, and part of it is gut
instinct from running Livingston stuff in the past...
>I haven't run a TC chassis, but *every* *single* *one* of the
>NETServer/16s that I've come in contact with have had at least
>one modem fail within six months, usually more. Great idea,
>lousy implementation.
The MP's? Toss 'em out the door from everything I've heard....the chassis
based stuff is much more solid.
--
Jeff McAdams Email: jeffm@iglou.com
Head Network Administrator Voice: (502) 966-3848
IgLou Internet Services (800) 436-4456
Subject:Re: (usr-tc) ISDN problem From: Brian <signal@shreve.net> Date: 1997-07-30 18:05:12
> Brian <signal@shreve.net> writes:
>
> > in TCM what option is imdmCcStartV2 and what should it be set for?
>
> Hmm - I don't know - it's also part of the ISDN call control group
> (that's the "imdmCc" table) so presumably would be in the same area of
> TCM as the other setting you indicated. The MIB description is:
>
> "This object is used to set the data mode of the modem and
> is equivalent to *V2 = x AT command. Default =1"
>
> so maybe TCM has something about "data mode of the modem"?
>
> The default value is "autodetect", but you can restrict it to
> v.110/120 only, analog (modemOrFaxOnly), clear channel sync, async to
> sync PPP or x75.
I found this, its set for "autodetect", which is where we would want it
(as long as autodetect works! :) )
>
> > max b channels should be set at 46
>
> Should be or are? :-)
are :)
I am going to get the syslog output for a call to try and help me some
more.
>
> Ok, another thought - are you using (intentionally or unintentionally)
> resource pools on the PRI card? If you've got any resource pools
> defined based on dialed number on the PRI card, and you don't have the
> NETServer in the appropriate group, even though the PRI knows that it
> is an isdn-gw, it won't try to route calls there.
no resource pools, thank god!
Brian
>
> -- David
>
> /-----------------------------------------------------------------------\
> \ David Bolen \ Internet: db3l@ans.net /
> | ANS Communications, Inc. \ Phone: (914) 789-5327 |
> / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
> \-----------------------------------------------------------------------/
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) ISDN problem From: David Bolen <db3l@ans.net> Date: 1997-07-30 18:34:37
Brian <signal@shreve.net> writes:
> in TCM what option is imdmCcStartV2 and what should it be set for?
Hmm - I don't know - it's also part of the ISDN call control group
(that's the "imdmCc" table) so presumably would be in the same area of
TCM as the other setting you indicated. The MIB description is:
"This object is used to set the data mode of the modem and
is equivalent to *V2 = x AT command. Default =1"
so maybe TCM has something about "data mode of the modem"?
The default value is "autodetect", but you can restrict it to
v.110/120 only, analog (modemOrFaxOnly), clear channel sync, async to
sync PPP or x75.
But from your next paragraph your not falling back to these cards
anyway, so...
> Yes, because on those chassis, on the PRI card, you can show the DS0's and
> it will show ISDN-GW as whats handling the call, rather than QUAD-I-MODEM
Yep, that'll definitely indicate it.
> max b channels should be set at 46
Should be or are? :-)
Ok, another thought - are you using (intentionally or unintentionally)
resource pools on the PRI card? If you've got any resource pools
defined based on dialed number on the PRI card, and you don't have the
NETServer in the appropriate group, even though the PRI knows that it
is an isdn-gw, it won't try to route calls there.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) OSPF From: Robert Sanders <rsanders@mindspring.net> Date: 1997-07-30 18:48:11
Brian Elfert <brian@citilink.com> writes:
> Why wouldn't they use the same 4.0 OS now used on the Netserver/16? The
Good point; I've never seen a NETserver/16. Does the command line
look more like a Portmaster or a USR LANLinker?
-- Robert
Subject:(usr-tc) ISDN Problem, update From: Brian <signal@shreve.net> Date: 1997-07-30 20:16:33
Here is a capture of the hub I cannot receive ISDN calls on:
27:51:49.
Jul 30 20:14:31 usr1ts1 acct 00005289 dialnet: port S5 PPP succeeded dest
Negotiated
Jul 30 20:14:47 usr1ts1 dialnet: port S5 ppp_sync failed dest
Jul 30 20:14:48 usr1ts1 acct 00005289 dial: S5 hung up the phone. Call
duration
0:0:37.
Jul 30 20:14:49 usr1ts1 mpip_process_request:
Jul 30 20:14:49 usr1ts1 MPIP_LINK_DEREG_REQ
Jul 30 20:14:50 usr1ts1 ^M
Jul 30 20:14:50 usr1ts1 mpip_process_request:
Jul 30 20:14:50 usr1ts1 MPIP_LINK_DEREG_REQ
Jul 30 20:14:50 usr1ts1 ^M
Jul 30 20:14:50 usr1ts1 MODEM: S5: CALL_REF >0x0000528a< PRI_SLOT >0< TS
>8< SPAN >0< B_CH >1<
Jul 30 20:14:50 usr1ts1 acct 0000528a dial: S5 call arrived.
Jul 30 20:14:51 usr1ts1 sent out answer incoming call for S5.
Jul 30 20:14:53 usr1ts1 MODEM: S10: CALL_REF >0x0000528b< PRI_SLOT >0< TS
>25< SPAN >0< B_CH >6<
Jul 30 20:14:53 usr1ts1 acct 0000528b dial: S10 call arrived.
Jul 30 20:14:53 usr1ts1 sent out answer incoming call for S10.
Jul 30 20:15:03 usr1ts1 acct 0000528a dial: S5 answered the phone using
handle 5.
Jul 30 20:15:05 usr1ts1 acct 0000528a dialnet: port S5 PPP succeeded dest
Negotiated
Jul 30 20:15:06 usr1ts1 acct 0000528b dial: S10 answered the phone using
handle
10.
Jul 30 20:15:08 usr1ts1 acct 0000528b dialnet: port S10 PPP succeeded dest
Negotiated
Jul 30 20:15:09 usr1ts1 dialnet: port S5 ppp_sync failed dest
am.shreve.net
Jul 30 20:15:09 usr1ts1 mpip_process_request:
Jul 30 20:15:09 usr1ts1 [BIF IS NULL]
Jul 30 20:15:09 usr1ts1 [MPIP_LINK_REG_REQ]
Jul 30 20:15:09 usr1ts1 ^M
Jul 30 20:15:09 usr1ts1 mpip_process_response:
Jul 30 20:15:09 usr1ts1 ^M
Jul 30 20:15:09 usr1ts1 acct 0000528a dialnet: port S5 am succeeded dest
208.206.76.23
Jul 30 20:15:09 usr1ts1 dialnet: port S5 connection succeeded dest
am.shreve.net
That is what happens when someone tries to call in with ISDN, all that
MPIP stuff.
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) ISDN Problem From: Brian <signal@shreve.net> Date: 1997-07-30 21:29:19
Here is some output from when a ISDN user tries to dial in. He gets a
busy signal, this is only on our first hub. Analog calls work fine:
Here is a DEBUG output from PRI card during a call setup:
RX0: 02 01 64 72 08 02 1C E7 0F
TX0: 02 01 01 66
TX1: 00 01 01 01
RX1: 00 01 01 01
TX0: 00 01 01 67
RX0: 00 01 01 73
TX1: 00 01 01 01
RX1: 00 01 01 01
TX0: 00 01 01 67
RX0: 00 01 01 73
TX1: 00 01 01 01
RX1: 00 01 01 01
RX0: 02 01 66 72 08 02 1C A5 05 04 02 88 90 18 03 A9 83
8E 6C
TX0: 02 01 01 68
TX0: 00 01 72 68 08 02 9C A5 02 18 03 A9 83 8E
RX0: 00 01 01 74
TX0: 00 01 74 68 08 02 9C A5 07
RX0: 00 01 01 76
RX0: 02 01 68 76 08 02 1C A5 0F
TX0: 02 01 01 6A
TX0: 00 01 76 6A 08 02 99 ED 45 08 02 80 90
RX0: 00 01 01 78
RX0: 02 01 6A 78 08 02 19 ED 4D
TX0: 02 01 01 6C
TX0: 00 01 78 6C 08 02 99 ED 5A
RX0: 00 01 01 7A
TX0: 00 01 7A 6C 08 02 9C A5 45 08 02 80 90
RX0: 00 01 01 7C
RX0: 02 01 6C 7C 08 02 1C A5 4D
TX0: 02 01 01 6E
TX0: 00 01 7C 6E 08 02 9C A5 5A
RX0: 00 01 01 7E
TX1: 00 01 01 01
RX1: 00 01 01 01
Here is a syslog dump during call setup:
Jul 30 21:11:01 usr1ts1 acct 00000018 dialnet: port S14 PPP succeeded dest
Negotiated
Jul 30 21:11:04 usr1ts1 acct 00000018 dialnet: port S14 carla succeeded
dest 208.214.44.10
Jul 30 21:11:04 usr1ts1 dialnet: port S14 connection succeeded dest
usr1-10.shreve.net
Jul 30 21:11:16 usr1ts1 PRI: I0: CALL_REF >0x00000019< PRI_SLOT >0< TS
>23< SPAN >0< B_CH >14<
Jul 30 21:11:19 usr1ts1 acct 00000019 dialnet: port I0 PPP succeeded dest
Negotiated
Jul 30 21:11:20 usr1ts1 MODEM: S19: CALL_REF >0x0000001a< PRI_SLOT >0< TS
>24< SPAN >0< B_CH >15<
Jul 30 21:11:20 usr1ts1 acct 0000001a dial: S19 call arrived.
Jul 30 21:11:20 usr1ts1 sent out answer incoming call for S19.
Jul 30 21:11:22 usr1ts1 dialnet: port I0 ppp_sync failed dest
kheflin-gw.shreve.net
Jul 30 21:11:23 usr1ts1 mpip_process_request:
Jul 30 21:11:23 usr1ts1 [MPIP_LINK_REG_REQ]
Jul 30 21:11:23 usr1ts1 ^M
Jul 30 21:11:23 usr1ts1 mpip_process_response:
Jul 30 21:11:23 usr1ts1 ^M
Jul 30 21:11:23 usr1ts1 vtp_process_layer2_reg_response: Service Not
Provided by GW code = 36.Try backup if provided.
Jul 30 21:11:23 usr1ts1 mpip_process_request:
Jul 30 21:11:23 usr1ts1 MPIP_LINK_DEREG_REQ
Jul 30 21:11:23 usr1ts1 ^M
Jul 30 21:11:24 usr1ts1 mpip_process_response:
Jul 30 21:11:24 usr1ts1 ^M
Jul 30 21:11:25 usr1ts1 MODEM: S18: CALL_REF >0x0000001b< PRI_SLOT >0< TS
>25< SPAN >0< B_CH >14<
Jul 30 21:11:25 usr1ts1 acct 0000001b dial: S18 call arrived.
Here are some more syslog dumps:
...skipping
Jul 30 21:04:29 usr1ts1 acct 000052e3 dial: S6 hung up the phone. Call
duration
0:4:51.
Jul 30 21:04:29 usr1ts1 acct 000052e3 dialnet: port S6 session
disconnected dest usr1-48.shreve.net
Jul 30 21:04:30 usr1ts1 PRI: I0: CALL_REF >0x00000004< PRI_SLOT >0< TS >3<
SPAN
>0< B_CH >4<
Jul 30 21:04:31 usr1ts1 acct 00005261 dial: S50 hung up the phone. Call
duration 1:36:29.
Jul 30 21:04:31 usr1ts1 acct 00005261 dialnet: port S50 session
disconnected dest usr1-14.shreve.net
Jul 30 21:04:32 usr1ts1 MODEM: S9: CALL_REF >0x00000005< PRI_SLOT >0< TS
>4< SPAN >0< B_CH >5<
Jul 30 21:04:32 usr1ts1 acct 00000005 dial: S9 call arrived.
Jul 30 21:04:32 usr1ts1 sent out answer incoming call for S9.
Jul 30 21:04:33 usr1ts1 acct 00005262 dial: S31 hung up the phone. Call
duration 1:34:27.
Jul 30 21:04:33 usr1ts1 acct 00005262 dialnet: port S31 session
disconnected dest usr1-11.shreve.net
Jul 30 21:04:33 usr1ts1 acct 00000004 dialnet: port I0 PPP succeeded dest
Negotiated
Jul 30 21:04:36 usr1ts1 acct 00005265 dial: S17 hung up the phone. Call
duration 1:25:28.
Jul 30 21:04:36 usr1ts1 acct 00005265 dialnet: port S17 session
disconnected dest usr1-7.shreve.net
Jul 30 21:04:37 usr1ts1 dialnet: port I0 ppp_sync failed dest
208.214.45.17
Jul 30 21:04:37 usr1ts1 mpip_process_request:
Jul 30 21:04:37 usr1ts1 [MPIP_LINK_REG_REQ]
Jul 30 21:04:37 usr1ts1 ^M
Jul 30 21:04:37 usr1ts1 mpip_process_response:
Jul 30 21:04:37 usr1ts1 ^M
Jul 30 21:04:37 usr1ts1 acct 0000525c dial: S34 hung up the phone. Call
duration 1:39:28.
Jul 30 21:04:37 usr1ts1 acct 0000525c dialnet: port S34 session
disconnected dest usr1-5.shreve.net
Jul 30 21:04:38 usr1ts1 vtp_process_layer2_reg_response: Service Not
Provided by GW code = 36.Try backup if provided.
Jul 30 21:04:38 usr1ts1 mpip_process_request:
Jul 30 21:04:38 usr1ts1 MPIP_LINK_DEREG_REQ
Jul 30 21:04:38 usr1ts1 ^M
Jul 30 21:04:38 usr1ts1 mpip_process_response:
Jul 30 21:04:38 usr1ts1 ^M
Jul 30 21:04:40 usr1ts1 acct 00000003 dial: S7 answered the phone using
handle 7.
Jul 30 21:10:20 usr1ts1 acct 00000017 dialnet: port I0 PPP succeeded dest
Negotiated
Jul 30 21:10:21 usr1ts1 acct 00000010 dial: S14 hung up the phone. Call
duration 0:2:57.
Jul 30 21:10:23 usr1ts1 dialnet: port I0 ppp_sync failed dest
kheflin-gw.shreve.net
Jul 30 21:10:23 usr1ts1 mpip_process_request:
Jul 30 21:10:23 usr1ts1 [MPIP_LINK_REG_REQ]
Jul 30 21:10:23 usr1ts1 ^M
Jul 30 21:10:23 usr1ts1 mpip_process_response:
Jul 30 21:10:23 usr1ts1 ^M
Jul 30 21:10:24 usr1ts1 vtp_process_layer2_reg_response: Service Not
Provided by GW code = 36.Try backup if provided.
Jul 30 21:10:24 usr1ts1 mpip_process_request:
Jul 30 21:10:24 usr1ts1 MPIP_LINK_DEREG_REQ
Jul 30 21:10:24 usr1ts1 ^M
Jul 30 21:10:24 usr1ts1 mpip_process_response:
Jul 30 21:10:24 usr1ts1 ^M
Jul 30 21:10:45 usr1ts1 MODEM: S14: CALL_REF >0x00000018< PRI_SLOT >0< TS
>22< SPAN >0< B_CH >10<
Jul 30 21:10:45 usr1ts1 acct 00000018 dial: S14 call arrived.
Jul 30 21:10:45 usr1ts1 sent out answer incoming call for S14.
Jul 30 21:10:57 usr1ts1 acct 00000018 dial: S14 answered the phone using
handle
14.
Jul 30 21:11:01 usr1ts1 acct 00000018 dialnet: port S14 PPP succeeded dest
Negotiated
Jul 30 21:11:04 usr1ts1 acct 00000018 dialnet: port S14 carla succeeded
dest 208.214.44.10
Jul 30 21:11:04 usr1ts1 dialnet: port S14 connection succeeded dest
usr1-10.shreve.net
Jul 30 21:11:16 usr1ts1 PRI: I0: CALL_REF >0x00000019< PRI_SLOT >0< TS
>23< SPAN >0< B_CH >14<
Jul 30 21:11:19 usr1ts1 acct 00000019 dialnet: port I0 PPP succeeded dest
Negotiated
Jul 30 21:11:20 usr1ts1 MODEM: S19: CALL_REF >0x0000001a< PRI_SLOT >0< TS
>24< SPAN >0< B_CH >15<
If anyone has any ideas, im listening :)
Brian
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Robert Sanders <rsanders@mindspring.net> writes:
> Don't be so sure you were the only voice crying out in the
> wilderness. :-)
You are of course, entirely correct :-)
> It would be interesting to know how many features and fixes
> are requested in near-simultaneity by USR's customers.
Definitely. Although I'm also betting that there are more than a fair
share of ideas that are somewhat unique to particular customers or
customer bases. The good thing about that is that the end product
tends to get the amalgamate of each of those request sources and I for
example, end up with features I might not have thought to ask about
but are really nice, as well as those I (and others) pushed for.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
On Wed, 30 Jul 1997, Tatai SV Krishnan wrote:
> 3.5.34 - NETServer code
>
> set nasdns_info on
>
> will do this for you
>
> krish
Whats the command to set VPN local routing on? I dont think I see it
listed in 'help set' on 3.5.34
Subject:Re: (usr-tc) Total Control User Count via SNMP From: David Bolen <db3l@ans.net> Date: 1997-07-31 04:08:56
Bosco Tsang <bosco@ipoline.com> writes:
> Is it possible for me to get a user count for USR Total Control via SNMP,
> so that I can plot it out via MRTG? What are the OIDs?
I'm not sure how implementable these methods are with MRTG (is that an
SNMP display tool of some sort?), but if all you're really concerned
with is simultaneous port count (as opposed to username information or
other NETServer authentication type of stuff), there are a few
approaches you can take. The NETServer itself won't help all that
much (it supports very little via SNMP) but you can try:
* Walking the mdmCsStatus object. This will give you a list of
objects for each modem (e.g., mdmCsStatus.2001 is for modem 1 in
slot 2). Count those that have an enumerated value of
onlineAnswer(8) - or onlineOriginate(7) too if you do outbound,
and you'll have a count of "live" modems. You can look at other
enumeration values to see users that are training, or in other states.
It's not the fastest in the world, but walking a hub with 48 modems
should take about 10 seconds or so.
You can "cheat" if you know just how many modems there are, by
constructing a query that uses GetNext, and queries the objects just
in front of the known modems. For example, if you know you have 48
modems in slots 2-13, instead of doing 48 GetNext queries to walk
table dynamically, build a single query that queries the objects:
mdmCsStatus.2000, mdmCsStatus.2001,
mdmCsStatus.2002, mdmCsStatus.2003,
mdmCsStatus.3000, mdmCsStatus.3001,
(etc...)
mdmCsStatus.13002, mdmCsStatus.13003
and then issue a single GetNext query (or just a few to avoid making
the PDU too large). The instances will "roll" to the appropriate
modem (e.g., your .2000 query will get you modem 2001), and you'll
have many less PDUs to handle, cutting down the overhead. You can
query a hub worth of modems this way in only about 2-3 seconds.
Note that this approach is only useful for hubs where the modems
handle all callers, so if you have ISDN hubs that pass callers
right to the NETServer this won't count them.
* Ask your circuit card(s) what the status of their individual
span channels are. You can break it out by those that are connected
in or out, busied out, etc.. any of the enumerations as shown
in the MIBs for ds0StatDs0 (channelized T1) or ids0StatDs0 (PRI).
One approach is to actually walk the appropriate MIB tree but I
wouldn't recommend it if you can parse an opaque object instead,
because walking the DS0 status tree is deathly slow, even trying
the trick above - the interface to the T1/PRI cards is just too
slow.
Instead, I would suggest querying the newer bulk access objects
(ds0BulkAccessStatDs0Modem for channelized configurations and
ids0BulkAccessStatDs0Mdm for PRI). These objects are a single
opaque value with information on all channels in one query, and
allow you to query the span information in a single SNMP object
in well under a second. The instance for the objects is the
entity of the DS1 span (e.g., 1001 for the first DS1 in slot 1).
You do have to break the information apart a bit, once you get it
back, but for the performance it's worth it. For the channelized
T1 case the object is two bytes per channel. The first byte is
the ds0StatDs0 enumeration and the second the ds0StatModem
enumeration. So just pluck out every other byte for your DS0
channel status.
In the PRI case, the bulk object is 4 bytes per channel, the first
being the ids0StatDs0 enumeration, the second the ids0StatDevConnTo
enumeration, followed by ids0StatSlotConnTo and ids0StatChanConnTo
(the latter two are actually 0xFF for no connection which isn't
really documented in the objects themselves). So pluck out the
first of every 4 bytes and you've got your DS0 status.
Once you've got the status of your channels you can break them
out, and sum them up however you'd like.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) RFC1877 From: Peter Evans <peter@gol.com> Date: 1997-07-31 04:39:07
Ricardo Rizzi wrote:
| Is possible to configure the netserver card to send DNS in a PPP conection
| (RFC1877)???
aka: M$ dns?
I believe USR fixed it to do that for us.
P
----*
--
A well fed missile is a happy missile! - TRR 1997
O_u \\ Ciscomancer // P-Chan ya \\ Global OnLine Japan
U \Beh! \\ Postmonster // P-Moji-Yo! \\ Steam Engine Dept
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Brian <signal@shreve.net> Date: 1997-07-31 06:16:13
On Tue, 29 Jul 1997, Tom Bilan wrote:
> Mine locked up on me again last night. I talked to someone at USR and they
> said to set SW5 to nuke the config and then retype the config in because
> when upgrading it may mess up the config conversion.
I have seen the config get messed up yes, but I dont think thats whats
happening. Goto there web site, and throw field report #2245 in there
face.......its pretty much the same problem your having.
next time it happens, console in, do a show mem and a show stream, get
them the output......
>
> Sounds like a load of crap to me but I'm going to try it ONCE. After I type
> in all 700 set commands and it locks up 3 days later I'm going to be all
> over USR like white on rice.
>
When I opened my ticket with them for this EPIDEMIC problem alot of people
seem to be having, they act like they haven't heard this before.
> BTW: What's everyone's opinion on the last STABLE release of non quake lag
> code?
>
> Tom
>
> At 07:09 PM 7/26/97 -0500, you wrote:
> >On Sat, 26 Jul 1997, Brian Elfert wrote:
> >
> >>
> >>
> >> On Sat, 26 Jul 1997, William M Sheeler Sr wrote:
> >>
> >> > Both working fine (knock on wood). These are new units, purchased 6/97
> >> >
> >> > Been running and operational for about 2weeks now. Lots of users
> coming in
> >> > and hammering, with no ill effects.
> >> >
> >> > I have experienced no lost of ethernet at all.
> >> >
> >> > Are your conditions the same as mine?
> >>
> >> You may have the newer 'enhanced packet bus' Netserver card which doesn't
> >> have the problem. Also, I have the slightly older 'standard packet bus'
> >> Netserver card purchased 4/97, and I don't have the problem. Somebody
> >> mentioned that there have been many revs of the hardware for the older
> >> Netserver card, and that the most recent cards might not see the problem.
> >>
> >> I think you'll be fine.
> >>
> >> Brian
> >>
> >>
> >
> >
> >Most of the hubs here ARE Standard packet bus's, and we DO see the problem
> >(on Standard pb units).
> >
> >This is totally unacceptable. Users dial in, and cant get PPP, takes me
> >30 min before I am notified, and able to reboot the unit, this has been
> >going on now since the upgrade to 2.5.1. My users are pissed, and I am
> >starting to get a bad rap.
> >
> >USR gets a bad rap also, because its there x2 modems my users will be
> >blaming the problem on.
> >
> >Does Anyone know the status of this? Is this problem officially
> >acknowledged by USR? I think we have done all the "field testing" to show
> >that Standard packet bus netservers nics lock up with this new code.
> >
> >I hope this gets priority treatment, and we see a fix REAL soon.
> >
> >What are you all doing about this? Did you fall back to a older code rev?
> >If so, what is safe to fallback too? (Framed-Route is very important too
> >us, and I don't need 500 users complaining of Quake lag either if it can
> >be avoided).
> >
> >Brian
> >
> >
> >
> >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> >Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
> >UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
> >signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
> >oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> >
> >
> >
> >
>
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
On Thu, 31 Jul 1997, Laszlo Vecsey wrote:
> On Wed, 30 Jul 1997, Tatai SV Krishnan wrote:
>
> > 3.5.34 - NETServer code
> >
> > set nasdns_info on
> >
> > will do this for you
> >
> > krish
>
> Whats the command to set VPN local routing on? I dont think I see it
> listed in 'help set' on 3.5.34
>
>
set local_routing off/on
krish
\ T.S.V. Krishnan \
\ Network System Engineer \ ( : - : )
\ 3Com ............ \
----------------------------------------------/
tkrishna@bubba.ae.usr.com
----------------------------/ http://interproc.ae.usr.com ----/
Any Sufficiently advanced bug is indistinguishable for a feature.
- Rick Kulawiec
Subject:Re: (usr-tc) Unable to execute netsrvr.exe From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-31 08:54:00
->
In-Reply-To:
<199707291816.OAA13003@agape.wingnet.net>
-> Message-ID: <Pine.LNX.3.93.970729135431.26083A-100000@www.shreve.net>
-> MIME-Version: 1.0
-> Content-Type: TEXT/PLAIN; charset=US-ASCII
-> Sender: owner-usr-tc@xmission.com
-> Precedence: bulk
-> Reply-To: usr-tc@mail.xmission.com
->
-> On Tue, 29 Jul 1997, System Administrator wrote:
->
-> > I want to be able to launch netsrvr.exe from the TC software. I've >
-> installed it in the default c:\usrsuite directory, but it still gives > the
-> error above.
-> >
-> > Anyone know the trick for getting this to interoperate?
-> >
-> > Thanks,
-> >
-> > WingNET System Administrator
-> > 423-559-LINK (v)
-> > 423-559-5444 (f)
-> >
->
-> Ours does this also........
Copy the netserver.exe file to the \usrsuite\tcm\ directory to fix this.
Jeff Binkley
ASA Network Computing
Subject:(usr-tc) OSPF From: Brian Elfert <brian@citilink.com> Date: 1997-07-31 11:04:15
On 30 Jul 1997, Robert Sanders wrote:
> Brian Elfert <brian@citilink.com> writes:
>
> > Why wouldn't they use the same 4.0 OS now used on the Netserver/16? The
>
> Good point; I've never seen a NETserver/16. Does the command line
> look more like a Portmaster or a USR LANLinker?
The 4.0 version is the first version not based on Livingston code. It is
not Portmaster like anymore. The release notes do say it's based on the
OS developed for the Lanlinker.
I'm assuming this same OS will be migrated to the Netserver card
eventually, as Livingston is not going to permit use of ComOS forever.
Livingston already wanted USR to quit using ComOS last year.
I'm assuming a whole new OS is being developed for the Hiper since it no
longer has an x86 processor.
Brian
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Pete Ashdown <pashdown@xmission.com> Date: 1997-07-31 11:37:41
Tom Bilan said once upon a time:
>BTW: What's everyone's opinion on the last STABLE release of non quake lag
>code?
And which code would that be? We still have problems on 3.5.34. The best
thing that we've been able to do is switch to QuakeWorld.
Which is the last firmware version to X.25/PAD Card?
Is it compatible with TCS 2.5.1?
I have tryed to use X.25/PAD Card v.3.0.2 with TCS 2.5.1, but the card
doesn't work. If I do a downgrade on TCS to v.2.5.0, the card works ok.
Rizzi
Subject:Re: (usr-tc) Quake problems From: Jason S Kohles <robobob@xmission.com> Date: 1997-07-31 12:05:12
On Thu, 31 Jul 1997, Jeff Binkley wrote:
> On another note can someone point me in the direction on what is involved in
> setting up a Quake server ? A FAQ would be great. Also I am curious as to
> what folks are charging for use of their Quake servers and how large the
> market is for it.
>
Quake and Quakeworld servers for most platforms are available at
http://www.stomped.com/, I doubt anyone is charging for quake server usage,
and if anyone is, it is unlikely there is anyone playing on that server,
since there are hundreds of free servers.
Jason Kohles -- System Administrator -- XMission Internet Access
robobob@xmission.com (at work) robobob@mindwell.com (at play)
"One-seventh of your life is spent on Monday."
Subject:(usr-tc) Quake problems From: Robert Sanders <rsanders@mindspring.net> Date: 1997-07-31 12:16:32
Many of our customers have complained of extreme lag when playing
Quake. Judging from the USR bug reports and other posts here, we're
not alone. What brings this problem into sharp relief for us is that
we're gradually converting our TC+PM25 chassis into TC+NETservers, and
the PM25s didn't exhibit this laggy behavior. In fact, this and the
NETserver's habit of severely corrupting packets when forced to
fragment them for low-MTU links are the only major PM to NETserver
issues remaining for us.
Has anybody had *any* success with USR's recent releases fixing the
Quake problems? If so, which versions? Any information you can pass
along would be appreciated.
-- Robert
Subject:Re: (usr-tc) Total Control User Count via SNMP From: Bosco Tsang <tstsang2@ipoline.com> Date: 1997-07-31 12:17:49
Hi David,
At 04:08 AM 7/31/97 EDT, you wrote:
>I'm not sure how implementable these methods are with MRTG (is that an
>SNMP display tool of some sort?) ...
MRTG is a web graph display tool, which can query router via SNMP. It's
quite a nice tiny tool that can display information from 5 minutes interval
to 1 year interval. You can find out more about MRTG in their web page
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html.
From your suggestion, seems that it will involve quite a number of gets
which will tight up the already busy server. Is there any simplier SNMP
enquiry that can do the same. I've setted up MRTG for the ascend max and
just a simple MIB (snmpget -v 1 host.domain commstring
.1.3.6.1.4.1.529.15.9.0) can do the work. Aren't there any similiar MIB for
the TC?
Thanks and Regards,
Bosco Tsang
InterPacific Online
tstsang@ipoline
Subject:Re: (usr-tc) Quake problems From: Brian <signal@shreve.net> Date: 1997-07-31 13:22:14
On 31 Jul 1997, Robert Sanders wrote:
> Many of our customers have complained of extreme lag when playing
> Quake. Judging from the USR bug reports and other posts here, we're
> not alone. What brings this problem into sharp relief for us is that
> we're gradually converting our TC+PM25 chassis into TC+NETservers, and
> the PM25s didn't exhibit this laggy behavior. In fact, this and the
> NETserver's habit of severely corrupting packets when forced to
> fragment them for low-MTU links are the only major PM to NETserver
> issues remaining for us.
>
> Has anybody had *any* success with USR's recent releases fixing the
> Quake problems? If so, which versions? Any information you can pass
> along would be appreciated.
Yep, I think Quake lag got fixed somewhere near 3.4.3X. Current release
version of Netserver 3.4.34 does not have the Quake lag problem.
>
> -- Robert
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:Re: (usr-tc) Quake problems From: Brian <signal@shreve.net> Date: 1997-07-31 13:22:14
On 31 Jul 1997, Robert Sanders wrote:
> Many of our customers have complained of extreme lag when playing
> Quake. Judging from the USR bug reports and other posts here, we're
> not alone. What brings this problem into sharp relief for us is that
> we're gradually converting our TC+PM25 chassis into TC+NETservers, and
> the PM25s didn't exhibit this laggy behavior. In fact, this and the
> NETserver's habit of severely corrupting packets when forced to
> fragment them for low-MTU links are the only major PM to NETserver
> issues remaining for us.
>
> Has anybody had *any* success with USR's recent releases fixing the
> Quake problems? If so, which versions? Any information you can pass
> along would be appreciated.
Yep, I think Quake lag got fixed somewhere near 3.4.3X. Current release
version of Netserver 3.4.34 does not have the Quake lag problem.
>
> -- Robert
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET
UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612
signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Subject:(usr-tc) Quake problems From: Jeff Binkley <jeff.binkley@asacomp.com> Date: 1997-07-31 13:45:00
-> Many of our customers have complained of extreme lag when playing Quake.
-> Judging from the USR bug reports and other posts here, we're not alone.
-> What brings this problem into sharp relief for us is that we're gradually
-> converting our TC+PM25 chassis into TC+NETservers, and the PM25s didn't
-> exhibit this laggy behavior. In fact, this and the NETserver's habit of
-> severely corrupting packets when forced to fragment them for low-MTU links
-> are the only major PM to NETserver issues remaining for us.
->
-> Has anybody had *any* success with USR's recent releases fixing the Quake
-> problems? If so, which versions? Any information you can pass along would
-> be appreciated.
On another note can someone point me in the direction on what is involved in
setting up a Quake server ? A FAQ would be great. Also I am curious as to
what folks are charging for use of their Quake servers and how large the market
is for it.
Thanks in advance,
Jeff Binkley
ASA Network Computing
Subject:RE: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: Tom Bilan <tom@tdi.net> Date: 1997-07-31 14:00:44
------ =_NextPart_000_01BC9DBA.240C6040
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Been running QW for a few months. Occassionally someone will get a > 1000 ping and then it
starts happening to all my dialed up users.
3.5.34 seems to have helped that problem (at least that is what the players tell me) but now the
Netserver card just plain locks up.
Tom
-----Original Message-----
Sent: Thursday, July 31, 1997 1:38 PM
Tom Bilan said once upon a time:
>BTW: What's everyone's opinion on the last STABLE release of non quake lag
>code?
And which code would that be? We still have problems on 3.5.34. The best
thing that we've been able to do is switch to QuakeWorld.
------ =_NextPart_000_01BC9DBA.240C6040
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+Ii0SAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht
aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P
BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT
TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA
AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np
b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQA3AAAAUkU6ICh1
c3ItdGMpIDMuNS4zNCBtYWtlcyBteSBuZXRzZXJ2ZXIgZXRoZXJuZXQgbG9ja3VwAE0SAQWAAwAO
AAAAzQcHAB8ADgAAACwABAA4AQEggAMADgAAAM0HBwAfAA0AOwAWAAQAXAEBCYABACEAAABFREFD
OEMzNzk4MDlEMTExOUJGRDAwNjA5NzdCMjg5QwA9BwEDkAYAdAYAACEAAAALAAIAAQAAAAsAIwAA
AAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAgL1dqtudvAEeAHAAAQAAADcA
AABSRTogKHVzci10YykgMy41LjM0IG1ha2VzIG15IG5ldHNlcnZlciBldGhlcm5ldCBsb2NrdXAA
AAIBcQABAAAAFgAAAAG8nduqXTeMrO8JmBHRm/0AYJd7KJwAAB4AHgwBAAAABQAAAFNNVFAAAAAA
HgAfDAEAAAAMAAAAdG9tQHRkaS5uZXQAAwAGENGm6MIDAAcQRQIAAB4ACBABAAAAZQAAAEJFRU5S
VU5OSU5HUVdGT1JBRkVXTU9OVEhTT0NDQVNTSU9OQUxMWVNPTUVPTkVXSUxMR0VUQTEwMDBQSU5H
QU5EVEhFTklUU1RBUlRTSEFQUEVOSU5HVE9BTExNWURJQUxFRFUAAAAAAgEJEAEAAABCAwAAPgMA
AIEEAABMWkZ1pyUcfHcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcThwKDAFAO9nBycTIP9iZ9CoAI
yCA7CW8yNWY1AoAKgXVjAFALA2MDAEELYG5nMTAzMwkLpiBCCeEgcnVuwwMAFXAgUVcgAhAFwB5h
F1AH0QRgAjBocy5AICBPY2NhBBBpQwIgB0BseSBzA3BlmQIgZSAD8BkwIGcPwJkXkT4gFZAa0CBw
FvLZAHBkIBgwFoFpBUEKsT0KgHMBkAAgBCAPgHBwswnwFvJ0bxeQGhFtGVDGZAcxCYAgdXAekA+w
DQ+gLhwkHCQzLjUu7DM0GWAJ4G0EIB2RD4C2dhnQG7BsHSAbgmEFQM0RQG8CYCCAICgh0R5g/xjA
BUAhswQAGeAhwhuhGwA9C2B5HvEbkCFQHeFlKcggYnUFQG5vB+Abof8cJAfAHMAEkCEQBcAYsAsg
PCBqHtAh4QtiIrBvY+5rBCAeoB8rVANwHzoK9PBsaTM2AUAVEAFAIgEJJLBjdBCEMTYgLfUsMk8F
EGcLgAdABdAHkPxzYRpALDMfNitEKxELE8ErRmktMTQ0AUAqkBwxOBrQDMEv02IgRtUDYToMg2IP
4FAPwBnQMEFzaGQlkAOgW1MwTVRQOgqwMlRAeJZtBAEY8S4FoG1dHzVPMQAGYAIwMWdUaAhwc0Jk
JFAsIEp1GUEzQjE2YDE5OTcasDr0Mzgx4E00hylAMWce0GByLXRjQADAAxAuYzO6NIh1YmorcTFn
UnxlOiJwORQlIB/1AMBr/weRHgEZwCZ2D8AbsASgGlH/J/IeoC3fLuoqlAu2KPYWULcDEAORLUBp
G4ACIGMZ0HceoAIgF5F0B3ExYB9JPqhCVFc8QFchwScEINplJrF5GbFF4W8bERjxD0NhI+MLYCLx
U1RBQjxMRRagIVAi0RnQb2azJXEDoHF1PXFHoWdE5WsFoAEAPx86QRtxI6BpXw9wJuAEcRngCGBs
IZVi+0qQGHBXGdAcgBoCIPMiBf9GoQOgH/QYYTXgGdBNEByA7xwkGDAdUyHCd0aAIRFNEP8WgQGg
HmAdgjJwI2ID4TlQ60vwHZFRSXJXBbBMkB8rBRIBAFUAAAADABAQAAAAAAMAERABAAAAAwCAEP//
//9AAAcwQO7PedudvAFAAAgwQO7PedudvAELAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA
AAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAA
UoUAALcNAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAmgAggBgAA
AAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA
MIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUA
AAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAA
wAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAAB
AAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAA4YA=
------ =_NextPart_000_01BC9DBA.240C6040--
Subject:RE: (usr-tc) Quake problems From: Tom Bilan <tom@tdi.net> Date: 1997-07-31 14:03:20
------ =_NextPart_000_01BC9DBA.8172E600
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Try rec.games.computer.quake.servers or www.stomped.com
It's basically simple. Just download the Quakeworld Server software and
type 'qwsv' at the prompt.
Tom
-----Original Message-----
Sent: Thursday, July 31, 1997 2:45 PM
-> Many of our customers have complained of extreme lag when playing Quake.
-> Judging from the USR bug reports and other posts here, we're not alone.
-> What brings this problem into sharp relief for us is that we're gradually
-> converting our TC+PM25 chassis into TC+NETservers, and the PM25s didn't
-> exhibit this laggy behavior. In fact, this and the NETserver's habit of
-> severely corrupting packets when forced to fragment them for low-MTU links
-> are the only major PM to NETserver issues remaining for us.
->
-> Has anybody had *any* success with USR's recent releases fixing the Quake
-> problems? If so, which versions? Any information you can pass along would
-> be appreciated.
On another note can someone point me in the direction on what is involved in
setting up a Quake server ? A FAQ would be great. Also I am curious as to
what folks are charging for use of their Quake servers and how large the market
is for it.
Thanks in advance,
Jeff Binkley
ASA Network Computing
------ =_NextPart_000_01BC9DBA.8172E600
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64
eJ8+IhYSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAyAEAAAEAAAAQAAAAAwAAMAIAAAAL
AA8OAAAAAAIB/w8BAAAATwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHVzci10Y0BtYWlsLnht
aXNzaW9uLmNvbQBTTVRQAHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAHgACMAEAAAAFAAAAU01U
UAAAAAAeAAMwAQAAABkAAAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAwAVDAEAAAADAP4P
BgAAAB4AATABAAAAGwAAACd1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20nAAACAQswAQAAAB4AAABT
TVRQOlVTUi1UQ0BNQUlMLlhNSVNTSU9OLkNPTQAAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAABkA
AAB1c3ItdGNAbWFpbC54bWlzc2lvbi5jb20AAAAAAgH3XwEAAABPAAAAAAAAAIErH6S+oxAZnW4A
3QEPVAIAAAAAdXNyLXRjQG1haWwueG1pc3Npb24uY29tAFNNVFAAdXNyLXRjQG1haWwueG1pc3Np
b24uY29tAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAArFkAQSAAQAcAAAAUkU6ICh1
c3ItdGMpIFF1YWtlIHByb2JsZW1zADsJAQWAAwAOAAAAzQcHAB8ADgADABQABAAjAQEggAMADgAA
AM0HBwAfAA4AAgARAAQAHwEBCYABACEAAABGOUFDOEMzNzk4MDlEMTExOUJGRDAwNjA5NzdCMjg5
QwAzBwEDkAYAGAgAACEAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAA
AwA2AAAAAABAADkAQEPEB9ydvAEeAHAAAQAAABwAAABSRTogKHVzci10YykgUXVha2UgcHJvYmxl
bXMAAgFxAAEAAAAWAAAAAbyd3AfEN4ys+gmYEdGb/QBgl3sonAAAHgAeDAEAAAAFAAAAU01UUAAA
AAAeAB8MAQAAAAwAAAB0b21AdGRpLm5ldAADAAYQtaupKwMABxAwBAAAHgAIEAEAAABlAAAAVFJZ
UkVDR0FNRVNDT01QVVRFUlFVQUtFU0VSVkVSU09SV1dXU1RPTVBFRENPTUlUU0JBU0lDQUxMWVNJ
TVBMRUpVU1RET1dOTE9BRFRIRVFVQUtFV09STERTRVJWRVJTT0ZUVwAAAAACAQkQAQAAAAEFAAD9
BAAANAcAAExaRnXhPGzEAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzOdAfcgAqQD4wIAY2gKwOBzZXQw
IAcTAoMAUKEQdnBycTIRdn0KgNkIyCA7CW8OMDUCgAqBbHVjAFALA2MSEgvEIBBUcnkgCXBjLmcK
YQeBLgWgbXB1dAEEkC5xdWFrZS65ETBydgSQBCAFsXcZ0P0ZEHQYQQmAGCIKogqECoDISXQnBCBi
YQ3RB0AubBdwAJAYUGwZACAgBEp1GhAgZG93bgEJAGFkIHRoZSDqURjSdwWwbB3ABmEZUfUcYG8B
gHcKwB4AAHALMQka4nR5GlAgJ3F3+HN2Jx/ABUAd4hLAGEE0dC4aylQarAr0bGl8MzYBQBaQAUAh
kRiAY0J0EgQxNiAtJbJPPQUQZwuAB0AF0AeQc2H8Z2UlsxrGJMQkkQsTJMZgaS0xNDQBQCQQMRw4
MAFADNApU2IgRlUDYToMg2IRYEoBESAaQguAaxywF3BbU02QVFA6agERLmIr1N5AG+AA0BhBGCJd
GsUqgCcGYAIwKudUaAhwc2SYYXksHPEcQTMxMBAAMTk5NyAyOjTwNSBQTS43IsAq5x0QYHItdGNA
AMADEC50eG0EAWkCIBqJLqF1rmIsoCUAKucoMsQpHhTzIYICYGVtEMAnbyh5JBTzC7Ya0y0+BdAA
cBdwH1DzGZAIcCBjHREDcBliEQA/GVA7IBhBC2IJgDqyZXjWdAlwB4AgC2BnGcAd8PsDoAtReQuA
PaAeIyH1OkE9HQBkJjE9oANSHdNVU9pSG8B1PaAJcHAJEQQg/x/RGZAd4QXAQTAaEDuxBJCiZTAQ
d2UnH6FuJNBvH8AJADyQPuhXEQAFQGK/BRAPIAQgHeAEADa2IAuA9xogHGARAXAXgSQQARA/8P8F
sR0QRgBFIiEhQvQJwB2wrxjQHDE55wWgbhlRdD5S8TryVEMrMWAOMDsgEQCPM7FHgUYiSpFORVQZ
JR8wEEGSHeJKwgQgZGlk/G4nJRA59j0ARVAs8CEyy0VhPYFnF3BiZTvRM9CrGKAc4EkDoGYA0HQw
EP9FQ0zWTBcboREATuIfUDnnnxEwGVFG0BdwBaFydQUwez5SCrBjGPBBYT3DRzFj/zyhRjEDUCbQ
B4ACMB3SQDDTRzIJAHctLGBVPXAr0X83NTpBH5Id4gIgHEEAwGrfBbExYFYiTBdHkXMKUAQgvz0x
C3E/w0dDPuc550gb4HUfwXkG4GQXcBEAHcAq/TqBKhxgFgBV8AQRA/Ad4N9AghuhF5FWskbBZRvg
B5G9KSB4PlId5znnNsY/UGHfK6AfQELRRVAQ8CAZUjPR/WMxQTqRC4BHMQDASgACIPwgeQhgOyAD
kQqwBBFDkr89oQhgHqA550/QH8BwEsDfBZAHMBiAGnAayk8DoABw/0HUQ1E8AQORH0AHgEOxQiH/
RhFZoB4AC4Ad002wF5Flk+9lsT3AISFLY3YG8BlQHcD/C4Ea0xExSgNUgB/ANlVapeVjQUEqkEFR
ZwRn4gnB8yEgHNFBbB9AUHAfwEAw3zswBRAIYEFxRSFvGsRtM/0CEGxYMFjTEPI/tEdDWUHfK6Ad
4Wxwb4tBdGgdYD1x93TwWQQAwHJVIRrERWFHMr9O8CH8EQBYIWviHbB2AHCdVfAsGsorehrEQVNw
kOcHwB9wBbBrIAhQGFI+URci/gqAE4EAgDAAAAADABAQAAAAAAMAERAAAAAAAwCAEP////9AAAcw
YE3j4dudvAFAAAgwYE3j4dudvAELAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAI
IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALcN
AAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAmgAggBgAAAAAAwAAA
AAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAIIAYA
AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAe
AEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAAAAAA
AEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAA
AAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAAZxc=
------ =_NextPart_000_01BC9DBA.8172E600--
Subject:Re: (usr-tc) 3.5.34 makes my netserver ethernet lockup From: David Bolen <db3l@ans.net> Date: 1997-07-31 15:32:09
tom@tdi.net (Tom Bilan) writes:
> Mine locked up on me again last night. I talked to someone at USR and they
> said to set SW5 to nuke the config and then retype the config in because
> when upgrading it may mess up the config conversion.
If you upgrade to 3.5.x from a release earlier than 3.4.x there are in
fact some problems - particularly you may find your user table,
netmask table or global RADIUS settings get corrupted. I think you
have to be back as far as 3.2.x for the RADIUS settings, but going
from 3.3.x I believe hits the other items.
(This falls I believe under the issue that transparent upgrades are
supported between releases but not guaranteed across larger spans. So
if you had a 3.2.x system, first upgraded to 3.3.x then 3.4.x and
finally 3.5.x you wouldn't lose anything, but the loss is kind of
minimal anyway, so...)
However, just deleting the corrupted entries and readding them should
deal with it. I don't think they should have any impact on managing
to hang the ethernet (as I've experienced as well).
> Sounds like a load of crap to me but I'm going to try it ONCE. After I type
> in all 700 set commands and it locks up 3 days later I'm going to be all
> over USR like white on rice.
Do you have an automated way to send those initial commands? Keeping
them in a file (or generated by a script) and sending to NETServers
automatically during initial config works very well for us. (I'm
assuming the answer is yes due to the number of commands - if no, then
I sympathize with you :-))
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Total Control User Count via SNMP From: David Bolen <db3l@ans.net> Date: 1997-07-31 15:51:28
Bosco Tsang <tstsang2@ipoline.com> writes:
> >From your suggestion, seems that it will involve quite a number of gets
> which will tight up the already busy server. Is there any simplier SNMP
> enquiry that can do the same. I've setted up MRTG for the ascend max and
> just a simple MIB (snmpget -v 1 host.domain commstring
> .1.3.6.1.4.1.529.15.9.0) can do the work. Aren't there any similiar MIB for
> the TC?
I don't believe so. I don't know what that particular Ascend object
represents but the problem from my perspective is that I'm not sure
what kind of single object would be appropriate in the USR chassis.
It's somewhat ambiguous to ask a question about how many users, since
that might be phrased as how many lines are in use, how many modems,
how many packet bus sessions, how many TDM slots, etc.. The NMC
doesn't track all of the possibl aggregation points and summarize them
in single objects, although I guess some of those aggregations would
be useful. I think an advantage Ascend has in this regard is that
their box is a bit more tightly coupled whereas the management setup
for the USR chassis is more loosely coupled (with all sorts of
combinations of cards you can mix and match which may work
differently).
We get around this by having our management code that runs locally in
all of our racks track the callers that enter and leave a rack so that
the management daemon knows subtotals for usage in real time and it
makes that available via SNMP. So to answer a question like yours we
actually poll our management daemon rather than the chassis itself.
But that requires a hefty startup cost in terms of getting such a
daemon operational.
None of this really seems to be that much of a problem for MRTG
though. I grabbed a copy of 2.4.1, and it doesn't require that it be
a single object. You can use external programs to gather data in any
form you want and return the resultant value to MRTG for display. For
example, the contrib directory actually has an "ascendget" function
that uses a TCL snmpwalk to do very much like the modem status
suggestion I had for the USR chassis - it walks a modem status object
counting those that are in a connected state, and then returning that
total for MRTG to use. You could probably model your setup for the
USR gear on something like this sort of external poller for MRTG.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ Internet: db3l@ans.net /
| ANS Communications, Inc. \ Phone: (914) 789-5327 |
/ 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \
\-----------------------------------------------------------------------/
Subject:Re: (usr-tc) Total Control User Count via SNMP From: Bosco Tsang <bosco@ipoline.com> Date: 1997-07-31 17:32:43
Hi David,
At 02:13 PM 7/31/97 -0400, you wrote:
> * Walking the mdmCsStatus object.
Where can I get hold of the OID for this and other related MIB? It seems
not in the mdmMib-II group.
Thanks and regards,
Bosco Tsang
InterPacific Online
bosco@ipoline.com
On Thu, 31 Jul 1997 13:22:14 -0500 (CDT), Brian <signal@shreve.net>
wrote:
>> Has anybody had *any* success with USR's recent releases fixing the
>> Quake problems? If so, which versions? Any information you can pass
>> along would be appreciated.
>
>Yep, I think Quake lag got fixed somewhere near 3.4.3X. Current release
>version of Netserver 3.4.34 does not have the Quake lag problem.
>
I did some testing with a PM2E-30 (v3.3.3, individual analog lines), a
USR hub (3.5.34, dual PRI), and a local quake server, quake.dfa.net.
As far as Quake lag goes, the PM2 was much less latent with average
in-game ping times ranging from 150-250ms. The USR hub running 3.5.34
averaged 300-800ms. The PM2 call connected at 26.4, and the USR call
connected at 28.8. I used a Supra 28.8 modem on the client.
3.5.34 has not fixed the Quake lag problem for me.
Looking at the "Field reports" on USR's customer service web-site,
report ID 2135 is titled "Quake Causes the Latency in the NETServer".
The software revisions reported to have the problem in the report are
3.4.23 and 3.5.31. The work around they suggest is moving to 3.5.93.
Is anybody running 3.5.93? Is it stable? Does it get rid of "Quake
lag"?
Regards,
Russ