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

FreeBSD Manual Pages

  
 
  

home | help
IPMI-CONFIG(8)			System Commands			IPMI-CONFIG(8)

NAME
       ipmi-config - configure IPMI values

SYNOPSIS
       ipmi-config [OPTION...]

DESCRIPTION
       ipmi-config is used to get and set configuration	parameters in IPMI. In
       can be used to configured usernames, passwords, networking information,
       security,  Serial-over-LAN  (SOL), Platform Event Filtering (PEF), boot
       devices,	power restoration policy, sensor  thresholds,  sensor  events,
       and many	more configuration options.

       Some  configuration is typically	required before	most IPMI tools	can be
       used to access a	machine	remotely. By default,  ipmi-config,  will  let
       you --checkout or --commit only the core	IPMI values necessary for IPMI
       configuration. For additional advanced configuration fields related  to
       Chassis	configuration (including boot options),	Platform Event Filter-
       ing (PEF), or Sensors, see the --category option	below.

       The majority of configuration operations	require	ADMIN  privilege  when
       using  ipmi-config out-of-band. Although	connecting via a user with AD-
       MIN privileges is not required for out-of-band use, the	vast  majority
       of configuration	options	will not be retrieved or set.

       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).
       See GENERAL USE below for a description on basic	use of ipmi-config.

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	ADMIN 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 AD-
	      MIN 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-CONFIG OPTIONS
       The following options are used to read, write, and find differences  in
       configuration values.

       -g CATEGORY, --category=CATEGORY
	      Specify the category or categories of configuration data to con-
	      figure.  Currently available choices:  core,  chassis,  sensors,
	      pef,  dcmi. Multiple categories can be separated by comma.  core
	      includes all major IPMI configuration necessary to get  IPMI  to
	      function on a sytem, such	as configuration for users, passwords,
	      authentication, networking, and serial-over-lan  (SOL).  chassis
	      includes	all  chassis relevant configuration including boot op-
	      tions, front panel buttons, and power  behavior.	dcmi  includes
	      specialized functions provided by	the Data Center	Management In-
	      terface (DCMI). Defaults to core if not specified.

       -o, --checkout
	      Fetch configuration information.

       -c, --commit
	      Update configuration information	from  a	 config	 file  or  key
	      pairs.

       -d, --diff
	      Show differences between stored information and a	config file or
	      key pairs.

       -n FILENAME, --filename=FILENAME
	      Specify a	config file  for  checkout/commit/diff.	 If  specified
	      with  checkout,  cannot  use  with  multiple hosts or with --al-
	      ways-prefix.

       -e "KEY=VALUE", --key-pair="KEY=VALUE"
	      Specify KEY=VALUE	pairs for checkout/commit/diff.	Specify	KEY by
	      SectionName:FieldName.  This  option can be used multiple	times.
	      On commit, any KEY=VALUE pairs will overwrite any	 pairs	speci-
	      fied in a	file with --filename.

       -S SECTION, --section=SECTION
	      Specify a	SECTION	for checkout. This option can be used multiple
	      times. The SECTION you are specifying must be within  the	 cate-
	      gory or categories specified with	--category.

       -L, --listsections
	      List  available  sections	for checkout with respect to the cate-
	      gory or categories under --category. Some	sections in  the  list
	      may  not	be checked out by default and may require verbosity to
	      be increased.

       -v, --verbose
	      Output verbose information. When	used  with  --checkout,	 addi-
	      tional  uncommon	sections  and/or  fields will be shown.	In the
	      core category, this includes checking out	 Serial	 Configuration
	      parameters,  Vlan	parameters, IPv4 Header	parameters, RMCP port,
	      and sections for each channel on a system, if multiple  channels
	      exist.  In the pef category, this	includes checkout out sections
	      for each channel on a system, if multiple	channels exist.

       -vv    Output very verbose information. Output additional detailed  in-
	      formation	 about	what fields can	and cannot be checked out, and
	      sometimes	the reason why.	Sometimes output fields	that are iden-
	      tified as	unsupported on the motherboard.

       --lan-channel-number=NUMBER
	      Use  an  specific	channel	number for LAN configuration. Particu-
	      larly useful if motherboard contains multiple LAN	channels and a
	      user wishes to use a specific one.

       --serial-channel-number=NUMBER
	      Use an specific channel number for serial	configuration. Partic-
	      ularly useful if motherboard contains multiple  serial  channels
	      and a user wishes	to use a specific one.

       --sol-channel-number=NUMBER
	      Use  an  specific	channel	number for SOL configuration. Particu-
	      larly useful if motherboard contains multiple SOL	channels and a
	      user wishes to use a specific one.

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.

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.

