Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

IPMI: Intelligent Platform Management Interface

News Administration of Remote Servers Recommended Links Dell DRAC iLO BPipmi
ipmitool ipmiutil Lights out management Viewing serial console over network via IPMI 2.0 Humor Etc

The Intelligent Platform Management Interface (IPMI) specification defines a set of common interfaces to a computer system which system administrators can use to monitor system health IPMI and manage the system.

Dell, HP, Intel Corporation and NEC Corporation announced IPMI v1.0 on 1998-09-16, v1.5 on 2001-03-01, and v2.0 on 2004-02-14. New in IPMI V2.0

IPMI is implemented on a hardware chip known as the Baseboard Management Controller (BMC), or Management Controller (MC). BMC operates independently of the operating system and allows administrators to manage a system remotely even in the absence of an operating system, or if the monitored system is powered off, but connected to a power source.

IPMI also functions after the operating system has started, and offers enhanced features when used with system management software.

IPMI version 1.5 and later can send out alerts via a direct serial connection, a local area network (LAN) or a serial over LAN (SOL) connection to a remote client. System administrators can then use IPMI messaging to query platform status, to review hardware logs, or to issue other requests from a remote console through the same connections.

The standard also defines an alerting mechanism for the system to send a simple network management protocol (SNMP) platform event trap (PET). Among them temperature, voltage, fan speed, bus errors, etc. It can perform recovery operations (local or remote system resets and power on/off operations), and an interface for logging without operating system intervention for abnormal or ‘out-of-range’ conditions for later examination and alerting.

BMC is always powered  on even when the main system is OFF, or the operating system has crashed. So the BMC can be configured to look at the status of local hardware from another server for secure remote monitoring and recovery (such as system reset) regardless of the status of the platform.

Along with  main controller  BMC (Baseboard Management Controller ) there can be other management controllers distributed among different system modules that are referred to as "satellite" controllers. Such satellite controllers can implement Web interface like Dell DRAC as well as additional functions. For example remote CDROM drive.

The satellite controllers within the same chassis connect to the BMC via the system interface called IPMB (Intelligent Platform Management Bus/Bridge) — an enhanced implementation of I˛C (Inter-Integrated Circuit). The BMC connects to satellite controllers or another BMC in another chassis via IPMC (Intelligent Platform Management Chassis) bus/bridge. It may be managed with the Remote Management Control Protocol (RMCP), a specialized wire protocol defined by this specification.

A Field Replaceable Unit (FRU) holds the inventory (such as vendor id, manufacturer etc.) of potentially replaceable devices.

A Sensor Data Records (SDR) repository provides the properties of the individual sensors present on the board. For example, the board may contain sensors for temperature, fan speed, and voltage.

Top updates

Bulletin Latest Past week Past month
Google Search


Old News ;-)

[Nov 09, 2017] Looks like IME is running on MINIX by Steven J. Vaughan-Nichols

Nov 07, 2017 |
Matthew Garrett, the well-known Linux and security developer who works for Google, explained recently that, "Intel chipsets for some years have included a Management Engine [ME] , a small microprocessor that runs independently of the main CPU and operating system. Various pieces of software run on the ME, ranging from code to handle media DRM to an implementation of a TPM. AMT [Active Management Technology] is another piece of software running on the ME."

In May, we found out that AMT had a major security flaw , which had been in there for nine -- count 'em -- nine years.

"Fixing this requires a system firmware update in order to provide new ME firmware (including an updated copy of the AMT code)," Garrett wrote. "Many of the affected machines are no longer receiving firmware updates from their manufacturers, and so will probably never get a fix," he said. "Anyone who ever enables AMT on one of these devices will be vulnerable."

Quick! How many of you patched your PC or server's chip firmware? Right. Darn few of you. That's bad. It's not every processor, but if you or your hardware vendor has "explicitly enabled AMT", your machine is still vulnerable to attack.

The Electronic Frontier Foundation (EFF) has called for Intel to provide a way for users to disable ME . Russian researchers have found a way to disable ME after the hardware has initialized, and the main processor has started. That doesn't really help much. ME is already running by then.

But Minnich found that what's going on within the chip is even more troubling. At a presentation at Embedded Linux Conference Europe , he reported that systems using Intel chips that have AMT, are running MINIX.

If you learned about operating systems in the late '80s and early '90s, you knew MINIX as Andrew S Tanenbaum's educational Unix-like operating system. It was used to teach operating system principles. Today, it's best known as the OS that inspired Linus Torvalds to create Linux.

So, what's it doing in Intel chips? A lot. These processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what version or how it's been modified since we don't have the source code. We do know that with it there:

