Tricky OID in Mikrotik wireless, containing mac addresses

[jensovel]

This is a question if it is possible to convert a mac address in hex to an integer format and use it in a OID, used in an Item prototype in a Discovery list.

I've spent days looking through Zabbix documentation, forums, evaluating downloadable templates, testing Zabbix 4.0, googling and so on in an effort to try to read Microtik wireless statuses through SNMP.
Reading ethernet interfaces, CPU, voltage etc is no problem. But to read the different WIRELESS statuses in a Mikrotik AP is harder. Why? Because the OIDs there are build partly from the mac addresses of the wireless connections. It's not enough with a numeric SMNP index.

So, to find the statuses of the connections to the wireless stations/clients (all connected to the same AP) we need to look into the wireless table and registration table in the AP.
I've add the MIB file from Mikrotik and it makes it simpler for snmpwalk.

snmpwalk -v 2c -c public 10.221.2.1 -On MIKROTIK-MIB::mtxrWlRtabUptime
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.35.224.56. 8 = Timeticks: (116377300) 13 days, 11:16:13.00
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.35.224.64. 8 = Timeticks: (116377300) 13 days, 11:16:13.00
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.44.77.92.8 = Timeticks: (116377100) 13 days, 11:16:11.00
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.96.136.199 .8 = Timeticks: (34980200) 4 days, 1:10:02.00
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.96.137.12. 8 = Timeticks: (116377300) 13 days, 11:16:13.00
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.219.76.195 .8 = Timeticks: (115348800) 13 days, 8:24:48.00
.1.3.6.1.4.1.14988.1.1.1.2.1.11.0.12.66.241.231.33 .8 = Timeticks: (116351900) 13 days, 11:11:59.00

Here 7 clients are connected to the AP, and the different uptimes are showing. A part of the OID, example "0.12.66.241.231.33" in the last line is the mac of the client.
MIKROTIK-MIB::mtxrWlRtabUptime cannot be used with index, as I can see.
All OIDs contain prefix, the mac and a suffix. I cannot see how to use a SNMPINDEX here to collect the client info one by one in a Discovery list.

Ok, we do a test:
To log, display and alert for different statuses like uptime, wireless speed, noise floor, and so on, we define Discovery list/rules and under there Item prototypes.

The mac addresses can be found using a discovery rule:
discovery[{#SNMPVALUE},1.3.6.1.4.1.14988.1.1.1.2.1.1]
#SNMPVALUE vill then contain teh mac addresses in hex.
Available clients:
snmpwalk -v 2c -c public 10.221.2.1 -On 1.3.6.1.4.1.14988.1.1.1.2.1.1
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.35.224.56.8 = Hex-STRING: 00 0C 42 23 E0 38
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.35.224.64.8 = Hex-STRING: 00 0C 42 23 E0 40
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.44.77.92.8 = Hex-STRING: 00 0C 42 2C 4D 5C
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.96.136.199. 8 = Hex-STRING: 00 0C 42 60 88 C7
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.96.137.12.8 = Hex-STRING: 00 0C 42 60 89 0C
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.219.76.195. 8 = Hex-STRING: 00 0C 42 DB 4C C3
.1.3.6.1.4.1.14988.1.1.1.2.1.1.0.12.66.241.231.33. 8 = Hex-STRING: 00 0C 42 F1 E7 21

We define Item prototypes:
Key: WirelessRegistrationTable-NoiseFloor[{#SNMPVALUE}]
SNMP OID: .1.3.6.1.4.1.14988.1.1.1.2.1.12.{#SNMPVALUE}.8

We connect this to a device.
From the log:
item "BR-MI-S21 - Kvaale Vest 3:WirelessRegistrationTable-NoiseFloor[00 0C 42 60 88 C7 ]" became not supported: snmp_parse_oid(): cannot parse OID "1.3.6.1.4.1.14988.1.1.1.2.1.12.00 0C 42 60 88 C7.8".

It tells: cannot parse OID "1.3.6.1.4.1.14988.1.1.1.2.1.12.00 0C 42 60 88 C7.8"
Of course it can't. The string "00 0C 42 60 88 C7" needs to be converted to the integer representation, with dots added. That means: "0.12.66.96.136.199"

snmpwalk -v 2c -c public 10.221.2.1 -On 1.3.6.1.4.1.14988.1.1.1.2.1.12.0.12.66.96.136.199. 8
.1.3.6.1.4.1.14988.1.1.1.2.1.12.0.12.66.96.136.199 .8 = INTEGER: 58
So the noise floor for this connected client is 58dB. That is what we are looking for. But how to make this work in Zabbix? Converting "00 0C 42 60 88 C7" to "0.12.66.96.136.199". Or any other approach?

Have tried to implement this conversion with macro and regsub, unsuccessfully. Zabbix 3.0 is in production, but I have Zabbix 3.4 available too, and can switch to it.
Anyone who can help?
Thanks.

[Linwood]

{#SNMPINDEX} will be the remainder of the OID on an LLD. So if you walk .1.3.6.1.4.1.14988.1.1.1.2.1.1, while {#SNMPVALUE is the unsable MAC, {#SNMPINDEX} should be usable to retrieve like this: .1.3.6.1.4.1.14988.1.1.1.2.1.11.{#SNMPINDEX}

[jensovel]

Thanks!
Using #SNMPINDEX was the first I tried, but it failed for me. So I thought that the index was a kind of single integer. When I now try again - IT WORKS!
Could be that the template I found and used missed the trailing "8" in the OID, like this: .1.3.6.1.4.1.14988.1.1.1.2.1.12.{#SNMPINDEX}.8
Could also be that I have a server-proxy setup and sometimes it takes a very long time (or never) to bring the configuration through, and the SNMP value back. I use to restart both server and proxy to bring the config changes through faster. But even then it can be slow. Both server and proxy have more than enough resources. I wish I could figure out how to bring config changes quicker through the system. If anyone knows, I'll be glad to hear.
It is kind of hard to clearly see what is not working, what is working and why.
Thanks again!

[Linwood]

One common confusion (that I make often) is templates will use an OID that corresponds itself to an index, and in the walk {#SNMPINDEX} and {#SNMPVALUE} will actually be the same return. You then get in the habit of using {#SNMPVALUE} as the index in the key or prototype OID and things break. Been there, done that. Glad you got it figured out.