ipmi-sensors man page on Scientific

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

IPMI-SENSORS(8)			System Commands		       IPMI-SENSORS(8)

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 par‐
       ticular sensor because sensor readings and events are not  analyzed  by
       default. Users may wish to use the --output-sensor-state option to out‐
       put 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	 typi‐
       cal of a sensor that is busy or a reading that cannot be calculated. If
       sensors report "Unrecognized State", it is indicative of an unkown sen‐
       sor  type, typically an OEM sensor. If the sensor OEM interpretation is
       available, the --intepret-oem-data may be able to report the  appropri‐
       ate 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_inter‐
	      pret_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.

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

       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 to 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-address=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, Fujitsu
       iRMC S1 and iRMC S2 systems,  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,  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, Wistron/Dell Poweredge 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.1	  2013-11-21		       IPMI-SENSORS(8)
[top]

List of man pages available for Scientific

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