ipmipower(8)

📦
version 1.6.20 · 14 versions
, in arch rolling, centos-stream 10, centos-stream 9

🎀 NAME

ok so this is ipmipower(8) from the System Commands section — it's the IPMI power control utility, and honestly it's about to become your new bestie for remote power stuff ✨

✨ SYNOPSIS

ipmipower [OPTION...]

💅 DESCRIPTION

Ipmipower lets you remotely power on, power off, cycle, hard reset, grab a power status query, fire off a pulse diagnostic interrupt, or kick off a soft-shutdown of the OS via ACPI — all through the IPMI over LAN protocol 🦋

So here's the vibe: if you put a power command (--on, --off, --cycle, --reset, --stat, --pulse, or --soft) on the command line, Ipmipower runs that power command on every hostname you listed on the command line, and then it dips out and exits 💨

But if you don't give it any power commands, ipmipower goes into interactive mode instead — which is basically a little command line interface where you type commands yourself. The deets of that interactive CLI live down in INTERACTIVE COMMANDS below, iykyk 👀

Down below you'll also find general IPMI options, tool specific options, troubleshooting info, workaround info, examples, and known issues. And if you want a general intro to FreeIPMI, go peek at freeipmi(7) 🫶

🔥 GENERAL OPTIONS

these are the general options for setting up IPMI communication and running the general tool commands 🌸

  • -D IPMIDRIVER, --driver-type=IPMIDRIVER — tells it which driver type to use instead of letting it auto-select. The out-of-band drivers available rn are LAN and LAN_2_0, which do IPMI 1.5 and IPMI 2.0 respectively 💫
  • -h IPMIHOST1,IPMIHOST2,...,, --hostname=IPMIHOST1[:PORT],IPMIHOST2[:PORT],... — specify the remote host(s) to talk to. Multiple hostnames can be separated by commas, or you can use a range format; check out HOSTRANGED SUPPORT below bestie. Each host can take an optional port too, which is lowkey useful for port forwarding and similar situations. And if you're giving an IPv6 address plus a port, use the format [ADDRESS]:PORT 👑
  • -u USERNAME, --username=USERNAME — the username to use when authenticating with the remote host. If you don't specify one, a null (i.e. anonymous) username is assumed. Heads up: the user needs at least OPERATOR privileges to run the --on, --off, --reset, --cycle, --pulse, or --soft power control commands. And they need at least USER privileges to determine the machine's power status through --stat 🌈
  • -p PASSWORD, --password=PASSWORD — the password to use when authenticating with the remote host. If you don't give one, a null password is assumed. Maximum password length is 16 for IPMI 1.5 and 20 for IPMI 2.0 🔐
  • -P, --password-prompt — prompts you for the password so it doesn't end up listed in process lists (no snooping, periodt) 🙈
  • -k K_G, --k-g=K_G — the K_g BMC key to use when authenticating with the remote host for IPMI 2.0. If not specified, a null key is assumed. To input the key in hexadecimal form, prefix the string with '0x'. E.g., the key 'abc' can be entered with either the string 'abc' or the string '0x616263' 🧚
  • -K, --k-g-prompt — prompts for k-g so it doesn't show up in process lists either 💜
  • --session-timeout=MILLISECONDS — the session timeout in milliseconds. Defaults to 20000 milliseconds (20 seconds) if you don't specify it ⏳
  • --retransmission-timeout=MILLISECONDS — the packet retransmission timeout in milliseconds. Defaults to 400 milliseconds (0.4 seconds) if you don't specify it 🔁
  • -a AUTHENTICATION-TYPE, --authentication-type=AUTHENTICATION-TYPE — the IPMI 1.5 authentication type to use. Available authentication types rn are NONE, STRAIGHT_PASSWORD_KEY, MD2, and MD5. Defaults to MD5 if not specified ✨
  • -I CIPHER-SUITE-ID, --cipher-suite-id=CIPHER-SUITE-ID — the IPMI 2.0 cipher suite ID to use. A Cipher Suite ID identifies a set of authentication, integrity, and confidentiality algorithms to use for IPMI 2.0 communication: the authentication algorithm identifies the algorithm used for session setup, the integrity algorithm identifies the algorithm used for session packet signatures, and the confidentiality algorithm identifies the algorithm used for payload encryption. Defaults to cipher suite ID 3 if not specified. These are the cipher suite ids currently supported:
    • 0 - Authentication Algorithm = None; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 1 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 2 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = None
    • 3 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128
    • 6 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 7 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = None
    • 8 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128
    • 11 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = None
    • 12 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = AES-CBC-128
    • 15 - Authentication Algorithm = HMAC-SHA256; Integrity Algorithm = None; Confidentiality Algorithm = None
    • 16 - Authentication Algorithm = HMAC-SHA256; Integrity Algorithm = HMAC_SHA256_128; Confidentiality Algorithm = None
    • 17 - Authentication Algorithm = HMAC-SHA256; Integrity Algorithm = HMAC_SHA256_128; Confidentiality Algorithm = AES-CBC-128
  • -l PRIVILEGE-LEVEL, --privilege-level=PRIVILEGE-LEVEL — the privilege level to use. Currently available privilege levels are USER, OPERATOR, and ADMIN. Defaults to OPERATOR if not specified 👑
  • --config-file=FILE — point it at an alternate configuration file 🗂️
  • -W WORKAROUNDS, --workaround-flags=WORKOROUNDS... ok no, it's --workaround-flags=WORKAROUNDS 😭 — this specifies workarounds for vendor compliance issues. Multiple workarounds can be given separated by commas. There's also a special command line flag of "none", which indicates no workarounds (useful for overriding configured defaults). See WORKAROUNDS below for the list of available workarounds 🛠️
  • --debug — turns on debugging 🐛
  • -?, --help — spits out a help list and exits 💖
  • --usage — spits out a usage message and exits 💫
  • -V, --version — outputs the program version and exits 🎀

