There is more going on than you think. If you can see the trap in trapd's
log, then he is done with it. Logging it is the last thing he does, not
the first. He has to pull the trap off the socket, decode the asn.1
elements in it, send it to all connected applications which register for
traps, and finally, log it. So if you can see the result in trapd.log,
then trapd is already working on something else.
But the symptoms you describe, and the down-level code you have, match
those of someone sending an ill-formed trap, or perhaps something that is
not a trap at all, to trapd's socket, 162/udp. Remember that a trap
starts out with x'30' followed by a length, and there is no theoretical
limit to that length. If it just so happens that the next few bytes
define what looks like a very large length in asn.1 notation, then at the
level of code you have, trapd will pull that many bytes off his socket
before he starts decoding. If the there are not that many there, then he
will wait until they accumulate. So the result may be that trap
processing seems hung for quite a while. That's one of the problems
identified, and addressed, in later versions of NetView by what are called
the CERT fixes, IY28562, because they were prompted by CERT Advisory
CA-2002-03. After you have these fixes applied, this kind of denial of
service should not happen. But the fixes also introduce a limit of about
512 bytes per varbind. This limit was set by IBM's internal security
experts and it conforms with recommendations made in other sources for
varbind size. Prior to the fixes, trapd would accept much, much bugger
sizes. Now it looks like this limit will have to be raised again, perhaps
to 1024, in future releases, because we are getting so much negative
feedback about it, mostly from vendors who never did any length-checking
when they sent traps. The balancing act between security and service
(ease-of-use) is never-ending.
My final comment is about whatever tool you are using to look at APARs.
Try also to get the dates, the applicable releases, and the status (open,
closed). Closed APARS are finished. If they indicate a code change
(closing code PER - for "Programming ERror" ) , then that fix is already
part of the code shipped to customers after the date of closure. If your
code is later than that, then you already have to fix. That way you'll
avoid getting needlessly concerned about old problems. It is only the
open ones that are still being worked on. If you have questions about
them, then you should call Support.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Chan, Jack" <jack.chan@nz.unisys.com>
08/28/2002 07:25 PM
To: nv-l@lists.tivoli.com
cc: "Boulieris, Arthur" <Arthur.Boulieris@nz.unisys.com>
Subject: RE: [nv-l] APAR IX60605 trap with Octect string exceeds
249 chara cter
Thanks James.
I have a Netview correlation heartbeat, TEC server snmp to Netview server,
using ruleset, Netview sends postemsg to TEC, TEC touches a file, and if
file is not updated in 15 mins, then some thing along the Netview chain is
wrong.
What I saw as the trapd.log received a rather long string as octect
string,
and the trapd.log does not receive any traps anymore. ovstatus on all
daemons are RUNNING. I have to stop and start trapd to fix the issue, and
also stopping the source of sending the long snmp trap.
I didn't see an update on the APAR, so I thought the APAR was relevant. I
am
still doubting the trapd of handling long octect strings.
Long Trap example in trapd.log (suspected to crash the trapd):
1030513350 3 Wed Aug 28 17:42:30 2002 Security Client is ESMSec a Trap:
14 Security Client is ESMSec Undefined security event. INFO:
08-28-2002 16:58:34 Local0.Alert 10.153.15.10 ,28-Aug-2002
16:59:56,ARMN,10.43.15.10,ISS,ESMSec_Logon_with_special_privileges,
,,10.43.15.10,,10.43.15.10,,, 1516,,1 CRITICAL
I am building a 7.02 new server on solaris 8 now, with switch analyzer.
This
will be the replacement of the 6.02. The 6.02 has disk problems, which I
want to get rid of.
regards,
Jack
-----Original Message-----
From: James Shanks [mailto:jshanks@us.ibm.com]
Sent: Thursday, 29 August 2002 12:07 a.m.
To: nv-l@lists.tivoli.com
Subject: Re: [nv-l] APAR IX60605 trap with Octect string exceeds 249
character
Jack -
How did you make this determination?
This APAR you are talking about, IX60605, is just for the actionsvr
daemon -- no other parts of NetView were affected -- and it was fixed in
NetView Version 4. It has long been a part of the code you have, so I
seriously doubt that this is your problem. What makes you think it is?
What daemons are dying? Have you talked to Support?
At this point I don't have a clear idea of what your problem really is,
but NetView 6.0.3, the next level up from what you have, has been out for
over a year. I think there is a good chance that whatever your issue is,
it has already been addressed there. The upgrade only takes about half
an hour. To get the code, you can just call your local office and order
it. Else you can send an email to The IBM / Tivoli Software Distribution
center in Copenhagen, tivoli@dk.ibm.com, which handles all shipments
outside the US. Tell them your customer number and what you want, and they
will advise you how to order it.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group
"Chan, Jack" <jack.chan@nz.unisys.com>
08/28/2002 01:54 AM
To: nv-l@lists.tivoli.com
cc:
Subject: [nv-l] APAR IX60605 trap with Octect string
exceeds
249 character
Hi List,
I am running into trouble that Netview is crashing all the time. The
reason
- it is receiving traps with octect string greater than 249 characters.
(APAR IX60605)
Platform NV 6.02 on solaris 2.6
Questions:
1. Is this fixed in later versions?
2. There is a temp fix in the APAR which says "I have modified the code to
allow up to 500 bytes on strings that we have to manipulate (those that
contain a single quote character ') and unlimited for any other string. If
the 500 character limit is exceeded, we will truncate and log a message
that
the string was truncated."
How exactly can I carry this out? I need an urgent fix.
regards,
Jack
---------------------------------------------------------------------
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)
---------------------------------------------------------------------
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)
---------------------------------------------------------------------
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)
|