It should be possible to pass all the SNMP variables onto to a script and
perhaps decode it that way and (re)generate a properly converted trap?
I've got exactly the same problem with Backup_Exec and got the same answer
from Seagate. Am trying to scope out what I need to do in the script
now.....
Neil Whitehead (x22808)
IT Services (Telecoms)
The Royal Bank of Scotland
Tel: 0131-523 2808
e-mail: whitern@rbos.co.uk
> -----Original Message-----
> From: James Shanks [SMTP:James_Shanks@TIVOLI.COM]
> Sent: Monday, May 03, 1999 12:27 PM
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Re: amending values in a netview snmp event
>
>
> *** Warning : this message originates from the Internet ****
>
> I don't see how this can be done. No conversion facility is provided.
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
>
>
> "Rafter, Marcel A." <marcel.rafter@NZ.UNISYS.COM> on 05/02/99 07:41:08 PM
>
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on
> NetView <NV-L@UCSBVM.UCSB.EDU>
>
> To: NV-L@UCSBVM.UCSB.EDU
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: Re: amending values in a netview snmp event
>
>
>
>
>
> The problem is with inoculan and arcserve(cheyenne products) snmp traps
> for
> netware.
> These traps come into netview with the information in hex.
> I questioned this group about this before and you replied with:
> "I'll bet if you translate the hex, in addition to the printable
> ASCII
> characters, there are non-printable ones, like pads of x'00'.
> When
> NetView gets a trap which says it is sending ASCII
> but contains non-printable stuff, it "assumes" that what it is
> getting is
> something like a MAC address and displays it all in hex, because
> it
> has no
> idea which characters are significant and which aren't. There is
> nothing
> you can do about it, except to notify the vendor who is sending
> the
> malformed trap and ask him to change it. He should agree, since
> sending
> non-printable characters in an octet string is a violation of SNMP
> protocol.
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support"
> Which is spot on.
> I have contacted the vendor about this, they have past the problem
> onto their development team, but I think thats all I'll hear from them for
> some time.
> In the meantime I have to finish this project.
> If possible I would like netview to convert the data from hex to ascii
> before forwarding the event to the TEC server.
> Ideas?
>
> Thanks heaps
> Marcel.
>
> -----Original Message-----
> From: James Shanks [mailto:James_Shanks@TIVOLI.COM]
> Sent: Saturday, 1 May 1999 00:41
> To: NV-L@UCSBVM.UCSB.EDU
> Subject: Re: amending values in a netview snmp event
>
>
> What ultimately are you trying to do? Tell us that first and perhaps we
> can suggest how best to do it. Your overrides in a ruleset will not
> affect the trapd.log. They only affect what happens to the event after
> you
> change it.
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
>
>
> "Rafter, Marcel A." <marcel.rafter@NZ.UNISYS.COM> on 04/30/99 12:04:12 AM
>
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on
> NetView <NV-L@UCSBVM.UCSB.EDU>
>
> To: NV-L@UCSBVM.UCSB.EDU
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: amending values in a netview snmp event
>
>
>
>
>
> HI ALL,
>
> I have an snmp event arriving in netview for which I would like to amend a
> couple of the slot values i.e NVATTR_1 and NVATTR_2. Using an inline
> action
> from the ruleset I am calling a script which does the needed conversion of
> the attribute values and sets them correctly as a envirnoment variables.
> The
> problem is the script ends and these correct variables are then lost
> forever
> :-(.
> Is there is a way read in the correct values back to NVATTR_1.
> Is there a better way to do this.
>
> Cheers
> Marcel
> marcel.rafter@unisys.com
This e-mail message is confidential and for use by the addressee only. If the
message is received by anyone other than the addressee, please return the
message to the sender by replying to it and then delete the message from your
computer.
'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc
does not accept responsibility for changes made to this message after it was
sent.'
|