IPMI-SENSORS(8)

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

💖 ipmi-sensors(8) — System Commands 💖

okay so real talk, bestie: this is the manual page for ipmi-sensors, from the System Commands section of the manual. it's a lot. but it's a good lot. grab a matcha, we're doing this. 🍵✨

✨ NAME ✨

ipmi-sensors — literally just shows you IPMI sensor info. that's the whole vibe. 👑

🦋 SYNOPSIS 🦋

ipmi-sensors [OPTION...]

🌸 DESCRIPTION 🌸

okay so here's what she does 💅 — Ipmi-sensors displays the current readings of sensors and the sensor data repository (SDR) information. by default you get, for each sensor: the record id, the sensor name, the sensor type name, the sensor reading (if that even applies), and the current sensor event. iconic baseline behavior.

want more tea? there are verbose options listed further down that give you more deets. go off.

big important thing tho 🫶: Ipmi-sensors does not tell you when something's wrong with a particular sensor, because sensor readings and events are not analyzed by default. like, she's just the messenger. if you want analysis, you probably want the --output-sensor-state option, which outputs the analyzed sensor state. 🙈

some sensors might show a sensor reading or sensor event of "N/A" if that info just isn't available. that's giving "not enabled" or "not owned by a BMC" — very normal, no cap. if you're dealing with sensors not owned by a BMC, peep the --bridge-sensors option below.

sensors may output a sensor event of "Unknown" if the sensor reading can't be read — that's typical of a sensor that's busy, or a reading that literally cannot be calculated. 😭

if sensors report "Unrecognized State", that's a hint of an unknown sensor type, typically an OEM sensor. if the sensor OEM interpretation is available, the --interpret-oem-data option may be able to report the appropriate sensor state. slay.

also! sensors need not always report a sensor event. when a sensor event isn't present, "OK" is typically reported. 🎀

listed below are general IPMI options, tool specific options, trouble shooting information, workaround information, examples, and known issues. for a general intro to FreeIPMI please see freeipmi(7). to perform IPMI sensor configuration, please see ipmi-config(8). to perform some advanced SDR management, please see bmc-device(8). 🔥

⭐ GENERAL OPTIONS ⭐