In addition, thanks to Minnich and his fellow researchers' work, MINIX is running on three separate x86 cores on modern chips. There, it's running:

MINIX also has access to your passwords. It can also reimage your computer's firmware even if it's powered off. Let me repeat that. If your computer is "off" but still plugged in, MINIX can still potentially change your computer's fundamental settings.

And, for even more fun, it "can implement self-modifying code that can persist across power cycles". So, if an exploit happens here, even if you unplug your server in one last desperate attempt to save it, the attack will still be there waiting for you when you plug it back in.

How? MINIX can do all this because it runs at a fundamentally lower level.

x86-based computers run their software at different privilege levels or "rings" . Your programs run at ring three, and they have the least access to the hardware. The lower the number your program runs at, the more access they have to the hardware. Rings two and one don't tend to be used . Operating systems run on ring zero. Bare-metal hypervisors, such as Xen , run on ring -1. Unified Extensible Firmware Interface (UEFI) runs on ring -2. MINIX? It runs on ring -3.

You can't see it. You can't control it. It's just humming away there, running your computer. The result, according to Minnich is "there are big giant holes that people can drive exploits through." He continued, "Are you scared yet? If you're not scared yet, maybe I didn't explain it very well, because I sure am scared."

... ... ...


Thu 11 Mar 2010 | Hackery

Tags: , , , ,

Spent a few days deep in the bowels of a couple of datacentres last week, and realised I didn't know enough about Dell's DRAC base management controllers to use them properly. In particular, I didn't know how to mess with the drac settings from within the OS. So spent some of today researching that.

Turns out there are a couple of routes to do this. You can use the Dell native tools (e.g. racadm) included in Dell's OMSA product, or you can use vendor-neutral IPMI, which is well-supported by Dell DRACs. I went with the latter as it's more cross-platform, and the tools come native with CentOS, instead of having to setup Dell's OMSA repositories. The Dell-native tools may give you more functionality, but for what I wanted to do IPMI seems to work just fine.

So installation is just:

yum install OpenIPMI OpenIPMI-tools
chkconfig ipmi on
service ipmi start

and then from the local machine you can use ipmitool to access and manipulate all kinds of useful stuff:

# IPMI commands
ipmitool help
man ipmitool

# To check firmware version
ipmitool mc info
# To reset the management controller
ipmitool mc reset [ warm | cold ]

# Show field-replaceable-unit details
ipmitool fru print

# Show sensor output
ipmitool sdr list
ipmitool sdr type list
ipmitool sdr type Temperature
ipmitool sdr type Fan
ipmitool sdr type 'Power Supply'

# Chassis commands
ipmitool chassis status
ipmitool chassis identify [<interval>]   # turn on front panel identify light (default 15s)
ipmitool [chassis] power soft            # initiate a soft-shutdown via acpi
ipmitool [chassis] power cycle           # issue a hard power off, wait 1s, power on
ipmitool [chassis] power off             # issue a hard power off
ipmitool [chassis] power on              # issue a hard power on
ipmitool [chassis] power reset           # issue a hard reset

# Modify boot device for next reboot
ipmitool chassis bootdev pxe
ipmitool chassis bootdev cdrom
ipmitool chassis bootdev bios

# Logging
ipmitool sel info
ipmitool sel list
ipmitool sel elist                       # extended list (see manpage)
ipmitool sel clear

For remote access, you need to setup user and network settings, either at boot time on the DRAC card itself, or from the OS via ipmitool:

# Display/reset password for default root user (userid '2')
ipmitool user list 1
ipmitool user set password 2 <new_password>

# Display/configure lan settings
ipmitool lan print 1
ipmitool lan set 1 ipsrc [ static | dhcp ]
ipmitool lan set 1 ipaddr
ipmitool lan set 1 netmask
ipmitool lan set 1 defgw ipaddr

Once this is configured you should be able to connect using the 'lan' interface to ipmitool, like this:

ipmitool -I lan -U root -H chassis status

which will prompt you for your ipmi root password, or you can do the following:

echo <new_password> > ~/.racpasswd
chmod 600 ~/.racpasswd

and then use that password file instead of manually entering it each time:

ipmitool -I lan -U root -f ~/.racpasswd -H chassis status

I'm using an 'ipmi' alias that looks like this:

alias ipmi='ipmitool -I lan -U root -f ~/.racpasswd -H'

# which then allows you to do the much shorter:
ipmi chassis status
# OR
ipmi <hostname> chassis status

Finally, if you configure serial console redirection in the bios as follows:

