Nut upsdev - Oct 2017 - Updating snmp-mib.c with new Cyberpower v2.0 MIB

Hey all,


?I'm feeling spunky... and want to update nut to handle the new v2.0 MIB
from CyberPower.

I've looked at the cyberpower v0.1 .c/.h and being new to working on nut to
this level -- anything anyone has to offer on adding code besides the obvious?

like: should the 0.1 and 2.0 coexist somehow? (maybe different files)

(also, is there a list of all the parms I can match up from the MIB? -- i.e. the
APC MIB.c is pretty comprehensive, I suppose I could use that as a model. I
haven't looked at all the SNMP .C files yet though. Will do that later
tonight and get busy.)

Cheers,


?-Ben

On October 31, 2017 2:32:36 AM GMT+01:00, Ben Kamen <ben at benkamen.net>
wrote:
>Hey all,
>
>
>?I'm feeling spunky... and want to update nut to handle the new v2.0
>MIB from CyberPower.
>
>I've looked at the cyberpower v0.1 .c/.h and being new to working on
>nut to this level -- anything anyone has to offer on adding code
>besides the obvious?
>
>like: should the 0.1 and 2.0 coexist somehow? (maybe different files)
>
>(also, is there a list of all the parms I can match up from the MIB? --
>i.e. the APC MIB.c is pretty comprehensive, I suppose I could use that
>as a model. I haven't looked at all the SNMP .C files yet though. Will
>do that later tonight and get busy.)
>
>Cheers,
>
>
>?-Ben
>
>
>
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Welcome!

If the new data is in a separate OID tree, it can quite be a new MIB. Otherwise
you can use the UNIQUE flag and set the preferred (e.g. newer, more precise)
source for a value first in the list of same-named mappings in existing file -
if there's a hit on an actual device, it will be used and not iterated
onwards. The flag is not yet supported for all cases though (e.g. daisy-chained
devices), so some other combinations would set the preferred value mapping last
in list.

I'm on the road now so can't point exactly, but there's a text file
in docs/ (?)  which lists and describes the mappings which drivers should share
(for any media and vendor-protocol -- e.g. networked snmp in this case).

Hope this helps,
Jim 

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

On 10/31/2017 01:13 AM, Jim Klimov wrote:
> If the new data is in a separate OID tree, it can quite be a new MIB.
Otherwise you can use the UNIQUE flag and set the preferred (e.g. newer, more
precise) source for a value first in the list of same-named mappings in existing
file - if there's a hit on an actual device, it will be used and not
iterated onwards. The flag is not yet supported for all cases though (e.g.
daisy-chained devices), so some other combinations would set the preferred value
mapping last in list.
> I'm on the road now so can't point exactly, but there's a text
file in docs/ (?)  which lists and describes the mappings which drivers should
share (for any media and vendor-protocol -- e.g. networked snmp in this case).
the gen-snmp script -- VERY handy... looks like I just have to fish through the
MIB (which seems pretty well documented) to add the beef...


As for the UNIQUE flag, since this is SNMP, I'm guessing we'll have the
network plug-ins that are the old MIB (I'll have to look it up) versus the
new network modules that support the v2.0 MIB.

for now, I'm building a separate .C and .H file.

More later..

?-Ben