Hi,
I have a custom OS discovery file for a Dinstar MTG200C VoIP gateway that used to work and now fails after updating to a recent dev release.
Environment
- LibreNMS 26.11.0-dev.147+3feaacb605 (2026-11-04)
- DB schema 2026_10_31_000000_split_device_types_config (430)
- PHP 8.4.27, Python 3.10.12, MariaDB 10.6.23, SNMP 5.9.1
- OS detected correctly as dinstar (sysDescr match)
What I have
resources/definitions/os_discovery/dinstar.yaml (abridged):
mib: VOIP-MTG2000-3000-MIB
modules:
sensors:
state:
data:
-
oid: 'PRILinkStatusTable'
value: 'LinkStatus'
num_oid: '.1.3.6.1.4.1.38111.7.1.2.1.1.5.{{ $index }}'
descr: 'PRI0 Status'
state_name: 'PRI0LinkStatus'
index: 'LinkStatus.{{ $index }}'
states:
- { descr: 'Fault', value: 3, generic: 2, graph: 0 }
- { descr: 'Establishing', value: 1, generic: 1, graph: 0 }
- { descr: 'Normal', value: 0, generic: 0, graph: 0 }
# same pattern for E1Port0 and SIPTrunkStatusTable
Detection file resources/definitions/os_detection/dinstar.yaml has os: dinstar and a sysDescr match. No mib_dir is set, so the default mibs/dinstar should apply.
What I checked
- The MIB is in /opt/librenms/mibs/dinstar/VOIP-MTG2000-3000-MIB, with no extension. The module name on the DEFINITIONS ::= BEGIN line matches the filename exactly. I previously had it in the mibs/ root and moved it to mibs/dinstar/ per the MIB guidelines.
- snmptranslate -M /opt/librenms/mibs:/opt/librenms/mibs/dinstar -m VOIP-MTG2000-3000-MIB -Tp loads the module without errors.
The problem
lnms device:discover 27 -m sensors -vvv produces:
SNMP\['/usr/bin/snmpbulkwalk' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/dinstar:/opt/librenms/mibs/' '-m' 'SNMPv2-TC:SNMPv2-MIB:IF-MIB:IP-MIB:TCP-MIB:UDP-MIB:NET-SNMP-VACM-MIB' ... 'PRILinkStatusTable'\]
PRILinkStatusTable: Unknown Object Identifier (Sub-id not found: (top) -> PRILinkStatusTable)
The -M path now correctly includes mibs/dinstar, but VOIP-MTG2000-3000-MIB is not in the -m list. The mib: key at the top of my YAML seems to be ignored, so the symbolic OID names can’t be resolved. The same happens for the other two tables.
Did the handling of the top-level mib: key in os_discovery YAML change recently?
I can’t understand why it isn’t working anymore.
Thanks