GENERAL	USE
       Most users of will want to:

       A) Run with --checkout to get a copy of the current  configuration  and
       store  it in a file. The	standard output	can be redirected to a file or
       a file can be specified with the	--filename option.

       B) Edit the configuration file with an editor.

       C) Commit the configuration back	using the --commit option and specify-
       ing  the	configuration file with	the --filename option.	The configura-
       tion can	be committed to	multiple hosts in parallel via	the  hostrange
       support.

       Although	not typically necessarily, some	motherboards do	not store con-
       figuration values in non-volatile memory. Therefore, after  system  re-
       boots, some configuration values	may have changed. The user may wish to
       run configuration tools on each boot to ensure configuration values re-
       main.

       Comments	will be	listed on occassion in checked out files with informa-
       tion on how to configure	fields.	 The ipmi-config.conf(5) manpage  also
       provides	additional information on the meaning of different fields.

       For users with large clusters or	sets of	nodes, you may wish to use the
       same configuration file for all nodes. The one  problem	with  this  is
       that  the  IP address and MAC address will be different on each node in
       your cluster and	thus can't be configured through the same config file.
       The  IP	address	and MAC	address	in your	config file may	be overwritten
       on the command line using  --key-pair  option.  The  following  example
       could  be used in a script to configure each node in a cluster with the
       same BMC	config file. The script	only needs to determine	the correct IP
       address and MAC address to use.

       #     ipmi-config    --commit	-k    Lan_Conf:Ip_Address=$MY_IP    -k
       Lan_Conf:Mac_Address=$MY_MAC --filename=my_bmc.conf

CORE SPECIAL CASE CONFIGURATION	INFORMATION
       The UserN:Password fields (where	N is a number) cannot be  checked  out
       on some systems,	therefore the checked out value	will always be blank.

       The UserN:Enable_User field (where N is a number) cannot	be checked out
       on older	IPMI systems, therefore	the checked out	value will sometime be
       blank.

       The   UserN:Lan_Session_Limit   and  UserN:Serial_Session_Limit	fields
       (where N	is a number) cannot be checked out on some systems,  therefore
       the  checked  out value will always be blank. If	not specified in later
       commits of configurations, the field may	be reset to 0  due  to	a  re-
       quirement  that	other fields (configured along with the	session	limit)
       will require an input value for the session limit.  Under  most	condi-
       tions,  it is not necessary to set this field and most users may	choose
       to ignore it. This field	is considered optional by IPMI standards,  and
       may  result  in	errors	when  attempting to configure it to a non-zero
       value. If errors	to occur, setting the value back to 0  should  resolve
       problems.

       The  fields Lan_Conf:IP_Address and Lan_Conf:MAC_Address	cannot be com-
       mitted in parallel via hostrange	support. Each machine must be  config-
       ured  with a unique IP Address and MAC Address tuple, therefore we dis-
       allow this configuration	in ipmi-config.

       On some motherboards, Lan_Conf:MAC_Address may be read only and the MAC
       address is automatically	configured.

       On some motherboards, Lan_Conf:MAC_Address may be read only and the MAC
       address is configured via an OEM	command. See ipmi-oem(8) to see	if OEM
       configuration for your motherboard is supported.

       On  some	 motherboards, a number	of user	configuration fields cannot be
       read or configured until	after a	non-null username or non-null password
       is  configured.	In  some  of these cases, an appropriate output	in the
       config file will	indicate this situation. However, not all  motherboard
       corner  cases  may  be detected.	Users may wish to play around with the
       ordering	of fields to work around these problems.

       On some motherboards, OEM Authentication	in Lan_Conf_Auth cannot	be en-
       abled.  However,	the default motherboard	settings have these fields en-
       abled. Users are	advised	to disable all OEM Authentication in this sec-
       tion.

       On some motherboards, multiple channels may exist for either LAN	or Se-
       rial IPMI communication.	If multiple channels exist,  configuration  of
       both  channels  can  be	viewed	and  ultimately	 configured by running
       --checkout under	verbose	mode. Each section or key name	will  be  suf-
       fixed  appropriately  with the word Channel and the channel number. For
       example,	you might see  a  Lan_Conf_Channel_1  and  Lan_Conf_Channel_3,
       where  you  can configure LAN configuration on Channels 1 and 3 respec-
       tively.

       On some motherboards, configuration changes will	not be	"absorbed"  by
       the  system  until  the	motherboard  is	hard-reset. This can be	accom-
       plished by physically powering off  and	on  the	 system	 (e.g.	button
       push), or it can	be accomplished	through	a cold-reset. A	cold-reset can
       be executed via bmc-device.

