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

FreeBSD Manual Pages

  
 
  

home | help
ipmipower(8)			System Commands			  ipmipower(8)

NAME
       ipmipower - IPMI	power control utility

SYNOPSIS
       ipmipower [OPTION...]

DESCRIPTION
       Ipmipower  allows  users	 to remotely power on, off, cycle, hard	reset,
       get a power status query, perform a pulse diagnostic interrupt, or ini-
       tiate a soft-shutdown of	the OS via ACPI	through	the IPMI over LAN pro-
       tocol.

       When a power command (--on, --off, --cycle, --reset,  --stat,  --pulse,
       or  --soft) is specified	on the command line, Ipmipower will attempt to
       run the power command on	all hostnames listed on	the command line  then
       exit.

       If  no power commands are specified on the command line,	ipmipower will
       run in interactive mode.	Interactive mode gives the user	a command line
       interface to enter various commands. Details of the interactive command
       line interface can be found below under INTERACTIVE COMMANDS.

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

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.

       -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 to run the
	      --on, --off, --reset, --cycle, --pulse, or --soft	power  control
	      commands.	 The  user must	have atleast USER privileges to	deter-
	      mine the power status of the machine through --stat.

       -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	400 milliseconds (0.4 seconds) if not specified.

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

IPMIPOWER OPTIONS
       The following options are specific to ipmipower.

       -n, --on
	      Power on the target hosts.

       -f, --off
	      Power off	the target hosts.

       -c, --cycle
	      Power cycle the target hosts.

       -r, --reset
	      Reset the	target hosts.

       -s, --stat
	      Get power	status of the target hosts.

       --pulse
	      Send power diagnostic interrupt to target	hosts.

       --soft Initiate a soft-shutdown of the OS via ACPI.

       --on-if-off
	      The IPMI specification does not require the power	cycle or  hard
	      reset  commands  to  turn	on a machine that is currently powered
	      off. This	option will force ipmipower to issue a power  on  com-
	      mand  instead  of	a power	cycle or hard reset command if the re-
	      mote machine's power is currently	off.

       --wait-until-on
	      The IPMI specification allows power on commands to return	 prior
	      to  the  power  on actually taking place.	This option will force
	      ipmipower	to regularly query the remote BMC and return only  af-
	      ter the machine has powered on.

       --wait-until-off
	      The IPMI specification allows power off commands to return prior
	      the power	off actually taking place. This	option will force  ip-
	      mipower  to regularly query the remote BMC and return only after
	      the machine has powered off.

       --oem-power-type=OEM-POWER-TYPE
	      This option informs ipmipower to initiate	power  control	opera-
	      tions via	an IPMI	OEM specific power control extension. The cur-
	      rently available POWERTYPEs are NONE and C410X. Please  see  OEM
	      POWER EXTENSIONS below for additional information.