👑 IPMIPOWER OPTIONS

these ones are specific to ipmipower, bestie 🌸

  • -n, --on — power on the target hosts 🔌
  • -f, --off — power off the target hosts 💀
  • -c, --cycle — power cycle the target hosts 🔄
  • -r, --reset — reset the target hosts ⚡
  • -s, --stat — get the power status of the target hosts 📊
  • --pulse — send a power diagnostic interrupt to the target hosts 💥
  • --soft — initiate a soft-shutdown of the OS via ACPI 🍓
  • --on-if-off — so the IPMI specification does not require the power cycle or hard reset commands to turn on a machine that's currently powered off 😬 which is a whole thing. This option forces ipmipower to issue a power on command instead of a power cycle or hard reset command if the remote machine's power is currently off ✨
  • --wait-until-on — the IPMI specification allows power on commands to return before the power on actually takes place 👀 this option forces ipmipower to regularly query the remote BMC and only return after the machine has actually powered on ⏳
  • --wait-until-off — same energy: the IPMI specification allows power off commands to return before the power off actually takes place. This option forces ipmipower to regularly query the remote BMC and return only after the machine has actually powered off 💤
  • --oem-power-type=OEM-POWER-TYPE — this tells ipmipower to initiate power control operations via an IPMI OEM specific power control extension. The currently available POWERTYPEs are NONE and C410X. Peep OEM POWER EXTENSIONS below for more info 🧚

🌐 IPMIPOWER ADVANCED NETWORK OPTIONS 💅