Serial Communication -> Serial Communication:       On with Console Redirection via COM2
Serial Communication -> External Serial Connector:  COM2
Serial Communication -> Redirection After Boot:     Disabled

then you can setup standard serial access in grub.conf and inittab on com2/ttyS1 and get serial console access via IPMI serial-over-lan using the 'lanplus' interface:

ipmitool -I lanplus -U root -f ~/.racpasswd -H sol activate

which I typically use via a shell function:

# ipmi serial-over-lan function
isol() {
   if [ -n "$1" ]; then
       ipmitool -I lanplus -U root -f ~/.racpasswd -H $1 sol activate
       echo "usage: sol <sol_ip>"

# used like:
isol <hostname>

Further reading:

ipmitool Cheatsheet and Configuring DRAC from ipmitool

1) List of helpful ipmitool commands: #ipmitool -I open bmc info | grep -A3 "Firmware Revision" #ipmitool sel #ipmitool sel list #ipmitool raw 0x34 0x11 #ipmitool mc reset cold

2) Configure DRAC from ipmitool

#ipmitool lan set 1 ipsrc static #ipmitool lan set 1 ipaddr <ip add of bmc> #ipmitool lan set 1 netmask <netmask addr> #ipmitool lan set 1 defgw ipaddr <ip add> #ipmitool raw 0x30 0x24 2 #ipmitool raw 0x30 0x24 0 #ipmitool raw 0x30 0x25

[Output of 00 means shared and 02 means dedicated]

#ipmitool mc reset warm

[Aug 20, 2009] Blueprints Using Intelligent Platform Management Interface (IPMI) on IBM System x Linux Platforms

Html version is at IBM Information Center for Linux

Note that while many IBM Blades include a BMC, remote management of the BladeCenter is typically done through the Management Module using a different protocol. Also, the Blade's BMC LAN channel is limited to internal access by the Management Module. However, you can run most of the IPMItool commands covered in this Blueprint directly to the BMC of the Blade using the OpenIPMI driver.

OpenIPMI Driver is included in all IBM supported Red Hat Enterprise Linux and Suse Linux Enterprise Server distributions.

The driver consists of several driver modules. In RHEL 5.2 and SLES 10.2, the OpenIPMI modular drivers that may be loaded include ipmi_msghandler, ipmi_devintf, ipmi_si, ipmi_watchdog, and ipmi_poweroff.

There is also a legacy, closed source deprecated driver known as the OSA IPMI driver which is in use mainly with older versions of Linux. However, you should consider using the open source driver OpenIPMI.

Activating the IPMI Service

In default RHEL5 and SLES10 installations, the OpenIPMI drivers are automatically installed as modules To start using IPMI to manage your hardware, activate the IPMI service by issuing the following commands:

# chkconfig ipmi on
# service ipmi start
# service ipmi status
ipmi_msghandler module loaded.
ipmi_si module loaded.
ipmi_devintf module loaded.
/dev/ipmi0 exists.
Note: This loads the 3 basic drivers: ipmi_msghandler, ipmi_devintf, ipmi_si.


IPMItool is a utility to monitor, configure, and manage devices that support the Intelligent Platform Management Interface (IPMI).

Installing IPMItool

Although the IPMItool utility is available with most recent Linux distributions, this blueprint uses version IPMItool v1.8.10. Follow the instructions to download, build, and install the latest version of the IPMItool utility:

Download latest Linux Open Source IPMItool utility (MIGR 5069505) at systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5069538&brandind=5000008. A C compiler is the prerequisite of the install and needs to be available. For RHEL, the Development Tools package group is needed. For SLES, the C/C++ Complier & Tools package pattern is sufficient.

This blueprint includes some 'passive probing' commands to allow you to see specific aspects of your system through use of IPMItool. Each system can provide somewhat unique output in response to these commands. In some cases you will want to refer to the IPMI Specification to help interpret the results.

Considerations using IPMItool

Before using IPMItool, there are some important considerations that you must keep in mind.

Log In as Root IPMItool commands works only for root user.

IPMItool Version on Linux This blueprint is based on IPMItool version 1.8.10. To check your version:

# ipmitool -V

ipmitool version 1.8.10

You can use the instructions provided in section to install the IPMItoo version 1.8.10 l if needed.

IPMI Version on BMC

It is important to know what IPMI hardware version you have on the BMC in your system. Systems with IPMI v2.0 based BMCs have been out for several years plus many more have IPMI v1.5. Appendix B, "New in IPMI V2.0," on page 23 provides a short summary of the differences between IPMI v1.5 and IPMI v2.0 based BMCs.

