Intelligent Platform Management Interface IPMI

Subscribe to the IPMI mailing list.

IPMI Setup for Workstations running FreeBSD

IPMI Specification Features

Session-based Access (for LAN and serial channels)

• Supports multiple username/password/access levels
• MD5 or MD2 hashing of password and session data for authentication
• Also supports plaintext password or No authentication for secure channels

Link-level Authentication supported for Serial/PPP

System Sensor

• Data collection (fan speed, temperature, power supply status)
• System Event Log inspection and event posting (for example, memory errors, system boots, and chassis intrusions are logged to the SEL)

Sensor Data Repository (sensor configuration information)

• Max/Min/Hysteresis watermarks for event generation
• Enable/Disable/Present/Not Present flags
• Translation of raw sensor values into value & units

Field-Replaceable Unit (FRU) repository

• Lists of devices in system, including serial numbers in many cases
• Sample devices: backplane board, power supply, removable devices

Multiple Interface access channels

• LAN
• Serial: PPP, Basic, Terminal
• System: Keyboard Controller Style (KCS), Server Management Interface Chip (SMIC), Block Transfer (BT) via System I/O space

Inter-channel messaging

• LAN can send messages to System Interfaces or other devices on internal Intelligent Platform Management Busses (IPMB) as bridged by the BMC
• Inter-Chassis Management Bus (ICMB) allows multiple chassis to communicate
• BMC can broker messages to other Private Management Buses internal to the system
• Most buses use I2C and raw messages can be sent using I2C Master commands via the BMC

Chassis Control

• Reset
• Power On/Off/Cycle
• Send NMI
• Chassis Status

Alerting and Paging

• Can send IPMI messages, numeric or text pages, and SNMP traps to alert operators to system problems
• Events can be filtered to cause different actions based on severity

Basic Hardware Monitoring

• Unified Watchdog Timer
• Power-On Hours Timer

While not IPMI-mandated features per se, some platforms (the Intels in particular) implement these management features which are controllable with IPMI:

• BIOS I/O redirection to a serial port, including post-boot programs that utilize BIOS video routines, i.e. DOS
• Alternative boot to a repair partition

Current Progress
Three sets of tools currently exist for interfacing with IPMI-equipped computers.

KCS

• A userland driver can communicate with the KCS interface.
• A simple command-line C program that can communicate with the system BMC. The command and request bytes are given on the command line, and a response is displayed as hex bytes with the standard IPMI/KCS return bytes decoded.
• Some small programs that execute particular command(s) and decode the output for inspection.

SMIC

• A userland driver and simple command executor adapted from the KCS one exist for testing.

Python IPMI

• A Python module that implements IPMI interfaces and commands. The module takes care of session management, including authentication. The module provides a method to send raw commands and receive responses.
• Supported interfaces: KCS, SMIC, LAN
• The module also provides accessory functions for handing data from the SDR and FRU repositories, reading and converting sensor values, controlling chassis functions, and reading the SEL.
• A sample program that uses the module(s) to retrieve and decode SEL and SDR info, perform chassis control, and return a converted sensor value.

All of this code is made available under a standard three-clause BSD license.

Design Ideas

The following tools or features are currently under consideration.

• A command-line tool to request frequently desired information and return it to stdout. The return format would be machine-readable and be targeted at automated monitoring and/or data collection. The output format could be as easy as whitespace-separation, or as complex as XML.
• A GUI browser to pick through sensor or System Event Log (SEL) records and display them in a table format.
• A daemon that polls important sensor and SEL events and write syslog messages if important events occur.
• A remote-control application that allows easy power control of remote systems, removing the need for dedicated hardware (power manager strips / APCs).
• A daemon to broker requests to the IPMI interfaces, since writing to I/O space from userland requires root privileges to run i386_set_ioperm (2).

Future Directions, Ideas, and Unfocused Rambling

