Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
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 en-
       abled 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  unknown
       sensor  type, typically an OEM sensor. If the sensor OEM	interpretation
       is available, the --interpret-oem-data may be able to report the	appro-
       priate  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 is-
       sues. For a general introduction	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
       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,
	      SUNBMC, and INTELDCMI.

       --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 re-
	      quests 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.  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 as-
	      sumed. 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  re-
	      mote 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.  De-
	      faults to	1000 milliseconds (1 second) if	not specified. The re-
	      transmission 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 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 OP-
	      ERATOR 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 de-
	      faults).

       -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 ex-
	      cluded (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  en-
	      tries shared by a	SDR entry. By setting this option, each	sensor
	      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  ig-
	      nored  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 de-
	      termined	   by	  the	  configuration	    file      /usr/lo-
	      cal/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 ig-
	      nored 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 op-
	      tions 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.

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

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

TIME OPTIONS
       By  IPMI	definition, all	IPMI times and timestamps are stored in	local-
       time. However, in many situations, the timestamps will not be stored in
       localtime.  Whether  or not a system truly stored the timestamps	in lo-
       caltime varies on many factors, such as the vendor, BIOS, and operating
       system.

       The  following options will allow the user to adjust the	interpretation
       of the stored timestamps	and how	they should be output.

       --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 time-
	      stamps.  Value can range from -86400 to 86400 seconds.  Defaults
	      to 0.

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) al-
	      gorithm  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  ma-
       chine'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	 ipmi-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 ad-
       ditional	 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 en-
       tered) is not correct. It may also be possible the K_g key is not  cor-
       rectly 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 ci-
       pher suite ids are not correctly	configured on the remote BMC.

       "ipmi 2.0 unavailable" -	IPMI 2.0 was not discovered on the remote  ma-
       chine. 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 re-
       mote server, the	network	connection is bad, etc.	Please verify configu-
       ration 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 re-
       port 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  in-
       dicated 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  ca-
       pabilities, 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, authenti-
       cation 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  ac-
       cepted  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.   Is-
       sue 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  ob-
       served 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,	Intel Windmill,	Quanta Winter-
       fell, and Wiwynn	Windmill.

       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"  er-
       rors.   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,	Quanta
       QSSC-S4R/Appro GB812X-CN, and Dell C5220. This workaround is  automati-
       cally 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 us-
       ing  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 Su-
       permicro	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 number  of  SDR  records  have  been
       read. This will work around systems that	have mis-implemented SDR read-
       ing functions. Those hitting this issue may see "SDR record  count  in-
       valid" 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. de-
       assert).	This option works around poorly	defined	(and arguably illegal)
       SDR  records  that  expect  analog sensor readings to be	read alongside
       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 S2600GZ, Intel S2600WP,  Intel  S5000PAL,  Intel  Windmill,
       Quanta  Winterfell,  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,  Su-
       permicro	 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
       # 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 (C) 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.

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

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

IPMI Sensors version 1.6.5	  2020-05-21		       IPMI-SENSORS(8)

NAME | SYNOPSIS | DESCRIPTION | GENERAL OPTIONS | IPMI-SENSORS OPTIONS | SDR CACHE OPTIONS | TIME OPTIONS | HOSTRANGED OPTIONS | HOSTRANGED SUPPORT | GENERAL TROUBLESHOOTING | WORKAROUNDS | OEM INTERPRETATION | EXAMPLES | DIAGNOSTICS | KNOWN ISSUES | REPORTING BUGS | COPYRIGHT | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=ipmi-sensors&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help