IPMI-SENSORS man page on Oracle

Man page or keyword search:  
man Server   33470 pages
apropos Keyword Search (all sections)
Output format
Oracle logo
[printable version]

/* Copyright (C) 1991‐2012 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The	GNU  C	Library is free software; you can redistribute it
and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later ver‐
sion.

   The	GNU  C Library is distributed in the hope that it will be
useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See  the
GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Pub‐
lic
   License along with the GNU C Library; if not, see
   <http://www.gnu.org/licenses/>.  */ /* This header is separate
from features.h so that the compiler can
   include  it	implicitly at the start of every compilation.  It
must
   not itself include <features.h> or any other header	that  in‐
cludes
   <features.h>	 because  the  implicit	 include comes before any
feature
   test macros that may be defined in a	 source	 file  before  it
first
   explicitly  includes	 a  system header.  GCC knows the name of
this
   header in order to preinclude it.  */ /* We do support the IEC
559  math  functionality,  real	 and complex.  */ /* wchar_t uses
ISO/IEC 10646 (2nd ed., published 2011‐03‐15) /
IPMI-SENSORS(8)			System Commands		       IPMI-SENSORS(8)

   Unicode 6.0.	 */ /* We do not support C11 <threads.h>.  */

NAME
       ipmi-sensors - display IPMI sensor information

SYNOPSIS
       ipmi-sensors [OPTION...]

DESCRIPTION
       Ipmi-sensors displays current  readings	of  sensors  and  sensor  data
       repository (SDR) information. The default display outputs each sensor's
       record id, sensor name, sensor type name, sensor reading (if  appropri‐
       ate),  and  the	current	 sensor event. More verbose information can be
       found using the verbose options specified below.	 Ipmi-sensors does not
       inform  the  user  if a problem exists with a particular sensor because
       sensor readings and events are not analyzed by default. Users may  wish
       to  use	the --output-sensor-state option to output the analyzed sensor
       state.  Some sensors may have a sensor reading or sensor event of "N/A"
       if  the information is unavailable. This is typical of a sensor that is
       not enabled or not owned by a BMC. Please see  --bridge-sensors	option
       below  to  deal	with  sensors not owned by a BMC. Sensors may output a
       sensor event of "Unknown" if the sensor reading cannot be read. This is
       typical	of  a  sensor  that is busy or a reading that cannot be calcu‐
       lated. If sensors report "Unrecognized State", it is indicative	of  an
       unkown  sensor  type, typically an OEM sensor. If the sensor OEM inter‐
       pretation is available, the --interpret-oem-data may be able to	report
       the  appropriate	 sensor state. Sensors need not always report a sensor
       event. When a sensor event is not 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 introduction to FreeIPMI please see  freeipmi(7).
       To  perform  IPMI  sensor  configuration,  please see ipmi-sensors-con‐
       fig(8).	To perform some	 advanced  SDR	management,  please  see  bmc-
       device(8).

GENERAL OPTIONS
       The following options are general options for configuring IPMI communi‐
       cation and executing general tool commands.

       -D IPMIDRIVER, --driver-type=IPMIDRIVER
	      Specify the driver type to use instead of doing an  auto	selec‐
	      tion.   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, and
	      SUNBMC.

       --disable-auto-probe
	      Do not probe in-band IPMI devices for default settings.

       --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],IPMI‐
       HOST2[:PORT],...
	      Specify the remote host(s) to communicate with.  Multiple	 host‐
	      names  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.

       -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.

       -P, --password-prompt
	      Prompt  for  password  to	 avoid	possibility  of	 listing it in
	      process lists.

       -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	 time‐
	      out.

       -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 confidential‐
	      ity  algorithms to use for IPMI 2.0 communication. The authenti‐
	      cation 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 work‐
	      arounds 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.

