You are correct that there is a problem with snmptrap -t and traps sent via
tcp in NetView V5.1 and 5.1.1.
The trapd daemon was deleting everything in an application's queue when it
disconnected. This should not affect applications like MLM which connect
and stay connected. But others, like snmptrap -t, will have there traps
deleted before they can be processed. APAR IX87601 has been taken for
this. If you need an efix now, please contact Support.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Date: Fri, 26 Mar 1999 14:51:36 -0700
From: Bob Engley <bob.engley@UALBERTA.CA>
Subject: MidLevel Manager's snmptrap app.
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Folks,
I have been using NetView's midlevel manager to forward local
traps to NetView using default port 162 , but using TCP instead
of UDP. (Yes, we have a firewall!) This all works fine.
However (There always seems to be a glitch), when testing the
link I sometimes would like to use snmptrap (the standalone)
application that comes with MidLevel Manager, and to make things
simple - NOT go through the midLevel manager, but send the trap
directly to our NetView machine. The fact that "snmptrap -t ..."
doesn't reach Netview, but that "snmptrap ..." through the mlm
does work suggests that the snmptrap application doesn't work
correctly with tcp (the -t parameter)
Has anyone had any success using snmptrap and tcp?
--
/in haste
/Bob
|