The instructions in this blueprint are tested on both IPMI 1.5 and IPMI 2.0 hardware. However, only IPMI2.0 version is documented. You should expect possible differences in the IPMItool command outputs compared to this blueprint if your hardware is based on IPMI v1.5. The Serial Over LAN (SOL) section assumes your system has IPMI v2.0.If you have an IBM standalone server containing IPMI v1.5, it may be possible to upgrade the BMC firmware to IPMI v2.0. See the Baseboard Management Controller (BMC)

Update at

fora list of applicable systems and latest version of BMC firmware. These instructions were tested on an IBMxSeries 366 (Type 8863) that had been upgraded from IPMI v1.5 to IPMI v2.0.The BMC (or MC) command allows you to directly interact with the BMC and to display information about the BMC hardware. Issue the following command to get information about your BMC hardware and IPMI version. Note that the BMC in this hardware is of version 2.0:

# ipmitool mc info Device ID : 32
Device Revision : 0
Firmware Revision : 2.7
IPMI Version : 2.0
Manufacturer ID : 2
Manufacturer Name : Unknown (0x02)
Product ID : 7 (0x0007)
Product Name : Unknown (0x7)
Device Available : yes
Provides Device SDRs : no
Additional Device Support :
Sensor Device
SDR Repository Device
SEL Device
FRU Inventory Device
IPMB Event Receiver
IPMB Event Generator
Chassis Device
Aux Firmware Rev Info :

IPMItool commands

For more information about IPMItool, there are two good references for IPMItool commands:

1. The man page (new and improved with v1.8.10)

2. The built-in command line help provides a list of IPMItool commands:

# ipmitool help

You can also get help for many specific IPMItool commands by adding the word help after the command:

# ipmitool channel help

Logical Channels

IPMI uses logical channels as BMC communication pathways. Two key channels are the Open Interface and the LAN channel. The Open Interface is also called the System Interface and uses the OpenIPMI kernel driver. The LAN channel is used when the IPMItool is communicating with a remote machine's BMC. The command line -I option specifies the channel. The Open Interface is the default if you do not use this option. For example, both of these commands provide the same result:

# ipmitool -I open mc info

# ipmitool mc info

Since IPMI is a standardized, message-based interface, in general all the IPMItool commands in this blueprint work with all the IPMItool Interfaces (Open or System, LAN, and others). IPMItool uses the System Interface (″in-band″) so that the IPMI command executes on the local BMC through the OpenIPMI Driver. IPMItool can also use a LAN Interface to receive IPMI responses from a remote IPMI based platform, if you know its BMC IP address and have user access to the BMC. To find this information, you need to discover the specific channel numbers for your IPMI system. IBM platforms with IPMI assign the System Interface to channel number 15 and the LAN to channel number 1. You can discover details for each channel in your system by using info along with the channel number (in a range from 0 to 15). If you do not provide a channel number the BMC will always reply with information about the current channel that you are running the command on. For example, in this case the current channel is the System Interface and is on channel 15 (oxf).

# ipmitool channel info
Channel 0xf info: br> Channel Medium Type : System Interface
Channel Protocol Type : KCS
Session Support : session-less
Active Session Count : 0
Protocol Vendor ID : 7154
You can also use the following command and receive the same output as above:
# ipmitool channel info 15
All IBM platforms with IPMI also have a LAN interface which is assigned to channel number 1:
# ipmitool channel info 1
Channel 0x1 info:
Channel Medium Type : 802.3 LAN
Channel Protocol Type : IPMB-1.0
Session Support : multi-session
Active Session Count : 0
Protocol Vendor ID : 7154
Volatile(active) Settings
Alerting : enabled
Per-message Auth : disabled
User Level Auth : enabled
Access Mode : always available
Non-Volatile Settings
Alerting : enabled
Per-message Auth : disabled
User Level Auth : enabled
Access Mode : always available

See the IPMI specification for more details on available IPMI channels/communication pathways.

Chapter 2. Checking your system health

You can use your system BMC to keep watch of your system vital signs. Additionally, the BMC logs any potential health issues into the System Event Log (SEL). The vital signs are available for viewing with the

ipmitool Sensor Data Record (SDR) command.

To see all available SDRs in your system, issue the following command:

# ipmitool sdr list

For illustration purposes, focus on CPU temperature readings. In IPMI 2.0 environment running RHEL5.2, the temperature readings are listed as CPU * Temp records. To see all CPU temperature reading, issue the following Sensor Data Record (SDR) command:

