onsdag 18 mars 2009 12:11:47 skrev Philip Ward: Hi Philip, The best is to do a separate include like hpmib.h (or cpqmib.h), Like the pwmib.h for Powerware.
The R5500XR use the CPQPOWER.MIB. You may find info here: http://www.snmplink.org/cgi- bin/nd/m/Ent/H/Hewlett%20Packard%20(HP)/%5BALL%5D%20-%20HP%20Insight%20Management/Compaq/cpqpower.mib (Sorry for the line break) I'm not directly involved in the snmp driver, but I think you needed an answer. Regards Kjell > We use HP R5500XR UPS, and they all have SNMP cards. These devices > supposedly use the IETF MIB, but in order to get the SNMP driver to talk > to them I have had to hack it slightly. > > I'd like to see these UPS proplerly supported in the official nut > release (mostly so I don't have to faff around patching and repackaging > when a new version comes out) and would be more than happy to provide > patches, but I'd like to see if anyone has an opinion regarding these > fixes. Simply changing ietfmib.h (which is all I have had to do to get > it to work) would probably break it for other SNMP UPS. I can see a > couple of ways to fix this. > > One way would be to add a new mib (e.g. hpmib.h). This would be the > simplest, but adds extra maintenance. > > A more complicated way would be to make the snmp driver a little more > intelligent. > Currently it chokes when an expected oid is not available on the device > with which it is communicating. (For example ietfmib.h specifies > batt.current at oid 1.3.6.1.2.1.33.1.2.6.0. Our R5500XRs don't have > provide this oid so the snmp driver complains and dies.) It may be > better if it ignored absent oids. > > Also the expected data is not always in exactly the same place. For > example the IETF MIB specification states that output voltage should be > at oid 1.3.6.1.2.1.33.1.4.4.1.2. > ietfmib.h is written to get this data from oid > 1.3.6.1.2.1.33.1.4.4.1.2.0 > Our R5500XRs provide the data at oid 1.3.6.1.2.1.33.1.4.4.1.2.1 > Should the SNMP driver be told to find the data at > 1.3.6.1.2.1.33.1.4.4.1.2 and then automatically drill down further? > > I have attached a unified diff showing what had to change in ietfmib.h > to get the driver to work. I can document the changes in greater detail > if required. > > > - > Philip Ward > Unix Systems Administrator > Ext 7274 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