IPMIPOWER ADVANCED NETWORK OPTIONS
       The following options are used to change	the networking behavior	of ip-
       mipower.

       --retransmission-wait-timeout=MILLISECONDS
	      Specify the retransmission wait timeout length in	 milliseconds.
	      The retransmission wait timeout is similar to the	retransmission
	      timeout above, but is used  specifically	for  power  completion
	      verification  with  the --wait-until-on and --wait-until-off op-
	      tions.  Defaults to 500 milliseconds (0.5	seconds).

       --retransmission-backoff-count=COUNT
	      Specify the retransmission backoff  count	 for  retransmissions.
	      After  ever  COUNT  retransmissions,  the	retransmission timeout
	      length will be increased by another factor. Defaults to 8.

       --ping-interval=MILLISECONDS
	      Specify the ping interval	length in milliseconds.	 When  running
	      in  interactive  mode, RMCP (Remote Management Control Protocol)
	      discovery	messages will be sent to all configured	 remote	 hosts
	      every  MILLISECONDS to confirm their support of IPMI. Power com-
	      mands cannot be sent to a	host until it is  discovered  (or  re-
	      discovered if previously lost). Defaults to 5000 milliseconds (5
	      seconds).	Ping discovery messages	can  be	 disabled  by  setting
	      this  valu  to 0.	RMCP ping discovery messages are automatically
	      disabled in non-interactive mode.

       --ping-timeout=MILLISECONDS
	      Specify the ping timeout length in milliseconds. When running in
	      interactive mode,	RMCP (Remote Management	Control	Protocol) mes-
	      sages discovery will be sent to all configured remote  hosts  to
	      confirm  their  support  of  IPMI.  A  remote host is considered
	      undiscovered if the host does not	respond	in MILLISECONDS	 time.
	      Defaults	to  30000  milliseconds	(30 seconds). The ping timeout
	      cannot be	larger than the	ping interval.

       --ping-packet-count=COUNT
	      Specify the ping packet count size.  Defaults  to	 10.  See  the
	      --ping-percent-fR	 option	below for more information on this op-
	      tion.

       --ping-percent=PERCENT
	      Specify the ping percent value. Defaults to 50.

	      Since IPMI is based on UDP, it is	 difficult  for	 ipmipower  to
	      distinguish  between  a  missing	machine	 and a bad (or heavily
	      loaded) network connection in interactive	mode. when running  in
	      interactive mode.	For example, suppose a link consistently drops
	      80% of the packets to a particular machine.  The	power  control
	      operation	may have difficulty completing,	although a recent pong
	      response from RMCP makes ipmipower believe the machine is	up and
	      functioning properly.

	      The ping packet acount and percent options are used to alleviate
	      this problem.  Ipmipower	will  monitor  RMCP  ping  packets  in
	      packet count chunks. If ipmipower	does not receive a response to
	      greater than ping	percent	of those packets, ipmipower  will  as-
	      sume  the	 link to this node is bad and will not send power con-
	      trol operations to that node until the connection	is  determined
	      to be reliable. This heuristic can be disabled by	setting	either
	      the ping packet count or ping percent to 0. This feature is  not
	      used if ping interval is set to 0.

       --ping-consec-count=COUNT
	      Specify  the  ping  consecutive count. This is another heuristic
	      used to determine	if a node  should  be  considered  discovered,
	      undiscovered, or with a bad connection. If a valid RMCP pong re-
	      sponse was received for the last COUNT ping packets, a node will
	      be  considered discovered, regardless of other heuristics	listed
	      above. Defaults to 5. This heuristic can be disabled by  setting
	      this value to 0. This feature is not used	if other ping features
	      described	above are disabled.

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. Indicates the maximum number of
	      power control operations that can	be executed in parallel.

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

