ipmitool(1)

✨ ipmitool(1) ✨

okay so this is the manual page for ipmitool(1) β€” ipmitool β€” the utility for controlling IPMI-enabled devices. bestie, it's a long one, so buckle up, hydrate, and let's go πŸ’–


🌸 SYNOPSIS 🌸

ipmitool [ <options> ] <command> [ <sub-commands and sub-options> ]

<options>           := [ <general-options> | <conditional-opts> ]

Any recognized option is accepted. Conditional options may be ignored or
it's usage postponed until shell or exec processes relevant command.

<general-options>   := [ -h | -V | -v | -I <interface> | -H <address> |
                         -d <N> | -p <port> | -c | -U <username> |
                         -L <privlvl> | -l <lun> | -m <local_address> |
                         -N <sec> | -R <count> | <password-option> |
                         <oem-option> | <bridge-options> ]

<conditional-opts>  := [ <lan-options> | <lanplus-options> |
                         <command-options> ]
Bridging:
<bridge-options>    := -t <target_address> [ -b <channel> |
                       [ -T <address> | -B <channel> ] ]

Options used with -I lan:
<lan-options>       := [ -A <authtype> ]

Options used with -I lanplus:
<lanplus-options>   := [ -C <ciphersuite> | <key-option> ]

Option groups setting same value:
<key-option>        := [ -k <key> | -K | -y <hex_key> | -Y ]
<password-option>   := [ -f <password_file> | -a | -P <password> | -E ]
<oem-option>        := [ -o <oemtype> | -g | -s ]

Options used with specific command <command-options>:
<options-sdr>       := [ -S <sdr_cache_file> ]
<options-sel>       := [ -O <sel_oem> ]
<options-sol>       := [ -e <sol_escape_char> ]

so basically: <options> is either some general ones or some conditional ones, and any recognized option gets accepted β€” the conditional ones might just get ignored, or their usage gets postponed until a shell or exec process hits the relevant command. iykyk 🫢


πŸ¦‹ DESCRIPTION πŸ¦‹

This program lets you manage Intelligent Platform Management Interface (IPMI) functions β€” either of the local system, via a kernel device driver, or of a remote system, using IPMI v1.5 and IPMI v2.0. And what does "manage" mean here? Obsessed you asked: printing FRU information, LAN configuration, sensor readings, and remote chassis power control. the range, honestly πŸ‘‘

IPMI management of a local system interface requires a compatible IPMI kernel driver to be installed and configured. On Linux this driver is called OpenIPMI and it is included in standard distributions. On Solaris this driver is called BMC and it is included in Solaris 10. Management of a remote station requires the IPMI-over-LAN interface to be enabled and configured. Depending on the particular requirements of each system it may be possible to enable the LAN interface using ipmitool over the system interface. no cap, that's the whole vibe ✨


