Bug 462016
| Summary: | Net SNMP doesn't smux dell open manage | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Louis Savage <louis.savage> | ||||
| Component: | net-snmp | Assignee: | Jan Safranek <jsafrane> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.7 | CC: | ctatman, jesse.gonzalez, jfeeney, ksrot, louis.savage, martinez, mkoci, narendra_k, rvokal, tao, wwlinuxengineering | ||||
| Target Milestone: | rc | Keywords: | ZStream | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
* snmpd expects the "type" field of snmp_set_var_value() to be filled before the function is called. However SMUX, as previously implemented, expected these events in the reverse order. As a result, trap forwarding from SMUX peers would not work. SMUX now expect events to take place in the same order as snmpd, thereby enabling trap forwarding from SMUX peers.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-05-18 20:18:53 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 484334 | ||||||
| Attachments: |
|
||||||
|
Description
Louis Savage
2008-09-11 22:28:58 UTC
What exact version of net-snmp was the last one working? There were many versions '5.1.2-11' - it should have also some additional numbers, like 5.1.2-11.EL4.12 or so. I expect the dump you posted is from snmptrapd, right? Could you also post the one from snmpd? Or, preferably, tcpdump of communication between snmpd and snmptrapd and the smux peer (Dell open manage), so I can play with it and eventually reproduce the bug. Thanks in advance. Hello Jan, Sorry about the delay, Below is the version numbers : Worked : net-snmp-5.1.2-11.el4_6.11.3', 'net-snmp-libs-5.1.2-11.el4_6.11.3', 'net-snmp-libs-5.1.2-11.el4_6.11.3 After up2date ran : net-snmp-5.1.2-13.el4', 'net-snmp-libs-5.1.2-13.el4', 'net-snmp-libs-5.1.2-13.el4 I am going to start looking into some more as well . Thanks, Louis Hello Jan, The dump I have posted is from runing the snmpd with the following options : /usr/sbin/snmpd -Ddump Then from there I triggered the blinks and failed drives from within open manage to get a output of the errors. I have attached a strace of it happening. I forced a blink / unblink of the drives. Created attachment 317329 [details]
strace of snmpd in debug mode
snmpd -Ddump
strace
Here is the tcpdump :
tcpdump -i lo -vvv -nn -n
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
18:06:00.713301 IP (tos 0x0, ttl 64, id 49092, offset 0, flags [DF], proto 6, length: 403) 127.0.0.1.36399 > 127.0.0.1.199: P 3613762888:3613763239(351) ack 3617003159 win 8192 <nop,nop,timestamp 2469723851 2469564491>
18:06:00.713302 IP (tos 0x0, ttl 64, id 54582, offset 0, flags [DF], proto 6, length: 52) 127.0.0.1.199 > 127.0.0.1.36399: . [tcp sum ok] 1:1(0) ack 351 win 8192 <nop,nop,timestamp 2469723851 2469723851>
18:06:00.715031 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 411) 127.0.0.1.33197 > 127.0.0.1.162: { SNMPv2c { V2Trap(35) R=314038665 .1.3.6.1.2.1.1.3.0=126183 [|snmp] } }
18:06:21.771101 IP (tos 0x0, ttl 64, id 49094, offset 0, flags [DF], proto 6, length: 400) 127.0.0.1.36399 > 127.0.0.1.199: P 351:699(348) ack 1 win 8192 <nop,nop,timestamp 2469744908 2469723851>
18:06:21.771120 IP (tos 0x0, ttl 64, id 54584, offset 0, flags [DF], proto 6, length: 52) 127.0.0.1.199 > 127.0.0.1.36399: . [tcp sum ok] 1:1(0) ack 699 win 8192 <nop,nop,timestamp 2469744908 2469744908>
18:06:21.772818 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 408) 127.0.0.1.33197 > 127.0.0.1.162: { SNMPv2c { V2Trap(35) R=314038666 .1.3.6.1.2.1.1.3.0=128289 [|snmp] } }
Thanks for the info, I have reproduced the bug. It was caused by rewrite of snmp_set_var_value() for bug #329631 - it now expects that the 'type' field is filled before the function is called and SMUX tries to fill it after the call -> you can see "no storage for OID" in the log and all values are zeroed. Upstream patch: http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/agent/mibgroup/smux/smux.c?r1=14246&r2=14245&pathrev=14246 This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP. *** Bug 477094 has been marked as a duplicate of this bug. *** Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: * snmpd expects the "type" field of snmp_set_var_value() to be filled before the function is called. However SMUX, as previously implemented, expected these events in the reverse order. As a result, trap forwarding from SMUX peers would not work. SMUX now expect events to take place in the same order as snmpd, thereby enabling trap forwarding from SMUX peers. I verified this on RHEL 4.8 snapshot 3 - net-snmp version:5.1.2-18.el4. The issue is fixed. Traps show the details. 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 therefore 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-2009-0984.html |