INTERACTIVE COMMANDS
       Ipmipower provides the following	interactive commands at	the ipmipower>
       prompt.	Before any power commands (on, off, cycle, reset, stat,	pulse,
       or  soft) can be	used, hostnames	must be	configured into	ipmipower, ei-
       ther through the	command	prompt or the hostname command below. The  pa-
       rameters	 and  options  to  the commands	below mirror their appropriate
       command line options.

       hostname	[IPMIHOST(s)]
	      Specify a	new set	of hosts. No input to unconfigure all hosts.

       username	[USERNAME]
	      Specify a	new username. No input for null	username.

       password	[PASSWORD]
	      Specify a	new password. No input for null	password.

       k_g [K_G]
	      Specify a	new K_g	BMC Key. No input for null  key.  Prefix  with
	      '0x' to enter a key in hexadecimal

       ipmi-version IPMIVERSION
	      Specify the ipmi version to use.

       session-timeout MILLISECONDS
	      Specify a	new session timeout length.

       retransmission-timeout MILLISECONDS
	      Specify a	new retransmiision timeout length.

       authentication-type AUTHENTICATION-TYPE
	      Specify the authentication type to use.

       cipher-suite-id CIPHER-SUITE-ID
	      Specify the cipher suite id to use.

       privilege-level PRIVILEGE-LEVEL
	      Specify the privilege level to use.

       workaround-flags	WORKAROUNDS
	      Specify workaround flags.

       debug [on|off]
	      Toggle debug output.

       on [IPMIHOST(s)]
	      Turn on all configured hosts or specified	hosts.

       off [IPMIHOST(s)]
	      Turn off all configured hosts or specified hosts.

       cycle [IPMIHOST(s)]
	      Power cycle all configured hosts or specified hosts.

       reset [IPMIHOST(s)]
	      Reset all	configured hosts or specified hosts.

       stat [IPMIHOST(s)]
	      Query power status for all configured hosts or specified hosts.

       pulse [IPMIHOST(s)]
	      Pulse  diagnostic	 interrupt  all	 configured hosts or specified
	      hosts.

       soft [IPMIHOST(s)]
	      Initiate a soft-shutdown for all configured hosts	 or  specified
	      hosts.

       identify-on [IPMIHOST(s)]
	      Turn on physical system identification.

       identify-off [IPMIHOST(s)]
	      Turn off physical	system identification.

       identify-status [IPMIHOST(s)]
	      Query physical system identification status.

       on-if-off [on|off]
	      Toggle on-if-off functionality.

       wait-until-on [on|off]
	      Toggle wait-until-on functionality.

       wait-until-off [on|off]
	      Toggle wait-until-off functionality.

       retransmission-wait-timeout MILLISECONDS
	      Specify a	new retransmission wait	timeout	length.

       retransmission-backoff-count COUNT
	      Specify a	new retransmission backoff count.

       ping-interval MILLISECONDS
	      Specify a	new ping interval length.

       ping-timeout MILLISECONDS
	      Specify a	new ping timeout length.

       ping-packet-count COUNT
	      Specify a	new ping packet	count.

       ping-percent PERCENT
	      Specify a	new ping percent.

       ping-consec-count COUNT
	      Specify a	new ping consec	count.

       buffer-output [on|off]
	      Toggle buffer-output functionality.

       consolidate-output [on|off]
	      Toggle consolidate-output	functionality.

       fanout COUNT
	      Specify a	fanout.

       always-prefix [on|off]
	      Toggle always-prefix functionality.

       help   Output help menu.

       version
	      Output version.

       config Output the current configuration.

       quit   Quit program.

OEM POWER EXTENSIONS
       Some  motherboards include IPMI OEM extensions for alternate power con-
       trol mechanisms.	For example, these power control mechanisms may	 allow
       you to power control a sub-device within	the system rather than the en-
       tire system itself.

       By specifying an	OEM power type via  --oem-power-type  on  the  command
       line  or	freeipmi.conf(5), you can instruct ipmipower to	execute	alter-
       nate power control implementations over the standard ones. Depending on
       the  OEM	extension, some	power control commands may no longer be	avail-
       able. For example, an OEM extension may allow on	but  not  cycle.  Spe-
       cific ipmipower options may not longer function either.

       Some  OEM  extensions  may require additional arguments for their power
       control action, such as a sub-device identifier.	 Additional  arguments
       can  be	provided by appending a	plus sign ('+')	and the	extra informa-
       tion to the end of the hostname.	This can be done on the	 command  line
       or in interactive mode. For example, the	hostname mynode+18 would indi-
       cate the	power control operation	should be sent to the host mynode, and
       18  is  the identifier of a possible sub-device to be power controlled.
       The --consolidate-output	option is commonly disabled when using an  OEM
       power control that requires extra arguments.

       Because	OEM  power control may involve subtypes, it is possible	a user
       may wish	to power control multiple sub-devices on the  same  host.  For
       example,	 you  might specify the	hosts mynode+1,mynode+2, indicating to
       power control subdevice 1 and 2 on mynode.  Because  many  BMCs	cannot
       handle  multiple	 IPMI  sessions,  power	control	operations to the same
       host will be serialized internally by ipmipower.

       The following are the current OEM power types available,	along with in-
       formation  on  the  systems they	work with and the power	control	opera-
       tions available.

       C410X  This OEM power type supports the power control of	PCIe slots  on
	      Dell Poweredge C410x systems. It supports	on, off, and stat. The
	      PCIe slot	number ranges from 1-16	and must always	 be  specified
	      when  attempting to power	control	with this extension. For exam-
	      ple, the hostname	mynode+2 would inform ipmipower	to operate  on
	      slot  number  2 on mynode.  The C410x appears to have difficulty
	      handling new slot	power control requests until prior  ones  have
	      completed.  Users	 may  wish  to	strongly  consider  using  the
	      --wait-until-on and --wait-until-off options if  multiple	 slots
	      will be power controlled in short	succession.

       NONE   This informs ipmipower that no OEM power type extension is to be
	      used and standard	IPMI power control is used. This  is  the  de-
	      fault.

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	socket will be created
       for each	host and polled	on, effectively	allowing communication to  all
       hosts  in  parallel.  This will allow communication to large numbers of
       nodes far more quickly than if done in serial.  The -F option can  con-
       figure the number of nodes that can be communicated with	in parallel at
       the same	time.

       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.