these are the general options for configuring IPMI communication and executing general tool commands. yes there are many. no we're not skipping any. 💜

  • -D IPMIDRIVER, --driver-type=IPMIDRIVER — specifies the driver type to use instead of doing an auto selection. the currently available outofband drivers are LAN and LAN_2_0, which perform IPMI 1.5 and IPMI 2.0 respectively. the currently available inband drivers are KCS, SSIF, OPENIPMI, SUNBMC, and INTELDCMI.
  • --disable-auto-probe — do not probe in-band IPMI devices for default settings. hands off, she said. ✋
  • --driver-address=DRIVER-ADDRESS — specify the in-band driver address to be used instead of the probed value. DRIVER-ADDRESS should be prefixed with "0x" for a hex value and '0' for an octal value.
  • --driver-device=DEVICE — specify the in-band driver device path to be used instead of the probed path.
  • --register-spacing=REGISTER-SPACING — specify the in-band driver register spacing instead of the probed value. argument is in bytes (i.e. 32bit register spacing = 4).
  • --target-channel-number=CHANNEL-NUMBER — specify the in-band driver target channel number to send IPMI requests to.
  • --target-slave-address=SLAVE-ADDRESS — specify the in-band driver target slave number to send IPMI requests to.
  • -h IPMIHOST1,IPMIHOST2,...,, --hostname=IPMIHOST1[:PORT],IPMIHOST2[:PORT],... — specify the remote host(s) to communicate with. multiple hostnames may be separated by comma or may be specified in a range format; see HOSTRANGED SUPPORT below. an optional port can be specified with each host, which may be useful in port forwarding or similar situations. if specifying an IPv6 address and port, use the format [ADDRESS]:PORT. 🌐
  • -u USERNAME, --username=USERNAME — specify the username to use when authenticating with the remote host. if not specified, a null (i.e. anonymous) username is assumed. the user must have atleast OPERATOR privileges in order for this tool to operate fully.
  • -p PASSWORD, --password=PASSWORD — specify the password to use when authenticationg with the remote host. if not specified, a null password is assumed. maximum password length is 16 for IPMI 1.5 and 20 for IPMI 2.0. (and yes, the original page really does say "authenticationg" — we stan a typo. 🫶)
  • -P, --password-prompt — prompt for password to avoid possibility of listing it in process lists. very "stop leaking your secrets in ps" of her. 🙈
  • -k K_G, --k-g=K_G — specify 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 the either the string 'abc' or the string '0x616263'.
  • -K, --k-g-prompt — prompt for k-g to avoid possibility of listing it in process lists.
  • --session-timeout=MILLISECONDS — specify the session timeout in milliseconds. defaults to 20000 milliseconds (20 seconds) if not specified.
  • --retransmission-timeout=MILLISECONDS — specify the packet retransmission timeout in milliseconds. defaults to 1000 milliseconds (1 second) if not specified. the retransmission timeout cannot be larger than the session timeout. ⚠️
  • -a AUTHENTICATION-TYPE, --authentication-type=AUTHENTICATION-TYPE — specify the IPMI 1.5 authentication type to use. the currently available authentication types are NONE, STRAIGHT_PASSWORD_KEY, MD2, and MD5. defaults to MD5 if not specified.
  • -I CIPHER-SUITE-ID, --cipher-suite-id=CIPHER-SUITE-ID — specify the IPMI 2.0 cipher suite ID to use. the 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 to use for session setup, the integrity algorithm identifies the algorithm to use for session packet signatures, and the confidentiality algorithm identifies the algorithm to use for payload encryption. defaults to cipher suite ID 3 if not specified. the following cipher suite ids are 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 — specify the privilege level to be used. the currently available privilege levels are USER, OPERATOR, and ADMIN. defaults to OPERATOR if not specified.
  • --config-file=FILE — specify an alternate configuration file.
  • -W WORKAROUNDS, --workaround-flags=WORKAROUNDS — specify workarounds to vendor compliance issues. multiple workarounds can be specified separated by commas. a special command line flag of "none" will indicate no workarounds (may be useful for overriding configured defaults). see WORKAROUNDS below for a list of available workarounds. 🛠️
  • --debug — turn on debugging.
  • -?, --help — output a help list and exit.
  • --usage — output a usage message and exit.
  • -V, --version — output the program version and exit.

more coming, bestie — don't go anywhere 💅

✨ IPMI-SENSORS OPTIONS ✨

