Nut upsdev - Mar 2009 - SNMP on HP UPS

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


-- 
Academic Excellence at the Heart of Scotland.
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ietfchanges
Type: text/x-patch
Size: 3491 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090318/970e981a/attachment.bin

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