EXAMPLES
       Determine the power status of foo[0-2] with null	username and password
	       ipmipower -h foo[0-2] --stat

       Determine the power status of foo[0-2] with non-null username and pass-
       word
	       ipmipower -h foo[0-2] -u	foo -p bar --stat

       Hard reset nodes	foo[0-2] with non-null username	and password
	       ipmipower -h foo[0-2] -u	foo -p bar --reset

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.

       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.

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

IPMIPOWER TROUBLESHOOTING
       When powering on	a powered off machine, the client must have a means by
       which to	resolve	the MAC	address	of the remote machine's	ethernet card.
       While most modern IPMI solutions	support	the ability to ARP and resolve
       addresses when the machine is powered off, some older machines do  not.
       This is typically solved	in one of two ways:

       1)  Enable  gratuitous  ARPs  on	the remote machine. The	remote machine
       will send out a gratuitous ARP, which advertises	the  ethernet  IP  and
       MAC  address  so	 that  other  machines on the network this information
       their local ARP cache. For large	clusters, this method  is  not	recom-
       mended  since  gratuitous  ARPs	can flood the network with unnecessary
       traffic.

       2) Permanently store the	remote machine's MAC address in	the local  ARP
       cache. This is the more common approach on large	clusters.

       Other methods are listed	in the IPMI specification.

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

       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.

       ipmiping	- This workaround option will inform  ipmipower	 to  use  IPMI
       based ping packets instead of RMCP ping packets.	Some motherboards have
       been observed to	not implement RMCP ping/pong support despite being re-
       quired  by  the	IPMI  specification. Issue observed on Intel Windmill,
       Quanta Winterfell, and Wiwynn Windmill.

       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.

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.

       When operating in interactive mode, the exit value will be based	on the
       last power operation executed.

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.

       IPMI specifications do not require BMCs to perform a power control  op-
       eration	before	returning a completion code to the caller.  Therefore,
       it is possible for ipmipower to return power status queries opposite of
       what  you  are  expecting.   For	example, if a "power off" operation is
       performed, a BMC	may return a successful	completion code	 to  ipmipower
       before  the  "power  off"  operation  is	actually performed. Subsequent
       power status queries may	return "on" for	several	seconds, until the BMC
       actually	performs the "power off" operation.

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

COPYRIGHT
       Copyright (C) 2007-2015 Lawrence	Livermore National Security, LLC.
       Copyright (C) 2003-2007 The Regents of the University of	California.

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

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

ipmipower 1.6.6			  2020-09-03			  ipmipower(8)

NAME | SYNOPSIS | DESCRIPTION | GENERAL OPTIONS | IPMIPOWER OPTIONS | IPMIPOWER ADVANCED NETWORK OPTIONS | HOSTRANGED OPTIONS | INTERACTIVE COMMANDS | OEM POWER EXTENSIONS | HOSTRANGED SUPPORT | EXAMPLES | GENERAL TROUBLESHOOTING | IPMIPOWER TROUBLESHOOTING | WORKAROUNDS | 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=ipmipower&sektion=8&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help