Repository navigation
HP iLO 4 answers Get SDR with InsufficientPrivilege (D4h) intermittently and the whole walk fails #146
Closed as not planned
Description
Activity
Closing as caused by the lab environment, not by the library.
What was going on. A broken MetricsHub connector in the lab deletes the IPMI sessions of this iLO every two minutes. A deleted session stays usable at first, then answers D4h to every command: the iLO applies the deletion at a whole minute of the session's age (60 s, 120 s, 180 s). The lab card is an iLO 5 (ProLiant Gen10), not an iLO 4.
- Measured with low-level probes: once a session gets D4h, Set Session Privilege Level gets it too, and the same Get SDR sent 61 times over 22 s never succeeds. A new session works at once. Sending the request again in the same session, as suggested above, therefore cannot help.
- Dedicated account: with a
metricshubaccount created on the iLO, sessions were still revoked at whole minutes of their age, whatever the keep-alive command. The broken connector probably deletes every session it can see. The fix belongs in that connector.
What #152 changes for this symptom:
- A Get Sensor Reading refused with any completion code costs only that sensor (WARN naming the sensor and the host), not the whole walk.
- Troubleshooting describes the revoked-session symptom:
0xD4on commands that worked earlier in the same session.
A walk whose session is revoked mid-way still fails. The only library-side cure would be to open a new session and resume the walk at the same record. It's not planned unless a revocation shows up outside this lab.
- added a commit that references this issue
on Oct 9, 2026
Where:
src/main/java/org/metricshub/ipmi/client/runner/AbstractIpmiRunner.java(getSensorData),GetSensorsRunner.javaandGetFrusRunner.java(call).What happens: an HP iLO 4 (ilo-hp-ceph, ProLiant) answers Get SDR with completion code
D4h(Cannot execute command due to insufficient privilege level or other security-based restriction) now and then, in the middle of a repository walk that otherwise works at the User privilege level.getSensorData()rethrows everyIPMIExceptionother thanCannotRespond/UnspecifiedError, and the runners rethrow everyIPMIExceptionother thanReservationCanceled, so the whole call fails:getFrusAndSensorsAsStringResult()throwsExecutionExceptionwrapping thatIPMIExceptionand returns nothing.Evidence (survey of 2026-10-09, branch
fix/decoders): on this iLO,getSensors()alone succeeds (107 sensors, 39 and 45 s in two runs),getFrus()alone succeeds (12 FRUs, 58 s), but 3 of 8getFrusAndSensorsAsStringResult()calls failed after about 61 s with theD4hon a Get SDR (stack:GetSdr.getResponseData→IpmiCommandCoder.validateResponse). The same code was also seen once on a Read FRU Data at offset 2016 of FRU 2 (logged and tolerated by the FRU reader since #143). ipmitool is not affected in the same way because it retries the command.Suggested fix: in
getSensorData(), send the Get SDR of the same record again (once or twice, re-reserving the repository) when the BMC answers with an error code that is not one of the "record too large" codes, and only fail the walk when the retry fails too. The same for Get Sensor Reading: an error code other thanDataNotPresenton one sensor should cost that sensor, not the walk. Reproducible on the lab iLO 4 by repeating the combined call a few times.Related: #101 (privilege level is not configurable: Operator might avoid the
D4hon this firmware), #77/#140 (the retries of the transport layer only cover lost replies).