Okay bestie, these are the options that are specifically for ipmi-sensors — like, the ones that make this tool do its little dance instead of just being generic IPMI. Buckle up 💅

  • -v, --verbose — Gives you the verbose sensor output ✨ This one spills additional tea about sensors: thresholds, ranges, numbers, and event/reading type codes. It's giving "tell me everything" energy.
  • -vv — Very verbose sensor output, i.e. even more than -v 😭 This one adds info about events, other sensor types, and oem sensors. Yes, it's a whole extra level. No cap.
  • -i, --sdr-info — Shows you the sensor data repository (SDR) information. Like, the SDR's whole vibe check 🫶
  • -q, --quiet-readings — Doesn't output sensor reading values by default. Lowkey iconic if you wanna use hostranged output across a cluster and consolidate the output — this is the option for that exact situation.
  • -r RECORD-IDS-LIST, --record-ids=RECORD-IDS-LIST — Pick which sensors to show by record id. Multiple record ids get separated by commas or spaces. Heads up: if you specify both --record-ids and --sensor-types, then --record-ids takes precedence 👑 And there's a special command line record id of "all" which means all record ids should be shown (may be useful for overriding configured defaults).
  • -R RECORD-IDS-LIST, --exclude-record-ids=RECORD-IDS-LIST — The opposite vibe: specify sensors to not show, by record id. Multiple record ids separated by commas or spaces. Special command line record id of "none" means no record ids should be excluded (again, may be useful for overriding configured defaults).
  • -t SENSOR-TYPE-LIST, --sensor-types=SENSOR-TYPE-LIST — Specify sensor types to show outputs for. Multiple types separated by commas or spaces. Same rule as above: if both --record-ids and --sensor-types are specified, --record-ids takes precedence. A special command line type of "all" means all types should be shown (may be useful for overriding configured defaults). And you can specify sensor types by string (see --list-sensor-types below) or by number (decimal or hex) 🎀
  • -T SENSOR-TYPE-LIST, --exclude-sensor-types=SENSOR-TYPE-LIST — Specify sensor types to not show outputs for. Multiple types separated by commas or spaces. A special command line type of "none" means no types should be excluded (may be useful for overriding configured defaults). Same deal as the include version: string (see --list-sensor-types below) or number (decimal or hex) 💖
  • -L, --list-sensor-types — Lists sensor types. That's it, that's the whole thing. Simple, clean, ate 💅
  • -b, --bridge-sensors — By default, sensor readings are not attempted for sensors on non-BMC owners. Set this option and sensor requests can be bridged to non-BMC owners to obtain sensor readings. Warning though: bridging may not work on some interfaces/driver types 🙈
  • --shared-sensors — Some sensors share the same sensor data record (SDR). This is typically used for system event log (SEL) entries and not for sensor readings. BUT — some motherboards use this format for multiple active sensors, or the user is just curious to see the permutation of entries shared by a SDR entry. With this option, each sensor number shared by a record gets iterated over and output 🌀
  • --interpret-oem-data — Attempts to interpret OEM data — like event data, sensor readings, or general extra info, etc. If no OEM interpretation is available, the default output gets generated instead. And fr fr, the correctness of OEM interpretations cannot be guaranteed, because OEM vendors may change products, firmware, etc. See OEM INTERPRETATION below for confirmed supported motherboard interpretations.
  • --ignore-not-available-sensors — Ignores not-available (i.e. N/A) sensors in output. Bye bye, N/A noise 👋
  • --ignore-unrecognized-events — Ignores unrecognized sensor events 😌 This suppresses output of unrecognized events, which are typically shown as 'Unrecognized Event = XXXXh' in the output. Bonus: unrecognized events will also be ignored when calculating sensor state with --output-sensor-state below.
  • --output-event-bitmask — Outputs the event bitmask value instead of the string representation. Numbers girlies rise 🔥
  • --output-sensor-state — Outputs sensor state in the output. This adds an additional output reporting whether a sensor is in a NOMINAL, WARNING, or CRITICAL state. The sensor state is an interpreted value based on the current sensor event, and those interpretations are determined by the configuration file /etc/freeipmi//freeipmi_interpret_sensor.conf (yes that's the exact path, double slash and all, don't come for me 💀). See freeipmi_interpret_sensor.conf(5) for more info. This option gives identical output to the sensor state previously output by ipmimonitoring(8) — glow-up but make it backwards compatible ✨
  • --sensor-state-config-file=FILE — Specify an alternate sensor state configuration file. This option is ignored if --output-sensor-state isn't specified. Simple as that 🎀
  • --entity-sensor-names — Outputs sensor names prefixed with their entity id and instance number when appropriate. This can be necessary on some motherboards to help identify what sensors are referencing — like, a motherboard might have multiple sensors all named 'TEMP', and the entity id + instance number help clarify which sensor refers to "Processor 1" vs. "Processor 2". Main character energy for disambiguation 👑
  • --output-sensor-thresholds — Outputs sensor thresholds in the output. This adds columns to the default output for: lower non-recoverable, lower critical, lower non-critical, upper non-critical, upper critical, and upper non-recoverable thresholds. Six whole columns, she's thorough 💖
  • --no-sensor-type-output — Don't show sensor type output for each entry. On many systems the sensor type is redundant to the name of the sensor — especially true if --entity-sensor-names is specified. So if the sensor name is sufficient, or you just don't care about sensor type, use this to condense that output 🫶
  • --comma-separated-output — Outputs fields in comma separated format. CSV girlies, this is your moment 🍓
  • --no-header-output — Don't output column headers. May be useful in scripting 🤖
  • --non-abbreviated-units — Outputs non-abbreviated units (e.g. 'Amps' instead of 'A'). May aid in disambiguation of units (e.g. 'C' for Celsius or Coulombs) — because context matters, bestie 😭
  • --legacy-output — Outputs in legacy format. Newer options may not be applicable to legacy output. Old school, but make it cute 💜
  • --ipmimonitoring-legacy-output — Outputs in the legacy format of the legacy ipmimonitoring tool. Newer options may not be applicable to legacy output. Yes, legacy of legacy. She's vintage 🎀