πŸ’… OPTIONS πŸ’…

  • -a β€” Prompt for the remote server password. cute, interactive, it'll ask.
  • -A <authtype> β€” Specify an authentication type to use during IPMIv1.5 lan session activation. Supported types are NONE, PASSWORD, MD2, MD5, or OEM.
  • -b <channel> β€” Set destination channel for bridged request.
  • -B <channel> β€” Set transit channel for bridged request (dual bridge).
  • -b <channel> β€” Set destination channel for bridged request. (yes it's in here twice, the page really do be like that πŸ™ˆ)
  • -B <channel> β€” Set transit channel for bridged request. (dual bridge)
  • -c β€” Present output in CSV (comma separated variable) format. This is not available with all commands.
  • -C <ciphersuite> β€” The remote server authentication, integrity, and encryption algorithms to use for IPMIv2.0 lanplus connections. See table 22-20 in the IPMI v2.0 specification. The default is 17, which specifies RAKP-HMAC-SHA256 authentication, HMAC-SHA256-128 integrity, and AES-CBC-128 encryption algorithms.
NOTE: In ipmitool 1.8.18 and earlier the default was 3, which was insecure and was not supported by some more recent BMC implementations. so if you're on an old one, that's why, and also, respectfully, upgrade 😭
  • -d N β€” Use device number N to specify the /dev/ipmiN (or /dev/ipmi/N or /dev/ipmidev/N) device to use for in-band BMC communication. Used to target a specific BMC on a multi-node, multi-BMC system through the ipmi device driver interface. Default is 0.
  • -e <sol_escape_char> β€” Use supplied character for SOL session escape character. The default is to use ~ but this can conflict with ssh sessions. (the classic ~ jumpscare πŸ’€)
  • -E β€” The remote server password is specified by the environment variable IPMI_PASSWORD or IPMITOOL_PASSWORD. The IPMITOOL_PASSWORD takes precedence.
  • -f <password_file> β€” Specifies a file containing the remote server password. If this option is absent, or if password_file is empty, the password will default to NULL.
  • -g β€” Deprecated. Use: -o intelplus
  • -h β€” Get basic usage help from the command line.
  • -H <address> β€” Remote server address, can be IP address or hostname. This option is required for lan and lanplus interfaces. non-negotiable, you need it 🫑
  • -I <interface> β€” Selects IPMI interface to use. Supported interfaces that are compiled in are visible in the usage help output.
  • -k <key> β€” Use supplied Kg key for IPMIv2.0 authentication. The default is not to use any Kg key.
  • -K β€” Read Kg key from IPMI_KGKEY environment variable.
  • -l <lun> β€” Set destination lun for raw commands.
  • -L <privlvl> β€” Force session privilege level. Can be CALLBACK, USER, OPERATOR, ADMINISTRATOR. Default is ADMINISTRATOR. This value is ignored and always set to ADMINISTRATOR when combined with -t target address. (the -t option said "hold my crown" πŸ‘‘)
  • -m <local_address> β€” Set the local IPMB address. The local address defaults to 0x20 or is auto discovered on PICMG platforms when -m is not specified. There should be no need to change the local address for normal operation. like fr, leave it alone πŸ’œ
  • -N <sec> β€” Specify nr. of seconds between retransmissions of lan/lanplus messages. Defaults are 2 seconds for lan and 1 second for lanplus interfaces. Command raw uses fixed value of 15 seconds. Command sol uses fixed value of 1 second.
  • -o <oemtype> β€” Select OEM type to support. This usually involves minor hacks in place in the code to work around quirks in various BMCs from various manufacturers. Use -o list to see a list of current supported OEM types.
  • -O <sel oem> β€” Open selected file and read OEM SEL event descriptions to be used during SEL listings. See examples in contrib dir for file format.
  • -p <port> β€” Remote server UDP port to connect to. Default is 623.
  • -P <password> β€” Remote server password is specified on the command line. If supported it will be obscured in the process list. Note! Specifying the password as a command line option is not recommended.
  • -R <count> β€” Set the number of retries for lan/lanplus interface (default=4). Command raw uses fixed value of one try (no retries). Command hpm uses fixed value of 10 retries.
  • -s β€” Deprecated. Use: -o supermicro
  • -S <sdr_cache_file> β€” Use local file for remote SDR cache. Using a local SDR cache can drastically increase performance for commands that require knowledge of the entire SDR to perform their function. Local SDR cache from a remote system can be created with the sdr dump command. it's giving ✨speed✨
  • -t <target_address> β€” Bridge IPMI requests to the remote target address. Default is 32. The -L privlvl option is always ignored and value set to ADMINISTRATOR.
  • -T <address> β€” Set transit address for bridge request (dual bridge).
  • -T <transmit_address> β€” Set transit address for bridge request. (dual bridge) (again, listed twice in the source, we do not gatekeep πŸŽ€)
  • -U <username> β€” Remote server username, default is NULL user.
  • -v β€” Increase verbose output level. This option may be specified multiple times to increase the level of debug output. If given three times you will get hexdumps of all incoming and outgoing packets. Using it five times provides details on request and expected reply processing. The hpm commands targetcap compprop abort upgstatus rollback rollbackstatus selftestresult increases the verbosity level.
  • -V β€” Display version information.
  • -y <hex key> β€” Use supplied Kg key for IPMIv2.0 authentication. The key is expected in hexadecimal format and can be used to specify keys with non-printable characters. E.g. '-k PASSWORD' and '-y 50415353574F5244' are equivalent. The default is not to use any Kg key.
  • -Y β€” Prompt for the Kg key for IPMIv2.0 authentication.
  • -z <size> β€” Change Size of Communication Channel. (OEM)

If no password method is specified then ipmitool will prompt the user for a password. If no password is entered at the prompt, the remote server password will default to NULL. so, like, don't just mash enter and act surprised πŸ™ˆ


πŸ”₯ SECURITY πŸ”₯

okay bestie, this section is the "please take this seriously" section, no cap.

There are several security issues be be considered before enabling the IPMI LAN interface. A remote station has the ability to control a system's power state as well as being able to gather certain platform information. To reduce vulnerability it is strongly advised that the IPMI LAN interface only be enabled in 'trusted' environments where system security is not an issue or where there is a dedicated secure 'management network'. literally the whole power state. respect the LAN interface 🫢

Further it is strongly advised that you should not enable IPMI for remote access without setting a password, and that that password should not be the same as any other password on that system. (yes, reusing passwords is still a crime, we've been over this πŸ’€)

When an IPMI password is changed on a remote machine with the IPMIv1.5 lan interface the new password is sent across the network as clear text. This could be observed and then used to attack the remote system. It is thus recommended that IPMI password management only be done over IPMIv2.0 lanplus interface or the system interface on the local station. clear text!! in the group chat!! no πŸ’€

For IPMI v1.5, the maximum password length is 16 characters; longer passwords might be truncated or rejected by the server, or rejected by ipmitool.

For IPMI v2.0, the maximum password length is 20 characters; longer passwords will be rejected by ipmitool.


🌈 COMMANDS 🌈

  • help β€” This can be used to get command-line help on ipmitool commands. It may also be placed at the end of commands to get option usage help. the icon that it is πŸŽ€

and that's just the very first command on the list β€” there's a whole buffet of them waiting, so stay tuned bestie πŸ’–

K so real talk: ipmitool help is your little map of everything the tool can do, and it lowkey prints this exact list. Copy-paste safe, character for character:

> ipmitool help
Commands:
        bmc          Deprecated. Use mc
        channel      Configure Management Controller channels
        chassis      Get chassis status and set power state
        dcmi         Data Center Management Interface
        delloem      Manage Dell OEM Extensions.
        echo         Used to echo lines to stdout in scripts
        ekanalyzer   run FRU-Ekeying analyzer using FRU files
        event        Send events to MC
        exec         Run list of commands from file
        firewall     Configure Firmware Firewall
        fru          Print built-in FRU and scan for FRU locators
        fwum         Update IPMC using Kontron OEM Firmware
Update Manager
        gendev       Read/Write Device associated with Generic
Device locators sdr
        hpm          Update HPM components using PICMG HPM.1 file
        i2c          Send an I2C Master Write-Read command and
print response
        ime          Upgrade/Query Intel ME firmware
        isol         Configure and connect Intel IPMIv1.5
Serial-over-LAN
        kontronoem   Manage Kontron OEM Extensions
        lan          Configure LAN Channels
        mc           Management Controller status and global
enables
        nm           Node Manager
        pef          Configure Platform Event Filtering (PEF)
        picmg        Run a PICMG/ATA extended command
        power        Shortcut to chassis power commands
        raw          Send a RAW IPMI request and print response
        sdr          Print Sensor Data Repository entries and
readings
        sel          Print System Event Log (SEL)
        sensor       Print detailed sensor information
        session      Print session information
        set          Set runtime variable for shell and exec
        shell        Launch interactive IPMI shell
        sol          Configure and connect IPMIv2.0
Serial-over-LAN
        spd          Print SPD info from remote I2C device
        sunoem       Manage Sun OEM Extensions
        tsol         Configure and connect Tyan IPMIv1.5
Serial-over-LAN
        user         Configure Management Controller users

Now the vibe check on each one, bestie, so you know what you're picking up:

  • bmc β€” ✨ deprecated ✨. It literally says Deprecated. Use mc. So use mc, ok? Not me still seeing people type bmc in 2024 😭.
  • channel β€” configure management controller channels. Your whole comms setup lives here.
  • chassis β€” get chassis status and set power state. The classic "is it on, can I turn it off" zone.
  • dcmi β€” Data Center Management Interface. Very data-center, very serious.
  • delloem β€” manage Dell OEM extensions. Dell-specific club πŸ’…
  • echo β€” used to echo lines to stdout in scripts. Baby's first script tool, iconic.
  • ekanalyzer β€” run FRU-Ekeying analyzer using FRU files. Niche, but she's valid.
  • event β€” send events to MC.
  • exec β€” run a list of commands from a file. Batch mode nation 🫢
  • firewall β€” configure Firmware Firewall. Security girlie.
  • fru β€” print built-in FRU and scan for FRU locators.
  • fwum β€” update IPMC using Kontron OEM Firmware Update Manager.
  • gendev β€” read/write device associated with generic device locators sdr.
  • hpm β€” update HPM components using a PICMG HPM.1 file.
  • i2c β€” send an I2C master write-read command and print the response.
  • ime β€” upgrade/query Intel ME firmware.
  • isol β€” configure and connect Intel IPMIv1.5 Serial-over-LAN.
  • kontronoem β€” manage Kontron OEM extensions.
  • lan β€” configure LAN channels.
  • mc β€” management controller status and global enables. (This is the one. The main character.)
  • nm β€” Node Manager.
  • pef β€” configure Platform Event Filtering (PEF).
  • picmg β€” run a PICMG/ATA extended command.
  • power β€” shortcut to the chassis power commands, no cap.
  • raw β€” send a RAW IPMI request and print the response. Powerful, slightly feral πŸ”₯
  • sdr β€” print Sensor Data Repository entries and readings.
  • sel β€” print the System Event Log (SEL).
  • sensor β€” print detailed sensor information.
  • session β€” print session information.
  • set β€” set a runtime variable for shell and exec.
  • shell β€” launch the interactive IPMI shell.
  • sol β€” configure and connect IPMIv2.0 Serial-over-LAN.
  • spd β€” print SPD info from a remote I2C device.
  • sunoem β€” manage Sun OEM extensions.
  • tsol β€” configure and connect Tyan IPMIv1.5 Serial-over-LAN.
  • user β€” configure management controller users.

🌸 channel 🌸

authcap <channel number> <max priv>

Shows you the authentication capabilities of the channel you picked, at the privilege level you picked. Simple, honest, slays.

The possible privilege levels are, and yes you need to memorise these:

1   Callback level
2   User level
3   Operator level
4   Administrator level
5   OEM Proprietary level
15   No access
Ngl the jump from 5 to 15 is such a choice, but that's the spec, not me πŸ™ˆ.

info [channel number]

Tells you everything about the chosen channel. Don't pass a channel number? It just shows you info about whatever channel is currently in use. Lowkey convenient.

> ipmitool channel info
Channel 0xf info:
  Channel Medium Type   : System Interface
  Channel Protocol Type : KCS
  Session Support       : session-less
  Active Session Count  : 0
  Protocol Vendor ID    : 7154

Look at her go. 0xf, KCS, session-less, zero active sessions β€” a whole mood πŸ’….

getaccess <channel number> [<userid>]

Sets the given userid as the default on that channel number. Then whenever that channel gets used later, the user is identified implicitly by that userid. So it's like... pre-booking the identity. Cute.

Configures the access info for that userid on that channel. Everything in brackets is optional, so take what you need:

  • callin=on|off
  • ipmi=on|off
  • link=on|off
  • privilege=level

getciphers <ipmi|sol> [<channel>]

Spits out the list of cipher suites supported for the app you name β€” ipmi or sol β€” on the channel you name. Cipher shopping, but make it secure πŸ”.


πŸŽ€ chassis πŸŽ€

status

Status info related to power, buttons, cooling, drives and faults. The whole vibe check of the physical box.

power

The power moves, and here's the full menu:

  • status
  • on
  • off
  • cycle
  • reset
  • diag
  • soft

That's it. That's the list. Pick your fighter πŸ’€.

identify [<seconds>|force]

The identify interval β€” you know, the "which server am I even looking at" light.

  • Default is 15 seconds.
  • 0 β€” off.
  • force β€” turn it on indefinitely.

policy

What should happen when power gets restored? Big philosophical question, honestly.

  • list β€” show the available options.
  • always-on
  • previous
  • always-off

restart_cause

Shows the last restart cause. Receipts for why it rebooted πŸ”.

poh

Get power on hours. How long has she been awake. 😭

bootdev

Where should this thing boot from? The options:

  • none β€” do not change boot device order.
  • pxe β€” force PXE boot.
  • disk β€” force boot from default hard-drive.
  • safe β€” force boot from default hard-drive, request Safe Mode.
  • diag β€” force boot from Diagnostic Partition.
  • cdrom β€” force boot from CD/DVD.
  • bios β€” force boot into BIOS Setup.
  • floppy β€” force boot from Floppy/primary removable media.

bootmbox get [text] [block <block#>]

Reads the Boot Initiator Mailbox, either as a hex dump or in text mode (that's what the text bit is for).

By default the whole mailbox gets read. But if you give a block number, only that particular block gets read. And heads up: for block 0, or when you're reading the whole mailbox, it also prints the Boot Initiator IANA Enterprise Number plus the matching enterprise name. Extra info, no extra charge ✨.

bootmbox set text [block <block#>] <IANA_PEN> "<data_string>"

Writes either the specified <block> or the entire Boot Initiator Mailbox, in text mode.

You must give a decimal IANA Enterprise Number that the boot initiator on the target system actually recognises β€” check with your target system manufacturer for the details, bestie, I can't guess that for you. Everything after that is a text string.

Real talk warning 🚨: when you request a single block write, the total length of <data> may not exceed 13 bytes for block 0, or 16 bytes otherwise. Overshoot and it's not gonna be cute.

bootmbox set [block <block#>] <IANA_PEN> <data_byte> [<data_byte> ...]

Same thing as above, except the arguments after the IANA PEN are separate data byte values, each separated by spaces.

bootparam get <opt_id> [<opt_param>]

Gets the value of system boot option number <opt_id>. Some boot options (option 7, for example) can also take an optional numeric parameter, which is what <opt_param> is for.

bootparam set bootflag <device> [options=...]

Sets a boot flag. The valid devices:

  • force_pxe β€” force PXE boot.
  • force_disk β€” force boot from default hard-drive.
  • force_safe β€” force boot from default hard-drive, request Safe Mode.
  • force_diag β€” force boot from Diagnostic Partition.
  • force_cdrom β€” force boot from CD/DVD.
  • force_bios β€” force boot into BIOS Setup.

And the valid options:

  • PEF β€” clear the valid bit on reset/power cycle caused by PEF.
  • timeout β€” automatically clear the boot flag valid bit on timeout.
  • watchdog β€” clear the valid bit on reset/power cycle caused by watchdog.
  • reset β€” clear the valid bit on push button reset/soft reset.
  • power β€” clear the valid bit on power up via power push button or wake event.

selftest

Gets the chassis self-test results. Is she okay? Let's find out 🫢.


πŸ’œ dcmi πŸ’œ

discover

Used to discover the capabilities supported in DCMI. It's the "what can you even do" command.

power <command>

The platform power limit commands are:

  • reading β€” get power related readings from the system.
  • get_limit β€” get the configured power limits.
  • set_limit <parameter> <value> β€” set a power limit option.
  • activate β€” activate the set power limit.
  • deactivate β€” deactivate the set power limit.

And the possible parameters/values for set_limit, since this is the messy part:

  • action <No Action | Hard Power Off & Log Event to SEL | Log Event to SEL> β€” the exception action taken is either "No Action", "Hard Power Off system and log events to SEL", or "Log event to SEL only".
  • limit <number in Watts> β€” the power limit requested, in Watts.
  • correction <number in milliseconds> β€” the correction time limit, in milliseconds.
  • sample <number in seconds> β€” the statistics sampling period, in seconds.

sensors

Prints the available DCMI sensors.

asset_tag

Prints the platform's asset tag. Name tag energy 🏷️.

set_asset_tag <string>

Sets the platform's asset tag.

get_mc_id_string

Gets the management controller identifier string.

set_mc_id_string <string>

Sets the management controller identifier string. The maximum length is 64 bytes, and that includes a null terminator β€” so don't go spending all 64 on your cute nickname πŸ™ˆ.

thermalpolicy [<get | set>]

Thermal Limit policy get/set. The commands are:

  • Get <entityID> <instanceID> β€” get Thermal Limit values.

entityID is the physical entity that a sensor or device is associated with β€” like, which thing are we even talking about. instanceID is a particular instance of an entity. Entity Instance can live in one of two ranges: system-relative or device-relative. For example, a system with four processors could use an Entity Instance value of "0" to identify the first processor. 🫢

  • Set <entityID> <instanceID> β€” Set Thermal Limit values. πŸ”₯

Ngl, the next bit is literally the same paragraph again, but your girl doesn't skip lore: entityID is the physical entity that a sensor or device is associated with, and instanceID is a particular instance of an entity. Entity Instance can be in one of two ranges, system-relative or device-relative. For example, a system with four processors could use an Entity Instance value of "0" to identify the first processor. (yes bestie, "0" = first processor, iconic numbering) πŸ’…

  • get_temp_reading β€” Get Temperature Sensor Readings. 🌑️
  • get_conf_param β€” Get DCMI Configuration Parameters. βš™οΈ
  • set_conf_param <parameters> β€” Set DCMI Configuration Parameters.

The Configuration Parameters are:

  • activate_dhcp β€” Activate/restart DHCP. πŸš€
  • dhcp_config β€” Discover DHCP Configuration.
  • init β€” Set DHCP Initial timeout interval, in seconds. The recommended default is four seconds.
  • timeout β€” Set DHCP Server contact timeout interval, in seconds. The recommended default timeout is two minutes.
  • retry β€” Set DHCP Server contact retry interval, in seconds. The recommended default timeout is sixty-four seconds.
  • oob_discover β€” Ping/Pong Message for DCMI Discovery. πŸ“

πŸ¦‹ delloem 🌈

The delloem commands provide information on Dell-specific features. It's giving "Dell said lemme add my own commands" energy, and honestly? Respect. πŸ‘‘

πŸ’– setled {b:d.f} {state..}

Sets the drive backplane LEDs for a device.

  • {b:d.f} = PCI Address of device (eg. 06:00.0)
  • {state} = one or more of the following: online | present | hotspare | identify | rebuilding | fault | predict | critical | failed

πŸŽ€ lcd

set {mode}|{lcdqualifier}|{errordisplay} β€” Allows you to set the LCD mode and user-defined string.

Then the individual LCD moves, in all their glory:

lcd set mode {none}|{modelname}|{ipv4address}|{macaddress}|{systemname}|{servicetag}|{ipv6address}|{ambienttemp}|{systemwatt}|{assettag}|{userdefined}<text>

Allows you to set the LCD display mode to any of the preceding parameters.

lcd set lcdqualifier {watt}|{btuphr}|{celsius}|{fahrenheit}

Allows you to set the unit for the system ambient temperature mode.

lcd set errordisplay {sel}|{simple}

Allows you to set the error display.

lcd info β€” Displays the LCD screen information. πŸ“Ί

lcd set vkvm {active}|{inactive}

Allows you to set the vKVM status to active or inactive. When it is active and session is in progress, a message appears on LCD.

lcd status β€” Displays the LCD status for vKVM display active or inactive and Front Panel access mode (viewandmodify, view-only or disabled). No cap, that's a whole vibe check of your front panel right there.

🌸 mac

Displays the information about the system NICs.

mac list β€” Displays the NIC MAC address and status of all NICs. It also displays the DRAC/iDRAC MAC address. 🧚

mac get <NIC number> β€” Displays the selected NICs MAC address and status.

⭐ lan

Displays the information of Lan.

lan set <Mode> β€” Sets the NIC selection mode (dedicated, shared with lom1, shared with lom2, shared with lom3, shared with lom4, shared with failover lom1, shared with failover lom2, shared with failover lom3, shared with failover lom4, shared with Failover all loms, shared with Failover None).

lan get β€” Returns the current NIC selection mode (dedicated, shared with lom1, shared with lom2, shared with lom3, shared with lom4, shared with failover lom1, shared with failover lom2, shared with failover lom3, shared with failover lom4, shared with Failover all loms, shared with Failover None).

lan get active β€” Returns the current active NIC (dedicated, LOM1, LOM2, LOM3 or LOM4).

πŸ”₯ powermonitor

Displays power tracking statistics.

powermonitor clear cumulativepower β€” Reset cumulative power reading.

powermonitor clear peakpower β€” Reset peak power reading.

powermonitor powerconsumption <watt>|<btuphr> β€” Displays the power consumption in watt or btuphr.

powermonitor powerconsumptionhistory <watt>|<btuphr> β€” Displays the power consumption history in watt or btuphr.

powermonitor getpowerbudget <watt>|<btuphr> β€” Displays the power cap in watt or btuphr.

powermonitor setpowerbudget <val><watt|btuphr|percent> β€” Allows you to set the power cap in watt, BTU/hr or percentage.

powermonitor enablepowercap β€” Enables set power cap. ⚑

powermonitor disablepowercap β€” Disables set power cap.

πŸ’œ vFlash info Card

Shows Extended SD Card information. πŸ“


✨ echo πŸ’–

For echoing lines to stdout in scripts. Tiny command, big main character energy β€” your scripts said "I need a little guy to just print things" and echo delivered.


🧚 ekanalyzer πŸ’«

ekanalyzer <command> <xx=filename1> <xx=filename2> [<rc=filename3>] ...
NOTE: This command can support a maximum of 8 files per command line. Eight. Not nine. Bestie, don't push it. πŸ™ˆ

Here's who's who in that command line:

  • filename1 β€” binary file that stores FRU data of a Carrier or an AMC module
  • filename2 β€” binary file that stores FRU data of an AMC module. These binary files can be generated from command: ipmitool fru read <id> <filename>
  • filename3 β€” configuration file used for configuring On-Carrier Device ID or OEM GUID. This file is optional.

And xx? It indicates the type of the file. It can take the following value:

  • oc β€” On-Carrier device
  • a1 β€” AMC slot A1
  • a2 β€” AMC slot A2
  • a3 β€” AMC slot A3
  • a4 β€” AMC slot A4
  • b1 β€” AMC slot B1
  • b2 β€” AMC slot B2
  • b3 β€” AMC slot B3
  • b4 β€” AMC slot B4
  • sm β€” Shelf Manager

The available commands for ekanalyzer are:

carrier (default) <oc=filename1> <oc=filename2> ... β€” Display point to point physical connectivity between carriers and AMC modules.

Example, served fresh:

> ipmitool ekanalyzer print carrier oc=fru oc=carrierfru
   From Carrier file: fru
      Number of AMC bays supported by Carrier: 2
      AMC slot B1 topology:
         Port 0 =====> On Carrier Device ID 0, Port 16
         Port 1 =====> On Carrier Device ID 0, Port 12
         Port 2 =====> AMC slot B2, Port 2
      AMC slot B2 topology:
         Port 0 =====> On Carrier Device ID 0, Port 3
         Port 2 =====> AMC slot B1, Port 2
   *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
   From Carrier file: carrierfru
      On Carrier Device ID 0 topology:
         Port 0 =====> AMC slot B1, Port 4
         Port 1 =====> AMC slot B1, Port 5
         Port 2 =====> AMC slot B2, Port 6
         Port 3 =====> AMC slot B2, Port 7
      AMC slot B1 topology:
         Port 0 =====> AMC slot B2, Port 0
      AMC slot B1 topology:
         Port 1 =====> AMC slot B2, Port 1
      Number of AMC bays supported by Carrier: 2

Look at all those arrows. The topology ate and left no crumbs. 🫢

power <xx=filename1> <xx=filename2> ... β€” Display power supply information between carrier and AMC modules.

all <xx=filename> <xx=filename> ... β€” Display both physical connectivity and power supply of each carrier and AMC modules. The "why not both" option, honestly iconic. πŸ’…

πŸŽ€ frushow <xx=filename>

Convert a binary FRU file into human readable text format. Use -v option to get more display information. πŸ‘€

⭐ summary [<match | unmatch | all>]

  • match (this one's the default, so if you don't say anything else it's what you get πŸ’…) <xx=filename> <xx=filename> ... β€” shows you only the matched results of the Ekeying match, whether it's between an On-Carrier device and an AMC module, or between 2 AMC modules. Like, the "y'all actually line up" report ✨

Example, because a picture is worth a thousand words:

 > ipmitool ekanalyzer summary match oc=fru b1=amcB1 a2=amcA2
  On-Carrier Device vs AMC slot B1
   AMC slot B1 port 0 ==> On-Carrier Device 0 port 16
    Matching Result
    - From On-Carrier Device ID 0
     -Channel ID 11 || Lane 0: enable
     -Link Type: AMC.2 Ethernet
     -Link Type extension: 1000BASE-BX (SerDES Gigabit) Ethernet link
     -Link Group ID: 0 || Link Asym. Match: exact match
    - To AMC slot B1
     -Channel ID 0 || Lane 0: enable
     -Link Type: AMC.2 Ethernet
     -Link Type extension: 1000BASE-BX (SerDES Gigabit) Ethernet link
     -Link Group ID: 0 || Link Asym. Match: exact match
    *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
   AMC slot B1 port 1 ==> On-Carrier Device 0 port 12
    Matching Result
    - From On-Carrier Device ID 0
     -Channel ID 6 || Lane 0: enable
     -Link Type: AMC.2 Ethernet
     -Link Type extension: 1000BASE-BX (SerDES Gigabit) Ethernet link
     -Link Group ID: 0 || Link Asym. Match: exact match
    - To AMC slot B1
     -Channel ID 1 || Lane 0: enable
     -Link Type: AMC.2 Ethernet
     -Link Type extension: 1000BASE-BX (SerDES Gigabit) Ethernet link
     -Link Group ID: 0 || Link Asym. Match: exact match
    *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  On-Carrier Device vs AMC slot A2
   AMC slot A2 port 0 ==> On-Carrier Device 0 port 3
    Matching Result
    - From On-Carrier Device ID 0
     -Channel ID 9 || Lane 0: enable
     -Link Type: AMC.2 Ethernet
     -Link Type extension: 1000BASE-BX (SerDES Gigabit) Ethernet link
     -Link Group ID: 0 || Link Asym. Match: exact match
    - To AMC slot A2
     -Channel ID 0 || Lane 0: enable
     -Link Type: AMC.2 Ethernet
     -Link Type extension: 1000BASE-BX (SerDES Gigabit) Ethernet link
     -Link Group ID: 0 || Link Asym. Match: exact match
    *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  AMC slot B1 vs AMC slot A2
   AMC slot A2 port 2 ==> AMC slot B1 port 2
    Matching Result
    - From AMC slot B1
     -Channel ID 2 || Lane 0: enable
     -Link Type: AMC.3 Storage
     -Link Type extension: Serial Attached SCSI (SAS/SATA)
     -Link Group ID: 0 || Link Asym. Match: FC or SAS interface {exact match}
    - To AMC slot A2
     -Channel ID 2 || Lane 0: enable
     -Link Type: AMC.3 Storage
     -Link Type extension: Serial Attached SCSI (SAS/SATA)
     -Link Group ID: 0 || Link Asym. Match: FC or SAS interface {exact match}
  *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  • unmatch <xx=filename> <xx=filename> ... β€” the opposite vibe 🫢 shows you the unmatched results of the Ekeying match, again between an On-Carrier device and an AMC module, or between 2 AMC modules. It's giving "these two are not seeing each other".
  • all <xx=filename> <xx=filename> ... β€” the whole story, bestie: displays both the matched results and the unmatched results of the Ekeying match between two cards or two modules πŸ”₯

πŸŽ€ event πŸŽ€

<predefined event number N> 🌸

Sends a pre-defined test event into the System Event Log. The events below are there as a way to test that the System Event Log component of the BMC is actually, like, functioning (an entry gets added every single time the event N command runs πŸ‘‘).

Currently supported values for N are:

  • 1 β€” Temperature: Upper Critical: Going High
  • 2 β€” Voltage Threshold: Lower Critical: Going Low
  • 3 β€” Memory: Correctable ECC
NOTE: these pre-defined events will likely not produce "accurate" SEL records for a particular system, because they aren't correctly tied to a valid sensor number β€” but they're still plenty to verify correct operation of the SEL. So don't come for them 😭

file <filename> πŸ¦‹

Event log records specified in <filename> will be added to the System Event Log.

The format of each line in the file is as follows:

<{EvM Revision} {Sensor Type} {Sensor Num} {Event Dir/Type} {Event Data 0} {Event Data 1} {Event Data 2}>[# COMMENT]

e.g.:

0x4 0x2 0x60 0x1 0x52 0x0 0x0 # Voltage threshold: Lower Critical: Going Low

Field-by-field, because ikyk y'all want the deets:

  • EvM Revision β€” the "Event Message Revision" is 0x04 for messages that comply with the IPMI 2.0 Specification and 0x03 for messages that comply with the IPMI 1.0 Specification.
  • Sensor Type β€” tells you the Event Type or Class.
  • Sensor Num β€” represents the 'sensor' within the management controller that generated the Event Message.
  • Event Dir/Type β€” this field is encoded with the event direction as the high bit (bit 7) and the event type as the low 7 bits. Event direction is 0 for an assertion event and 1 for a deassertion event.

See the IPMI 2.0 specification for further details on the definitions for each field πŸ“š

<sensorid> <list> ✨

Gets you a list of all the possible Sensor States and the pre-defined Sensor State Shortcuts available for a particular sensor. sensorid is the character string representation of the sensor, and it must be enclosed in double quotes if it includes white space. Several different commands, including ipmitool sensor list, can be used to obtain a list that includes the sensorid strings representing the sensors on a given system 🫢

> ipmitool -I open event "PS 2T Fan Fault" list
Finding sensor PS 2T Fan Fault... ok
Sensor States:
  State Deasserted
  State Asserted
Sensor State Shortcuts:
  present    absent
  assert     deassert
  limit      nolimit
  fail       nofail
  yes        no
  on         off
  up         down

<sensorid> <sensor state> [<direction>] πŸ’œ

Generates a custom event based on existing sensor info. That optional event direction can be either assert (the default, if you don't say anything) or deassert.

> ipmitool event "PS 2T Fan Fault" "State Asserted"
Finding sensor PS 2T Fan Fault... ok
   0 | Pre-Init Time-stamp   | Fan PS 2T Fan Fault | State Asserted
> ipmitool event "PS 2T Fan Fault" "State Deasserted"
Finding sensor PS 2T Fan Fault... ok
   0 | Pre-Init Time-stamp   | Fan PS 2T Fan Fault | State Desserted

(yes, Desserted is literally what it prints β€” no cap, that's the output, we don't fix it πŸ“)


🌈 exec 🌈

exec <filename> β€” runs ipmitool commands straight out of filename. Each line is a complete command, and the syntax of those commands is defined by the COMMANDS section in this manpage. Every line may have an optional comment at the end of the line, delimited with a # symbol πŸ’…

e.g., a command file with two lines:

sdr list # get a list of sdr records
sel list # get a list of sel records

πŸ”₯ firewall πŸ”₯

This command supports the Firmware Firewall capability. Use it to add or remove security-based restrictions on certain commands/command sub-functions, or to list the current firmware firewall restrictions set on any commands. For each firmware firewall command listed below, parameters may be included to make the command execute with increasing granularity β€” on a specific LUN, for a specific NetFn, for a specific IPMI Command, and finally for a specific command's sub-function (peep Appendix H in the IPMI 2.0 Specification for a listing of any sub-function numbers that may be associated with a particular command πŸ‘‘).

Parameter syntax and dependencies are as follows:

[<channel H>] [<lun L> [ <netfn N> [<command C [<subfn S>]]]]
Heads up bestie: if netfn <N> is specified, then lun <L> must also be specified; if command <C> is specified, then netfn <N> (and therefore lun <L>) must also be specified, and so forth. The nesting is real 😭

channel <H> is an optional and standalone parameter. If you don't specify it, the requested operation happens on the current channel. Note that command support may vary from channel to channel β€” it's giving "every channel's got its own personality" πŸ™ˆ

Firmware firewall commands:

info [<Parms as described above>] ⭐

Lists firmware firewall information for the specified LUN, NetFn, and Command (if supplied) on the current or specified channel. The listed information includes the support, configurable, and enabled bits for the specified command or commands πŸ’–

Some usage examples:

  • info [<channel H>] [<lun L>] β€” this one lists firmware firewall info for all NetFns for the specified LUN on either the current channel or the channel you specify. πŸ’…
  • info [<channel H>] [<lun L> [ <netfn N> ] β€” this prints out all command information for a single LUN/NetFn pair.
  • info [<channel H>] [<lun L> [ <netfn N> [<command C] ]] β€” this prints detailed, human-readable info showing the support, configurable, and enabled bits for the specified command on the specified LUN/NetFn pair. Info gets printed about each of the command subfunctions. ✨
  • info [<channel H>] [<lun L> [ <netfn N> [<command C [<subfn S>]]]] β€” print out information for a specific sub-function.
  • enable [<Parms as described above>] β€” enables commands for a given NetFn/LUN combination on the specified channel.
  • disable [<Parms as described above>] [force] β€” disables commands for a given NetFn/LUN combination on the specified channel. Great care should be taken if using the force option so as not to disable the Set Command Enables command. 😭
  • reset [<Parms as described above>] β€” resets the firmware firewall back to a state where all commands and command sub-functions are enabled. 🫢

πŸ“ fru β€” Field Replaceable Unit era

  • print β€” read all Field Replaceable Unit (FRU) inventory data and extract stuff like serial number, part number, asset tags, and short strings describing the chassis, board, or product.
  • read <fru id> <fru file> β€” fru id is the digit ID of the FRU (see output of fru print). fru file is the absolute pathname of a file to dump the binary FRU data pertaining to the specified FRU entity into.
  • write <fru id> <fru file> β€” fru id is the digit ID of the FRU (see output of fru print). fru file is the absolute pathname of a file to pull the binary FRU data from before uploading it to the specified FRU.
  • upgEkey <fru id> <fru file> β€” update a multirecord FRU location. fru id is the digit ID of the FRU (see output of fru print). fru file is the absolute pathname of a file to pull the binary FRU data from to upload into the specified multirecord FRU entity.
  • edit <fru id> β€” provides interactive editing of some supported records, namely PICMG Carrier Activation Record. fru id is the digit ID of the FRU (see output of fru print); default is 0.
  • edit <fru id> field <section> <index> <string> β€” sets a field string to a new value. It replaces the FRU data found at index in the specified section with the supplied string.

fru id is the digit ID of the FRU (see output of fru print).

<section> is a string which refers to FRU Inventory Information Storage Areas and may refer to:

  • c β€” FRU Inventory Chassis Info Area
  • b β€” FRU Inventory Board Info Area
  • p β€” FRU Inventory Product Info Area

<index> specifies the field number. Field numbering starts on the first 'english text' field type. For instance in the <board> info area field 0 is <Board Manufacturer> and field 2 is <Board Serial Number>; see IPMI Platform Management FRU Information Storage Definition v1.0 R1.1 for field locations.

<string> must be the same length as the string being replaced and must be 8-bit ASCII (0xCx).

  • edit <fru id> oem iana <record> <format> [<args>] β€” edits the data found in the multirecord area. Support for OEM specific records is limited.

🧚 fwum β€” Kontron OEM firmware update manager

Update IPMC using Kontron OEM Firmware Update Manager. πŸ’œ

  • info β€” show information about current firmware.
  • status β€” show status of each firmware bank present in the hardware.
  • download <filename> β€” download specified firmware.
  • upgrade [filename] β€” install firmware upgrade. If the filename is specified, the file is downloaded first, otherwise the last firmware downloaded is used.
  • rollback β€” ask IPMC to rollback to previous version.
  • tracelog β€” show firmware upgrade log.

πŸ¦‹ gendev β€” generic device locators

  • list β€” list all Generic Device Locators.
  • read <sdr name> <file> β€” read to a file the eeprom specified by Generic Device Locators.
  • write <sdr name> <file> β€” write from a file to the eeprom specified by Generic Device Locators.

πŸ‘‘ hpm β€” PICMG HPM.1 Upgrade Agent

  • check β€” check the target information.
  • check <filename> β€” display both the existing target version and image version on the screen.
  • download <filename> β€” download specified firmware.
  • upgrade <filename> [all] [component <x>] [activate] β€” upgrade the firmware using a valid HPM.1 image file. If no option is specified, the firmware versions are checked first and the firmware is upgraded only if they are different.
    • all β€” upgrade all components even if the firmware versions are the same (use this only after using check command).
    • component <x> β€” upgrade only the given component from the given file.
      • component 0 β€” BOOT
      • component 1 β€” RTK
    • activate β€” activate new firmware right away.
  • activate β€” activate the newly uploaded firmware.
  • targetcap β€” get the target upgrade capabilities.
  • compprop <id> <select> β€” get the specified component properties. Valid component id: 0-7. select can be one of the following:
    • 0 β€” General properties
    • 1 β€” Current firmware version
    • 2 β€” Description string
    • 3 β€” Rollback firmware version
    • 4 β€” Deferred firmware version
  • abort β€” abort the on-going firmware upgrade.
  • upgstatus β€” show status of the last long duration command.
  • rollback β€” perform manual rollback on the IPM Controller firmware.
  • rollbackstatus β€” show the rollback status.
  • selftestresult β€” query the self test results.

🌈 i2c <i2caddr> <read bytes> [<write data>]

This command may be used to execute raw I2C commands with the Master Write-Read IPMI command. ⚑


πŸŽ€ ime β€” Manageability Engine

  • help β€” print usage information.
  • info β€” displays information about the Manageability Engine (ME).
  • update <file> β€” upgrade the ME firmware with the specified image file. WARNING: You MUST use a supported image provided by your board vendor. πŸ’€
  • rollback β€” perform manual rollback of the ME firmware.

🌸 isol β€” Intel IPMI v1.5 Serial-over-LAN

  • info β€” retrieve information about the Intel IPMI v1.5 Serial-Over-LAN configuration.
  • set <parameter> <value> β€” configure parameters for Intel IPMI v1.5 Serial-over-LAN. Valid parameters and values are:
    • enabled β€” true, false.
    • privilege-level β€” user, operator, admin, oem.
    • bit-rate β€” 9.6, 19.2, 38.4, 57.6, 115.2.
  • activate β€” causes ipmitool to enter Intel IPMI v1.5 Serial Over LAN mode. An RMCP+ connection is made to the BMC, the terminal is set to raw mode, and user input is sent to the serial console on the remote server. On exit, the SOL payload mode is deactivated and the terminal is reset to its original settings.

Special escape sequences are provided to control the SOL session:

  • ~. β€” terminate connection
  • ~^Z β€” suspend ipmitool
  • ~^X β€” suspend ipmitool, but don't restore tty on restart
  • ~B β€” send break
  • ~~ β€” send the escape character by typing it twice
  • ~? β€” print the supported escape sequences
Note that escapes are only recognized immediately after newline. 🫢

⭐ kontronoem β€” OEM commands specific to Kontron devices

  • setsn β€” set FRU serial number.
  • setmfgdate β€” set FRU manufacturing date.
  • nextboot <boot device> β€” select the next boot order on the Kontron CP6012.

πŸ’– lan β€” LAN channel configuration

These commands will allow you to configure IPMI LAN channels with network information so they can be used with the lan and lanplus interfaces.

NOTE: To determine on which channel the LAN interface is located, issue the channel info number command until you come across a valid 802.3 LAN channel. For example:
> ipmitool -I open channel info 1
Channel 0x1 info:
  Channel Medium Type   : 802.3 LAN
  Channel Protocol Type : IPMB-1.0
  Session Support       : session-based
  Active Session Count  : 8
  Protocol Vendor ID    : 7154
  • print [<channel>]

Print the current config for the channel you point at β€” and if you just don't specify one, it'll slide into the first LAN channel it finds and print that. Comfy default, tbh.

πŸ› οΈ set <channel number> <command> <parameter>

Okay so this one sets the command and parameter on the channel you name. Valid command/parameter combos, bestie, are these:

  • ipaddr <x.x.x.x> β€” sets the IP address for this channel. literally the main character of network config.
  • netmask <x.x.x.x> β€” sets the netmask for this channel.
  • macaddr <xx:xx:xx:xx:xx:xx> β€” sets the MAC address for this channel.
  • defgw ipaddr <x.x.x.x> β€” sets the default gateway IP address.
  • defgw macaddr <xx:xx:xx:xx:xx:xx> β€” sets the default gateway MAC address.
  • bakgw ipaddr <x.x.x.x> β€” sets the backup gateway IP address. the understudy gateway 🎭
  • bakgw macaddr <xx:xx:xx:xx:xx:xx> β€” sets the backup gateway MAC address.
  • password <pass> β€” sets the null user password.
  • snmp <community string> β€” sets the SNMP community string.
  • user β€” enables user access mode for userid 1 (go issue the user command to display info about userids for a given channel, iykyk).
  • access <on|off> β€” sets the LAN channel access mode.
  • alert <on|off> β€” enables or disables PEF alerting for this channel.
  • ipsrc <source> β€” sets the IP address source. the options are:
    • none β€” unspecified
    • static β€” manually configured static IP address
    • dhcp β€” address obtained by BMC running DHCP
    • bios β€” address loaded by BIOS or system software
  • arp respond <on|off> β€” sets BMC generated ARP responses.
  • arp generate <on|off> β€” sets BMC generated gratuitous ARPs.
  • arp interval <seconds> β€” sets the BMC generated gratuitous ARP interval.
  • vlan id <off|id> β€” disables VLAN operation, or enables VLAN and sets the ID. the ID is the value of the virtual lan identifier between 1 and 4094 inclusive. πŸ¦‹
  • vlan priority <priority> β€” sets the priority associated with VLAN frames. ID: priority of the virtual lan frames between 0 and 7 inclusive.
  • auth <level,...> <type,...> β€” sets the valid authtypes for a given auth level.
    • Levels: callback, user, operator, admin
    • Types: none, md2, md5, password, oem
  • cipher_privs <privlist> β€” correlates cipher suite numbers with the maximum privilege level allowed to use it. so basically you can restrict cipher suites to users with a given privilege level β€” meaning, for example, admins are required to use a stronger cipher suite than normal users. gatekeeping, but make it security πŸ’…

The format of privlist is as follows: each character represents a privilege level, and the character position identifies the cipher suite number. So like, the first character represents cipher suite 0, the second represents cipher suite 1, and so on. privlist must be 15 characters long. no more, no less.

Characters used in privlist and their associated privilege levels:

  • X β€” Cipher Suite Unused
  • c β€” CALLBACK
  • u β€” USER
  • o β€” OPERATOR
  • a β€” ADMIN
  • O β€” OEM

So, to set the maximum privilege for cipher suite 0 to USER and suite 1 to ADMIN, you'd issue this:

> ipmitool -I interface lan set channel cipher_privs uaXXXXXXXXXXXXX
  • bad_pass_thresh <thresh_num> <1|0> <reset_interval> <lockout_interval> β€” sets the Bad Password Threshold. the deets:
    • <thresh_num> β€” if non-zero, this value determines the number of sequential bad passwords that will be allowed to be entered for the identified user before the user is automatically disabled from access on the channel.
    • <1|0> β€” 1 = generate a Session Audit sensor "Invalid password disable" event message. 0 = do not generate an event message when the user is disabled.
    • <reset_interval> β€” Attempt Count Reset Interval. the interval, in tens of seconds, for which the accumulated count of bad password attempts is retained before being automatically reset to zero.
    • <lockout_interval> β€” User Lockout Interval. the interval, in tens of seconds, that the user will remain disabled after being disabled because the Bad Password Threshold number was reached. πŸ’€

🚨 alert print [<channel>] [<alert destination>]

Prints alert info for the specified channel and destination. default behavior prints all alerts for all alert destinations on the first found LAN channel. the full scroll, bestie.

🚨 alert set <channel number> <alert destination> <command> <parameter>

Sets an alert on the given LAN channel and destination. you can see your Alert Destinations via the lan alert print command. valid command/parameter options:

  • ipaddr <x.x.x.x> β€” sets alert IP address.
  • macaddr <xx:xx:xx:xx:xx:xx> β€” sets alert MAC address.
  • gateway <default | backup> β€” sets the channel gateway to use for alerts.
  • ack <on | off> β€” turns Alert Acknowledge on or off.
  • type <pet | oem1 | oem2> β€” sets the destination type as PET or OEM.
  • time <seconds> β€” sets ack timeout or unack retry interval.
  • retry <number> β€” sets the number of alert retries.

πŸ“Š stats get [<channel number>]

Pulls info about the IP connections on the specified channel. default grabs statistics on the first found LAN channel. numbers go brrr πŸ“ˆ

🧹 stats clear [<channel number>]

Clears all IP/UDP/RMCP Statistics to 0 on the specified channel. default clears statistics on the first found LAN channel. fresh start energy ✨


πŸ’» mc | bmc

πŸ”„ reset <warm|cold>

Instructs the BMC to perform a warm or cold reset. pick your temperature, bestie 🌑️

πŸ†” guid [smbios|rfc4122|ipmi|dump]

Displays the Management Controller Globally Unique IDentifier. the whole encoding situation is a saga, so buckle up:

  • auto β€” this is the default behavior for ipmitool(1).

It tries to automatically detect the encoding based on the value of the version field and (for version 1) the timestamp. The version is considered valid if it is 1 through 5, and the timestamp is valid if the year is past or equal to UNIX Epoch (1970) and is before or equal to the current year.

If multiple encodings happen to have valid version fields, then precedence takes the one with version 1 and a valid timestamp. If neither one has that, then the precedence order is as follows: smbios, ipmi, rfc4122.

If neither encoding yields a valid version field, then ipmitool(1) defaults to dump mode.

If this option is in use, then ipmitool(1) will also print out the detected encoding and warn regarding IPMI specification violation if the encoding isn't ipmi. consider it a little heads up 🫢

  • smbios β€” decodes the GUID as if it was sent by the BMC as prescribed by the SMBIOS specification.
NOTE: this is a violation of the IPMI specification, but many BMC implementations do it this way. If your BMC's GUID is shown correctly using this option, you may want to inform your BMC manufacturer that they have a bug. drag them, respectfully πŸ™ˆ
  • ipmi β€” decodes the GUID according to the IPMI specification. It MUST show the correct GUID. If it doesn't, try other options and inform your BMC manufacturer of the bug.
  • rfc4122 or rfc β€” decodes the GUID as if it was sent by the BMC as prescribed by the RFC4122 specification.
NOTE: this is a violation of the IPMI specification. If your BMC's GUID is shown correctly using this option, you may want to inform your BMC manufacturer that they have a bug.
  • dump β€” dumps as hex the data received from BMC in response to the Get Device GUID command. No decoding or interpretation is performed. First received byte is dumped first. raw and unfiltered, no cap πŸ”₯

ℹ️ info

Displays info about the BMC hardware β€” including device revision, firmware revision, IPMI version supported, manufacturer ID, and info on additional device support. the whole rΓ©sumΓ© πŸ‘‘

⏱️ watchdog

These commands let a user view and change the current state of the watchdog timer.

  • get
  • the display one β€” shows the current Watchdog Timer settings and the countdown state. both bestie, at once 🫢
  • reset β€” resets the Watchdog Timer to its most recent state and restarts that countdown timer. fresh start energy πŸ”„
  • off β€” turns off a Watchdog countdown timer that's currently running. bye πŸ‘‹

  • selftest β€” checks on the basic health of the BMC by executing the Get Self Test results command and reports the results back to you. it's giving "vibe check, but for hardware" 🩺✨
  • getenables β€” displays a list of the options that are currently enabled on the BMC. πŸ“‹
  • setenables <option>=[on|off] β€” enables or disables the given option.
okay important πŸ’… per the IPMI specification, this command is only supported over the system interface. that's the spec talking, not me.

Currently supported values for option include:

  • recv_msg_intr β€” Receive Message Queue Interrupt
  • event_msg_intr β€” Event Message Buffer Full Interrupt
  • event_msg β€” Event Message Buffer
  • system_event_log β€” System Event Logging
  • oem0 β€” OEM-Defined option #0
  • oem1 β€” OEM-Defined option #1
  • oem2 β€” OEM-Defined option #2
  • getsysinfo <argument> β€” retrieves system info from the bmc for the given argument. for what the arguments actually are, go look at setsysinfo β€” the definitions live there, iykyk 🫑
  • setsysinfo <argument> <string> β€” stores a system info string to the bmc for the given argument. πŸ—„οΈ

Possible arguments are:

  • primary_os_name β€” Primary Operating System Name
  • os_name β€” Operating System Name
  • system_name β€” System Name of Server
  • delloem_os_version β€” Running version of operating system
  • delloem_URL β€” URL of BMC Webserver

✨ chassis ✨

whole-chassis energy, the main character of the box πŸ‘‘

  • status β€” displays information regarding the high-level status of the system chassis and the main power subsystem. πŸŽ›οΈ
  • poh β€” this command returns the Power-On Hours counter. like, how long has this thing been awake 😴⏰
  • identify <interval> β€” controls the front panel identify light. πŸ’‘ default interval is 15 seconds, use 0 to turn it off, and use "force" to turn it on indefinitely.
  • restart_cause β€” queries the chassis for the cause of the last system restart. detective mode πŸ•΅οΈβ€β™€οΈ
  • selftest β€” checks on the basic health of the BMC by executing the Get Self Test results command and reports the results. same vibe check, chassis edition 🩺
  • policy β€” sets the chassis power policy for the event of a power failure. ⚑
    • list β€” return supported policies.
    • always-on β€” turn on when power is restored.
    • previous β€” returned to previous state when power is restored.
    • always-off β€” stay off after power is restored.
  • power β€” performs a chassis control command to view and change the power state. πŸ”Œ
    • status β€” show current chassis power status.
    • on β€” power up chassis.
    • off β€” power down chassis into soft off (S4/S5 state).
⚠️ WARNING: this command does not initiate a clean shutdown of the operating system prior to powering down the system. fr fr, know what you're doing 😭
  • cycle β€” provides a power off interval of at least 1 second. no action should occur if chassis power is in S4/S5 state, but it is recommended to check the power state first and only issue a power cycle command if the system power is on, or in a lower sleep state than S4/S5.
  • reset β€” this command performs a hard reset. πŸ”¨
  • diag β€” pulses a diagnostic interrupt (NMI) directly to the processor(s). unhinged but iconic πŸ’€
  • soft β€” initiates a soft-shutdown of the OS via ACPI. this can be done in a number of ways, commonly by simulating an overtemperture or by simulating a power button press. it's necessary for there to be Operating System support for ACPI and some sort of daemon watching for events for this soft power to work. teamwork makes the dream work 🫢
  • bootdev <device> [<clear-cmos=yes|no>] [<options=help,...>] β€” requests the system to boot from an alternate boot device on the next reboot. the clear-cmos option, if supplied, instructs the BIOS to clear its CMOS on the next reboot. various options may be used to modify the boot device settings β€” run bootdev none options=help for a list of available boot device modifiers/options. πŸ₯Ύ

Currently supported values for <device> are:

  • none β€” do not change boot device
  • pxe β€” force PXE boot
  • disk β€” force boot from BIOS default boot device
  • safe β€” force boot from BIOS default boot device, request Safe Mode
  • diag β€” force boot from diagnostic partition
  • cdrom β€” force boot from CD/DVD
  • bios β€” force boot into BIOS setup
  • floppy β€” force boot from Floppy/primary removable media
  • bootparam β€” get or set various system boot option parameters. βš™οΈ
    • get <param #> β€” get boot parameter. currently supported values for <param #> are:
      • 0 β€” Set In Progress
      • 1 β€” Service Partition Selector
      • 2 β€” Service Partition Scan
      • 3 β€” BMC Boot Flag Valid Bit Clearing
      • 4 β€” Boot Info Acknowledge
      • 5 β€” Boot Flags
      • 6 β€” Boot Initiator Info
      • 7 β€” Boot Initiator Mailbox
    • set <device> [<options=help,...>] β€” set the boot device parameter used for the next boot. various options may be used to change when the next boot device is cleared. run options=help for a list of available bootparam set device options.

Currently supported bootparam device settings are:

  • force_pxe β€” force PXE boot
  • force_disk β€” force boot from default hard-drive
  • force_safe β€” force boot from default hard-drive, request Safe Mode
  • force_diag β€” force boot from diagnostic partition
  • force_cdrom β€” force boot from CD/DVD
  • force_bios β€” force boot into BIOS setup

Currently supported bootparam options settings are associated with BMC Boot Valid Bit Clearing, and they are as follows β€” and any option can be prefixed with "no-" to invert the sense of the operation. sneaky but valid πŸ’…

  • PEF β€” clear valid bit on reset/power cycle caused by PEF
  • timeout β€” automatically clear boot flag valid bit if Chassis Control command is not received within 60 seconds
  • watchdog β€” clear valid bit on reset/power cycle caused by watchdog timeout
  • reset β€” clear valid bit on push button reset / soft-reset
  • power β€” clear valid bit on power up via power push button or wake event

🌈 nm 🌈

  • alert β€” the Node Manager alert vibes 🚨
    • clear dest <dest> β€” clear the Node Manager Alert lan destination.
    • get β€” get the Node Manager Alert settings.
    • set chan <chan> dest <dest> string <string> β€” set the Node Manager alert channel, lan destination, and alert string number.
  • capability β€” obtains the Node Manager power control capabilities and ranges. πŸ“Š
  • control β€” the on/off switch era 🎚️
    • enable|disable β€” pick your fighter
      • global β€” enable/disable all policies for all domains. go big or go home πŸ‘‘

okay so we're still deep in Node Manager territory, and the enable|disable side of the group chat has exactly two moves. no cap, here they are:

  • per_domain <platform|CPU|Memory> β€” turns all the policies on or off for whichever domain you name. platform, CPU, or Memory, pick your fighter πŸ’…
  • per_policy <0-7> β€” turns the policy on or off for one specific domain/policy combo. the number is 0-7, bestie, don't freestyle it.

πŸ¦‹ discover

This one discovers Node Manager presence and spills the Node Manager version, revision, and patch number. presence check plus version tea ✨

πŸ’– policy

  • add β€” okay so this has two flavors, and both can add a new policy or overwrite an existing one:
    • power <watts> policy_id <0-7> [correction auto|soft|hard] trig_lim <seconds> stats <seconds> [domain <platform|CPU|Memory>] enable|disable β€” adds a power policy. correction controls how aggressive the frequency limiting is, and the default is auto. trig_lim is the correction time limit and has to be at least 6000 and not greater than 65535. stats is the averaging period in seconds, ranges from 1-65535. no domain? it defaults to platform. power policy slay πŸ”₯
    • inlet <temp> policy_id <0-7> [correction auto|soft|hard] trig_lim <seconds> stats <seconds> [domain <platform|CPU|Memory>] enable|disable β€” adds an inlet temp policy. same correction default auto, same trig_lim range 6000 to 65535, same stats range 1-65535, same domain default platform. temperature policy, but make it cute 🌑️
  • get policy_id <0-7> β€” grabs a policy that's already stored. retrieval era
  • limiting β€” reports the policy number if any policy is currently limiting power. snitch on the limiting policy πŸ‘€
  • remove policy_id <0-7> [domain <platform|CPU|Memory>] β€” deletes a policy. no domain? defaults to platform.

⚑ power

  • power min <minimum> max <maximum> [domain <platform|CPU|Memory>] β€” configures Node Manager power minimum and maximum power draw limits. min and max must be in the range 0-65535. no domain? defaults to platform. set the floor and the ceiling πŸ—οΈ

🌈 reset

  • comm policy_id <0-7> [domain <platform|CPU|Memory>] β€” resets Node Manager communication statistics. no domain? defaults to platform.
  • global β€” resets Node Manager global statistics. big reset energy
  • memory policy_id <0-7> [domain <platform|CPU|Memory>] β€” resets Node Manager memory throttling statistics. no domain? defaults to platform.
  • per_policy policy_id <0-7> [domain <platform|CPU|Memory>] β€” resets Node Manager per policy statistics. no domain? defaults to platform.
  • requests policy_id <0-7> [domain <platform|CPU|Memory>] β€” resets Node Manager unhandled requests statistics. no domain? defaults to platform.
  • response policy_id <0-7> [domain <platform|CPU|Memory>] β€” resets Node Manager response time statistics. no domain? defaults to platform.
  • throttling policy_id <0-7> [domain <platform|CPU|Memory>] β€” resets Node Manager throttling statistics. no domain? defaults to platform.

πŸ“ statistics

  • comm_fail β€” reports Node Manager communication failure statistics. the "oops" report 😭
  • cpu_throttling β€” reports Node Manager cpu throttling statistics.
  • mem_throttling β€” reports Node Manager memory throttling statistics.
  • policy_power policy_id <0-7> [domain <platform|CPU|Memory>] β€” reports Node Manager per policy power statistics (policy must be a power limit type policy). no domain? defaults to platform.
  • policy_temps policy_id <0-7> [domain <platform|CPU|Memory>] β€” reports Node Manager per policy temp statistics (policy must be an inlet temp limit policy). no domain? defaults to platform.
  • policy_throt policy_id <0-7> [domain <platform|CPU|Memory>] β€” reports Node Manager per policy throttling statistics. no domain? defaults to platform.
  • requests β€” reports Node Manager unhandled requests statistics.
  • response β€” reports Node Manager response time statistics.

🧚 suspend

  • get policy_id <0-7> [domain <platform|CPU|Memory>] β€” gets Node Manager policy suspend periods. no domain? defaults to platform.
  • set policy_id <0-7> [domain <platform|CPU|Memory>] <start> <stop> <repeat> β€” sets Node Manager policy suspend periods. no domain? defaults to platform. <start> and <stop> have to be in the range 0-239, which is the number of minutes past midnight divided by 6. <repeat> is the daily recurrence pattern: bit 0 is repeat every Monday, bit 1 is repeat every Tuesday, on through bit 6 for Sunday. calendar girl math πŸ—“οΈ

πŸ‘‘ threshold

  • get policy_id <0-7> [domain <platform|CPU|Memory>] β€” gets Node Manager policy Alert Threshold settings. no domain? defaults to platform.
  • set policy_id <0-7> [domain <platform|CPU|Memory>] thresh_array β€” sets Node Manager policy Alert Threshold values. no domain? defaults to platform. the thresh_array is 1, 2, or 3 integers that set three alert threshold settings. the setting type is a power or temperature value, and it must match the type of policy. matching energy only πŸ’…

🌸 pef

  • info β€” queries the BMC and prints information about the PEF supported features.
  • status β€” prints the current PEF status (the last SEL entry processed by the BMC, etc). status check
  • policy β€” lists the PEF policy table entries. each policy entry describes an alert destination. a policy set is a collection of table entries. PEF alert actions reference policy sets.
  • list β€” lists the PEF table entries. each PEF entry relates a sensor event to an action. when PEF is active, each platform event causes the BMC to scan this table for entries matching the event, and possible actions to be taken. actions are performed in priority order (higher criticality first). priority order, periodt πŸ”₯

πŸ”§ picmg <properties>

runs a PICMG/ATA extended command. Get PICMG properties may be used to obtain and print Extension major version information, PICMG identifier, FRU Device ID and Max FRU Device ID. PICMG lore unlocked 🧚

  • addrinfo β€” gets address information. this command may return information on the Hardware address, IPMB-0 Address, FRU ID, Site/Entity ID, and Site/Entity Type. address reveal
  • frucontrol <fru id> <options> β€” sets various control options:
    • 0x00 β€” Cold Reset
    • 0x01 β€” Warm Reset
    • 0x02 β€” Graceful Reboot
    • 0x03 β€” Issue Diagnostic Interrupt
    • 0x04 β€” Quiesce [AMC only]
    • 0x05-0xFF β€” Cold Reset
  • activate <fru id> β€” activates the specified FRU. wake it up ✨
  • deactivate <fru id> β€” deactivates the specified FRU.
  • policy get <fru id> β€” gets FRU activation policy.
  • policy set <fru id> <lockmask> <lock> β€” sets FRU activation policy. lockmask is 1 or 0 to indicate action on the deactivation or activation locked bit respectively. lock is 1 or 0 to set/clear locked bit.
  • portstate set|getall|getgranted|getdenied <parameters> β€” gets or sets various port states. see usage for parameter details. parameter details live in usage, bestie

⚑ power <chassis power command>

shortcut to the chassis power commands. see the chassis power commands for usage information. shortcut szn

πŸͺ„ raw <netfn> <cmd> [<data>]

this lets you execute raw IPMI commands. for example, to query the POH counter with a raw command:

> ipmitool -v raw 0x0 0xf
RAW REQ (netfn=0x0 cmd=0xf data_len=0)
RAW RSP (5 bytes)
3c 72 0c 00 00
note: the OpenIPMI driver provided by the Linux kernel will reject the Get Message, Send Message and Read Event Message Buffer commands because it handles the message sequencing internally. do not fight the driver, bestie πŸ’€

🌈 sdr

  • get <id> ... [<id>] β€” prints information for sensor data records specified by sensor id. sensor tea, served fresh πŸ“

info

Okay so this command will query the BMC for Sensor Data Record (SDR) Repository information. slay, now we know what the SDR repo is up to.

  • type [<sensor type>] β€” This command will display all records from the SDR Repository of a specific type. Run with type list (or simply with no type) to see the list of available types. For example to query for all Temperature sensors:
> ipmitool sdr type Temperature
Baseboard Temp   | 30h | ok  |  7.1 | 28 degrees C
FntPnl Amb Temp  | 32h | ok  | 12.1 | 24 degrees C
Processor1 Temp  | 98h | ok  |  3.1 | 57 degrees C
Processor2 Temp  | 99h | ok  |  3.2 | 53 degrees C
  • list | elist [<all|full|compact|event|mcloc|fru|generic>] β€” This command will read the Sensor Data Records (SDR) and extract sensor information of a given type, then query each sensor and print its name, reading, and status. If invoked as elist then it will also print sensor number, entity id and instance, and asserted discrete states.

The default output will only display full and compact sensor types, to see all sensors use the all type with this command.

Valid types are:

  • all β€” All SDR records (Sensor and Locator)
  • full β€” Full Sensor Record
  • compact β€” Compact Sensor Record
  • event β€” Event-Only Sensor Record
  • mcloc β€” Management Controller Locator Record
  • fru β€” FRU Locator Record
  • generic β€” Generic SDR records
  • entity <id>[.<instance>] β€” Displays all sensors associated with an entity. Get a list of valid entity ids on the target system by issuing the sdr elist command. A list of all entity ids can be found in the IPMI specifications. iykyk ✨
  • dump <file> β€” Dumps raw SDR data to a file. This data file can then be used as a local SDR cache of the remote managed system with the -S <file> option on the ipmitool command line. This can greatly improve performance over system interface or remote LAN. obsessed with a good cache glow-up πŸ’…
  • fill sensors β€” Create the SDR Repository for the current configuration. Will perform a 'Clear SDR Repository' command so be careful.
⚠️ Bestie, for real: fill sensors will perform a 'Clear SDR Repository' command, so be careful.
  • fill file <filename> β€” Fill the SDR Repository using records stored in a binary data file. Will perform a 'Clear SDR Repository' command so be careful.
⚠️ Same warning energy: fill file <filename> will perform a 'Clear SDR Repository' command, so be careful.

sel 🧾

⚠️ NOTE: System Event Log (SEL) entry-times are displayed as Pre-Init Time-stamp if the SEL clock needs to be set. Ensure that the SEL clock is accurate by invoking the sel time get and sel time set <time string> commands.
  • info β€” This command will query the BMC for information about the System Event Log (SEL) and its contents.
  • clear β€” This command will clear the contents of the SEL. It cannot be undone so be careful. no cap, this is the point of no return 😭
  • list | elist β€” When this command is invoked without arguments, the entire contents of the System Event Log are displayed. If invoked as elist (extended list) it will also use the Sensor Data Record entries to display the sensor ID for the sensor that caused each event. Note this can take a long time over the system interface.
    • <count> | first <count> β€” Displays the first count (least-recent) entries in the SEL. If count is zero, all entries are displayed.
    • last <count> β€” Displays the last count (most-recent) entries in the SEL. If count is zero, all entries are displayed.
  • delete <SEL Record ID> ... <SEL Record ID> β€” Delete one or more SEL event records. bye bye, little records πŸ¦‹
  • add <filename ID> β€” Read event entries from a file and add them to the SEL. New SEL entries are added onto the SEL after the last record in the SEL. Record added is of type 2 and is automatically timestamped.
  • get <SEL Record ID> β€” Print information on the specified SEL Record entry.
  • save <file> β€” Save SEL records to a text file that can be fed back into the event file ipmitool command. This can be useful for testing Event generation by building an appropriate Platform Event Message file based on existing events. Please see the available help for the 'event file ...' command for a description of the format of this file.
  • writeraw <file> β€” Save SEL records to a file in raw, binary format. This file can be fed back to the sel readraw ipmitool command for viewing.
  • readraw <file> β€” Read and display SEL records from a binary file. Such a file can be created using the sel writeraw ipmitool command.
  • time β€” SEL clock time stuff, because timestamps need to be cute and accurate ⏰
    • get β€” Displays the SEL clock's current time.
    • set <time string> β€” Sets the SEL clock. Future SEL entries will use the time set by this command. <time string> is of the form "MM/DD/YYYY HH:MM:SS". Note that hours are in 24-hour form. It is recommended that the SEL be cleared before setting the time.

sensor 🌑️

  • list β€” Lists sensors and thresholds in a wide table format.
  • get <id> ... [<id>] β€” Prints information for sensors specified by name.
  • thresh <id> <threshold> <setting> β€” This allows you to set a particular sensor threshold value. The sensor is specified by name.

Valid thresholds are:

  • unr β€” Upper Non-Recoverable
  • ucr β€” Upper Critical
  • unc β€” Upper Non-Critical
  • lnc β€” Lower Non-Critical
  • lcr β€” Lower Critical
  • lnr β€” Lower Non-Recoverable
  • thresh <id> lower <lnr> <lcr> <lnc> β€” This allows you to set all lower thresholds for a sensor at the same time. The sensor is specified by name and the thresholds are listed in order of Lower Non-Recoverable, Lower Critical, and Lower Non-Critical.
  • thresh <id> upper <unc> <ucr> <unr> β€” This allows you to set all upper thresholds for a sensor at the same time. The sensor is specified by name and the thresholds are listed in order of Upper Non-Critical, Upper Critical, and Upper Non-Recoverable.

session πŸ‘₯

  • info <active|all|id 0xnnnnnnnn|handle 0xnn> β€” Get information about the specified session(s). You may identify sessions by their id, by their handle number, by their active status, or by using the keyword all to specify all sessions.

set βš™οΈ

  • hostname <host> β€” Session hostname.
  • username <user> β€” Session username.
  • password <pass> β€” Session password.
  • privlvl <level> β€” Session privilege level force.
  • authtype <type> β€” Authentication type force.
  • localaddr <addr> β€” Local IPMB address.
  • targetaddr <addr> β€” Remote target IPMB address.
  • port <port> β€” Remote RMCP port.
  • csv [level] β€” Enable output in comma separated format. Affects following commands: user, channel, isol, sunoem, sol, sensor, sdr, sel, session. spreadsheet era πŸ“Š
  • verbose [verbose] β€” Verbosity level.

shell 🐚

This command will launch an interactive shell which you can use to send multiple ipmitool commands to a BMC and see the responses. This can be useful instead of running the full ipmitool command each time. Some commands will make use of a Sensor Data Record cache and you will see marked improvement in speed if these commands are able to reuse the same cache in a shell session. LAN sessions will send a periodic keepalive command to keep the IPMI session from timing out. main character shell energy ✨

sol 🌐

  • info [<channel number>] β€” Retrieve information about the Serial-Over-LAN configuration on the specified channel. If no channel is given, it will display SOL configuration data for the currently used channel.
  • payload <enable | disable | status> <channel number> <userid> β€” Enable, disable or show status of SOL payload for the user on the specified channel.
  • set <parameter> <value> [<channel>] β€” Configure parameters for Serial Over Lan. If no channel is given, it will display SOL configuration data for the currently used channel. Configuration parameter updates are automatically guarded with the updates to the set-in-progress parameter.

Valid parameters and values are:

  • set-in-progress β€” set-complete set-in-progress commit-write
  • enabled β€” true false
  • force-encryption β€” true false
  • force-authentication β€” true false
  • privilege-level β€” user operator admin oem
  • character-accumulate-level β€” Decimal number given in 5 milliseconds increments
  • character-send-threshold β€” Decimal number
  • retry-count β€” Decimal number. 0 indicates no retries after packet is transmitted.
  • retry-interval β€” a decimal number, counted in 10 millisecond increments. Set it to 0 and the retries get fired back to back with zero breathing room. πŸ’¨
  • non-volatile-bit-rate β€” your options are serial, 19.2, 38.4, 57.6, 115.2. If you set it to serial, that means the BMC should use the setting used by the IPMI over serial channel. iykyk ✨
  • volatile-bit-rate β€” same menu, bestie: serial, 19.2, 38.4, 57.6, 115.2. Set it to serial and the BMC should use the setting used by the IPMI over serial channel. πŸŽ€

activate [usesolkeepalive | nokeepalive] [instance=<number>]

This is the moment ipmitool slides into Serial Over LAN mode, and it's only available when you're using the lanplus interface β€” no substitutions, okay? πŸ’… An RMCP+ connection gets made to the BMC, your terminal gets flipped into raw mode, and everything you type gets yeeted straight to the serial console on the remote server. On exit, the SOL payload mode is deactivated and the terminal is reset to its original settings. Iconic behavior, honestly.

If you hand it an instance, it activates using that instance number. Default is 1.

Special escape sequences exist to control the SOL session, and they are:

  • ~. β€” terminate the connection
  • ~^Z β€” suspend ipmitool
  • ~^X β€” suspend ipmitool, but don't restore the tty on restart
  • ~B β€” send break
  • ~~ β€” send the escape character by typing it twice
  • ~? β€” print the supported escape sequences
Heads up bestie: escapes are only recognized immediately after a newline. So don't be out here mashing tildes mid-line and wondering why nothing happens 😭

deactivate [instance=<number>]

Deactivates Serial Over LAN mode on the BMC. Normally, exiting Serial Over LAN mode should automatically cause this command to be sent to the BMC β€” but if you had an unintentional exit from SOL mode, this command may be necessary to reset the state of the BMC. Basically it's the cleanup crew for when things got messy. 🧹

If you give it an instance, it deactivates that instance number. Default is 1.


πŸ¦‹ spd

spd <i2cbus> <i2caddr> [<channel>] [<axread>]

This command may be used to read SPD (Serial Presence Detect) data using the I2C Master Write-Read IPMI command. Very demure, very mindful, very low-level. ✨


🌈 sunoem

Okay so sunoem has a whole little friend group of subcommands, let's meet them πŸ‘‘

cli [<command string> ...]

Execute the service processor command line interface commands. With no command string at all, you get dropped into an interactive session inside the service processor command line environment β€” main character energy, you're literally inside the SP now. If you do specify a command string, that command string is executed on the service processor and the connection is closed. In and out. πŸšͺ

led

These commands provide a way to get and set the status of LEDs on a Sun Microsystems server. Use sdr list generic to get a list of devices that are controllable LEDs. The ledtype parameter is optional and not necessary to provide on the command line unless it is required by hardware.

  • get <sensorid> [<ledtype>] β€” Get status of a particular LED described by a Generic Device Locator record in the SDR. A sensorid of all will get the status of all available LEDS. πŸ‘€
  • set <sensorid> <ledmode> [<ledtype>] β€” Set status of a particular LED described by a Generic Device Locator record in the SDR. A sensorid of all will set the status of all available LEDS to the specified ledmode and ledtype. πŸŽ€

LED Mode is required for set operations:

  • OFF β€” Off
  • ON β€” Steady On
  • STANDBY β€” 100ms on 2900ms off blink rate
  • SLOW β€” 1HZ blink rate
  • FAST β€” 4HZ blink rate

LED Type is optional:

  • OK2RM β€” Ok to Remove
  • SERVICE β€” Service Required
  • ACT β€” Activity
  • LOCATE β€” Locate

nacname <ipmi name>

Return the full NAC name of a target identified by ipmi name. Short and sweet. πŸ“

ping <count> [<q>]

Send and receive count packets. Each packet is 64 bytes.

q β€” Quiet. Displays output only at the start and end of the process. So you don't get spammed with packets, slay. πŸ”‡

getval <property name>

Returns value of specified ILOM property. That's it, that's the whole thing. πŸ’œ

setval <property name> <property value> [<timeout>]

Sets value of ILOM property. If timeout is not specified, the default value is 5 seconds.

⚠️ NOTE: setval must be executed locally on host! Not remotely, not over the network, locally. Don't come crying to me when it doesn't work from your jump box 😭

sshkey

  • set <userid> <keyfile> β€” This command will allow you to specify an SSH key to use for a particular user on the Service Processor. This key will be used for CLI logins to the SP and not for IPMI sessions. View available users and their userids with the user list command. πŸ”‘
  • del <userid> β€” This command will delete the SSH key for a specified userid. Bye bye key πŸ’€

version

Display the version of ILOM firmware. Quick vibe check on the firmware. ⭐

getfile <file identifier> <destination file name>

This command will return various files from service processor and store them in specified destination file. Note that some files may not be present or be supported by your SP. πŸ™ˆ

File identifiers:

SSH_PUBKEYS
DIAG_PASSED
DIAG_FAILED
DIAG_END_TIME
DIAG_INVENTORY
DIAG_TEST_LOG
DIAG_START_TIME
DIAG_UEFI_LOG
DIAG_TEST_LOG
DIAG_LAST_LOG
DIAG_LAST_CMD

(Yes, DIAG_TEST_LOG is listed twice in the source β€” not a typo on my end, bestie, don't @ me πŸ’…)

getbehavior <feature identifier>

This command will test if various ILOM features are enabled.

Feature identifiers:

SUPPORTS_SIGNED_PACKAGES
REQUIRES_SIGNED_PACKAGES

🌸 tsol

This command allows Serial-over-LAN sessions to be established with Tyan IPMIv1.5 SMDC such as the M3289 or M3290. The default command run with no arguments will establish a default SOL session back to the local IP address. Optional arguments may be supplied in any order β€” chaotic but valid, we respect it 🫢

  • <ipaddr> β€” Send receiver IP address to SMDC, which it will use to send serial traffic to. By default this detects the local IP address and establishes a two-way session. Format of ipaddr is XX.XX.XX.XX.
  • port=NUM β€” Configure UDP port to receive serial traffic on. By default this is 6230.
  • ro|rw β€” Confiure SOL session as read-only or read-write. Sessions are read-write by default.

πŸ‘‘ user

The whole user-management situation, let's get into it πŸ’–

summary

Displays a summary of userid information, including the maximum number of userids, the number of enabled users, and the number of fixed names defined. A little dashboard of who's who. ✨

list

Displays a list of user information for all defined userids. Everyone's invited to the list. πŸŽ€

set

  • name <userid> <username> β€” Sets the username associated with the given userid. Name them, bestie 🏷️
  • password <userid> [<password> [<16|20>]] β€” Sets the password for the given userid. If no password is given, the password is cleared (set to the NULL password).
🚨 Be careful when removing passwords from administrator-level accounts. Like, genuinely be careful. That's a locked-door situation you're opening. 😭

If specified, 16 or 20 determines the maximum password length.

disable <userid>

Disables access to the BMC by the given userid. Revoked. 🚫

enable <userid>

Enables access to the BMC by the given userid. Access granted, welcome back πŸ’…

priv <userid> <privilege level> [<channel number>]

Set user privilege level on the specified channel. If the channel is not specified, the current channel will be used. Give them exactly the power they need, no more, no less. πŸ”₯

test <userid> <16|20> [<password>]

Determine whether a password has been stored as 16 or 20 bytes. Detective work, but make it credential-forensics πŸ•΅οΈβ€β™€οΈ

🌈 INTERFACES 🌈

πŸ’– OPEN INTERFACE πŸ’–

Okay so the open interface is the one that rides on the OpenIPMI kernel device driver. That driver ships in all modern 2.4 and all 2.6 kernels, and it should already be in recent Linux distro kernels too. There are also IPMI driver kernel patches for various kernel versions hanging out on the OpenIPMI homepage, iykyk.

The modules you need are different for 2.4 vs 2.6 kernels β€” do not mix and match, bestie. On a 2.4-based kernel, these modules must be loaded for ipmitool to work:

  • ipmi_msghandler β€” the incoming and outgoing message handler for IPMI interfaces.
  • ipmi_kcs_drv β€” an IPMI Keyboard Controller Style (KCS) interface driver for the message handler.
  • ipmi_devintf β€” the Linux character device interface for the message handler.

On a 2.6-based kernel, load these instead:

  • ipmi_msghandler β€” incoming and outgoing message handler for IPMI interfaces.
  • ipmi_si β€” an IPMI system interface driver for the message handler. This one supports a bunch of IPMI system interfaces like KCS, BT, SMIC, and even SMBus in 2.6 kernels. iconic tbh.
  • ipmi_devintf β€” the Linux character device interface for the message handler.

Once the required modules are loaded, there's a dynamic character device entry that must exist at /dev/ipmi0. On systems using devfs or udev, it'll show up at /dev/ipmi/0 instead. ✨

To create the device node, first figure out what dynamic major number the kernel assigned β€” peek in /proc/devices and look for the ipmidev entry. Usually, if this is the first dynamic device, the major number is 254, and the minor number for the first system interface is 0, so you'd create the device entry with:

mknod /dev/ipmi0 c 254 0

ipmitool also ships some sample initialization scripts that can do this task for you automatically at start-up, so you don't have to rawdog it manually 🫢

And to make ipmitool actually use the OpenIPMI device interface, just say so on the command line:

> ipmitool -I open <command>

🌸 BMC INTERFACE 🌸

The bmc interface uses the bmc device driver as provided by Solaris 10 and higher. To force ipmitool to use this interface, specify it on the command line:

> ipmitool -I bmc <command>

These files are associated with the bmc driver β€” know them, love them:

  • /platform/i86pc/kernel/drv/bmc β€” 32-bit ELF kernel module for the bmc driver.
  • /platform/i86pc/kernel/drv/amd64/bmc β€” 64-bit ELF kernel module for the bmc driver.
  • /dev/bmc β€” character device node used to communicate with the bmc driver.

πŸ¦‹ LIPMI INTERFACE πŸ¦‹

The lipmi interface uses the Solaris 9 IPMI kernel device driver. Heads up though: it has been superceeded by the bmc interface on Solaris 10. (Yeah, "superceeded" β€” that's how the page spells it, and I refuse to gaslight the manpage.) You can tell ipmitool to use this interface by specifying it on the command line:

> ipmitool -I lipmi <expression>

πŸŽ€ LAN INTERFACE πŸŽ€

The lan interface talks to the BMC over an Ethernet LAN connection using UDP under IPv4. The UDP datagrams are formatted to contain IPMI request/response messages with IPMI session headers and RMCP headers. Very layered, very demure.

IPMI-over-LAN uses version 1 of the Remote Management Control Protocol (RMCP) to support pre-OS and OS-absent management. RMCP is a request-response protocol delivered using UDP datagrams to port 623.

The LAN interface is an authentication multi-session connection β€” messages delivered to the BMC can (and should) be authenticated with a challenge/response protocol using either straight password/key or the MD5 message-digest algorithm. ipmitool will attempt to connect with administrator privilege level, because that's required to perform chassis power functions. main character privilege level fr fr πŸ‘‘

You can tell ipmitool to use the lan interface with the -I lan option:

> ipmitool -I lan -H <hostname> [-U <username>] [-P <password>] <command>

A hostname must be given on the command line to use the lan interface with ipmitool. The password field is optional; if you don't provide a password on the command line, ipmitool will attempt to connect without authentication. If you do specify a password, it'll use MD5 authentication if the BMC supports it, and straight password/key otherwise β€” unless you override that with a command line option.


🧚 LANPLUS INTERFACE 🧚

Like the lan interface, the lanplus interface communicates with the BMC over an Ethernet LAN connection using UDP under IPv4. The difference is that lanplus uses the RMCP+ protocol as described in the IPMI v2.0 specification. RMCP+ allows for improved authentication and data integrity checks, plus encryption and the ability to carry multiple types of payloads. Generic Serial Over LAN support requires RMCP+, so the ipmitool sol activate command requires the use of the lanplus interface. No shortcuts, bestie πŸ’…

RMCP+ session establishment uses a symmetric challenge-response protocol called RAKP (Remote Authenticated Key-Exchange Protocol), which allows the negotiation of many options. ipmitool does not yet allow the user to specify the value of every option, defaulting to the most obvious settings marked as required in the v2.0 specification. Authentication and integrity HMACS are produced with SHA1, and encryption is performed with AES-CBC-128. Role-level logins are not yet supported.

⚠️ ipmitool must be linked with the OpenSSL library in order to perform the encryption functions and support the lanplus interface. If the required packages aren't found, it will not be compiled in and supported. So if lanplus is ghosting you, that's why 😭

You can tell ipmitool to use the lanplus interface with the -I lanplus option:

> ipmitool -I lanplus -H <hostname> [-U <username>] [-P <password>] <command>

A hostname must be given on the command line in order to use the lan interface with ipmitool. With the exception of the -A and -C options, the rest of the command line options are identical to those available for the lan interface.

The -C option lets you specify the authentication, integrity, and encryption algorithms to use for a lanplus session, based on the cipher suite ID found in the IPMIv2.0 specification in table 22-20. The default cipher suite is 17, which specifies RAKP-HMAC-SHA256 authentication, HMAC-SHA256-128 integrity, and AES-CBC-128 encryption algorightms. (Again β€” "algorightms" is the original's spelling, we're keeping it, don't come for me πŸ™ˆ)


⭐ FREE INTERFACE ⭐

The free interface utilizes the FreeIPMI libfreeipmi drivers. You can tell ipmitool to use the FreeIPMI interface with the -I option:

> ipmitool -I free <command>

πŸ’œ IMB INTERFACE πŸ’œ

The imb interface supports the Intel IMB (Intel Inter-module Bus) Interface through the /dev/imb device. You can tell ipmitool to use the IMB interface with the -I option:

> ipmitool -I imb <command>

✨ EXAMPLES ✨

Example 1: Listing remote sensors

> ipmitool -I lan -H 1.2.3.4 -f passfile sdr list
Baseboard 1.25V  | 1.24 Volts        | ok
Baseboard 2.5V   | 2.49 Volts        | ok
Baseboard 3.3V   | 3.32 Volts        | ok

Example 2: Displaying status of a remote sensor

> ipmitool -I lan -H 1.2.3.4 -f passfile sensor get "Baseboard 1.25V"
Locating sensor record...
Sensor ID              : Baseboard 1.25V (0x10)
Sensor Type (Analog)   : Voltage
Sensor Reading         : 1.245 (+/- 0.039) Volts
Status                 : ok
Lower Non-Recoverable  : na
Lower Critical         : 1.078
Lower Non-Critical     : 1.107
Upper Non-Critical     : 1.382
Upper Critical         : 1.431
Upper Non-Recoverable  : na

Example 3: Displaying the power status of a remote chassis

> ipmitool -I lan -H 1.2.3.4 -f passfile chassis power status
Chassis Power is on

Example 4: Controlling the power on a remote chassis

> ipmitool -I lan -H 1.2.3.4 -f passfile chassis power on
Chassis Power Control: Up/On

πŸ“ FILES πŸ“

  • /usr/share/misc/enterprise-numbers β€” system IANA PEN registry taken from http://www.iana.org/assignments/enterprise-numbers
  • ~/.local/usr/share/misc/enterprise-numbers β€” user's override for the system IANA PEN registry; this file, if it exists, is loaded instead of the system registry (see above). Sneaky little override, love that for you πŸ’…

πŸ‘‘ AUTHORS πŸ‘‘

Originally written by Duncan Laurie <duncan@iceblink.org>.

Numerous contributors over time. (So many. A whole crowd. Respect 🫢)


πŸ’€ BUGS πŸ’€

Any bugs found in ipmitool please report via the GitHub issue system at https://github.com/ipmitool/ipmitool/issues. Don't suffer in silence, bestie β€” file the issue.


πŸ¦‹ SEE ALSO πŸ¦‹


That's the whole page, bestie, you made it to the end πŸŽ‰ Huge shoutout to Duncan Laurie, who wrote the original, and to the untold contributors over time β€” this is ipmitool(1), and it ate. Now go power-cycle a chassis responsibly. πŸ’–βœ¨πŸŽ€