IPMI-SENSORS OPTIONS
       The following options are specific to Ipmi-sensors.

       -v, --verbose
	      Output verbose sensor output. This option will output additional
	      information about sensors such as thresholds,  ranges,  numbers,
	      and event/reading type codes.

       -vv    Output  very verbose sensor output. This option will output more
	      additional information than the verbose option such as  informa‐
	      tion about events, other sensor types, and oem sensors.

       -i, --sdr-info
	      Show sensor data repository (SDR) information

       -q, --quiet-readings
	      Do  not  output sensor reading values by default. This option is
	      particularly useful if you want to use hostranged output	across
	      a cluster and want to consolidate the output.

       -r RECORD-IDS-LIST, --record-ids=RECORD-IDS-LIST
	      Specify sensors to show by record id. Multiple record ids can be
	      separated by commas or spaces. If both --record-ids  and	--sen‐
	      sor-types	 are  specified, --record-ids takes precedence. A spe‐
	      cial command line record id of "all", will indicate  all	record
	      ids  should  be  shown  (may be useful for overriding configured
	      defaults).

       -R RECORD-IDS-LIST, --exclude-record-ids=RECORD-IDS-LIST
	      Specify sensors to not show by record id.	 Multiple  record  ids
	      can  be  separated  by  commas or spaces. A special command line
	      record id of "none", will	 indicate  no  record  ids  should  be
	      excluded (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 can be
	      separated by commas or spaces. If both --record-ids  and	--sen‐
	      sor-types	 are specified, --record-ids takes precedence.	A spe‐
	      cial command line type of "all", will indicate all types	should
	      be  shown	 (may  be  useful for overriding configured defaults).
	      Users may	 specify  sensor  types	 by  string  (see  --list-sen‐
	      sor-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 can
	      be eparated by commas or spaces. A special command line type  of
	      "none", will indicate no types should be excluded (may be useful
	      for overriding configured defaults). Users  may  specify	sensor
	      types  by	 string	 (see  --list-sensor-types below) or by number
	      (decimal or hex).

       -L, --list-sensor-types
	      List sensor types.

       -b, --bridge-sensors
	      By default, sensors readings are not attempted  for  sensors  on
	      non-BMC  owners.	By setting this option, sensor requests can be
	      bridged to non-BMC owners to obtain  sensor  readings.  Bridging
	      may not work on some interfaces/driver types.

       --shared-sensors
	      Some  sensors  share  the same sensor data record (SDR). This is
	      typically utilized for system event log (SEL)  entries  and  not
	      for  sensor readings. However, there may be some motherboards in
	      which this format is utilized for multiple  active  sensors,  or
	      the  user	 simply	 has  interest	in  seeing  the permutation of
	      entries shared by a SDR entry. By setting this option, each sen‐
	      sor number shared by a record will be iterated over and output.

       --interpret-oem-data
	      Attempt  to interpret OEM data, such as event data, sensor read‐
	      ings, or general extra info, etc. If an  OEM  interpretation  is
	      not available, the default output will be generated. Correctness
	      of OEM interpretations cannot be	guaranteed  due	 to  potential
	      changes OEM vendors may make in products, firmware, etc. See OEM
	      INTERPRETATION below for confirmed supported motherboard	inter‐
	      pretations.

       --ignore-not-available-sensors
	      Ignore not-available (i.e. N/A) sensors in output.

       --ignore-unrecognized-events
	      Ignore  unrecognized sensor events. This will suppress output of
	      unrecognized events, typically shown as  'Unrecognized  Event  =
	      XXXXh'  in  output.  In  addition,  unrecognized	events will be
	      ignored when calculating sensor state with --output-sensor-state
	      below.

       --output-event-bitmask
	      Output event bitmask value instead of the string representation.

       --output-sensor-state
	      Output  sensor state in output. This will add an additional out‐
	      put reporting if a sensor is in a NOMINAL, WARNING, or  CRITICAL
	      state.   The  sensor  state is an interpreted value based on the
	      current sensor  event.  The  sensor  state  interpretations  are
	      determined	by	  the	     configuration	  file
	      /etc/freeipmi//freeipmi_interpret_sensor.conf.		   See
	      freeipmi_interpret_sensor.conf(5)	 for  more  information.  This
	      option gives identical output to	the  sensor  state  previously
	      output by ipmimonitoring(8).

       --sensor-state-config-file=FILE
	      Specify  an  alternate  sensor  state configuration file. Option
	      ignored if --output-sensor-state not specified.

       --entity-sensor-names
	      Output sensor names prefixed with their entity id	 and  instance
	      number  when  appropriate. This may be necessary on some mother‐
	      boards to help identify what sensors are referencing. For	 exam‐
	      ple,  a  motherboard may have multiple sensors named 'TEMP'. The
	      entity id and instance number  may  help	clarify	 which	sensor
	      refers to "Processor 1" vs. "Processor 2".

       --output-sensor-thresholds
	      Output sensor thresholds in output. This will add columns to the
	      default output for lower non-recoverable, lower critical,	 lower
	      non-critical, upper non-critical, upper critical, and upper non-
	      recoverable thresholds.

       --no-sensor-type-output
	      Do not show sensor type output for each entry. On many  systems,
	      the sensor type is redundant to the name of the sensor. This can
	      especially be true if --entity-sensor-names  is  specified.   If
	      the  sensor  name	 is sufficient, or if the sensor type is of no
	      interest to the user, this option can be specified  to  condense
	      output.

       --comma-separated-output
	      Output fields in comma separated format.

       --no-header-output
	      Do not output column headers. May be useful in scripting.

       --non-abbreviated-units
	      Output  non-abbreviated  units (e.g. 'Amps' instead of 'A'). May
	      aid  in  disambiguation  of  units  (e.g.	 'C'  for  Celsius  or
	      Coulombs).

       --legacy-output
	      Output  in legacy format. Newer options may not be applicable to
	      legacy output.

       --ipmimonitoring-legacy-output
	      Output  legacy  format  of  legacy  ipmimonitoring  tool.	 Newer
	      options may not be applicable to legacy output.

SDR CACHE OPTIONS
       This tool requires access to the sensor data repository (SDR) cache for
       general operation. By default, SDR data will be downloaded  and	cached
       on the local machine. The following options apply to the SDR cache.

       -f, --flush-cache
	      Flush  a	cached	version	 of  the  sensor data repository (SDR)
	      cache. The SDR is typically cached for faster subsequent access.
	      However,	it  may need to be flushed and re-generated if the SDR
	      has been updated on a system.

       -Q, --quiet-cache
	      Do not 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 recre‐
	      ate the sensor data repository (SDR) cache. This option  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. 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.

HOSTRANGED OPTIONS
       The following options manipulate hostranged output. See HOSTRANGED SUP‐
       PORT below for additional information on hostranges.

       -B, --buffer-output
	      Buffer  hostranged output. For each node, buffer standard output
	      until the node has completed its IPMI operation. When specifying
	      this  option, data may appear to output slower to the user since
	      the the entire IPMI operation must complete before any data  can
	      be output.  See HOSTRANGED SUPPORT below for additional informa‐
	      tion.

       -C, --consolidate-output
	      Consolidate hostranged output. The complete standard output from
	      every  node  specified  will  be consolidated so that nodes with
	      identical output are not output twice. A header will list	 those
	      nodes  with  the consolidated output. When this option is speci‐
	      fied, no output can be seen until the  IPMI  operations  to  all
	      nodes  has  completed.  If  the  user  breaks out of the program
	      early, all currently consolidated output	will  be  dumped.  See
	      HOSTRANGED SUPPORT below for additional information.

       -F NUM, --fanout=NUM
	      Specify  multiple	 host  fanout.	A "sliding window" (or fanout)
	      algorithm is used for parallel IPMI communication so that slower
	      nodes or timed out nodes will not impede parallel communication.
	      The maximum number of threads available at the same time is lim‐
	      ited by the fanout. The default is 64.

       -E, --eliminate
	      Eliminate	 hosts	determined  as undetected by ipmidetect.  This
	      attempts to remove the common issue of hostranged execution tim‐
	      ing  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 com‐
	      municating in-band. This option is primarily useful for  script‐
	      ing  purposes.  Option  will be ignored if specified with the -C
	      option.

HOSTRANGED SUPPORT
       Multiple hosts can be input either as an explicit comma separated lists
       of  hosts  or  a	 range of hostnames in the general form: prefix[n-m,l-
       k,...], where n < m and l < k, etc. The later form should not  be  con‐
       fused  with  regular expression character classes (also denoted by []).
       For example, foo[19] does not represent foo1 or foo9, but rather repre‐
       sents a degenerate range: foo19.

       This  range  syntax  is	meant only as a convenience on clusters with a
       prefixNN naming convention and specification of 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

       As a 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 thread	will  be  exe‐
       cuted  for each host in parallel up to the configured fanout (which can
       be adjusted via the -F option). This will allow communication to	 large
       numbers of nodes far more quickly than if done in serial.

       By  default,  standard  output  from each node specified will be output
       with the hostname prepended to each line. Although this output is read‐
       able  in	 many  situations, it may be difficult to read in other situa‐
       tions. For example, output from multiple nodes may be  mixed  together.
       The -B and -C options can be used to change this default.

       In-band	IPMI  Communication  will be used when the host "localhost" is
       specified. This allows the user to add  the  localhost  into  the  hos‐
       tranged output.

GENERAL TROUBLESHOOTING
       Most often, IPMI problems are due to configuration problems.

       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	privi‐
       lege,  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 bmc-config(8) tool can be used
       to check and/or change these configuration settings.

       Inband IPMI problems are	 typically  caused  by	improperly  configured
       drivers or non-standard BMCs.

       In  addition  to the troubleshooting tips below, please see WORKAROUNDS
       below to also if there are any vendor specific bugs that have been dis‐
       covered 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.

       "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	 maxi‐
       mum  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	avail‐
       able  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 authen‐
       ticate  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 con‐
       figuration 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 informa‐
       tion or have too many simultaneous sessions to manage. Please wait  and
       try again.

       "could  not  find inband device" - An inband device could not be found.
       Please check configuration or specify 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.

       "sensor	config file parse error" - A parse error was found in the sen‐
       sor  interpretation  configuration  file.  Please  see  freeipmi_inter‐
       pret_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 han‐
       dle discovered compliance issues. When possible, workarounds have  been
       implemented so they will be transparent to the user. However, some will
       require the user 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.  Different vendors may license their firmware from
       the same IPMI firmware developer, so it may be worthwhile to try	 work‐
       arounds 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 main‐
       tainers on <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.

       assumeio	 - This workaround flag will assume inband interfaces communi‐
       cate 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.

       authcap	-  This	 workaround  flag  will skip early checks for username
       capabilities, authentication capabilities, and K_g  support  and	 allow
       IPMI  authentication  to	 succeed.  It  works around multiple issues in
       which the remote system does not properly report username capabilities,
       authentication  capabilities,  or  K_g status. Those hitting this issue
       may  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 will tell FreeIPMI to not check
       the checksums returned from IPMI command	 responses.  It	 works	around
       systems that return invalid checksums due to implementation errors, but
       the packet is otherwise valid. Users are cautioned on the use  of  this
       option,	as  it	removes	 validation of packet integrity in a number of
       circumstances. However, it is unlikely to be an issue  in  most	situa‐
       tions.  Those hitting this issue may see "connection timeout", "session
       timeout", or "password verification timeout" errors. On IPMI  1.5  con‐
       nections,  the  "noauthcodecheck" workaround may also needed too. Issue
       observed on Supermicro X9SCM-iiF, Supermicro  X9DRi-F,  and  Supermicro
       X9DRFR.

       idzero  -  This	workaround  flag  will	allow  empty session IDs to be
       accepted by the client. It works around IPMI sessions that report empty
       session	IDs  to	 the client. Those hitting this issue may see "session
       timeout" errors. Issue observed on Tyan S2882 with M3289 BMC.

       unexpectedauth - This workaround flag will  allow  unexpected  non-null
       authcodes  to  be checked as though they were expected. It works around
       an issue when packets contain non-null authentication  data  when  they
       should  be  null due to disabled per-message authentication. Those hit‐
       ting this issue may see "session timeout"  errors.  Issue  observed  on
       Dell PowerEdge 2850,SC1425. Confirmed fixed on newer firmware.

       forcepermsg  -  This workaround flag will force per-message authentica‐
       tion to be used no matter what is advertised by the remote  system.  It
       works  around an issue when per-message authentication is advertised as
       disabled on the remote system, but it is actually required for the pro‐
       tocol.  Those  hitting  this  issue  may	 see "session timeout" errors.
       Issue observed on IBM eServer 325.

       endianseq - This workaround flag will flip the endian  of  the  session
       sequence	 numbers  to  allow the session to continue properly. It works
       around IPMI 1.5 session sequence numbers that  are  the	wrong  endian.
       Those  hitting  this  issue  may	 see  "session	timeout" errors. Issue
       observed on  some  Sun  ILOM  1.0/2.0  (depends	on  service  processor
       endian).

       noauthcodecheck	- This workaround flag will tell FreeIPMI to not check
       the authentication codes returned from IPMI 1.5 command	responses.  It
       works  around  systems  that return invalid authentication codes due to
       hashing or implementation errors. Users are cautioned  on  the  use  of
       this option, as it removes an authentication check verifying the valid‐
       ity of a packet. However, in most organizations, this is unlikely to be
       a  security  issue.  Those hitting this issue may see "connection time‐
       out", "session timeout", or  "password  verification  timeout"  errors.
       Issue observed on Xyratex FB-H8-SRAY.

       intel20	- This workaround flag will work around 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. Those hitting this issue may 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 will work around several Supermicro
       IPMI  2.0  authentication  issues  on  motherboards  w/	Peppercon IPMI
       firmware. The issues covered include handling invalid length  authenti‐
       cation  codes.  Those  hitting  this  issue  may see "password invalid"
       errors.	Issue observed on Supermicro H8QME with SIMSO  daughter	 card.
       Confirmed fixed on newerver firmware.

       sun20 - This workaround flag will work work around several Sun IPMI 2.0
       authentication issues. The issues covered include invalid lengthed hash
       keys,  improperly  hashed keys, and invalid cipher suite records. Those
       hitting this issue may 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 will slightly alter FreeIPMI's IPMI
       2.0 connection protocol to workaround 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.	Those  hitting
       this  issue may see "password invalid", "k_g invalid", or "bad rmcpplus
       status code" 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, and Quanta
       QSSC-S4R/Appro  GB812X-CN.  This	 workaround is automatically triggered
       with the "sun20" workaround.

       integritycheckvalue - This workaround flag will work 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. Those
       hitting this issue may see "k_g	invalid"  errors.  Issue  observed  on
       Supermicro  X8DTG,  Supermicro X8DTU, and Intel S5500WBV/Penguin Relion
       700, and Intel S2600JF/Appro 512X.

       assumemaxsdrrecordcount - This workaround will inform  SDR  reading  to
       stop reading after a known maximum numer of SDR records have been read.
       This will work around systems that  have	 mis-implemented  SDR  reading
       functions  that.	 Those	hitting	 this  issue may see "SDR record count
       invalid" errors. Issue observed on unspecified Inspur motherboard.

       discretereading - This workaround option will allow analog sensor read‐
       ings  (i.e.  rpm,  degrees,  etc.) to be read even if the event/reading
       type code for the sensor is for a  discrete  sensor  (i.e.  assert  vs.
       deassert).  This option works around poorly defined (and arguably ille‐
       gal) SDR records that expect analog sensor readings to be  read	along‐
       side  discrete  sensors. This option is confirmed to work around issues
       on HP Proliant DL380 G7 and HP ProLiant ML310 G5 motherboards.

       ignorescanningdisabled - This workaround option will allow sensor read‐
       ings  to	 be read even if the sensor scanning bit indicates a sensor is
       disabled. This option works around motherboards that incorrectly	 indi‐
       cate  sensors  as  disabled. This may problem may exist on your mother‐
       board if sensors are listed as "N/A" even if they should be  available.
       This  option is confirmed to work around issues on Dell Poweredge 2900,
       Dell Poweredge 2950, Dell Poweredge R410, Dell Poweredge R610,  and  HP
       Integrity rx3600 motherboards.

       assumebmcowner  -  This workaround option will allow sensor readings to
       be read if the sensor owner is the BMC, but the reported	 sensor	 owner
       is not the BMC. Typically, sensors owned by a non-BMC sensor owner must
       be bridged (e.g. with the --bridge-sensors option), however if the non-
       BMC  sensor  owner is invalid, bridging fails. This option works around
       motherboards that incorrectly report an non-BMC sensor owner by	always
       assuming	 the  sensor  owner is the BMC. This problem may exist on your
       motherboard if sensors are listed as  "N/A"  even  if  they  should  be
       available.  This	 option	 is confirmed to work around issues on Fujitsu
       RX300 and Fujitsu RX300S2 motherboards.

       ignoreauthcode - This workaround option will allow sensor  readings  to
       be  read	 if the remote machine is invalidly calculating authentication
       codes (i.e. authentication hashes) when communicating  over  LAN.  This
       problem	may exist on your system if the error "session timeout" errors
       or there is an appearance of a hang.  Users are cautioned on the use of
       this option, as it removes an authentication check verifying the valid‐
       ity of a packet. However, in most organizations, this is unlikely to be
       a  security  issue. The ignoring of authentication packets is only lim‐
       ited to the period in which sensor readings are done, and not  for  any
       portion	of the session authentication or session teardown. This option
       is confirmed to work on	Inventec  5441/Dell  Xanadu  II	 and  Inventec
       5442/Dell Xanadu III.  (Note: On the above systems, this issue has only
       been observed when the --bridge-sensors is used.)

       No IPMI 1.5 Support - Some motherboards that support IPMI 2.0 have been
       found  to  not support IPMI 1.5. Those hitting this issue may 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 HP Proliant DL 145.

OEM INTERPRETATION
       The following motherboards are confirmed to have atleast	 some  support
       by  the --interpret-oem-data option. While highly probable the OEM data
       interpretations would work across other motherboards by the same	 manu‐
       facturer,  there	 are no guarantees. Some of the motherboards below may
       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 S5000PAL, Supermicro X7DBR-3, Supermicro X7DB8, Supermicro
       X8DTN, Supermicro X7SBI-LN4, Supermicro X8DTH, Supermicro X8DTG, Super‐
       micro  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, Wistron/Dell Pow‐
       eredge C6220.

EXAMPLES
       # ipmi-sensors

       Show all sensors and readings on the local machine.

       # ipmi-sensors --verbose

       Show verbose sensors and readings on the local machine.

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

       Show sensor record ids 7, 11, and 102 on the local machine.

       # ipmi-sensors --sensor-types=fan

       Show all sensors of type fan on the local machine.

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

       Show all sensors on a remote machine using IPMI over LAN.

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

       Show all sensors across a cluster using IPMI over LAN.

DIAGNOSTICS
       Upon successful execution, exit status is 0. On error, exit  status  is
       1.

       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.

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. 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 infor‐
       mation.

       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.

       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.

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

COPYRIGHT
       Copyright © 2003-2012 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.

SEE ALSO
       freeipmi(7),   bmc-config(8),   bmc-device(8),  ipmi-sensors-config(8),
       freeipmi_interpret_sensor.conf(5)

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

IPMI Sensors version 1.2.9	  2014-05-01		       IPMI-SENSORS(8)
[top]

List of man pages available for Oracle

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net