Bug 253880 - [RHEL5.0] MIB info(udp.5) return IPv4 length as 8byte
[RHEL5.0] MIB info(udp.5) return IPv4 length as 8byte
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp (Show other bugs)
5.1
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-22 12:10 EDT by Flavio Leitner
Modified: 2010-10-22 14:01 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0498
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:16:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for RHEL5 (6.80 KB, patch)
2007-08-22 12:10 EDT, Flavio Leitner
no flags Details | Diff

  None (edit)
Description Flavio Leitner 2007-08-22 12:10:11 EDT
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.
Comment 1 Flavio Leitner 2007-08-22 12:10:14 EDT
Created attachment 162072 [details]
Patch for RHEL5
Comment 9 Issue Tracker 2007-08-30 04:24:53 EDT
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
Comment 11 Red Hat Bugzilla 2007-09-03 09:30:58 EDT
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.
Comment 13 errata-xmlrpc 2007-11-07 12:16:43 EST
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

Note You need to log in before you can comment on or make changes to this bug.