# ipmitool sdr list | grep Temp
Ambient Temp | 24 degrees C | ok
CPU 1 Temp | 42 degrees C | ok
CPU 2 Temp | disabled | ns
CPU 3 Temp | disabled | ns
CPU 4 Temp | disabled | ns

The first column is the sensorid name. This name is used to reference the sensor in other commands as well. The sensor reading in the second column indicates a healthy system at the moment. The value of disabled for several CPU's indicates that these CPU sockets are empty. The last column displays the reading relative to threshold values. You can find more information about the possible CPU temperature Sensor States by examining those of CPU 1's. Use a command utilizing the sensorid name, ″CPU 1 Temp″, in this case. Note when the sensorid name contains blanks it must be surrounded by double quotes. The following command lists all the possible states of CPU 1's temperature.

# ipmitool event "CPU 1 Temp" list
Finding sensor CPU 1 Temp... ok
Sensor States:
lnr : Lower Non-Recoverable
lcr : Lower Critical
lnc : Lower Non-Critical
unc : Upper Non-Critical
ucr : Upper Critical
unr : Upper Non-Recoverable

If a CPU temperature becomes too cold, a new record is created in the System Event Log (SEL). You can simulate a CPU temperature becoming too cold by selecting a sensorid name and a Sensor State name -"CPU 1 Temp" and "lnc: Lower Non-Critical" respectively, to pretend that CPU 1 is overheating to low temperature:

# ipmitool event "CPU 1 Temp" "lnc : Lower Non-Critical"
Finding sensor CPU 1 Temp... ok
0 | Pre-Init Time-stamp | Temperature CPU 1 Temp | Lower Non-critica l |
going low | Reading -128 < Threshold -128 degrees C

This command simulates a -128 Celsius Reading (below the -128 Celsius threshold) - even though the actual CPU 1 Reading from the sdr list command was 42 Celsius and creates a log in the System Event Log (SEL). You can confirm that the event is actually logged with the SEL command by looking at the last event entry:

# ipmitool sel list | tail -1
1c0 | 11/19/2008 | 21:38:22 | Temperature #0x98 | Lower Non-critical going low

The first column is a unique record number in hexadecimal, the next two are a date and time stamp, the fourth shows the corresponding sensor, and the final shows what happened. Finally, you can look back in time to see if your system had a possible bad health event by showing the entire history of your System Event Log:

# ipmitool sel list

The ipmievd deamon is related to the SEL. ipmievd is an event daemon that is packaged with IPMItool that listens for events from the BMC that are being sent to the SEL and also log those messages to a system log file. The daemon can run in one of two modes: either using the Event Message Buffer and asynchronous event notification from the OpenIPMI kernel driver or actively polling the contents of the SEL for new events. See the ipmievd man page for more information.

Chapter 3. Setting up password controls

You can set up password controls for BMC LAN access in stand-alone System x hardware. The following shows how to set up password control for two users in the LAN channel. They are the default user with userid 2 and the null user. See Section 6.9 User and Password Support of the IPMI Specification for more information about users and passwords. Additionally, there is an IPMI Specification convention relating to creation of a 'Null' user on userid #1 - section 6.9.1 Anonymous Login Convention for information about using a 'Null' user. This possibility is intended to support login by a separate software application if desired. Part of the convention is to set it up on userid #1 so the BMC can readily report whether anonymous login is enabled or not.

Note: To reduce vulnerability it is strongly advised that the IPMI LAN interface only be enabled in a trusted environment where system security is not an issue, or where it is connected to a dedicated secure or private network. Instructions in this section do not apply to IBM BladeCenters. IBM BladeCenter do not have IPMI remote access to the BMC on a Blade (the BMC IP address is not available outside of the BladeCenter). You should instead use remote management through the BladeCenter Management Module interface. For more information, see IBM eServer xSeries and BladeCenter Server Management Redbook. The BMC can be configured to support multiple users and passwords for all channels except the Open channel. Typically the same user and same password should work for all the BMC channels. Instructions to set up password control for other channels are not included here as they are less commonly used. The instructions in this section are for LAN channel only. User IDs and privilege levels are unique for each channel. To see the current user IDs in use and related information for the LAN channel (0x1):

# ipmitool user list 1

ID Name Callin Link Auth IPMI Msg Channel Priv Limit
2 USERID true false true ADMINISTRATOR

Note that on all IBM BMCs, the default userid 2 is USERID with a password of PASSW0RD with a zero
(0) instead of an O.
To change the name of userid 2 do the following:

# ipmitool user set name 2 <New User ID>

Set a new password for userid 2:

