Direct links to fixes
4.1.1-TIV-ITNMIP-Linux-FP0002
4.1.1_README_NLS_FP0002
4.1.1_README_FP0002
3.9.0-TIV-ITNMIP-Solaris-FP0005
3.9.0_INSTALL_NLS_FP0005
3.9.0_INSTALL_FP0005
3.9.0-TIV-ITNMIP-Windows-FP0005
3.9.0-TIV-ITNMIP-zLinux-FP0005
3.9.0-TIV-ITNMIP-Linux-FP0005
3.9.0-TIV-ITNMIP-AIX-FP0005
4.1.1_README_NLS_FP0001
4.1.1_README_FP0001
4.1.1-TIV-ITNMIP-Linux-FP0001
IBM Tivoli Network Manager IP Edition 3.9.0 Fix Pack 5, 3.9.0-TIV-ITNMIP-FP0005
IBM Tivoli Network Manager IP Edition 4.1.1 Fix Pack 2, 4.1.1-TIV-ITNMIP-FP0002
APAR status
Closed as program error.
Error description
> Compiled and committed UCD-SNMP-MIB to the ncmib DB. > Performed test using net-snmp tools to snmpwalk my target test machine and the results returned fine for both laLoadInt and laLoadFloat. > Attempted getNext of laLoadInt and laLoadFloat of target test machine from ITNM. As expected no results were returned in the MIB browser. So snooping the received UDP SNMP packets on my ITNM machine it would appear that the test machine had returned the correct response messages with load values just the same as net-snmpwalk had done. Looking into our SNMP software tracing it could be seen that the response packets were discarded. The reason they were being discarded is down to the UCD-SNMP-MIB specification of laLoadFloat. It is defined with SYNTAX type OPAQUE which our software does not handle correctly. This type 0x44h (ASN value) is deprecated and no new MIB definitions are allowed to include this however older MIBs like the UCD-SNMP-MIB will use it. To be compliant with the spec however we should support this type. See RFC 2578 Structure of Management Information Version 2 (SMIv2) The laLoadInt is obviously not an OPAQUE, it is defined as Integer32 however since the next parent OID is 1.3.6.1.4.1.2021.10.1.6 (which is laLoadFloat) the final getNext returns the response for this, which would normally indicate the end of the walk, but our software rejects it (due to Opaque type being present) and in turn discards all of the laLoadInt responses and considers the walk as failed. This is why we have the discrepancy between the GET working where the GETNEXT failed for this particular variable. This then causes an SNMP_TIMEOUT to be raised and so the snmp helper returns NULL to the MIB Browser
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All ITNM users on all platforms who specifically use the MIB * * Browser to retrieve private enterprises ucdavis MIB * * variables with snmp walk or getNext or any other which is * * defined with the deprecated snmp type SNMP_OPAQUE (in this * * instance laLoadFloat) * **************************************************************** * PROBLEM DESCRIPTION: * * Performing a walk of the laTable or the laLoadInt variable * * within the ucdavis MIB table will fail to return any results * * in the MIB Browser due to timeout. * **************************************************************** * RECOMMENDATION: * * Upgrade product version to * * 3.9.0-ITNMIP-FP0005 * * 4.1.0-ITNMIP-FP0001 * * 4.1.1-ITNMIP-FP0001 * * * * End of Support has been announced for 3.8. Customer should * * upgrade to 3.9 or above release. * * http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca * * &infotype=an&appname=iSource&supplier=897&letternum=ENUS914- * * 056#h2-wprodx * ****************************************************************
Problem conclusion
Support has been added to handle snmp returns with type snmp_opaque so as snmp walks can complete successfully after encountering this type.
Temporary fix
Comments
APAR Information
APAR number
IV38120
Reported component name
TIV NETWK MGR I
Reported component ID
5724S4500
Reported release
380
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-03-18
Closed date
2014-02-25
Last modified date
2015-04-24
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
TIV NETWK MGR I
Fixed component ID
5724S4500
Applicable component levels
R380 PSN
UP
R380 PSY
UP
R390 PSN
UP
R390 PSY
UP
R401 PSN
UP
R401 PSY
UP
R410 PSN
UP
R410 PSY
UP
Document Information
Modified date:
01 October 2021