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@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