# ipmitool user set password 2 ipmitool user set password 2 <New Password>

You can also use a null user for anonymous login. Change the password for the null user (userid 1) on
the LAN channel:

# ipmitool lan set 1 password <New Password>

You can see the users you have set up and find the new name (user ID) for userid 2 user. The null user is
not listed using this command when it is disabled in the BMC BIOS settings:

# ipmitool user list 1

Now that you have the users configured, set up the BMC LAN channel parameters to secure it for your
situation by setting its IP address, netmask, and snmp public community string:

# ipmitool lan set 1 ipaddr <Your IP address for the BMC>
# ipmitool lan set 1 netmask <Your Subnet Mask>
# ipmitool lan set 1 snmp <Your SNMP>

There may be other LAN parameters you want to set. You can use the help to see the possibilities:

# ipmitool lan set help

Check your LAN parameter settings with the following command. This shows output from the test environment:

# ipmitool lan print

Set in Progress : Set Complete

Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback :
: Operator : MD2 MD5 PASSWORD
: Admin : MD2 MD5 PASSWORD
: OEM :
IP Address Source : BIOS Assigned Address

IP Address :
Subnet Mask :

MAC Address : 00:14:5e:1b:c6:c1

SNMP Community String : public

IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl : 2.0 seconds
Default Gateway IP :
Default Gateway MAC : 00:00:00:00:00:00
Backup Gateway IP :
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : aaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: u=USER

If these results are what you expect, no unauthorized person can use the published defaults to access your BMC LAN channel to remotely cause your system to power cycle or other unauthorized activities. If you lose the BMC userid passwords, you can simply set new ones again with the above user commands, provided that you can login to the system and run ipmitool as root.

Chapter 4. Power cycling your system

The IPMItool chassis command can be used to obtain information and the status of a system locally or remotely. In the test environment, running ipmitool chassis status command returned the following results:

# ipmitool chassis status System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false

