Skip to content

Reference: HP iLO 3 firmware v1.94 quirks

Discovered idiosyncrasies of HP iLO 3 firmware 1.94 dated 2020-12-06 (the FINAL release for iLO 3) on Kay's DL380 G7 (arochukwu), captured during session 3 (2026-05-30).

This file is reference material for future sessions touching iLO. Read it before running ipmitool against this BMC, before logging into the web UI, before SSHing in, and before clicking anything in Administration / Security.

IPMI / in-band quirks

  • LAN config is on channel 2, NOT channel 1. ipmitool lan print 1 and lan set 1 ... return Invalid channel: 1. Channel walk: only channel 2 (802.3 LAN, IPMB-1.0) and channel 7 (KCS) are valid on this BMC. All lan ... commands MUST target channel 2.

  • HP OEM raw 0x06 0xc0 ... ("Get NIC Selection" family) is NOT implemented on this firmware. Returns rsp=0xc1 ("Invalid command") for any subcommand. The 0x06 0xc0 mapping is iLO 4 / iLO 5 syntax. Consequence: dedicated-vs-shared LOM mode cannot be queried via in-band IPMI on iLO 3. Use BIOS F8 RBSU at POST, sideloaded hponcfg, or visual switch-port-LED check.

  • BMC ARP Control defaults to ARP Responses Enabled, Gratuitous ARP Disabled. After any in-band lan set 2 ipaddr X.Y.Z.W change, iLO commits the new value to NVRAM but does NOT announce it to the upstream switch. Peers cannot ARP-resolve the new IP, ping fails, web UI is unreachable. Fix: ipmitool mc reset cold after the IP change — the BMC restart forces a fresh interface bring-up that does announce. Alternative (not validated on this box): toggle lan set 2 arp generate on BEFORE the IP change.

  • ipmitool sel only shows the IPMI standard SEL, not HP's Integrated Management Log (IML). This server's SEL has ~28 entries with last add 2023-08-27; none of the 2026 boots, IP changes, or BMC resets show up there. HP's IML (what the iLO web UI calls "log entries") is reachable via the web UI, RIBCL, or hponcfg. Don't trust SEL emptiness as evidence nothing is happening.

  • ipmitool mc reset cold is safe and clean. ~60 s downtime, no config drift (everything persists), no SSH disruption (KCS is host-local, unaffected by BMC restart). Good first reach for "iLO knows the change but the wire doesn't" symptoms.

  • iLO MAC is one OUI step after the host data NICs. Host data NICs end :8a / :8c / :8e / :90; iLO is :92. HP's standard sequential assignment — useful for confirming you're talking to the right BMC when multiple are on a flat network.