🌸 SDR CACHE OPTIONS 🌸

So here's the thing — this tool requires access to the sensor data repository (SDR) cache for general operation. By default, SDR data gets downloaded and cached on the local machine. These options are all about that cache 💾✨

  • --flush-cache — Flushes a cached version of the sensor data repository (SDR) cache. The SDR is typically cached for faster subsequent access, but it may need to be flushed and re-generated if the SDR has been updated on a system. Basically: out with the old 🧹
  • --quiet-cache — Don't output information about cache creation/deletion. May be useful in scripting 🤫
  • --sdr-cache-recreate — If the SDR cache is out of date or invalid, automatically recreate the sensor data repository (SDR) cache. May be useful for scripting purposes 🔁
  • --sdr-cache-file=FILE — Specify a specific sensor data repository (SDR) cache file to be stored or read from. Careful though: if this option is used when multiple hosts are specified, the same SDR cache file will be used for all hosts 😳
  • --sdr-cache-directory=DIRECTORY — Specify an alternate directory for sensor data repository (SDR) caches to be stored or read from. Defaults to the home directory if not specified 🏠

⏰ TIME OPTIONS ⏰

Okay so by IPMI definition, all IPMI times and timestamps are stored in localtime. BUT — plot twist — in many situations the timestamps will not actually be stored in localtime 😭 Whether or not a system truly stored the timestamps in localtime varies on many factors, like the vendor, BIOS, and operating system. So these options let you adjust how the stored timestamps are interpreted and how they should be output. Time zone chaos, but make it manageable 💅

  • --utc-to-localtime — Assume all times are reported in UTC time, and convert the time to localtime before being output 🌍➡️🏠
  • --localtime-to-utc — Convert all localtime timestamps to UTC before being output 🏠➡️🌍
  • --utc-offset=SECONDS — Specify a specific UTC offset in seconds to be added to timestamps. Value can range from -86400 to 86400 seconds. Defaults to 0 ⏱️

🌸 HOSTRANGED OPTIONS 🌸

okay so these are the options that mess with hostranged output, bestie. if you want the full tea on hostranges, scroll down to HOSTRANGED SUPPORT, iykyk 💅

  • -B, --buffer-output — this one buffers the hostranged output. fr, for each node it holds onto standard output until that node finishes its whole IPMI operation. so heads up 👀: if you use this, the data might look like it's coming out slower, because like... the entire IPMI operation has to complete before literally anything can be output. slay but slow 🐢. see HOSTRANGED SUPPORT below for more deets.
  • -C, --consolidate-output — consolidates the hostranged output, periodt. the complete standard output from every node you specified gets smushed together so nodes with identical output don't get printed twice (no one needs that dupe energy 💀). a header will list the nodes that have the consolidated output. but bestie, warning: when you use this, no output can be seen until the IPMI operations to ALL the nodes have completed. and if you break out of the program early, all the currently consolidated output gets dumped. see HOSTRANGED SUPPORT below for more.
  • -F NUM, --fanout=NUM — sets the multiple host fanout. there's a "sliding window" (aka fanout) algorithm used for parallel IPMI communication, so slower nodes or timed-out nodes don't block the parallel vibes ✨. the maximum number of threads available at the same time is limited by the fanout. the default is 64. iconic default ngl.
  • -E, --eliminate — eliminates hosts that ipmidetect determined as undetected. this is literally trying to fix the super common issue of hostranged execution timing out because several nodes got removed from service in a big cluster. important 🙈: the ipmidetectd daemon must be running on the node executing the command.
  • --always-prefix — always prefixes the output, even if there's only one host specified or you're communicating in-band. this one is mainly useful for scripting purposes 🫶. heads up tho: this option will be ignored if you specify it with the -C option.