CHASSIS	SPECIAL	CASE CONFIGURATION INFORMATION
       The	  Chassis_Front_Panel_Buttons:Enable_Standby_Button_For_Enter-
       ing_Standy,	  Chassis_Front_Panel_Buttons:Enable_Diagnostic_Inter-
       rupt_Button Chassis_Front_Panel_Buttons:Enable_Reset_Button, and	 Chas-
       sis_Front_Panel_Buttons:Enable_Power_Off_Button_For_Power_Off_Only
       fields may not be able to be checked out	on some	IPMI  systems,	there-
       fore  the  checked  out value may be blank. Some	of these fields	may be
       disableable, while some are not.

       The Chassis_Power_Conf:Power_Control_Interval field cannot  be  checked
       out. Therefore the checked out value will always	be blank.

PEF SPECIAL CASE CONFIGURATION INFORMATION
       On some motherboards, multiple channels may exist for LAN IPMI communi-
       cation. If multiple channels exist, configuration of both channels  can
       be viewed and ultimately	configured by running --checkout under verbose
       mode. Each section name will be suffixed	appropriately  with  the  word
       Channel	and  the  channel  number. For example,	you might see a	Commu-
       nity_String_Channel_1 and  Community_String_Channel_3,  where  you  can
       configure the Community String on Channels 1 and	3 respectively.

       The following are the options suitable for input	for Sensor_Type	in PEF
       configuration.

       Sensor_Type Options
	      Reserved,	Temperature, Voltage, Current, Fan, Physical_Security,
	      Platform_Security_Violation_Attempt,   Processor,	 Power_Supply,
	      Power_Unit,  Cooling_Device,  Other_Units_Based_Sensor,  Memory,
	      Drive_Slot,     Post_Memory_Resize,    System_Firmware_Progress,
	      Event_Logging_Disabled, Watchdog1, System_Event, Critical_Inter-
	      rupt,  Button_Switch, Module_Board, Microcontroller_Coprocessor,
	      Add_In_Card, Chassis, Chip_Set,  Other_FRU,  Cable_Interconnect,
	      Terminator, System_Boot_Initiated, Boot_Error, OS_Boot, OS_Crit-
	      ical_Stop, Slot_Connector,  System_ACPI_Power_State,  Watchdog2,
	      Platform_Alert,  Entity_Presence,	 Monitor_Asic_IC, Lan, Manage-
	      ment_Subsystem_Health, Battery,  Session_Audit,  Version_Change,
	      FRU_State, and Any

