Red Hat Bugzilla – Bug 132058
cannot snmpwalk ipAdEntIfIndex on x86_64 machine
Last modified: 2007-11-30 17:10:48 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 Description of problem: If you walk an x86_64, you cannot fetch the ipAdEntIfIndex or the ipAdEntBcastAddr fields for any address on the host. Both fields return integers. When putting snmpd into debug mode, the following entry logs when fetching these fields: sess_async_send: encoding failure I have verified through a quick debug patch that the right value for this field is fetched, so it looks like there's an encoding failure somewhere after the lookup procedures. tcpdump confirms that no response is ever sent for these fields. Fetching the same fields from an x86 box works fine. Version-Release number of selected component (if applicable): net-snmp-5.1.1-2 How reproducible: Always Steps to Reproduce: 1. snmpwalk -v 2c -c <comm> <x86_64-host> ipAddrTable 2. 3. Actual Results: Walk times out after last ipAdEntAddr entry Expected Results: Walk fetches all entries in the table Additional info: I cannot snmpget specific values either (as expected, since it appears the encoding of the response is failing, not the actual query for the values).
On AMD 64 Bit Linux snmp appears to not work on the following Kernels: Red Hat Enterprise Linux AS release 3 (Taroon Update 2) Kernel 2.4.21-15.ELsmp on an x86_64 Red Hat Enterprise Linux AS release 3 (Taroon Update 3) Kernel 2.4.21-20.ELsmp on an x86_64 We have verified the same issue exists on Red Hat Linux Advanced Workstation release 2.1AW (Derry) Kernel 2.4.18-e.31smp on an ia64 Snmp errror details snmpwalk <host> .iso.org.dod.internet.mgmt.mib-2.at yields interfaces.ifTable.ifEntry.ifSpecific.1 : OBJECT IDENTIFIER: . ccitt.zeroDotZero interfaces.ifTable.ifEntry.ifSpecific.2 : OBJECT IDENTIFIER: . ccitt.zeroDotZero interfaces.ifTable.ifEntry.ifSpecific.3 : OBJECT IDENTIFIER: . ccitt.zeroDotZero snmpwalk: No response arrived before timeout. same "snmpwalk: No response arrived before timeout." error happens on: snmpwalk <host> .iso.org.dod.internet.mgmt.mib-2.tcp.tcpConnTable. tcpConnEntry snmpwalk <host> .iso.org.dod.internet.mgmt.mib-2.tcp.tcpConnTable. tcpConnEntry.tcpConnState These commands work on the 32bit kernel Red Hat Enterprise Linux ES release 3 (Taroon Update 1) Kernel 2.4.21-9.ELsmp on an i686
Net-SNMP is riddled with long usage that destroys responses. In my particular case (the first one), the return for the ipAdEntIfIndex is actually a 4-byte int (actually, it's worse; it's an addr_t). When it comes time to encode it, the snmp daemon is requesting a long value. The ASN encoding is bailing out because the type it expects (long) isn't what it got (addr_t or int). There's no real easy way to find and fix all of the problems. Apparently, the net-snmp developers have known about this for a while and just don't care.
Hrunting, thx for pointing me to this. I think I see the problem in net-snmp-5.1-64bit.patch. I'm trying to rework this patch so it will get fixed.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Fixed in current release.
Is this fix/patch part of the RHEL4 release? If so please advise if it is going to be applied in U2. If this patch has not not made it into R4 then there is a issue tracker open which needs to be escalated to address this problem in R4.
I see that patch net-snmp-5.1-64bit.patch from FC2 has already been applied to RHEL4-GOLD. Was this the only patch that fixed this problem ? Becasue if it is still failing in R4 then it never got fixed or it can be a different problem.
Several patches adressing 64bit issues were applied on version comming out with U2 . I've also tested this problem with the latest RHEL4 package and it seems to be fixed there so please wait for U2 before openning any new 64bit bug.