🦋 HOSTRANGED SUPPORT 🦋

so you can input multiple hosts 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. ⭐

bestie pls don't confuse the range form with regular expression character classes (which also use []). for example, foo[19] does not represent foo1 or foo9 — it represents a degenerate range: foo19. 💀 yeah.

this range syntax is literally just a convenience for 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]. it's giving options, because you have options 💅

some examples of range usage, since we love a demo:

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 as a lil 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. protect your ranges, bestie 🎀

when you specify multiple hosts, a thread gets executed for each host in parallel up to the configured fanout (which you can adjust via the -F option). this lets communication to large numbers of nodes happen way more quickly than if it were done in serial. ate and left no crumbs 🔥

by default, standard output from each node specified gets output with the hostname prepended to each line. and like, this output is readable in many situations, but it may be hard to read in others 😭 — for example, output from multiple nodes may get mixed together. the -B and -C options can be used to change this default. pick your fighter 💖

in-band IPMI communication will be used when the host "localhost" is specified. this lets you add the localhost into the hostranged output. cute 🌸

🧚 GENERAL TROUBLESHOOTING 🧚

most often, IPMI problems are due to configuration problems. it's always the config, smh 😭

IPMI over LAN problems involve a misconfiguration of the remote machine's BMC. double-check that 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 that 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. run that vibe check bestie ✨

inband IPMI problems are typically caused by improperly configured drivers or non-standard BMCs. classic 🙈

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. they're lovely fr fr 💌

  • "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 one occurred. it's giving mystery 🕵️‍♀️
  • "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 you authenticated with. please try to authenticate with a higher privilege. this may require authenticating to a different user which has a higher maximum privilege. level up, bestie 👑
  • "privilege level cannot be obtained for this user" — the privilege level you're 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. throwback era 💀
  • "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 🐢
  • "device not found" — the specified device could not be found. please check configuration or inputs and try again.
  • "driver timeout" — communication with the driver or device has timed out. please try again.
  • "message timeout" — communication with the driver or device has timed out. please try again.
  • "BMC busy" — the BMC is currently busy. it may be processing information or have too many simultaneous sessions to manage. please wait and try again. she's booked and busy 💅
  • "could not find inband device" — an inband device could not be found. please check configuration or specify a specific device or driver on the command line.
  • "driver timeout" — the inband driver has timed out communicating to the local BMC or service processor. the BMC or service processor may be busy or (worst case) possibly non-functioning 😬
  • "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. they wanna know fr 🙏
  • "sensor config file parse error" — a parse error was found in the sensor interpretation configuration file. please see freeipmi_interpret_sensor.conf(5).

💜 WORKAROUNDS 💜

with so many different vendors implementing their own IPMI solutions, different vendors may implement their IPMI protocols incorrectly. the following describes a number of workarounds currently available to handle discovered compliance issues. when possible, workarounds have been implemented so they'll be transparent to you (the main character ✨). however, some will require you to specify a workaround be used via the -W option.

the hardware listed below may only indicate the hardware that a problem was discovered on. newer versions of hardware may fix the problems indicated below. similar machines from vendors may or may not exhibit the same problems. and plot twist 🌀: different vendors may license their firmware from the same IPMI firmware developer, so it may be worthwhile to try workarounds listed below even if your motherboard is not listed.

if you believe your hardware has an additional compliance issue that needs a workaround to be implemented, please contact the FreeIPMI maintainers on <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>. 🫶

  • assumeio — this workaround flag will assume inband interfaces communicate with system I/O rather than being memory-mapped. this will work around systems that report invalid base addresses. those hitting this issue may see "device not supported" or "could not find inband device" errors. issue observed on HP ProLiant DL145 G1.
  • spinpoll — this workaround flag will inform some inband drivers (most notably the KCS driver) to spin while polling rather than putting the process to sleep. this may significantly improve the wall clock running time of tools, because an operating system scheduler's granularity may be much larger than the time it takes to perform a single IPMI message transaction. however, by spinning, your system may be performing less useful work by not contexting out the tool for a more useful task. it's giving trade-offs, bestie ⚖️

