[impact]
ipmi-sensors reads the wrong sensor on a Lenovo BMC (although the problem may happen on other BMCs as well)
[test case]
run ipmi-sensors over the network using ipmi 1.5 or 2 protocol, and check the sensor output. Specifically for this case, the server is a Lenovo SR665 with only 1 cpu socket populated, and dimms 1-16 are connected to cpu 1 while dimms 17-32 are connected to cpu2, so dimms 17-32 should not return any values.
$ ipmi-sensors -u $USERNAME -p $PASSWD -D LAN_2_0 -l USER -h $BMCADDR | grep DIMM | grep Temp
110 | DIMM 1 Temp | Temperature | N/A | C | N/A
113 | DIMM 2 Temp | Temperature | N/A | C | N/A
116 | DIMM 3 Temp | Temperature | N/A | C | N/A
119 | DIMM 4 Temp | Temperature | N/A | C | N/A
122 | DIMM 5 Temp | Temperature | N/A | C | N/A
125 | DIMM 6 Temp | Temperature | N/A | C | N/A
128 | DIMM 7 Temp | Temperature | N/A | C | N/A
131 | DIMM 8 Temp | Temperature | N/A | C | N/A
134 | DIMM 9 Temp | Temperature | 52.00 | C | 'OK'
137 | DIMM 10 Temp | Temperature | 42.00 | C | 'OK'
140 | DIMM 11 Temp | Temperature | N/A | C | N/A
143 | DIMM 12 Temp | Temperature | N/A | C | N/A
146 | DIMM 13 Temp | Temperature | 27.00 | C | 'OK'
149 | DIMM 14 Temp | Temperature | 26.00 | C | 'OK'
152 | DIMM 15 Temp | Temperature | 24.00 | C | 'OK'
155 | DIMM 16 Temp | Temperature | 24.00 | C | 'OK'
158 | DIMM 17 Temp | Temperature | 218.00 | C | 'OK'
161 | DIMM 18 Temp | Temperature | 212.00 | C | 'OK'
165 | DIMM 19 Temp | Temperature | 212.00 | C | 'OK'
173 | DIMM 20 Temp | Temperature | N/A | C | N/A
176 | DIMM 21 Temp | Temperature | N/A | C | N/A
179 | DIMM 22 Temp | Temperature | N/A | C | N/A
182 | DIMM 23 Temp | Temperature | N/A | C | N/A
185 | DIMM 24 Temp | Temperature | N/A | C | N/A
188 | DIMM 25 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
191 | DIMM 26 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
194 | DIMM 27 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
197 | DIMM 28 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
200 | DIMM 29 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
203 | DIMM 30 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
206 | DIMM 31 Temp | Temperature | 0.00 | C | 'At or Below (<=) Lower Non-Critical Threshold'
209 | DIMM 32 Temp | Temperature | N/A | C | N/A
[regression potential]
any regression would likely result in incorrect values shown for some/all sensor readings
[scope]
this was recently fixed upstream, so it needed in all releases
https://github.com/chu11/freeipmi-mirror/pull/43
a new upstream release was made including the fix, so debian will pick it up in their next devel cycle
[other info]
the problem is that this particular BMC has chosen to use a non-zero 'LUN' number for these sensors; almost all BMCs use the standard LUN number 0, as the spec does state in section 19.3:
"Unless otherwise specified, commands that are listed as mandatory must be accessed via LUN 00b"
However the spec does allow for implementations to use alternate LUN numbers, specifically section 5.4 describes how the BMC would report the LUN number to the requesting software, and section 7.2 clarifies that while LUN 00b is reserved for devices beloning to the BMC itself and 10b is reserved for SMS messages, LUN numbers 01b and 11b are reserved for 'OEM' use. So it does appear valid for the BMC implementation to place sensor(s) under LUN 01b instead of the default 00b.
The cause of the invalid sensor readings in this particular case is because the BMC also defines sensors with the exact same sensor id number, but with LUN 00b. So when freeipmi attempts to read e.g. 'DIMM 17 Temp' sensor, it actually reads the current value for a completely different sensor, which (in this case) isn't even a temperature sensor, resulting in invalid temperature reading shown for the sensor, instead of showing it as N/A (since the DIMM slot isn't populated).
Note that ipmitool correctly uses the alternate LUN number so this bug does not exist with that tool, this affects only freeipmi tooling.
proposed fix https:/