IPMI on FreeBSD

Introduction

The Intelligent Platform Management Interface (IPMI) is a specification that defines system, network, and system board-level interfaces to an Intelligent Management device (sometimes called a Base Management Controller, or BMC) on or attached to the system board that performs monitoring and control operations. The IPMI specification defines interfaces for such operations as power control, System Event Log management, system sensor readings, event handling, system parts inventory, and more. Currently, Intel's server motherboards implement large portions of the IPMI standard and are used as a reference platform for FreeBSD software development. A sample SCB2-based system is the current guinea pig.

IPMI is a specification currently under development by Dell, HP, Intel, and NEC. Information about IPMI is available on Intel's site. Usage of the IPMI specification and tools is made available under a patent agreement with adopters that discourages patent protection of key portions of the specification by requiring any such patent to be licensed with no royalties to the other adopters.

Work on FreeBSD software for IPMI is sponsored by FreeBSD Systems, Inc.

IPMI Specification Features

IPMI pulls together so much information, it's difficult to enumerate an entire feature list.  A short list of features IPMI supports:

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

Download

The Download and Building page has the tarball link and simple build instructions. The main repository for changes to this source is now on sourceforge.

Tested Hardware

The FreeBSD/IPMI software was developed and/or tested on the following machines.  These are just the ones I could get my hands on; it may work with other machines that are of similar specification.  The number in parentheses is the IPMI version the hardware supports.  v1.5 has the multi-channel (LAN/serial) support.

• Intel SCB2 in a SR1200 chassis (v1.5) (Motherboard config instructions here)
• HP LPr (v0.9, with some v1.0 SDRs)
• HP LP1000r (v1.0)
• HP LP2000r (v1.0)
• HP LH6000 (v1.0) (Additional information)

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

Please send email if there's particular information that would be useful in a production context.

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.
  

Request For Comments

If you have comments, suggestions, or questions, please email me directly at <dwhite@freebsd.org>.