SNMP Discovery does not support long {#SNMPINDEX}

[lhy719]

Hello Sir / Madam,

I used SNMP Discovery rules for Aruba Switch and APs. That rule does get AP Names, but couldn't get other values for each AP. I find that's due to Zabbix use the last session of OID of AP Name. I hope you may modify the program to substring {#SNMPINDEX} including this circumstance.

I've Aruba SNMP values like,
Name/OID: wlanAPName.0.11.134.194.136.230; Value (OctetString): 4F.AP61.253
Name/OID: wlanAPName.36.222.198.192.51.208; Value (OctetString): 6F.AP93.251

Where wlanAPName is .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.3.0.11.134.194. 136.230

That OID Value tells me, an AP called '4F.AP61.253' is indexed with '0.11.134.194.136.230' and another called '6F.AP93.251' is indexed with '36.222.198.192.51.208'

Thus I suppose Zabbix will fetch connected clients on an AP by adding a item prototype like,
.1.3.6.1.4.1.14823.2.2.1.5.2.1.5.1.7.{#SNMPINDEX}

However, Zabbix set {#SNMPINDEX} as '208' instead of '36.222.198.192.51.208'. That's the reason related item prototypes fails.

I suggest Zabbix treats {#SNMPINDEX} with remove SNMP OID of discovery rule from SNMP response values. With this method, multi-session or single session {#SNMPINDEX} will work fine too.

Hope this could add to coming release soon!

[ceinmart]

Need this too

Hi lhy719,

I need this resource too , where need monitor database sessions where the INDEX looks like 893002000.4 (893002000 = database id , 4 = session number ) , but the SNMPINDEX returns only the 4 .

This appear be fixed on next version :

https://support.zabbix.com/browse/ZBX-3449

There is a patch to zabbix-server , maybe you can try it.

I will wait... the offical release, since I use the opensuse package... I don't want re-customize here...

[lhy719]

Good to know that will solve in resent release.

Hi Ceinmart,

Thanks for your information! I compiled 2.0.5. Maybe the patch works for me!

[rocksteady]

The patch works like a charm on 2.0.6 .... I wonder why this is not included in 2.0 branch .

Cheers R.

[lhy719]

Agree with you! The patch works fine on 2.0.x.