Force sw/hw information from another MIB?

LibreNMS does not show the hardwaremodel/serial/firmware version for my Eaton UPSes with the new model management card (M2). I believe this is due to LibreNMS polling the old vendor MIB (upsmg) for these values, and the new model card does not support this MIB.

This is the hardware/software info I can extract from the two cards. (The new card is an entirely new platform, not just a software upgrade.)

Eaton MS (old management card)

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.705.1

UPS-MIB::upsIdentManufacturer.0 = STRING: EATON
UPS-MIB::upsIdentModel.0 = STRING: Eaton 9PX 1000i RT 2U
UPS-MIB::upsIdentUPSSoftwareVersion.0 = STRING: INV: 01.14.4257
UPS-MIB::upsIdentAgentSoftwareVersion.0 = STRING: Network Management Card V6.00 LD
UPS-MIB::upsIdentName.0 = STRING: ID: GA10H2xxxx , Msg: 9PX1000iRT2U

MG-SNMP-UPS-MIB::upsmgIdentFamilyName.0 = STRING: "Eaton 9PX"
MG-SNMP-UPS-MIB::upsmgIdentModelName.0 = STRING: "1000i RT 2U"
MG-SNMP-UPS-MIB::upsmgIdentFirmwareVersion.0 = STRING: "01.14.4257"
MG-SNMP-UPS-MIB::upsmgIdentSerialNumber.0 = STRING: "GA10H2xxxx"
MG-SNMP-UPS-MIB::upsmgAgentFirmwareVersion.0 = STRING: "LD"

XUPS-MIB::xupsIdentManufacturer.0 = STRING: "EATON"
XUPS-MIB::xupsIdentModel.0 = STRING: "Eaton 9PX 1000i RT 2U"
XUPS-MIB::xupsIdentSoftwareVersion.0 = STRING: "INV: 01.14.4257"

Eaton M2 (new management card)

SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.534.1

UPS-MIB::upsIdentManufacturer.0 = STRING: EATON
UPS-MIB::upsIdentModel.0 = STRING: Eaton 9PX 1000i RT 2U
UPS-MIB::upsIdentUPSSoftwareVersion.0 = STRING: 01.20.5072
UPS-MIB::upsIdentAgentSoftwareVersion.0 = STRING: 1.7.5
UPS-MIB::upsIdentName.0 = STRING: GA10K0yyyy

XUPS-MIB::xupsIdentManufacturer.0 = STRING: "EATON"
XUPS-MIB::xupsIdentModel.0 = STRING: "Eaton 9PX 1000i RT 2U"
XUPS-MIB::xupsIdentSoftwareVersion.0 = STRING: "01.20.5072"
XUPS-MIB::xupsIdent.5.0 = STRING: "9PX1000iRT2U"
XUPS-MIB::xupsIdent.6.0 = STRING: "GA10K0yyyy"

XUPS-MIB::xups.14.1.0 = STRING: "Eaton"
XUPS-MIB::xups.14.2.0 = STRING: "Eaton Gigabit Network Card"
XUPS-MIB::xups.14.3.0 = STRING: "1.7.5"
XUPS-MIB::xups.14.4.0 = STRING: "744-A3983-02"
XUPS-MIB::xups.14.5.0 = STRING: "G312K0zzzz"

(The new card has some XUPS entries not present in the old card’s version of the same MIB. A new MIBfile does exist.)

As can be seen, both cards support both UPS-MIB and XUPS-MIB. Only the old one supports MG-SNMP-UPS-MIB/upsmg.

Can I force both devices to get the hw/sw info from the UPS-MIB? The UPSes are otherwise identical, only the management card is different.

The current code does:

$version = trim(snmp_get($device, 'upsmgIdentFirmwareVersion.0', '-OQv', 'MG-SNMP-UPS-MIB'), '" ');

$hardware  = trim(snmp_get($device, 'upsmgIdentFamilyName.0', '-OQv', 'MG-SNMP-UPS-MIB'), '" ');
$hardware .= ' '.trim(snmp_get($device, 'upsmgIdentModelName.0', '-OQv', 'MG-SNMP-UPS-MIB'), '" ');

$serial = trim(snmp_get($device, 'upsmgIdentSerialNumber.0', '-OQv', 'MG-SNMP-UPS-MIB'), '" ');

I propose to combine the UPS firmware version number and management card firmware version number into one, such that both bits of information can be searched and displayed.
This appears to be the way it is done for APC UPSes and PDUs.

I was hoping the following would do the trick, but it looks like I am missing a part of the logic for matching devices to the right yaml file.

$hardware = trim(snmp_get($device, 'upsIdentModel.0', '-OQv', 'UPS-MIB'), '" ');

$version = trim(snmp_get($device, 'upsIdentAgentSoftwareVersion.0', '-OQv', 'UPS-MIB'), '" ');
$version += ' / '.trim(snmp_get($device, 'upsIdentUPSSoftwareVersion.0', '-OQv', 'UPS-MIB'), '" ');

$serial = trim(snmp_get($device, 'upsIdentName.0', '-OQv', 'UPS-MIB'), '" ');

This only results in no OS information being recorded at all. Would love some guidance.

As it seems that this old M1 card is a mess, I would suggest to create a new OS for the M2. Then you can poll the OID you like without touching the old M1 card.

I thought we had too many OSes already? :slight_smile:

Seeing how the actual UPS is the same, and that there is a common option for getting data from the two cards, I find it compelling to make them share code. I’ll listen to arguments against this, of course.

The final(?) sw release for the old card (LD) makes it somewhat workable. If not trustworthy. Too many crazy bugs fixed just recently. And weak crypto.

If you can include it in the existing OS without touching the existing code, then of course do it.
But if you have to change the code, you may break it and this M1 device is known to be “bad” to say the least :slight_smile:
As you say, it is a completely new device, so the same it should be for LibreNMS.

I found the relevant doc. Will see if I can figure this out.

I think I’ve been able to fix this issue on our M2’s.
I’ll create a PR, would be nice if someone could check for possible regressions