• Intel has an advertising slick on their Intel Server Management page promising to bring full serial redirection over LAN via IPMI to a future version of the specification. This would remove the need for separate console servers entirely, although some may contend that it puts a heavy burden on the NIC and network infrastructure; if the NIC fails, the system becomes unreachable, even for management. Currently IPMI does support redirecting the BIOS video out the serial port and the LAN (this includes anything else that uses the BIOS video routines, including DOS and option ROMs, like SCSI setup).
• Hopefully, Intel will make available their modifications to ucd-snmp so that their Windows tools (Direct Platform Control (DPC)) can access the system and request the system to shut down nicely before restarting. Right now, the OS is "Unknown" so any actions cause an abrupt restart. The ucd-snmp modifications are binary-only on RedHat and use (ancient) version 4.1.1.
• On a related thread, Intel is putting forward an initiative, called Metolius, which would push much of the IPMI driver functionality into ACPI. This would require the OS to only make ACPI method calls to access IPMI features. The BMC could then signal the OS via ACPI instead of requring custom daemons. Considering the track record of ACPI and DSDT methods, this has a long way to go before becoming reality.
• Encryption over the LAN channels would be a big bonus. The authentication isn't great, but MD5 hashing with sequence numbers is better than nothing. End-to-end encryption is really necessary for console-over-LAN, where root passwords going out in the clear would be a Bad Thing.
• A newbus driver might be fun to put together since the BMC acts like a big bridge to multiple busses that can be addressed directly. It's not clear at this point which System Interfaces will end up in common use. IPMI mandates that one of the specified interfaces exist in the system, and there doesn't appear to be any consensus as to which to implement. Intel primarily uses KCS while HP uses SMIC.
• Some of the config info for the system interface is hidden in the SMBIOS tables. This is a problem for early IPMI systems that chose not to use the reference implemention's addresses (like the HP LH 6000). Also, the BMC interrupt is stored there (if not directly configurable in BIOS). Hopefully someone will add a command to get the BMC hardware config information so you could start at KCS and move to BT once you have the resource information.

Session-based Access (for LAN and serial channels)

These are recommended settings for the iNET1700, iNET2200, (and similar) servers for optimal use under FreeBSD, with full console redirection from BIOS and from loader(8), and enabling remote control over LAN (optional). Only the "Setup Utilities" section should be required; the IPMI commands can be used for automated reconfiguration if desired.
This configuration assumes that the machine will be connected to a (secure) LAN and that the serial console will be connected to a console server or similar device, and not a modem. This means that you do not plan on using the built-in modem paging capabilities and/or PPP or Direct mode IPMI sessions to the BMC (from a tool such as Intel Direct Platform Control).  
Some of the items give the data bytes for equivalent IPMI commands. Use with caution! Note: This is a work in progress. This page, and the associated program(s) found on the link below will be updated as work is further completed and validated on other iNET servers.

Setup Utilities

BIOS Settings

Change Serial Port2 to COM1 settings

• Address 3F8, IRQ 4
• This makes the onboard RJ45 ports COM1 and thus the default serial console.
• You can disable Serial Port1 if it isn't present on your system (i.e., iNET1700/2200 chassis)
• Put "-h" in /boot.config to make FreeBSD use the serial console by default. See Handbook section 15.6 ("Setting Up the Serial Console") for details.

Change BIOS console redirection settings (under Server / Console Redirection)

• Enable serial console redirection
• Serial port: COM1 3F8 IRQ 4

Baud Rate

• 9600 if using default FreeBSD speeds
• Whatever you like if you have built new boot1/2/loader with BOOT_COMCONSOLE_SPEED set (I've rebuilt it to use 115200)

Flow Control

• Whatever your hardware supports

System Setup Utility (SSU) Settings

Platform Event Manager

Configure EMP

• Access Mode to "Disabled"

Configure PEP

• Disable PEP (unchecked)

Configure LAN (optional, if LAN IPMI access desired)

• set static IP or DHCP
• Disable LAN alerts
• Access Mode to "Always available"
• Must set SNMP trap string if enabled

IPMI Commands

Set Channel Access for Channel #1 (serial) -- 0x20

• Same effect as changing the SSU settings above for EMP
• Platform Event Filtering off
• Disable access mode (always shunt to SYSTEM [BIOS & host])
  • These can be configured in SSU. 'Shared' channel access mode can't, but I don't think we want to use it on this system.

Set Serial Mux -- 0x2

• Updates Enabled
• set to SYSTEM

Set Serial Config --
Modepage 8 -- 0x11 0x7

• Enable switch keys
• disable autodetect
• disable reset keys

Downloading and Building IPMI on FreeBSD

The tools provided in the tarball are intended as a sneaky-peek at what is to come, and to give some tools for finding hardware support for IPMI.  I would not suggest using these in any serious application yet.  The APIs are not fixed and in fact change daily.  There are as yet unknown hardware dependencies.  There are certainly bugs.

Download: ipmi-0.2.tar.gz

Building

For the KCS and SMIC userland drivers, you generally just need to grab smic-common.c or kcs-common.c, ipmi/ipmi-common.c and the appropriate header files.  Eventually this will get built into a library.
ioport is a Python C module that provides Python routines for calling i386_set_ioperm(2), inb(), and outb().  To build it, go into the ioport directory and run:

• make -f Makefile.pre.in boot
• make
• make install

Request For Comments

The following mailing list has been created for public discussion and comments with respect to IPMI.
Please subscribe to our IPMI email list