Web UI quirks

  • Web UI speaks TLS 1.0 only. Modern browsers (Chrome, Edge non-IE-mode, Safari) refuse the handshake and have no clean toggle. Use Firefox with about:config → security.tls.version.min = 1. Self-signed cert; accept via the standard browser security override. Works fully after the toggle — no functional limits.

  • ACCEPTED RISK 2026-06-07 (security audit C5): TLS 1.0 is cryptographically broken. There is NO FIX — HP discontinued iLO 3 firmware updates in 2020-12 with v1.94. Mitigations relied on:

    1. iLO is on isolated MGMT VLAN 40 since 2026-06-04 (Session 7)
    2. pfSense blocks VLAN 10 → MGMT cross-traffic since 2026-06-04 (Session 7, verified six ways)
    3. Only Kay's laptop (172.16.1.100) and PVE host (172.16.1.5) are on VLAN 40 — small attack surface
    4. Treat any iLO web session as untrusted: don't store sensitive data, don't paste tokens, don't use over public networks
    5. Track for replacement at iLO swap (would require hardware change — Gen8+)

  • Server identity (Server Name + Server FQDN, displayed in web UI title bar, IML entries, and SNMP-out) is stored in iLO NVRAM separately from the OS hostname. Not in SMBIOS, FRU, or mc getsysinfo system_name. Whatever the last HP CIM management agent on the host wrote into it persists across OS reinstalls. On arochukwu it showed ECL-ESX02.eclh.lan (from a prior ESXi install) until 2026-05-30 when it was renamed via iLO web UI Access Settings to arochukwu / arochukwu.hm.iamkay.eu. Clearing this field is only doable via iLO web UI or RIBCL — no IPMI surface for it.

  • iLO Subsystem Name (used in DHCP hostname / SNMP sysName) is yet another separate field, in Network → Dedicated Network Port → General. Distinct from the displayed Server Name. Changing Subsystem Name requires an iLO reset to apply (the web UI flags "There are pending changes that may not take effect until iLO is reset"). On arochukwu it was changed from factory ILOCZ212806VN to arochukwu-ilo on 2026-05-30, via web UI + Information → Diagnostics → Reset.

  • Time Zone lives in Network → Dedicated Network Port → SNTP (not in any obvious "system" page). Factory default is Atlantic/Reykjavik (GMT) on this firmware. Also needs an iLO reset to apply.

  • SMASH CLP (set /system1 name=...) is NOT supported on iLO 3 v1.94. iLO 4 / iLO 5 accept it; iLO 3 returns a syntax error from the SSH SMASH prompt. For renames, use the web UI Access Settings / Network pages.

  • HPE System Management Homepage (SMH) link shown in the iLO SNMP page (https://<server>:2381) is a dead end on a non-HP-supported OS. SMH is HP's host-side management agent; there's no Debian / Proxmox build. Nothing listens on port 2381. Ignore the link; don't sideload SMH for it.

  • Integrated Remote Console (IRC) is non-functional on modern Windows. The iLO Advanced license unlocks IRC, but the actual delivery mechanisms are both broken in current setups:

  • Java applet path: blocked because the NPAPI browser plugin has been removed from modern browsers (Firefox dropped it; Chrome / Edge never supported it on this codepath). Recent Java JREs also don't expose the legacy applet runtime to browser callers.
  • Standalone .NET IRC.exe path: doesn't launch / hangs on modern Windows. The .NET Framework version it expects is outside the supported range.

Verified non-functional on the laptop's current Windows 10/11 + Firefox/Edge setup (session 4, 2026-05-31). Don't waste time debugging it.

Use these alternatives instead: - ssh ilo → [email protected] with the legacy KEX/cipher flags (see SSH quirks above). Gets you the iLO SMASH CLP shell. - From the SSH session, vsp enters the Virtual Serial Port (host serial console + BIOS POST output). Useful for "host network is broken, I need to fix /etc/network/interfaces from the host's text console". Requires the host's Linux kernel to be configured to emit serial console output — not currently wired up on arochukwu (a future config item), but the iLO side works whenever the host side is enabled. - Physical keyboard + monitor at the chassis is the ultimate fallback for any unrecoverable network state.

SSH quirks

  • iLO 3's SSH server only supports legacy KEX / host-key / cipher / MAC algorithms. Modern OpenSSH (laptop side) refuses by default. Working ~/.ssh/config snippet for ssh ilo: 
    Host ilo
    HostName 10.0.110.3
    User kay
    KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
    HostKeyAlgorithms +ssh-rsa,ssh-dss
    Ciphers +aes128-cbc,3des-cbc
    MACs +hmac-sha1
    Exact set of flags may need tweaking if Windows OpenSSH defaults change in the future.

Account quirks

  • HP factory "Administrator" account at user ID 1 was renamed kay on this box long ago. ipmitool user list 2 shows no user literally named "Administrator" — default credentials no longer apply. When future scripts say "set Administrator password", they probably mean "set ID 1 password" — verify with user list 2 before guessing the name.

Licensing

  • iLO Advanced unlocks Virtual Media (network ISO boot), Integrated Remote Console, power graphs, advanced auth. Without it the web UI works but those features are greyed out.
  • Community-shared key 35DPH-SVSXJ-HGBJN-C7N5R-2SS4W activates Advanced on iLO 3. Applied via Administration → Licensing in the web UI. Status: OK after apply.

Firmware

  • Firmware 1.94 dated 2020-12-06 is the FINAL release for iLO 3. No newer build exists; no upgrade path. Whatever quirks exist in 1.94 are permanent.

DO NOT TOUCH

  • NEVER enable FIPS Mode (Administration → Security → Encryption). Enabling FIPS factory-resets iLO and wipes everything: Advanced license, user accounts, IP config, server-identity strings, SSH/IPMI customisations, the lot. Permanent rule, also documented in CLAUDE.md Section 0 rule 7.

Earlier-session corrections

  • Session 3 mid-stream conjecture that "1.94 is from the 2014 era" was wrong — it's dated 2020-12-06 per the web UI's About panel. Still the final release for iLO 3, but more recent than that.
  • Session 3 mid-stream conjecture that iLO unreachability was due to shared-LOM mode was wrong. Actual root cause was gratuitous ARP disabled (see IPMI quirks above). NIC mode is dedicated; cable was always in the right port.