nv-l

RE: [nv-l] APAR IX60605 trap with Octect string exceeds 249 chara cter

2002-08-29 09:27:47
Subject: RE: [nv-l] APAR IX60605 trap with Octect string exceeds 249 chara cter
From: James Shanks <jshanks AT us.ibm DOT com>
To: nv-l AT lists.tivoli DOT com
Date: Thu, 29 Aug 2002 09:27:47 -0400
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 AT nz.unisys DOT com>
08/28/2002 07:25 PM

 
        To:     nv-l AT lists.tivoli DOT com
        cc:     "Boulieris, Arthur" <Arthur.Boulieris AT nz.unisys DOT 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 AT us.ibm DOT com]
Sent: Thursday, 29 August 2002 12:07 a.m.
To: nv-l AT lists.tivoli DOT 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 AT dk.ibm DOT 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 AT nz.unisys DOT com>
08/28/2002 01:54 AM

 
        To:     nv-l AT lists.tivoli DOT 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 AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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 AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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 AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT 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)





<Prev in Thread] Current Thread [Next in Thread>