Description of problem: MIB info(udp.5) return IPv4 length as 8byte How reproducible: Always Steps to Reproduce: (1) Edit /etc/snmp/snmpd.conf and add following setting view systemview included .1 (2) Restart snmpd daemon (3) Get udp.5 mib information by snmpwalk command from localhost # snmpwalk -v1 -c public -d localhost udp.5 Environment: Only IA64 and EM64T net-snmp-5.3.1-14.el5 (RHEL5.0) net-snmp-5.3.1-14.0.1.el5 Actual results: # uname -a linux xxxxx 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux # rpm -q net-snmp net-snmp-5.3.1-14.0.1.el5 # snmpwalk -d -v1 -c public localhost udp.5 : Sending 51 bytes to UDP: [127.0.0.1]:161 0000: 30 31 02 01 00 04 06 70 75 62 6C 69 63 A1 24 02 01.....public.$. 0016: 04 45 B1 FC 56 02 01 00 02 01 00 30 16 30 14 06 .E..V......0.0.. 0032: 10 2B 06 01 02 01 07 05 01 01 0A 81 51 15 46 81 .+..........Q.F. 0048: 0A 05 00 ... Received 60 bytes from UDP: [127.0.0.1]:161 0000: 30 3A 02 01 00 04 06 70 75 62 6C 69 63 A2 2D 02 0:.....public.-. 0016: 04 45 B1 FC 56 02 01 00 02 01 00 30 1F 30 1D 06 .E..V......0.0.. 0032: 11 2B 06 01 02 01 07 05 01 01 81 40 81 28 01 46 .+.........@.(.F 0048: 81 09 40 08 C0 A8 01 46 00 00 00 00 ..@....F.... UDP-MIB::udpLocalAddress.192.168.1.70.137 = IpAddress: 192.168.1.70 The last line "81 09 40 08 C0 A8 01 46 00 00 00 00", shows"08" byte IP information and unnecessary code "00 00 00 00". Expected results: return 4byte Additional info: RFC1155 define return IPv4 length as 4 byte. 3.2.3.2. IpAddress This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order. When this ASN.1 type is encoded using the ASN.1 basic encoding rules, only the primitive encoding form shall be used. http://tools.ietf.org/html/rfc1155#page-8 I have the report that the patch here resolved the issue: http://sourceforge.net/tracker/index.php?func=detail&aid=1550635&group_id=12694&atid=456380 I'll attach the patch for RHEL-5.
Created attachment 162072 [details] Patch for RHEL5
Hello all, > I am a bit confused by the business justification and the lack of an impact statement. Are you saying that all future business with Hitachi depends on this datatype bug? The JP1-releated business will stop. > Also: what is the actual impact: the deployment of middleware is completely blocked by this? Yes. Please refer to the following. Let me know if you need more information: - Hitachi starts to support RHEL5 from 5.1. - There are a middleware called "JP1", the enterprise integrated management tool provided by Hitachi. - Without this bug being fixed, JP1 cannot receive the correct information from the maintained servers, thus hindering the proper functionality of the middleware. - Hitachi JP1 team considers this as a show-stopper, and they won't be able to announce its official support of RHEL5 on JP1. At the same time, the pre-loaded RHEL5.1 servers are to be shipped with restrictions stating it's NOT JP1-complient, causing the business to withhold until it's officially supported. - Whenever large number of servers are shipped in specific business, there's always chance for selling such middleware. Thus this can make impact on their server solution business. I am asking for any more specific business impact however. Please kindly consider the current consequence and have this fixed. Let me know if you need any more information. Thanks, This event sent from IssueTracker by tumeya issue 129377
Bug report changed to from ON_QA to VERIFIED status by Errata System. Advisory RHBA-2007:0498-06. http://errata.devel.redhat.com/errata/showrequest.cgi?advisory=5543 Reproduced and fixed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0498.html