Hi,

Please change debug level to 4 in a configuration file and attach log between these lines:

In get_value_snmp() key:'fan.2' oid:'SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.3"index","SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5"," FAN #1"'
.......
End of get_value_snmp():SUCCEED (or FAIL)

Logs with function get_value_snmp

The same behavior is in Zabbix 2.0.0rc2.

Is there any chance to fix this issue any time soon? This issue is blocking our zabbix migration to version 1.8.11 and next to version 2.0.

Seeing the same here with a new 1.8.11 install, but not on the upgraded one. So it seems to work for an upgraded host, but not for a new machine where I restored the backup from. This means that for our environment nearly all monitoring/checks will fail.

10872:20120413:150642.945 item [stub-nik-226.ams-ix.net:if[1/8,multicast,in]] became not supported: cannot find index [1.3.6.1.2.1.31.1.1.1.1] of the OID [1.3.6.1.4.1.1991.1.1.3.3.5.1.40["index","1.3.6.1.2.1.31.1.1.1.1","etherne
10872:20120413:150642.945 item [stub-nik-226.ams-ix.net:if[1/8,multicast,out]] became not supported: cannot find index [1.3.6.1.2.1.31.1.1.1.1] of the OID [1.3.6.1.4.1.1991.1.1.3.3.5.1.41["index","1.3.6.1.2.1.31.1.1.1.1","etherne

Confirmed in latest 1.8 r26847.

Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-4793

would this also fix ZBX-4882 ?

(1) if there were some changes to how zabbix handles quoted values, the resulting logic should be documented

<dimir> It's a regression, so I guess nothing should be.

<richlv> CLOSED then

Successfully tested. Please review my tiny change at r26893.

<Sasha> CLOSED

Fixed in version pre-1.8.12 r26905.

Fixed in version pre-2.0.0rc3 r26919.

Could this still be broken for SNMPv3? I have pretty much the exact same problem under 2.0.0rc3. No issue for older hosts, but a new host I added 'cannot find index'

attached debug 4 log file

Hmmm can't attach (because it's closed?), so I'll just paste in here.

32114:20120423:152602.289 In substitute_key_macros() data:'sunfire.fault.ps'
32114:20120423:152602.289 End of substitute_key_macros():SUCCEED data:'sunfire.fault.ps'
32114:20120423:152602.289 In substitute_simple_macros() data:'161'
32114:20120423:152602.289 In substitute_simple_macros() data:'welunix'
32114:20120423:152602.289 In substitute_simple_macros() data:'xxxx'
32114:20120423:152602.289 In substitute_simple_macros() data:'xxxx'
32114:20120423:152602.289 In substitute_simple_macros() data:EMPTY
32114:20120423:152602.289 In substitute_key_macros() data:'sunPlatAlarmState["index","entPhysicalName","/SYS/PS_FAULT"]'
32114:20120423:152602.289 End of substitute_key_macros():SUCCEED data:'sunPlatAlarmState["index","entPhysicalName","/SYS/PS_FAULT"]'
32114:20120423:152602.289 In get_value() key:'sunfire.fault.ps'
32114:20120423:152602.289 In get_value_snmp() key:'sunfire.fault.ps' oid:'sunPlatAlarmState["index","entPhysicalName","/SYS/PS_FAULT"]'
32114:20120423:152602.289 In snmp_open_session()
32114:20120423:152602.310 SNMPv3 [welunix@ldb004-c:161]
32114:20120423:152602.310 End of snmp_open_session()
32114:20120423:152602.311 Special processing
32114:20120423:152602.311 method:index
32114:20120423:152602.311 oid_index:entPhysicalName
32114:20120423:152602.311 index_value:/SYS/PS_FAULT
32114:20120423:152602.311 In snmp_normalize(oid:entPhysicalName)
32114:20120423:152602.311 End of snmp_normalize():entPhysicalName
32114:20120423:152602.311 In cache_get_snmp_index(oid:entPhysicalName,value:/SYS/PS_FAULT)
32114:20120423:152602.311 End of cache_get_snmp_index(index:0):FAIL
32114:20120423:152602.311 In snmp_get_index() oid:'entPhysicalName' value:'/SYS/PS_FAULT' bulk:1
32114:20120423:152602.320 snmp_get_index() snmp_synch_response():0
32114:20120423:152602.320 End of snmp_get_index():NOTSUPPORTED
32114:20120423:152602.321 In cache_del_snmp_index(oid:entPhysicalName,value:/SYS/PS_FAULT)
32114:20120423:152602.321 End of cache_del_snmp_index()
32114:20120423:152602.321 In snmp_close_session()
32114:20120423:152602.321 End of snmp_close_session()
32114:20120423:152602.321 End of get_value_snmp():NOTSUPPORTED
32114:20120423:152602.321 Item [ldb004:sunfire.fault.ps] error: Cannot find index [entPhysicalName] of the OID [sunPlatAlarmState["index","entPhysicalName","/SYS/PS_FAULT"]]: NOT FOUND: entPhysicalName[/SYS/PS_FAULT]
32114:20120423:152602.321 End of get_value():NOTSUPPORTED

(2) REOPENED SNMP strings with a null character in Zabbix shows as hex.

snmpwalk -v2c -c public <ip> ifDescr
IF-MIB::ifDescr.1 = STRING: Software Loopback Interface 1
IF-MIB::ifDescr.2 = STRING: WAN Miniport (SSTP)
IF-MIB::ifDescr.3 = STRING: WAN Miniport (L2TP)
IF-MIB::ifDescr.4 = STRING: WAN Miniport (PPTP)
IF-MIB::ifDescr.5 = STRING: WAN Miniport (PPPOE)
IF-MIB::ifDescr.6 = STRING: WAN Miniport (IPv6)
IF-MIB::ifDescr.7 = STRING: WAN Miniport (Network Monitor)

Zabbix:
ifDescr.1 07 May 2012 13:33:42 53 6F 66 74 77 61 72 ... - History
ifDescr.2 07 May 2012 13:33:43 57 41 4E 20 4D 69 6E ... - History
ifDescr.3 07 May 2012 13:33:44 57 41 4E 20 4D 69 6E ... - History
ifDescr.4 07 May 2012 13:33:15 57 41 4E 20 4D 69 6E ... - History
ifDescr.5 07 May 2012 13:33:16 57 41 4E 20 4D 69 6E ... - History
ifDescr.6 07 May 2012 13:33:17 57 41 4E 20 4D 69 6E ... - History
ifDescr.7 07 May 2012 13:33:18 57 41 4E 20 4D 69 6E ... - History

<Sasha> RESOLVED in dev branch svn://svn.zabbix.com/branches/dev/ZBX-4793 r27380.

Related issue: ZBX-4921

Successfully tested. All strings should be handled properly now (no hex result).

(3) Non-ASCII strings are printed as Hex. They should be printed as text with non-ASCII characters as question marks.

<dimir> Use net-snmp functionality (e. g. DISPLAY-HINT, RFC2579) in order to better recognize hex strings. The returned values should be now exactly the way snmpwalk returns them. Non-ASCII strings will be printed as text with question marks, before this change they were printed as HEX.

RESOLVED in r27812

<Sasha> REOPENED Hex strings are not processed correctly

<dimir> RESOLVED in r27903

<Sasha> CLOSED Please review my changes in r27957

<dimir> Thanks, great improvement changes!

Fixed in pre-1.8.14 r27986, pre-2.0.1 r27988 and pre-2.1.0 (beta) r27989

Hi,
I downloaded pre-2.0.1 r27988, and I have still the same problem. (I started testing from 2.0.0)
There is my scenario (the same as above)
This scenario was created only for test - I know it has no sense

My SNMP OID: IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]

1. snmpwalk -cpublic -v2c 10.1.0.40 IF-MIB::ifPhysAddress
   IF-MIB::ifPhysAddress.1 = STRING: 0:15:99:67:5e:fe
   IF-MIB::ifPhysAddress.6 = STRING: 0:0:0:0:0:0

Notice ! There is no "0" index.

1. snmpwalk -cpublic -v2c 10.1.0.40 IF-MIB::ifAdminStatus
   IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
   IF-MIB::ifAdminStatus.6 = INTEGER: up(1)

So, in my opinion, i should get value "1" in my Item. But not. Error generated.

As I noticed I haven't got a problem where the index starts from "0" value, where there is no "0" in index, (index starts from "1") I got this error.

My log:
13156:20120606:212225.000 In substitute_key_macros() data:'dynamic.test'
13156:20120606:212225.000 End of substitute_key_macros():SUCCEED data:'dynamic.test'
13156:20120606:212225.000 In substitute_simple_macros() data:'161'
13156:20120606:212225.000 In substitute_simple_macros() data:'public'
13156:20120606:212225.000 In substitute_key_macros() data:'IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]'
13156:20120606:212225.000 End of substitute_key_macros():SUCCEED data:'IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]'
13156:20120606:212225.000 In get_value() key:'dynamic.test'
13156:20120606:212225.000 In get_value_snmp() key:'dynamic.test' oid:'IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]'
13156:20120606:212225.000 In snmp_open_session()
13156:20120606:212225.000 SNMP [[email protected]:161]
13156:20120606:212225.000 End of snmp_open_session()
13156:20120606:212225.000 Special processing
13156:20120606:212225.000 method:index
13156:20120606:212225.000 oid_index:IF-MIB::ifPhysAddress
13156:20120606:212225.000 index_value:0:15
13156:20120606:212225.000 In snmp_normalize(oid:IF-MIB::ifPhysAddress)
13156:20120606:212225.000 End of snmp_normalize():IF-MIB::ifPhysAddress
13156:20120606:212225.000 In cache_get_snmp_index(oid:IF-MIB::ifPhysAddress,value:0:15)
13156:20120606:212225.000 End of cache_get_snmp_index(index:0):FAIL
13156:20120606:212225.000 In snmp_get_index() oid:'IF-MIB::ifPhysAddress' value:'0:15' bulk:1
13155:20120606:212225.001 In get_values()
13155:20120606:212225.001 In DCconfig_get_poller_items() poller_type:0
13155:20120606:212225.001 End of DCconfig_get_poller_items():0
13155:20120606:212225.001 End of get_values():0
13155:20120606:212225.001 poller #3 spent 0.000081 seconds while updating 0 values

Best Regards,
Grzegorz
BIG FAN of ZABBIX

The same in 28090

Log:
14025:20120606:215525.158 In substitute_key_macros() data:'dynamic.test'
14025:20120606:215525.158 End of substitute_key_macros():SUCCEED data:'dynamic.test'
14025:20120606:215525.158 In substitute_simple_macros() data:'161'
14025:20120606:215525.158 In substitute_simple_macros() data:'public'
14025:20120606:215525.158 In substitute_key_macros() data:'IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]'
14025:20120606:215525.158 End of substitute_key_macros():SUCCEED data:'IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]'
14025:20120606:215525.158 In get_value() key:'dynamic.test'
14025:20120606:215525.158 In get_value_snmp() key:'dynamic.test' oid:'IF-MIB::ifAdminStatus["index","IF-MIB::ifPhysAddress","0:15"]'
14025:20120606:215525.158 In snmp_open_session()
14025:20120606:215525.158 SNMP [[email protected]:161]
14025:20120606:215525.158 End of snmp_open_session()
14025:20120606:215525.158 Special processing
14025:20120606:215525.158 method:index
14025:20120606:215525.158 oid_index:IF-MIB::ifPhysAddress
14025:20120606:215525.158 index_value:0:15
14025:20120606:215525.158 In snmp_normalize(oid:IF-MIB::ifPhysAddress)
14025:20120606:215525.158 End of snmp_normalize():IF-MIB::ifPhysAddress
14025:20120606:215525.158 In cache_get_snmp_index() oid:'IF-MIB::ifPhysAddress' value:'0:15'
14025:20120606:215525.158 End of cache_get_snmp_index():FAIL index:0
14025:20120606:215525.158 In snmp_get_index() oid:'IF-MIB::ifPhysAddress' value:'0:15' bulk:1
14023:20120606:215525.158 In get_values()
14023:20120606:215525.158 In DCconfig_get_poller_items() poller_type:0
14023:20120606:215525.158 End of DCconfig_get_poller_items():0
14023:20120606:215525.158 End of get_values():0
14023:20120606:215525.159 poller #1 spent 0.000171 seconds while updating 0 values

Hi
What a shame
I checked everything ones again, all is working in 2.0.1rc.

Best regards,
Grzegorz

In Zabbix 1.8.13 this item works ok but in Zabbix 1.8.14 issue seems to came back. The problem is exact as in the initial post:

SNMP OID: SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.3"index","SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5"," FAN #1"

snmpwalk -v2c -c xxx vdx01 SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5
SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5.7 = STRING: " FAN #1"
[...]

snmpwalk -v2c -c xxx vdx01 SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.3.7
SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.3.7 = INTEGER: 4

Zabbix log:
3247:20120629:112855.397 item [vdx02:fan.1] became not supported: cannot find index [SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5] of the OID [SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.3["ind

The same behavior is in Zabbix 2.0.1rc2.

There is fix version is 1.8.15rc1 but I tested 1.8.15 and the issue still occurs.

I use zabbix 1.8.15 on scientific linux 6. My dynamic index:
.1.3.6.1.3.94.1.8.1.4["index",".1.3.6.1.3.94.1.8.1.3","On-Board Temperature 1-Ctlr A"]

Some linux command for diagnostic:

1. tcpdump -i any -s 0 host hp-array-1.0 and port 161 -n
   22:11:59.095474 IP 10.10.140.4.60695 > 10.10.110.130.snmp: GetNextRequest(29) .1.3.6.1.3.94.1.8.1.3
   22:11:59.701620 IP 10.10.110.130.snmp > 10.10.140.4.60695: GetResponse(77) .1.3.6.1.3.94.1.8.1.3.16.32.128.0.0.49.55.48.51.53.52.0.0.57.0.0.0.1="On-Board Temperature 1-Ctlr A"
   22:11:59.701820 IP 10.10.140.4.60695 > 10.10.110.130.snmp: GetRequest(30) .1.3.6.1.3.94.1.8.1.4.1
   22:11:59.703185 IP 10.10.110.130.snmp > 10.10.140.4.60695: GetResponse(30) noSuchName@1 .1.3.6.1.3.94.1.8.1.4.1=

1. snmpwalk -v1 -c public hp-array-1.0 1.3.6.1.3.94.1.8.1.3
   SNMPv2-SMI::experimental.94.1.8.1.3.16.32.128.0.0.49.55.48.51.53.52.0.0.57.0.0.0.1 = STRING: "On-Board Temperature 1-Ctlr A"
   SNMPv2-SMI::experimental.94.1.8.1.3.16.32.128.0.0.49.55.48.51.53.52.0.0.57.0.0.0.2 = STRING: "On-Board Temperature 1-Ctlr B"

1. snmpwalk -v1 -c public hp-array-1.0 1.3.6.1.3.94.1.8.1.4.16.32.128.0.0.49.55.48.51.53.52.0.0.57.0.0.0.1
   SNMPv2-SMI::experimental.94.1.8.1.4.16.32.128.0.0.49.55.48.51.53.52.0.0.57.0.0.0.1 = INTEGER: 3

The index value in this dynamic index is too long: "16.32.128.0.0.49.55.48.51.53.52.0.0.57.0.0.0.1". It may be a cause of the problem.

I'm now finding this issue as well... my SNMPv3 dynamic indexes are broken with a "timeout" on links that have higher latency... it seems the lower latency links that I have are working fine.

Is there any chance to fix this in 2.0 branch?

I am stuck in 1.8.13 because of this bug and I cannot upgrade zabbix in any way .

I tested 2.0.3rc1 and this issue still occurs (there is info "Fix Version/s: 2.0.1rc1" but I think this is incorrect).

Here's an example of a Wireshark of a non-working host (on the left) and a host where SNMP dynamic indexes work fine (see the 'Not working versus working' image above at the top)

The two hosts are both Cisco 2925 routers, using SNMpv3, with the exact same version of IOS (IOS 15.1).

Notice the 'get-next' requests from Zabbix, and the lack of response on the left... on the right, the get-next requests are all responded to with 'get-response'

Today at work I wrote a python script that basically serves as an external check, that I've used to take the place of dynamic indexes. I flipped the items we have from SNMPv3 agent dynamic index items to external check, and I call my script with myscript.py[

,ifInOctets,<Interface-description>]

If anyone's interested in the script just let me know, maybe I'll post it on the wiki or something. The lack of dynamic indexes is killing us at work (we're paying customers now too... we're in the process of buying Zabbix gold support).

Not very good that we changed values for "Fix Version/s" without any actual merges to code.
Latest changes to code made for 1.8.14 release, but later we changed 1.8.14rc1 -> 1.8.15rc1 -> 1.8.16rc1 which misleads visitors.

Would be better to not do that.
I'm fixing this: 1.8.16rc1 -> 1.8.14, hope I did a correct thing.

I am having the same issue of not being able to do dynamic indexes on CentOS 6.4 with Zabbix 2.5

Gene - I assume you mean Zabbix 2.0.5

In Zabbix 2.2 (not out yet) there is a huge fix that should be pointed out more in my humble opinion... the original Zabbix code that takes advantage of net-snmp libraries wasn't include the option to set the SNMP timeout that the user supplies in zabbix_server.conf in the actual net-snmp library calls. This was killing us for some time at work until we figured out what was going on.

In Zabbix 2.2 the net-snmp poller code has been updated to include the user specified SNMP timeout value. I don't know if that fixes SNMP dynamic indexes on higher latency links, but I'm thinking it will.

Last time this issue has been reopened by Robert Jerzak complaining for:

SNMP OID: SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.3"index","SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5"," FAN #1"

snmpwalk -v2c -c xxx vdx01 SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5
SNMPv2-SMI::enterprises.1588.2.1.1.1.1.22.1.5.7 = STRING: " FAN #1"

What we can see in output above? Yes, a leading space for searched value " FAN #1"

I performed similar experiment on zabbix 2.2.3
I have a port with a leading space prior its alias:

# snmpget -v1 -c public 10.20.0.7 .1.3.6.1.2.1.31.1.1.1.18.2
IF-MIB::ifAlias.2 = STRING:  FAN #2
# snmpget -v1 -c public 10.20.0.7 .1.3.6.1.2.1.31.1.1.1.18.2 -m:
iso.3.6.1.2.1.31.1.1.1.18.2 = STRING: " FAN #2"

you can see it in both outputs (in second case I loaded EMPTY mibs list, that's why the value is quoted <- this is internal libsnmp behavior)
As I see zabbix also removes the quotes.

If I create simple "snmpget" item - the value will be stored in DB w/o the leading space.
So supposedly we should not use the space when compare values.

If I create item with dynamic OID with the space:

.1.3.6.1.2.1.2.2.1.2["index",".1.3.6.1.2.1.31.1.1.1.18"," FAN #2"]

then the item complains with error "Cannot find index of " FAN #2" in ".1.3.6.1.2.1.31.1.1.1.18"."

When OID is without the space:

.1.3.6.1.2.1.2.2.1.2["index",".1.3.6.1.2.1.31.1.1.1.18","FAN #2"]

then it works correctly.

So issue should be closed again.

hmm, i don't like us trimming spaces. what if snmp will give both " FAN #2" and "FAN #2" ?

Rich, agree, reported as ZBX-8344