okay bestie, these next ones are all about how ipmipower does its little network dance — tuning the retries, the pings, the whole vibe. no cap, this is the section where you make it behave. 🦋

  • --retransmission-wait-timeout=MILLISECONDS — sets the retransmission wait timeout, in milliseconds. it's basically the cousin of the retransmission timeout from earlier, except this one is specifically for power completion verification when you're using --wait-until-on and --wait-until-off. defaults to 500 milliseconds (that's 0.5 seconds, bestie). ✨
  • --retransmission-backoff-count=COUNT — sets the retransmission backoff count for retransmissions. after every COUNT retransmissions, the retransmission timeout length gets increased by another factor. defaults to 8. the way it just keeps backing off… iconic 🌸
  • --ping-interval=MILLISECONDS — sets the ping interval length in milliseconds. when you're running in interactive mode, RMCP (Remote Management Control Protocol) discovery messages get sent to all configured remote hosts every MILLISECONDS to confirm they actually support IPMI. and listen — power commands cannot be sent to a host until it's discovered (or re-discovered, if it was previously lost). defaults to 5000 milliseconds (5 seconds). you can disable ping discovery messages entirely by setting this value to 0. also, RMCP ping discovery messages are automatically disabled in non-interactive mode, so don't stress about it there. 🎀
  • --ping-timeout=MILLISECONDS — sets the ping timeout length in milliseconds. in interactive mode, RMCP (Remote Management Control Protocol) messages discovery gets sent to all configured remote hosts to confirm their IPMI support. a remote host counts as undiscovered if it doesn't respond within MILLISECONDS time. defaults to 30000 milliseconds (30 seconds). heads up tho: the ping interval cannot be larger than the ping timeout. ⚠️
  • --ping-packet-count=COUNT — sets the ping packet count size. defaults to 10. peep the --ping-percent option below for the full tea on how this one actually works. 🍓
  • --ping-percent=PERCENT — sets the ping percent value. defaults to 50. so here's the situation: since IPMI is based on UDP, it's genuinely hard for ipmipower to tell the difference between a missing machine and a bad (or heavily loaded) network connection in interactive mode. like, say a link consistently drops 80% of the packets to a particular machine 😭 — the power control operation may have difficulty completing, even though a recent pong response from RMCP makes ipmipower believe the machine is up and functioning properly. the ping packet count and percent options exist to alleviate exactly this problem. ipmipower monitors RMCP ping packets in packet count chunks, and if it doesn't receive a response to greater than ping percent of those packets, it assumes the link to that node is bad and won't send power control operations to that node until the connection is determined to be reliable. you can disable this heuristic by setting either the ping packet count or the ping percent to 0. also, this feature isn't used if ping interval is set to 0. 🧚
  • --ping-consec-count=COUNT — sets the ping consecutive count. this is another heuristic for deciding whether a node should be considered discovered, undiscovered, or rockin' a bad connection. if a valid RMCP pong response was received for the last COUNT ping packets, the node gets considered discovered, regardless of all the other heuristics listed above. defaults to 5. you can disable this heuristic by setting the value to 0, and this feature isn't used if the other ping features described above are disabled. 💜

🎯 HOSTRANGED OPTIONS 🎯

these next options manipulate hostranged output. peep HOSTRANGED SUPPORT below for the extra info on hostranges, iykyk. 🔥

  • -B, --buffer-output — buffer hostranged output. for each node, standard output gets buffered until that node has completed its IPMI operation. when you specify this option, data may appear to output slower to the user, since the entire IPMI operation must complete before any data can be output. see HOSTRANGED SUPPORT below for more. 🫶
  • -C, --consolidate-output — consolidate hostranged output. the complete standard output from every node specified gets consolidated so that nodes with identical output aren't output twice. a header will list those nodes with the consolidated output. when you specify this option, no output can be seen until the IPMI operations to all nodes have completed — yes, all of them, bestie, be patient 😭. if the user breaks out of the program early, all currently consolidated output will be dumped. see HOSTRANGED SUPPORT below for more. ✨
  • -F NUM, --fanout=NUM — specify the multiple host fanout. it indicates the maximum number of power control operations that can be executed in parallel. look at it multitasking 👑
  • -E, --eliminate — eliminate hosts determined as undetected by ipmidetect. this attempts to remove the common issue of hostranged execution timing out due to several nodes being removed from service in a large cluster. the ipmidetectd daemon must be running on the node executing the command. 🙈
  • --always-prefix — always prefix output, even if only one host is specified or communicating in-band. this option is primarily useful for scripting purposes. it'll be ignored if you specify it with the -C option. 💅

💬 INTERACTIVE COMMANDS 💬

ipmipower gives you the following interactive commands at the ipmipower> prompt. before you can use any power commands (on, off, cycle, reset, stat, pulse, or soft), hostnames have to be configured into ipmipower — either through the command prompt or the hostname command below. the parameters and options to these commands mirror their appropriate command line options. periodt. 🌈

  • hostname [IPMIHOST(s)] — specify a new set of hosts. no input unconfigures all hosts.
  • username [USERNAME] — specify a new username. no input for null username.
  • password [PASSWORD] — specify a new password. no input for null password.
  • k_g [K_G] — specify a new K_g BMC Key. no input for null key. prefix with '0x' to enter a key in hexadecimal.
  • ipmi-version IPMIVERSION — specify the ipmi version to use.
  • session-timeout MILLISECONDS — specify a new session timeout length.
  • retransmission-timeout MILLISECONDS — specify a new retransmiision timeout length. (that spelling is straight from the source, bestie, we don't touch it 💀)
  • authentication-type AUTHENTICATION-TYPE — specify the authentication type to use.
  • cipher-suite-id CIPHER-SUITE-ID — specify the cipher suite id to use.
  • privilege-level PRIVILEGE-LEVEL — specify the privilege level to use.
  • workaround-flags WORKAROUNDS — specify workaround flags.
  • debug [on|off] — toggle debug output.
  • on [IPMIHOST(s)] — turn on all configured hosts or specified hosts.
  • off [IPMIHOST(s)] — turn off all configured hosts or specified hosts.
  • cycle [IPMIHOST(s)] — power cycle all configured hosts or specified hosts.
  • reset [IPMIHOST(s)] — reset all configured hosts or specified hosts.
  • stat [IPMIHOST(s)] — query power status for all configured hosts or specified hosts.
  • pulse [IPMIHOST(s)] — pulse diagnostic interrupt all configured hosts or specified hosts.
  • soft [IPMIHOST(s)] — initiate a soft-shutdown for all configured hosts or specified hosts.
  • identify-on [IPMIHOST(s)] — turn on physical system identification.
  • identify-off [IPMIHOST(s)] — turn off physical system identification.
  • identify-status [IPMIHOST(s)] — query physical system identification status.
  • on-if-off [on|off] — toggle on-if-off functionality.
  • wait-until-on [on|off] — toggle wait-until-on functionality.
  • wait-until-off [on|off] — toggle wait-until-off functionality.
  • retransmission-wait-timeout MILLISECONDS — specify a new retransmission wait timeout length.
  • retransmission-backoff-count COUNT — specify a new retransmission backoff count.
  • ping-interval MILLISECONDS — specify a new ping interval length.
  • ping-timeout MILLISECONDS — specify a new ping timeout length.
  • ping-packet-count COUNT — specify a new ping packet count.
  • ping-percent PERCENT — specify a new ping percent.
  • ping-consec-count COUNT — specify a new ping consec count.
  • buffer-output [on|off] — toggle buffer-output functionality.
  • consolidate-output [on|off] — toggle consolidate-output functionality.
  • fanout COUNT — specify a fanout.
  • always-prefix [on|off] — toggle always-prefix functionality.
  • help — output help menu.
  • version — output version.
  • config — output the current configuration.
  • quit — quit program. goodbye bestie 😭🫶

✨ OEM POWER EXTENSIONS ✨

Okay bestie, so some motherboards out there come with IPMI OEM extensions for alternate power control mechanisms. Like, for example, these power control mechanisms might let you power control a sub-device inside the system instead of the whole entire system itself. Cute, right? 🎀

So if you specify an OEM power type via --oem-power-type on the command line or in freeipmi.conf(5), you can tell ipmipower to run alternate power control implementations over the standard ones. Depending on the OEM extension, some power control commands may literally not be available anymore. Like, an OEM extension might allow on but not cycle. And specific ipmipower options may not function either. Yeah. It's giving "trade-offs." 💅

Some OEM extensions may need extra arguments for their power control action, like a sub-device identifier. You provide those extra arguments by appending a plus sign (+) and the extra info to the end of the hostname. You can do this on the command line or in interactive mode. For example, the hostname mynode+18 would mean the power control operation should be sent to the host mynode, and 18 is the identifier of a possible sub-device to be power controlled. The --consolidate-output option is commonly disabled when using an OEM power control that requires extra arguments.

Because OEM power control may involve subtypes, a user might want to power control multiple sub-devices on the same host. Example: you might specify the hosts mynode+1,mynode+2, meaning power control subdevice 1 and 2 on mynode. And since many BMCs cannot handle multiple IPMI sessions, power control operations to the same host will be serialized internally by ipmipower. No cap. 🔥

The following are the current OEM power types available, along with info on the systems they work with and the power control operations available:

  • C410X — This OEM power type supports power control of PCIe slots on Dell Poweredge C410x systems. It supports on, off, and stat. The PCIe slot number ranges from 1-16 and must always be specified when attempting to power control with this extension. For example, the hostname mynode+2 would inform ipmipower to operate on slot number 2 on mynode. The C410x appears to have difficulty handling new slot power control requests until prior ones have completed. Users may wish to strongly consider using the --wait-until-on and --wait-until-off options if multiple slots will be power controlled in short succession. 🙈
  • NONE — This tells ipmipower that no OEM power type extension is to be used and standard IPMI power control is used. This is the default. 👑

🌈 HOSTRANGED SUPPORT 🌈

(Yes, bestie, this is a different section from HOSTRANGED OPTIONS. Stay with me. 🫶)

Multiple hosts can be input either as an explicit comma separated list of hosts, or as a range of hostnames in the general form: prefix[n-m,l-k,...], where n < m and l < k, etc. Do not confuse the latter form with regular expression character classes (also denoted by []). For example, foo[19] does not represent foo1 or foo9 — it represents a degenerate range: foo19.

This range syntax is meant only as a convenience on clusters with a prefixNN naming convention, and specifying ranges should not be considered necessary — the list foo1,foo9 could be specified as such, or by the range foo[1,9].

Some examples of range usage follow:

foo[01-05] instead of foo01,foo02,foo03,foo04,foo05
foo[7,9-10] instead of foo7,foo9,foo10
foo[0-3] instead of foo0,foo1,foo2,foo3

And a friendly reminder to the reader: some shells will interpret brackets ([ and ]) for pattern matching. Depending on your shell, it may be necessary to enclose ranged lists within quotes. 💀

When multiple hosts are specified by the user, a socket will be created for each host and polled on, effectively allowing communication to all hosts in parallel. This allows communication to large numbers of nodes far more quickly than if done in serial. The -F option can configure the number of nodes that can be communicated with in parallel at the same time. Slay. ⚡

By default, standard output from each node specified will be output with the hostname prepended to each line. Although this output is readable in many situations, it may be difficult to read in other situations — e.g. output from multiple nodes may be mixed together. The -B and -C options can be used to change this default. 🦋

✨ EXAMPLES ✨

Determine the power status of foo[0-2] with null username and password:

ipmipower -h foo[0-2] --stat

Determine the power status of foo[0-2] with non-null username and password:

ipmipower -h foo[0-2] -u foo -p bar --stat

Hard reset nodes foo[0-2] with non-null username and password:

ipmipower -h foo[0-2] -u foo -p bar --reset

Look at that. Iconic. 🎀

💜 GENERAL TROUBLESHOOTING 💜

Most often, IPMI problems are due to configuration problems. Fr fr. 😭

IPMI over LAN problems involve a misconfiguration of the remote machine's BMC. Double check to make sure the following are configured properly in the remote machine's BMC: IP address, MAC address, subnet mask, username, user enablement, user privilege, password, LAN privilege, LAN enablement, and allowed authentication type(s). For IPMI 2.0 connections, double check to make sure the cipher suite privilege(s) and K_g key are configured properly. The ipmi-config(8) tool can be used to check and/or change these configuration settings. Use it. Bestie. 🫶

In addition to the troubleshooting tips below, please see WORKAROUNDS below to also see if there are any vendor specific bugs that have been discovered and worked around.

Listed below are many of the common issues for error messages. For additional support, please e-mail the <freeipmi-users@gnu.org> mailing list. 💌

  • "username invalid" — The username entered (or a NULL username if none was entered) is not available on the remote machine. It may also be possible the remote BMC's username configuration is incorrect.
  • "password invalid" — The password entered (or a NULL password if none was entered) is not correct. It may also be possible the password for the user is not correctly configured on the remote BMC.
  • "password verification timeout" — Password verification has timed out. A "password invalid" error (described above) or a generic "session timeout" (described below) occurred. During this point in the protocol it cannot be differentiated which occurred. Spooky. 👀
  • "k_g invalid" — The K_g key entered (or a NULL K_g key if none was entered) is not correct. It may also be possible the K_g key is not correctly configured on the remote BMC.
  • "privilege level insufficient" — An IPMI command requires a higher user privilege than the one authenticated with. Please try to authenticate with a higher privilege. This may require authenticating to a different user which has a higher maximum privilege.
  • "privilege level cannot be obtained for this user" — The privilege level you are attempting to authenticate with is higher than the maximum allowed for this user. Please try again with a lower privilege. It may also be possible the maximum privilege level allowed for a user is not configured properly on the remote BMC.
  • "authentication type unavailable for attempted privilege level" — The authentication type you wish to authenticate with is not available for this privilege level. Please try again with an alternate authentication type or alternate privilege level. It may also be possible the available authentication types you can authenticate with are not correctly configured on the remote BMC.
  • "cipher suite id unavailable" — The cipher suite id you wish to authenticate with is not available on the remote BMC. Please try again with an alternate cipher suite id. It may also be possible the available cipher suite ids are not correctly configured on the remote BMC.
  • "ipmi 2.0 unavailable" — IPMI 2.0 was not discovered on the remote machine. Please try to use IPMI 1.5 instead.
  • "connection timeout" — Initial IPMI communication failed. A number of potential errors are possible, including an invalid hostname specified, an IPMI IP address cannot be resolved, IPMI is not enabled on the remote server, the network connection is bad, etc. Please verify configuration and connectivity. 🔌
  • "session timeout" — The IPMI session has timed out. Please reconnect. If this error occurs often, you may wish to increase the retransmission timeout. Some remote BMCs are considerably slower than others. 🐢
  • "internal IPMI error" — An IPMI error has occurred that FreeIPMI does not know how to handle. Please e-mail <freeipmi-users@gnu.org> to report the issue.

🔥 IPMIPOWER TROUBLESHOOTING 🔥

So when powering on a powered off machine, the client must have a means by which to resolve the MAC address of the remote machine's ethernet card. While most modern IPMI solutions support the ability to ARP and resolve addresses when the machine is powered off, some older machines do not. This is typically solved in one of two ways:

  1. Enable gratuitous ARPs on the remote machine. The remote machine will send out a gratuitous ARP, which advertises the ethernet IP and MAC address so that other machines on the network this information their local ARP cache. For large clusters, this method is not recommended since gratuitous ARPs can flood the network with unnecessary traffic. 😬
  2. Permanently store the remote machine's MAC address in the local ARP cache. This is the more common approach on large clusters. 👑

Other methods are listed in the IPMI specification.

🌈 WORKAROUNDS 🌈

Okay bestie, real talk: every vendor out here implementing their own IPMI solution means some of them implement their IPMI protocols incorrectly 😭💀. So here's the whole list of workarounds available right now for the compliance issues people have discovered. When it was possible, the workarounds were implemented so they're transparent to you — but some of them you've gotta ask for yourself with the -W option.

The hardware listed below might only be the hardware the problem was discovered on. Newer versions of that hardware may have fixed the problem. Similar machines from the same vendor may or may not have the same problems. And because different vendors may license their firmware from the same IPMI firmware developer, it may be worth trying the workarounds below even if your motherboard isn't listed 👑.

If you think your hardware has an additional compliance issue that needs a workaround implemented, please hit up the FreeIPMI maintainers at <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org> 🫶.

  • authcap — this workaround flag skips the early checks for username capabilities, authentication capabilities, and K_g support, and just lets IPMI authentication succeed. It works around multiple issues where the remote system doesn't properly report username capabilities, authentication capabilities, or K_g status. If you're hitting this you might see "username invalid", "authentication type unavailable for attempted privilege level", or "k_g invalid" errors. Issue observed on Asus P5M2/P5MT-R/RS162-E4/RX4, Intel SR1520ML/X38ML, and Sun Fire 2200/4150/4450 with ELOM.
  • nochecksumcheck — this workaround flag tells FreeIPMI not to check the checksums returned from IPMI command responses. It works around systems that return invalid checksums because of implementation errors even though the packet is otherwise valid. ⚠️ Users are cautioned on the use of this option, because it removes validation of packet integrity in a number of circumstances — though it's unlikely to be an issue in most situations. If you're hitting this you might see "connection timeout", "session timeout", or "password verification timeout" errors. On IPMI 1.5 connections, the "noauthcodecheck" workaround may also be needed too. Issue observed on Supermicro X9SCM-iiF, Supermicro X9DRi-F, and Supermicro X9DRFR.
  • idzero — this workaround flag allows empty session IDs to be accepted by the client. It works around IPMI sessions that report empty session IDs to the client. If you're hitting this you might see "session timeout" errors. Issue observed on Tyan S2882 with M3289 BMC.
  • unexpectedauth — this workaround flag allows unexpected non-null authcodes to be checked as though they were expected. It works around an issue where packets contain non-null authentication data when they should be null because per-message authentication is disabled. If you're hitting this you might see "session timeout" errors. Issue observed on Dell PowerEdge 2850,SC1425. Confirmed fixed on newer firmware.
  • forcepermsg — this workaround flag forces per-message authentication to be used no matter what the remote system advertises. It works around an issue where per-message authentication is advertised as disabled on the remote system, but it's actually required for the protocol. If you're hitting this you might see "session timeout" errors. Issue observed on IBM eServer 325.
  • endianseq — this workaround flag flips the endian of the session sequence numbers so the session can keep going properly. It works around IPMI 1.5 session sequence numbers that are the wrong endian. If you're hitting this you might see "session timeout" errors. Issue observed on some Sun ILOM 1.0/2.0 (depends on service processor endian).
  • noauthcodecheck — this workaround flag tells FreeIPMI not to check the authentication codes returned from IPMI 1.5 command responses. It works around systems that return invalid authentication codes because of hashing or implementation errors. ⚠️ Users are cautioned on the use of this option, because it removes an authentication check that verifies the validity of a packet — though in most organizations, this is unlikely to be a security issue. If you're hitting this you might see "connection timeout", "session timeout", or "password verification timeout" errors. Issue observed on Xyratex FB-H8-SRAY, Intel Windmill, Quanta Winterfell, and Wiwynn Windmill.
  • intel20 — this workaround flag handles several Intel IPMI 2.0 authentication issues. The issues covered include padding of usernames, and password truncation if the authentication algorithm is HMAC-MD5-128. If you're hitting this you might see "username invalid", "password invalid", or "k_g invalid" errors. Issue observed on Intel SE7520AF2 with Intel Server Management Module (Professional Edition).
  • supermicro20 — this workaround flag handles several Supermicro IPMI 2.0 authentication issues on motherboards w/ Peppercon IPMI firmware. The issues covered include handling invalid length authentication codes. If you're hitting this you might see "password invalid" errors. Issue observed on Supermicro H8QME with SIMSO daughter card. Confirmed fixed on newerver firmware.
  • sun20 — this workaround flag works around several Sun IPMI 2.0 authentication issues. The issues covered include invalid lengthed hash keys, improperly hashed keys, and invalid cipher suite records. If you're hitting this you might see "password invalid" or "bmc error" errors. Issue observed on Sun Fire 4100/4200/4500 with ILOM. This workaround automatically includes the "opensesspriv" workaround.
  • opensesspriv — this workaround flag slightly alters FreeIPMI's IPMI 2.0 connection protocol to work around an invalid hashing algorithm used by the remote system. The privilege level sent during the Open Session stage of an IPMI 2.0 connection is used for hashing keys instead of the privilege level sent during the RAKP1 connection stage. If you're hitting this you might see "password invalid", "k_g invalid", "bad rmcpplus status code", or "privilege level cannot be obtained for this user" errors. Issue observed on Sun Fire 4100/4200/4500 with ILOM, Inventec 5441/Dell Xanadu II, Supermicro X8DTH, Supermicro X8DTG, Intel S5500WBV/Penguin Relion 700, Intel S2600JF/Appro 512X, Quanta QSSC-S4R/Appro GB812X-CN, Dell C5220, and the OpenIPMI software BMC. This workaround is automatically triggered with the "sun20" workaround.
  • integritycheckvalue — this workaround flag works around an invalid integrity check value during an IPMI 2.0 session establishment when using Cipher Suite ID 0. The integrity check value should be 0 length, however the remote motherboard responds with a non-empty field. If you're hitting this you might see "k_g invalid" errors. Issue observed on Supermicro X8DTG, Supermicro X8DTU, and Intel S5500WBV/Penguin Relion 700, and Intel S2600JF/Appro 512X.
  • ipmiping — this workaround option tells ipmipower to use IPMI based ping packets instead of RMCP ping packets. Some motherboards have been observed to not implement RMCP ping/pong support despite being required by the IPMI specification. If you're hitting this you might see "not discovered" errors in shell mode. Issue observed on Intel M50FCP, Intel Windmill, Quanta Winterfell, and Wiwynn Windmill.
  • No IPMI 1.5 Support — some motherboards that support IPMI 2.0 have been found to not support IPMI 1.5. If you're hitting this you might see "ipmi 2.0 unavailable" or "connection timeout" errors. This issue can be worked around by using IPMI 2.0 instead of IPMI 1.5 by specifying --driver-type=LAN_2_0. Issue observed on a number of HP and Supermicro motherboards.

🩺 DIAGNOSTICS 🩺

Slay, it worked: on successful execution, exit status is 0. On error, exit status is 1.

If you specified multiple hosts for communication, the exit status is 0 if and only if all targets successfully execute. Otherwise the exit status is 1 😤.

When you're operating in interactive mode, the exit value will be based on the last power operation executed.

💀 KNOWN ISSUES 💀

On older operating systems, if you type your username, password, and other potentially security relevant information on the command line, that info may be discovered by other users when using tools like the ps(1) command or looking in the /proc file system 😬. It's generally more secure to input password information with options like the -P or -K options. Configuring security relevant information in the FreeIPMI configuration file would also be an appropriate way to hide this information.

In order to prevent brute force attacks, some BMCs will temporarily "lock up" after a number of remote authentication errors. You may need to wait awhile for this temporary "lock up" to pass before you may authenticate again 🙈.

IPMI specifications do not require BMCs to perform a power control operation before returning a completion code to the caller. So yeah — it's possible for ipmipower to return power status queries opposite of what you're expecting 🫠. For example, if a "power off" operation is performed, a BMC may return a successful completion code to ipmipower before the "power off" operation is actually performed. Subsequent power status queries may return "on" for several seconds, until the BMC actually performs the "power off" operation.

🐛 REPORTING BUGS 🐛

Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

Copyright (C) 2007-2015 Lawrence Livermore National Security, LLC. Copyright (C) 2003-2007 The Regents of the University of California.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

👀 SEE ALSO 👀

freeipmi.conf(5), freeipmi(7), ipmi-config(8), ipmi-oem(8)

http://www.gnu.org/software/freeipmi/

okay that's the whole page bestie, you're officially an ipmipower girlie now 💅✨ This one's ipmipower 1.6.20, dated 2026-10-05 — go forth and power cycle responsibly, mwah 🎀🦋💜

📦 where this page comes from