I was trying to figure out why some output in FreeIPMI was different
than in ipmitool, then I figured it out. In lib/ipmi_sensor.c in
several locations after a sensor reading, there is code like this:
printf("| 0x%-8x | %-10s | 0x%02x%02x",
val,
unitstr, rsp->data[2], rsp->data[3]);
Most notably, the code is reading data[2] and data[3] from the response,
which maps to state offsets 0-7 and 8-14 of discrete sensors.
In the IPMI spec (35.14), only states 0-7 (byte data[2]) are required to
be returned, states 8-14 (byte data[3]) are optional. So if you have a
sensor that is returning only the first set of offsets, you have an
array out of bounds and the output is returning whatever junk is out
there. I've also found some sensors that don't return either byte
(which is a compliance issue, but nevertheless), perhaps that should be
handled as well.
Thinking about this for another 10 seconds, I suppose if the ipmi response (rsp var) were cleared properly in each ipmitool interface (lan, open, etc.), then this problem might go away, although I feel the array out of bounds is probably always a bad thing to do. (note the array out of bounds is not going off the array of allocated memory, but rather going passed the "max index" of data read.)
Looks like this has been fixed (by zeroing of the response buffer) back in 2012 by Jim Mankovich with commit [5d9600]. Closing.
Related
Commit: [5d9600]