...and here's the rest of the flag tour, bestie 🌸 These are all workaround flags — you pass them via --workaround-flags (comma-separated, remember), and each one is basically a "your BMC is doing something unhinged, let's cope" switch.

  • authcap — skips the early checks for username capabilities, authentication capabilities, and K_g support, and just lets IPMI authentication go through and succeed. It handles a whole pile of situations where the remote system is lying (or just clueless) about its username capabilities, authentication capabilities, or K_g status. If this is your problem you'll be seeing "username invalid", "authentication type unavailable for attempted privilege level", or "k_g invalid" errors. Spotted on Asus P5M2/P5MT-R/RS162-E4/RX4, Intel SR1520ML/X38ML, and Sun Fire 2200/4150/4450 with ELOM.
  • nochecksumcheck — tells FreeIPMI to not check the checksums that come back in IPMI command responses. Handles systems returning invalid checksums because of implementation bugs even though the packet is otherwise fine. ⚠️ Be careful with this one — it removes validation of packet integrity in a bunch of circumstances. That said, it's unlikely to bite you in most situations. Symptoms look like "connection timeout", "session timeout", or "password verification timeout" errors. On IPMI 1.5 connections you might also need the noauthcodecheck workaround alongside it. Spotted on Supermicro X9SCM-iiF, Supermicro X9DRi-F, and Supermicro X9DRFR.
  • idzero — lets the client accept empty session IDs. Handles IPMI sessions that report empty session IDs back to the client — rude. Symptom: "session timeout" errors. Spotted on Tyan S2882 with M3289 BMC.
  • unexpectedauth — lets unexpected non-null authcodes be checked as if they were expected. Handles that thing where packets carry non-null authentication data when they should be null, because per-message authentication is disabled. Symptom: "session timeout" errors. Spotted on Dell PowerEdge 2850, SC1425. Confirmed fixed on newer firmware. 🎉
  • forcepermsg — forces per-message authentication to be used, no matter what the remote system claims is enabled. Handles that cursed setup where the remote advertises per-message authentication as disabled but the protocol actually requires it. Symptom: "session timeout" errors. Spotted on IBM eServer 325.
  • endianseq — flips the endianness of the session sequence numbers so the session can actually keep going. Handles IPMI 1.5 session sequence numbers that came out the wrong endian. Symptom: "session timeout" errors. Spotted on some Sun ILOM 1.0/2.0 (depends on the service processor's endianness).
  • noauthcodecheck — tells FreeIPMI to not check the authentication codes returned in IPMI 1.5 command responses. Handles systems returning invalid authentication codes because of hashing or implementation bugs. ⚠️ Caution here too — it removes an authentication check that verifies packet validity. In most organizations that's unlikely to be a real security issue, but like, it is a check you're turning off. Symptoms: "connection timeout", "session timeout", or "password verification timeout" errors. Spotted on Xyratex FB-H8-SRAY, Intel Windmill, Quanta Winterfell, and Wiwynn Windmill.
  • intel20 — handles a handful of Intel IPMI 2.0 authentication issues: padding of usernames, and password truncation when the authentication algorithm is HMAC-MD5-128. Symptoms: "username invalid", "password invalid", or "k_g invalid" errors. Spotted on Intel SE7520AF2 with Intel Server Management Module (Professional Edition).
  • supermicro20 — handles several Supermicro IPMI 2.0 authentication issues on motherboards with Peppercon IPMI firmware, including dealing with authentication codes of invalid length. Symptom: "password invalid" errors. Spotted on Supermicro H8QME with SIMSO daughter card. Confirmed fixed on newer firmware.
  • sun20 — handles several Sun IPMI 2.0 authentication issues: invalid-lengthed hash keys, improperly hashed keys, and invalid cipher suite records. Symptoms: "password invalid" or "bmc error" errors. Spotted on Sun Fire 4100/4200/4500 with ILOM. This workaround automatically includes the opensesspriv workaround. 🫶
  • opensesspriv — slightly alters FreeIPMI's IPMI 2.0 connection protocol to work around an invalid hashing algorithm on the remote system. Specifically, the privilege level sent during the Open Session stage of an IPMI 2.0 connection gets used for hashing keys, instead of the privilege level sent during the RAKP1 connection stage. Symptoms: "password invalid", "k_g invalid", "bad rmcpplus status code", or "privilege level cannot be obtained for this user" errors. Spotted 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. Automatically triggered along with the sun20 workaround.
  • integritycheckvalue — handles an invalid integrity check value during IPMI 2.0 session establishment when you're using Cipher Suite ID 0. The integrity check value is supposed to be 0 length, but the remote motherboard responds with a non-empty field (iconic of it, honestly). Symptom: "k_g invalid" errors. Spotted on Supermicro X8DTG, Supermicro X8DTU, Intel S5500WBV/Penguin Relion 700, and Intel S2600JF/Appro 512X.
  • assumemaxsdrrecordcount — tells SDR reading to stop after a known maximum number of SDR records have been read. Handles systems with miss-implemented SDR reading functions. Symptom: "SDR record count invalid" errors. Spotted on an unspecified Inspur motherboard.
  • discretereading — lets analog sensor readings (rpm, degrees, etc.) be read even when the event/reading type code for that sensor says it's a discrete sensor (assert vs. deassert). Handles poorly defined — and honestly arguably illegal — SDR records that expect analog readings to be read alongside discrete sensors. Confirmed to work around issues on HP Proliant DL380 G7 and HP ProLiant ML310 G5 motherboards.
  • ignorescanningdisabled — lets sensor readings be read even when the sensor scanning bit says the sensor is disabled. Handles motherboards that incorrectly flag sensors as disabled. 💀 Your board might have this problem if sensors show up as "N/A" even though they should totally be available. Confirmed to work around issues on Dell Poweredge 2900, Dell Poweredge 2950, Dell Poweredge R410, Dell Poweredge R610, and HP Integrity rx3600 motherboards.
  • assumebmcowner — lets sensor readings be read when the sensor owner is the BMC but the reported sensor owner says it isn't. Normally, sensors owned by a non-BMC sensor owner have to be bridged (like, with the --bridge-sensors option), but if that non-BMC sensor owner is invalid, bridging just fails. This option handles boards that incorrectly report a non-BMC sensor owner by always assuming the owner is the BMC. Again, your board may have this problem if sensors are listed as "N/A" when they should be available. Confirmed to work around issues on Fujitsu RX300 and Fujitsu RX300S2 motherboards.
  • altbridging — attempts alternate bridging logic that doesn't work on some motherboards. Your board may have this problem if --bridge-sensors doesn't work and sensors are listed as "N/A" even though they should be available. Confirmed to work around issues on Lenovo SR650 v3 motherboards and Lenovo ThinkSystem servers.
  • ignoreauthcode — lets sensor readings be read when the remote machine is invalidly calculating authentication codes (i.e. authentication hashes) while communicating over LAN. Your system may have this problem if you get "session timeout" errors or it just kinda... appears to hang. ⚠️ Caution, bestie: this removes an authentication check that verifies packet validity. In most organizations it's unlikely to be a security issue, but still. The ignoring of authentication packets is only limited to the period in which sensor readings are done — not any portion of the session authentication or session teardown. Confirmed to work on Inventec 5441/Dell Xanadu II and Inventec 5442/Dell Xanadu III. (Note: on those systems, this issue has only been observed when --bridge-sensors is used.)
  • No IPMI 1.5 Support — some motherboards that support IPMI 2.0 turn out to not support IPMI 1.5 at all. Symptoms: "ipmi 2.0 unavailable" or "connection timeout" errors. Workaround is just to use IPMI 2.0 instead of IPMI 1.5 by specifying --driver-type=LAN_2_0. Spotted on a number of HP and Supermicro motherboards.

🦋 OEM INTERPRETATION 🦋

These motherboards are confirmed to have at least some support from the --interpret-oem-data option. It's highly probable the OEM data interpretations would work across other motherboards from the same manufacturer, but like, no guarantees, okay? 🙈 Also some of the boards below might be rebranded by vendors/distributors.

  • Dell Poweredge R210
  • Dell Poweredge R610
  • Dell Poweredge R710
  • Dell Poweredge R720
  • Fujitsu iRMC S1 and iRMC S2 systems
  • HP Proliant DL160 G8
  • Intel S5500WB/Penguin Computing Relion 700
  • Intel S2600JF/Appro 512X
  • Intel S2600GZ
  • Intel S2600WP
  • Intel S5000PAL
  • Intel Windmill
  • Quanta Winterfell
  • Supermicro X7DBR-3
  • Supermicro X7DB8
  • Supermicro X8DTN
  • Supermicro X7SBI-LN4
  • Supermicro X8DTH
  • Supermicro X8DTG
  • Supermicro X8DTU
  • Supermicro X8DT3-LN4F
  • Supermicro X8DTU-6+
  • Supermicro X8DTL
  • Supermicro X8DTL-3F
  • Supermicro X8SIL-F
  • Supermicro X9SCL
  • Supermicro X9SCM
  • Supermicro X8DTN+-F
  • Supermicro X8SIE
  • Supermicro X9SCA-F-O
  • Supermicro H8DGU-F
  • Supermicro X9DRi-F
  • Supermicro X9DRI-LN4F+
  • Supermicro X9SPU-F-O
  • Supermicro X9SCM-iiF
  • Wiwynn Windmill
  • Wistron/Dell Poweredge C6220

🌸 EXAMPLES 🌸

okay bestie, here's where it gets fun — actual things you can type 💅 every single one of these is a real move, no cap:

# ipmi-sensors

Show all sensors and readings on the local machine. the classic. the icon. ✨

# ipmi-sensors --verbose

Show verbose sensors and readings on the local machine. more words, more lore 🫶

# ipmi-sensors --record-ids="7,11,102"

Show sensor record ids 7, 11, and 102 on the local machine. yes, you can just pick them like that 🎀

# ipmi-sensors --sensor-types=fan

Show all sensors of type fan on the local machine. keeping it cool fr fr 🦋

# ipmi-sensors -h ahost -u myusername -p mypassword

Show all sensors on a remote machine using IPMI over LAN. long distance relationship with your server, slay 💖

# ipmi-sensors -h mycluster[0-127] -u myusername -p mypassword

Show all sensors across a cluster using IPMI over LAN. a whole cluster. main character energy 👑

💀 DIAGNOSTICS 💀

Upon successful execution, exit status is 0. On error, exit status is 1. that's it, that's the vibe check ✨

If multiple hosts are specified for communication, the exit status is 0 if and only if all targets successfully execute. Otherwise the exit status is 1. so like… everyone has to show up to the group chat or it's a fail, sorry 😭

🙈 KNOWN ISSUES 🙈

On older operating systems, if you input your username, password, and other potentially security relevant information on the command line, this information may be discovered by other users when using tools like the ps(1) command or looking in the /proc file system. and no, that's not a cute surprise, that's a privacy leak bestie 😭 It is 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. do that instead, please, i'm begging 🫶

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 in order to this temporary "lock up" to pass before you may authenticate again. so if you're locked out… it's not broken, it's just being dramatic and you gotta wait it out 💅

Some sensors may be output as not available (i.e. N/A) because the owner of the sensor is not the BMC. To attempt to bridge sensors and access sensors not on the BMC, users may wish to try the -b or --bridge-sensors options. that's your little bridge to the other side, iykyk 🌈

🐛 REPORTING BUGS 🐛

Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>. tell them everything, they wanna know 🫶

Copyright © 2003-2015 FreeIPMI Core Team.

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. legal stuff but make it iconic ⭐

🦋 SEE ALSO 🦋

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

go read those too, they're literally the whole extended universe 💜

and that's the whole page, bestie!! 🎀 this little masterpiece is IPMI Sensors version 1.6.20, dated 2026-10-05, and it lives at IPMI-SENSORS(8) in the manpage ecosystem 🌸 now go run some sensors, you absolute icon 💅✨

📦 where this page comes from