There are several executables in /usr/OV/bin which are not for customer
use. We ship them for a variety of reasons. Some we ship because we use
them during installation or under the covers for something else, and some
have been decremented from old releases, but are still shipped in case
someone had a customized set-up using them. More recently for example,
7.1 still ships xnmbrowser2 even though it is no longer on the menus.
Someday, someone will probably be given the job of removing all the
obsolete or non-functioning code in /usr/OV/bin. In the meantime, it
still ships. A note has been added to more recent release notes to the
effect that if we don't document it, then we may not still support it.
I personally have never seen xnmtelnet work, and someone would probably
have to take the code apart to see what it really does. I'd have to do
the same for deathtrap, but I think it was something they built back when
the marketing folks wanted to license NetView by the size of your network.
If you weren't licensed for it, I think deathtrap would stop everything
from working. I could be wrong about that, but that's what some part of
memory is telling me. In either case, they are probably not anything you
would want to use. Regular telnet works just fine, and I am not certain
that the hooks for deathtrap are still enabled. Probably not.
There are many reasons why snmptrap may be slow, and perhaps even slower
in your particular environment. First, it has a call to NetView security,
as do all the "snmpnnnn" commands. Second, it makes calls to a shared
libraries, which might slow it down as well. You can use the snmptrap
executable which ships with MLM if you like. It has a slightly different
syntax, but it installs standalone. It is all self-contained -- no
libraries and no security.
Alternatively, you could use any programming language you like so send
stuff to port 162/udp. I've attached a PERL script we've found useful
here (don't know it's origin, so if it's copyrighted I apologize in
advance. This one sends an authentication error for host 0.0.0.0. The
downside is that you have to code the hex directly. But it's a good
"hacker" tool -- you can send invalid as well as valid stuff, and SNMP V2
if you can code it, which you cannot do with snmptrap. You need a
relatively new version of PERL to run this -- one that supports socket
programming -- such as ships with AIX 4.3.3 these days.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Allison, Jason (JALLISON)" <JALLISON@arinc.com>
06/27/2002 02:11 PM
To: "'nv-l'" <nv-l@lists.tivoli.com>
cc:
Subject: [nv-l] /usr/OV/bin
/usr/OV/bin/snmptrap -
1. Is there a way to make this call in a non-blocking manner? I am
trying
to 'flood' one of our NMS for testing purposes. The snmptrap call will
not
return to the parent until in completes, i.e. ~1 trap .5 seconds, which is
not quick enough for me.
2. I have been unsuccessful trying to get the syntax correct for
specifying
additional parameters. Without additional parameters I will get FMT
errors
in the Events Window.
/usr/OV/bin/deathtrap -
1. What is this, no man-page on it.
/usr/OV/xnmtelnet -
1. Cant get this to work, would like to know what it is and how to use
it.
PS Is there an API for sending traps (UDP) to the NMS...quickly? Does
anyone have any source for doing this outside of Netview?
Thanks,
Jason Allison
Principal Engineer
ARINC Incorporated
Office: (410) 266-2006
FAX: (410) 573-3026
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
socktrap.auth.pl
Description: Binary data
|