Fix bogus reply from snmpwalk in ipNetToPhysicalPhysAddress

[PipoCanaja]

Check to catch bogus replies from snmpwalk (bad formatting). Seems that version 5.7.2 at least shows this behaviour.

Here is the wrong reply from snmpwalk :

IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.9 = 18:94:ef:13:eb:88

instead of

IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][10.19.0.9] = 18:94:ef:13:eb:88

DO NOT DELETE THE UNDERLYING TEXT

Please note

Please read this information carefully. You can run ./lnms dev:check to check your code before submitting.

• Have you followed our code guidelines?
• If my Pull Request does some changes/fixes/enhancements in the WebUI, I have inserted a screenshot of it.
• If my Pull Request makes discovery/polling/yaml changes, I have added/updated test data.

Testers

If you would like to test this pull request then please run: ./scripts/github-apply <pr_id>, i.e ./scripts/github-apply 5926
After you are done testing, you can remove the changes with ./scripts/github-remove. If there are schema changes, you can ask on discord how to revert.

[PipoCanaja]

Here is the wrong reply from snmpwalk :

-bash-4.2$ '/usr/bin/snmpwalk' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/cisco' '-v2c' '-c' 'xxxxxxxxx' '-OQXUte' 'udp:10.0.0.10:161' 'IP-MIB::ipNetToPhysicalPhysAddress'
IP-MIB::ipNetToPhysicalPhysAddress[4][ipv6][.253.0.0.0.0.0.0.12.0.0.0.0.0.0.0.1 = a2:1f:0:0:1:f9
IP-MIB::ipNetToPhysicalPhysAddress[4][ipv6z][.254.128.0.0.0.0.0.0.160.31.0.255.254.0.1.248 = a2:1f:0:0:1:f9
IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.8 = 18:94:ef:13:e4:68
IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.9 = 18:94:ef:13:eb:88
IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.10 = 10:50:56:85:e:1
IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.11 = 10:50:56:83:69:0
IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.13 = 10:50:56:9e:a9:41
IP-MIB::ipNetToPhysicalPhysAddress[17][ipv4][.10.19.0.15 = 10:50:56:83:3f:9c
...

[laf]

LGTM

[librenms-bot]

This pull request has been mentioned on LibreNMS Community. There might be relevant details there:

https://community.librenms.org/t/23-7-0-changelog/21841/1