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

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

On November 2, 2017 5:31:42 AM GMT+01:00, Ben Kamen <ben at benkamen.net>
wrote:
>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
>
>
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
I believe the main reason for a new set of .c/.h files here would be if the new
MIB is defined in a separate subtree. The top-level mapping binds the vendor
entry OIDs (often "hidden" so one has to know where to poke). It may
also be higher in the list of snmp-ups.h, in case the device also serves the
older MIB but you'd prefer the newer (e.g. common standard IETF one is
always last).

If both the older and newer data are in the same vendor tree, e.g. new leaf
points are added, you'd extend the existing table.

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

On 11/02/2017 01:52 AM, Jim Klimov wrote:
>
> I believe the main reason for a new set of .c/.h files here would be if the
new MIB is defined in a separate subtree. The top-level mapping binds the vendor
entry OIDs (often "hidden" so one has to know where to poke). It may
also be higher in the list of snmp-ups.h, in case the device also serves the
older MIB but you'd prefer the newer (e.g. common standard IETF one is
always last).
>
> If both the older and newer data are in the same vendor tree, e.g. new leaf
points are added, you'd extend the existing table.
I'll have to compare...? working on the basics at the moment.

Once I get the new one filled in -- I'll check it to the old 0.1 version
mib.c

Thanks,

?-Ben