You can use the IPMItool on a second server (it doesn't need to have IPMI hardware), to display the
chassis status of your first IPMI server by accessing through the BMC LAN interface. To do this you need
the BMC IP address, and you'll need to know the user ID and password for the remote BMC's LAN channel. To find out the BMC IP address of the remote IPMI server, issue ipmitool lan print in the remote server, as shown in the end of previous section.

# ipmitool lan print | grep "IP Address "
IP Address :

To view the chassis status from a remote server, use the following command. Note it is necessary to use
the '-I' (Capital I) option to specific use of the LAN channel. Use your BMC IP address for the '-H' parameter:

# ipmitool -I lan -H -U <User ID> -a chassis status

Note the '-U' option parameter is the 'userid' name. The '-a' option indicates to prompt for password; or you can use '-f <filename>' to get the password from a file; or you can use '-P <password>' to include the password on the command line. If the above command returns correctly, you can gracefully remote power cycle your system. Be very careful with this command as it might cause you to have to physically locate the machine and manually boot the system back on:

# ipmitool -I lan -H -U <User ID> -a chassis power cycle System Power : on Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false

Chapter 5. IPMI Watchdog Timer

IPMI includes a hardware timer built into the BMC that can be setup to automatically recover a hung or
crashed system. You can use this timer with the Linux software watchdog daemon. You do this by setting up two timers:

Note the Linux watchdog daemon process must be continually running on the system after the IPMI hardware watchdog timer has been setup. The daemon must periodically ″poke″ the IPMI watchdog hardware timer (through the OpenIPMI watchdog driver). The "poke" is needed to keep the IPMI watchdog hardware timer from causing a system reset (or some other configurable action). Consequently, if the system becomes hung and the software watchdog daemon can no longer ″poke″ the IPMI hardware watchdog timer, the hardware timer will continue to count down and trigger the desired system event (power down, system reset, etc.).

Setting up the IPMI Watchdog Timer

There are three main steps to set up the IPMI watchdog timer. Follow the instructions found on Linux Open Source watchdog daemon support replaces IPMI ASR - Servers at 5069505&brandind=5000008. The followings are some tips for each of the steps described, and also some additional steps to help you get through the process.

1. The first step is the enablement of the IPMI hardware timer. You will have to reboot the machine and get into the BIOS and find the option to set the two BMC watchdog variables. We found the option listed under Advanced Settings in our test environment.

2. The second step describes configuring and activating the IPMI watchdog driver. You can use one of two methods described in the instructions. We recommend the use of the method 2a. The activation of the ipmi service should output:

# service ipmi start Starting ipmi drivers: done

Starting ipmi_watchdog driver: done

3. After step 2, issue the following to stop the watchdog timer so that you have time to complete step 3:

# ipmitool mc watchdog off

Watchdog Timer Shutoff successful -- timer stopped

4. Before starting step 3 in the instructions, check to see if the configuration of your hardware watchdog

timer is setup correctly:

# ipmitool mc watchdog get

Watchdog Timer Use: SMS/OS (0x04)

Watchdog Timer Is: Stopped

Watchdog Timer Actions: No action (0x00)

Pre-timeout interval: 0 seconds

Timer Expiration Flags: 0x00

Initial Countdown: 300 sec

Present Countdown: 300 sec

5. The third step of the instructions is the configuration and activation of the watchdog daemon. Both RHEL5.2 and SLES10SP2 do not install the daemon by default. Therefore you need to install the watchdog daemon manually, as described in the Workaround step 1 of the instruction URL. This workaround involves downloading the latest watchdog package, compiling, and installing it.

6. After step 3, issue the following command to start the watchdog timer:

# ipmitool mc watchdog on

7. Now all the configuration is done and all related services are activated, the watchdog timer would reboot the hardware every 300 seconds, but at the same time a software timer resets the hardware watchdog timer every 5 seconds. By issuing the following command a few times and comparing the initial and present countdown values, you can see that the timer is constantly being reset back to 300 seconds.

# ipmitool mc watchdog get

Watchdog Timer Use: Digital State (0x44)

Watchdog Timer Is: Started/Running

Watchdog Timer Actions: Power Cycle (0x03)

Pre-timeout interval: 0 seconds

Timer Expiration Flags: 0x00

Initial Countdown: 300 sec

Present Countdown: 295 sec

8. If the system gets hung for some reason, the hardware timer will countdown and cause a power cycle

within 5 minutes.

9. To activate the watchdog so it will restart on every reboot, run the following command:

# chkconfig watchdog on

Turning off the Watchdog

It may become necessary to turn off the watchdog occasionally without triggering the watchdog to fire, such as when performing a BMC firmware flash (be sure to disable the watchdog daemon and driver before flashing). The IPMItool utility may be used to safely turn off a running hardware watchdog and so should be installed prior to the first use of the IPMI watchdog. For instructions on how to safely turn off the IPMI hardware watchdog using IPMItool v1.8.9 or prior versions, how to safely stop the Linux watchdog daemon, and how to unload the OpenIPMI watchdog driver see Safely disabling the open source watchdog used with OpenIPMI at systems/support/supportsite.wss/docdisplay?brandind=5000008&lndocid=MIGR-5075280. The IPMItool v1.8.10 includes a new watchdog command interface for safely turning off a running IPMI hardware watchdog timer:

# ipmitool mc watchdog off

Additional commands for Watchdog Timer adminstration

In addition to starting and stopping Watchdog Timer, there are several other commands that you can use for administering Watchdog Timer. You can see the Present Countdown value counting down at any time by issuing:

# ipmitool mc watchdog get

You can stop and start the Watchdog hardware timer prior to completion of the 300 second countdown by issuing:

#ipmitool mc watchdog off #ipmitool mc watchdog on

Note for IPMItool v1.8.9 and earlier, you can use the raw command to to the watchdog hardware:

# ipmitool raw 0x06 0x25

Sift through the bytes returned to find the current running status. For example:

# ipmitool raw 0x06 0x25 04 00 00 00 b8 0b b8 0b

The ″0″ portion of the first byte ″04″ indicates that the timer is off. If the timer were on, this byte would have been ″44″. The other bytes (in sequence) indicate the following: 00 = No pre-timeout set, no timeout action set 00 = Pre-timeout interval set to 0

00 = Timer hasn't expired yet

b8 0b = Initial countdown value. 0b is the most significant byte so countdown is set to 0x0bb8 (100

ms/count) which is 5 minutes.

b8 0b = Present countdown value. As with Initial countdown value, 0b is the most significant byte.

Should match Initial countdown value when the timer is first set.

For more information, see section 27.7 of the IPMI specification.

A simple howto for compile OpenIPMI 2.0 on SuSE Linux


1, Why write this text
I have to say, OpenIPMI is pretty hard to compile. I always have
difficalty on every new version compiling. This simple text is to help
people compile OpenIPMI more easy on SuSE Linux.

2, Preparation
On OpenSuSE10.1, SLES10, SLED10, the OpenIPMI 1.4 is included. OpenIPMI
2.0 is still under testing in OpenSuSE10.2 yet.

In order to compile, install and run OpenIPMI 2.0 binaries and
libraries, it is recommended to uninstall the installed OpenIPMI 1.4

Compiling OpenIPMI 2.0 needs more auxiliary packages. All the packages
can be found in SLE10/OpenSuSE SDK, some of them can not be found in
distribution media.

Installing OpenIPMI 2.0 is easy, all the auxiliary packages are
available on distribution media.

These packages should be install into your SuSE Linux before compiling
OpenIPMI 2.0:
aaa_base acl attr audit-libs autoconf automake bash bind-libs bind-utils
binutils bison bzip2 coreutils cpio cpp cracklib cvs cyrus-sasl db dia
diffutils e2fsprogs file filesystem fillup findutils flex gawk gcc gd
gd-devel gdbm gdbm-devel gettext gettext-devel glib glib-devel glibc
glibc-devel glibc-locale gpm grep groff gzip info insserv klogd
latex-ucs less libacl libattr libcom_err libgcc libjpeg libjpeg-devel
libpng libpng-devel libnscd libstdc++ libtool libxcrypt libzio m4 make
man mktemp module-init-tools ncurses ncurses-devel net-tools netcfg
openldap2-client openssl pam pam-modules patch perl permissions popt
popt-devel procinfo procps psmisc pwdutils python python-devel rcs
readline rpm sed strace swig sysvinit tar tcl tcl-devel tcpd te_latex
texinfo timezone tix unzip util-linux vim zlib zlib-devel.

Take it easy, most of the packages are installed when you selected
develop group. Just watch out to make sure the bellowed packages are
gd gd-devel swig swig-doc glib-devel swig-examples latex-ucs tcl-devel
libjpeg-devel te_latex libjpeg tetex libpng tix libpng-devel

Finally, do not forget download the source code from source forge.

3, Configuration
use the command line:
./configure --with-tcl=yes --with-tclcflags="-I /usr/include"

On SuSE Linux Code 10 (OpenSuSE 10.1, SLES/D 10), the default path of
tcl is different to the one in OpenIPMI sourcecode. We need to assign
the arbitrary value by configure.

4, Make
Typing 'make' will compile all the sourcecode.
After compilation completed, typing 'make rungui' can invoke the
Typing 'make install' will install all the binaries, scripts and

5, Build RPM
OpenIPMI packaging is different between SuSE version and sourceforge
version. So, typing 'make rpm' can not generate a set of RPM packages
for SuSE Linux.

The template of RPM spec file should be modified in order to build RPM
packages for SuSE Linux. I'll not touch this topic, we can wait for the
RPM and spec file on OpenSuSE 10.2.


Hope this text helpful to SuSE Linux guys.


IBM Information Center for Linux / Other considerations when using IPMItool

This topic discusses considerations when using IPMItool with multi-node, multi-BMCs, LAN access, and SOL and BMC LAN access with IBM BladeCenter.

Multi-node and Multi-BMCs

LAN Access

Note that IPMItool typically can not access the local machine via the LAN. Local IPMItool commands need to go through the Open Interface (the OpenIPMI Driver) by using -I Open or not specifying a -I option at all for the IPMItool command, thereby defaulting to using the Open Interface.

SOL and BMC LAN Access with IBM BladeCenter

SOL with IBM BladeCenter can be done through the Management Module. See the Serial over LAN (SOL) Setup Guide - BladeCenter at for details on how to do SOL for specific BladeCenter platforms. Also the IBM BladeCenter is internally configured such that the LAN channel for the BMC can only be seen by the Management Module. Thus external management of a BladeCenter is accomplished through the Management Module.

Novell Doc Novell ZENworks 7.2 Linux Management Installation Guide - Managed Device Requirements

Novell ZENworks Linux Management provides advanced features to deploy and manage Dell PowerEdge servers. Before you can use these features, you must install a newer release of the OpenIPMI driver than that included in the currently supported Linux distributions.

The following features are available for Dell PowerEdge servers in ZENworks Linux Management:

Dell provides the updated OpenIPMI driver as well as the Dynamic Kernel Module Support (DKMS) package to assist in compiling and installing the driver.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles



IPMI Specifications

IPMITool/OpenIPMI Projects IPMI Management Utilities The IPMI Management Utilities (ipmiutil) provides various tools to manage an IPMI system, such as view the IPMI firmware log, perform an IPMI reset, configure the IPMI LAN interface, get and set sensor thresholds, and so on.

Dell OpenIPMI drivers (RHEL/SLES packages)

Dell PowerSolutions Articles

Managing and Monitoring High-Performance Computing Clusters with IPMI

Managing Dell PowerEdge servers using IPMITool



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: June 15, 2018