Drop the unverified iLO 5 session-lifetime claims

Further lab runs with a dedicated iLO account showed that the D4h comes
from sessions deleted by another client of the lab iLO (a management tool
that deletes the IPMI sessions every two minutes): the iLO applies the
deletion at a whole minute of the session's age, whatever the keep-alive
command (a Get Device ID keep-alive session was revoked at 121 s too).
The keep-alive stays a Get Device ID, as ipmitool sends, without the
claim that Get Channel Authentication Capabilities shortens iLO sessions;
troubleshooting describes the revoked-session symptom instead.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Author: bertysentry

src/main/java/org/metricshub/ipmi/core/connection/Connection.java

@@ -687,8 +687,7 @@ public void notify(StateMachineAction action) {
 	}
 
 	/**
-	 * The keep-alive request: a Get Device ID, as ipmitool sends. HP iLO 5 revokes the privileges of a session 60 s
-	 * after a Get Channel Authentication Capabilities or a Set Session Privilege Level sent in it, instead of 120 s.
+	 * The keep-alive request: a Get Device ID, as ipmitool sends.
 	 */
 	private static final class KeepAlive extends IpmiCommandCoder {
 

src/site/markdown/troubleshooting.md

@@ -64,12 +64,11 @@ one, check:
 With the [low-level API](low-level-api.html#privilege-level), open the session with the level the
 command needs (Operator for Chassis Control, Administrator for configuration commands).
 
-When commands that worked earlier in the same session start failing with `0xD4`, the BMC revoked
-the session. HP iLO 5 does so 120 s after the session opened, whatever its privilege level, and
-can do so after 60 s when a Get Channel Authentication Capabilities or a Set Session Privilege
-Level command is sent during the session (the library's keep-alive is a Get Device ID for that
-reason). Each `IpmiClient` call opens its own session; with the low-level API, open a new session
-for work that lasts longer.
+When commands that worked earlier in the same session start failing with `0xD4`, the session was
+revoked, and sending the command again in the same session does not help. On HP iLO 5, this is
+what happens when another client deletes the sessions, for example a management tool logged in
+as an administrator; the revocation shows at a whole minute of the session's age (60 s, 120 s,
+...). Each `IpmiClient` call opens its own session, so the next call works again.
 
 ## `... is not yet implemented.`
 

src/site/markdown/upgrading.md

@@ -44,9 +44,8 @@ The `IpmiClient` API is unchanged, and the client is more tolerant of real-world
   reply is sent again;
 * the [keep-alive](configuration.html#keep-alive) is actually sent: with the default `pingPeriod`
   (`-1`) 1.2.02 sent no keep-alive at all, so a session could expire during a long collection; the
-  keep-alive is now a Get Device ID every 30 s by default, whose reply is discarded (not the Get
-  Channel Authentication Capabilities of 1.2.02, after which HP iLO 5 revokes the session within
-  60 s), and a Get Channel Authentication Capabilities command sent by the application in a
+  keep-alive is now a Get Device ID every 30 s by default, as `ipmitool` sends, whose reply is
+  discarded, and a Get Channel Authentication Capabilities command sent by the application in a
   session gets its reply (1.2.02 dropped it, as it did the keep-alive replies);
 * a one-way IPMI message (`IpmiConnector.sendOneWayMessage()`, `IpmiAsyncConnector.sendMessage()`
   with `isOneWay`) is queued like any request: its tag stays reserved, and it takes a slot of the

src/test/java/org/metricshub/ipmi/client/runner/GetSensorsRunnerTest.java

@@ -144,7 +144,7 @@ protected ConnectionHandle getHandle() {
 			final CompactSensorRecord record = new CompactSensorRecord();
 			record.setName(DEVICE_NAME);
 
-			// HP iLO answers D4h once it revoked the session
+			// HP iLO answers D4h once the session was revoked
 			failure.set(new IPMIException(CompletionCode.InsufficentPrivilege));
 			assertNull(runner.getSensorRecordReading(record));