SENSORS	SPECIAL	CASE CONFIGURATION INFORMATION
       Since   many   configurable  fields  involve  decimal  numbers,	preci-
       sion/floating point inaccuracies	may occur when configuring new thresh-
       olds. The inaccuracies may not be apparent immediately. It is recommend
       users verify their changes after	configuring new	thresholds.

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.

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.

       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.

       slowcommit - This workaround will slow  down  commits  to  the  BMC  by
       sleeping	 one  second  between  the commit of sections. It works	around
       motherboards that have BMCs that	can be overwhelmed by commits.	 Those
       hitting	this  issue may	see commit errors or commits not being written
       to the BMC. Issue observed on Supermicro	H8QME.

       veryslowcommit -	This workaround	will slow down commits to the  BMC  by
       sleeping	 one  second  between the commit of every key. It works	around
       motherboards that have BMCs that	can be overwhelmed by commits.	 Those
       hitting	this  issue may	see commit errors or commits not being written
       to the BMC. Issue observed on Quanta S99Q/Dell FS12-TY.

       solchannelassumelanchannel - This workaround will force ipmi-config  to
       assume  that  the channel used SOL is identical to the channel used for
       LAN. On some motherboards, the SOL  channel  is	reported  incorrectly,
       leading to incorrect configuration. Most	notably, this problem has come
       up when attempting to configure multiple	channels.  Issue  observed  on
       Intel S5500WBV/Penguin Relion 700.

EXAMPLES
       # ipmi-config --checkout

       Output  all core	configuration information to the console.  # ipmi-con-
       fig --checkout --category=pef

       Output all pef configuration information	to the console.	 # ipmi-config
       --checkout --category=pef,chassis

       Output all pef and chassis configuration	information to the console.

       # ipmi-config --checkout	--filename=bmc-data1.conf

       Store all core configuration information	in bmc-data1.conf.

       # ipmi-config --diff --filename=bmc-data2.conf

       Show  all  difference  between  the  current configuration and the bmc-
       data2.conf file.

       #  ipmi-config  --diff  --key-pair="lan_conf_misc:gratuitous_arp_inter-
       val=8"

       Show    difference    with    the   current   configuration   and   the
       'lan_conf_misc:gratuitous_arp_interval' of value	'8'.

       # ipmi-config --commit --filename=bmc-data1.conf

       Commit all configuration	values from the	bmc-data1.conf file.

       # ipmi-config --commit  --key-pair="lan_conf_misc:gratuitous_arp_inter-
       val=4"

       Commit key 'lan_conf_misc:gratuitous_arp_interval' of value '4'.

       #    ipmi-config	   --commit    --filename=bmc-data-updt.conf	--key-
       pair="lan_conf_misc:gratuitous_arp_interval=4"

       Commit  all  configuration  values  from	 bmc-data-updt.conf  and   key
       'lan_conf_misc:gratuitous_arp_interval' of value	'4'.

DIAGNOSTICS
       Upon  successful	 execution, exit status	is 0. On non-fatal error, exit
       status is 1. On fatal error, exit status	is 2.

       If multiple hosts are specified for communication, the exit status is 0
       if and only if all targets successfully execute.	If any non-fatal error
       occurs, exit status is 1. If any	fatal error occurs, exit status	is 2.

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.

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
       ipmi-config.conf(5), freeipmi(7), bmc-device(8)

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

ipmi-config 1.6.6		  2020-09-03			IPMI-CONFIG(8)

NAME | SYNOPSIS | DESCRIPTION | GENERAL OPTIONS | IPMI-CONFIG OPTIONS | SDR CACHE OPTIONS | HOSTRANGED OPTIONS | GENERAL USE | CORE SPECIAL CASE CONFIGURATION INFORMATION | CHASSIS SPECIAL CASE CONFIGURATION INFORMATION | PEF SPECIAL CASE CONFIGURATION INFORMATION | SENSORS SPECIAL CASE CONFIGURATION INFORMATION | HOSTRANGED SUPPORT | GENERAL TROUBLESHOOTING | WORKAROUNDS | 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-config&sektion=8&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help