IPMI on FreeBSD
Doug White <email@example.com>
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
- 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
- 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
- Sample devices: backplane board, power supply, removable
- Multiple Interface access channels
- 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
- 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
- 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
- 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
- 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
Three sets of tools currently exist for interfacing with IPMI-equipped
- 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.
- 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
All of this code is made available under a standard three-clause BSD license.
and Building page has the tarball link and simple build instructions.
The main repository for changes to this source is now on sourceforge.
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.
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
- 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
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