[Nut-upsdev] SNMP Stuff/MIBs for CyberPower and APC UPSs

[Jim Klimov]

On June 11, 2017 8:58:11 AM GMT+02:00, Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:
>On 10 June 2017 23:26:47 EEST, Tim Dawson <tadawson at tpcsvc.com> wrote:
>>Build from source, and done . . . wasting your time looking for a less
>>out of date RPM is pointless. . . RPM, .deb, etc are almost always
>>downrev. . . 
>>
>>- Tim
>>
>>On June 10, 2017 2:06:42 PM CDT, Ben Kamen <ben at benkamen.net> wrote:
>>>Hey all,
>>>
>>> I recently got an RMCARD205 for my Cyber UPS....
>>>
>>>if I use no MIBS line in the config file, I get this:
>>>
>>>
>>>> Network UPS Tools - UPS driver controller 2.6.5
>>>> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5)
>>>> No matching MIB found for sysOID '.1.3.6.1.4.1.3808.1.1.1'!
>>>> Please report it to NUT developers, with an 'upsc' output for your
>>>device.
>>>> Going back to the classic MIB detection method.
>>>> Detected PR1500LCDRTXL2Ua on host 192.168.125.10 (mib: cyberpower
>>>0.1)
>>>> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5)
>>>> Detected SMART-UPS 3000 RM on host 192.168.125.7 (mib: apcc 1.2)
>>>> [shop] Warning: excessive poll failures, limiting error reporting
>>>> [shop] Warning: excessive poll failures, limiting error reporting
>>>
>>>If I use the mibs = cyberpower
>>>
>>>it works as somewhat expected:
>>>
>>>>
>>>> Network UPS Tools - UPS driver controller 2.6.5
>>>> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5)
>>>> Detected PR1500LCDRTXL2Ua on host 192.168.125.10 (mib: cyberpower
>>>0.1)
>>>> Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5)
>>>> Detected SMART-UPS 3000 RM on host 192.168.125.7 (mib: apcc 1.2)
>>>> [shop] Warning: excessive poll failures, limiting error reporting
>>>> [shop] Warning: excessive poll failures, limiting error reporting
>>>
>>>
>>>but could use updating as the upsc output is kinda lacking some
>>desired
>>>measurements (that I get with APC) ... I see the current is 2.7.x but
>>>I'm on CentOS/RH 6.x which seems to have stalled out at 2.6.5
>>>
>>>Does 2.7 have the newer fancy MIB and I can just compile up and
>>install
>>>manually?
>>>
>>>I'm assuming RH/CentOS 6 won't be getting anymore updates. :(
>>>
>>>I'll look around some more for an RPM for 6.x
>>>
>>>Cheers,
>>>
>>> -Ben
>>>
>>>
>>>Also,
>>>
>>>when I go to : http://networkupstools.org/docs/man/snmp-ups.html and
>>>click on the link at the bottom:
>>>http://www.networkupstools.org/protocols/snmp/ I get a 404 error.
>>(just
>>>an FYI)
>>>
>>>_______________________________________________
>>>Nut-upsdev mailing list
>>>Nut-upsdev at lists.alioth.debian.org
>>>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>
>I can upload to http://wolfy
>.fedorapeople
>org  the packages I built for  2.7.4, if you are willing to test them.
>I am using them for several months.
>
>Wolfy
>
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Hi.

The SNMP support in NUT works by having a large number of mapping tables  that correlate certain OIDs (exact or recently patterned, for arrays of similar data points) to NUT keys, and sometimes define conversion functions to get standard-units values. The MIB files are not directly used for this at runtime, though are often invaluable to create or maintain these mapping tables as hardware support evolves.

UPS management cards might refer to their standard entry point, which allows the driver to guess a relevant MIB as recommended by vendor, though there are cases when another MIB matches better in practice - so there is an option to pick it explicitly. NUT can also probe these entry points that it knows from mapping data, to see if it gets a meaningful response. Also most devices provide some data (without fancy vendor-specific features) in the IETF standard MIB subtree, so it is the last fallback choice in automatic guesswork.

>Does 2.7 have the newer fancy MIB and I can just compile up and
>install manually?

I cherish this part of your question ;) as I spent a large part of last year co-developing the DMF (dynamic mapping format for me, though there are other de-abbreviations) technology which allows just that - give the capable version of snmp-ups the suitable mapping file, reload the driver and try out support for new hardware with unchanged binaries. This mapping file is an XML with mappings described above - whereas the original NUT mappings are in C code and stuff must be recompiled to change this data.

Currently the DMF branch is in PR limbo (being a large chunk of added code), and there were questions whether anyone needs it beside our forked project this was made for. IMHO it would be useful in cases like yours as well, where people are stuck with whatever their distro offers (perhaps due to compliance and certification, or lack of time or skill to re-roll their own package), so please speak up to sway the balance ;)

Finally, as you would compile your own, consider taking the github upstream/master branch - it has quite advanced ahead of the latest official tarballed release.

Jim

--
Typos courtesy of K-9 Mail on my Redmi Android