Learn › BMC & Server Management › In-Band Access and the KCS System Interface
Final test: the whole In-Band Access chapter. Read the controller over the network and reduce it to four identity fields, capture a console session onto node01 with script, watch three kernel modules build the in-band path, trace the KCS interface from SMBIOS and ACPI to the driver that resolved it, reach the same controller with ipmitool -I open and no credentials, compare the two identity readings and state the verdict, file the chassis record, power state, event log, sensor table and user table read in band, put the two LAN readings side by side and name the limit, keep the channel access change this controller refuses, and hand back a report with node01 still running. 25 objectives on a real workstation with a real IPMI 2.0 controller at 10.100.0.2.
This chapter covers the following topics:
ipmitool -I open, and the identity comparisonWhat you already know. Chapter 1 read mc info and named the controller identity fields. Chapter 2 moved host power. Chapter 3 read the event log. Chapter 4 read the sensor table. Chapter 6 read the user table and the LAN channel. Chapter 7 attached to the host console over Serial over LAN. Every one of those took the same route: an address, a sign-in and a cipher suite, over the management network. This chapter takes the other route, from inside the host itself, and then proves the two arrive at the same controller.
Objectives. After this chapter you can:
ipmitool -I open, with no address and no sign-in, and read its identity, power state, event log and sensorsThe machine. One workstation called mgmt, one controller at 10.100.0.2, and one managed host called node01 with no network of its own. node01 has to stay running: in band means inside a running host, so a powered-off node01 has no console and no in-band path. Boot is longer than earlier chapters, because the seat installs ipmitool and podman, builds the controller in about 45 seconds and fetches the guest before node01 starts; the lab card waits up to 6 minutes. Every output below was captured on the machine you will get. The machine is yours for 60 minutes and stops itself after 20 minutes idle.
This chapter uses a real Linux workstation and software-emulated IPMI hardware. The protocol requests and replies are real; controller identity, sensor values and host behavior may be seeded or emulated. Supplied physical-hardware captures are labeled separately.
These five questions establish whether you need this chapter in full. Each explanation names the section that covers the point.
>>> Out of band the controller is a host on a network, so it needs an address, a sign-in and a cipher suite. In band it is a device on the managed host board, so it needs none of those, and it needs the one thing the network path does not: a host that is running, with the driver loaded. Section 10.1.
ipmi_si, because it is the driver that talks to the hardwareipmi_devintf, the device interface moduleipmitool, the first time it is run with -I openudev, from a rule shipped with the controller firmware>>> Three modules build the path: ipmi_msghandler is the core message layer, ipmi_devintf creates the character device, and ipmi_si drives the hardware interface. ipmi_si can initialise an interface with no device node present, because the node is somebody else job. Section 10.3.
>>> SMBIOS type 38 and ACPI device IPI0001 both describe the interface, and on this board both proposed KCS at i/o address 0xca2. The driver holds both proposals until it can compare them and then keeps one. Neither table was wrong. Section 10.4.
root account on the host, mapped to the controller administrator/etc/ipmi/credentials>>> There is no session over the system interface, so there is no sign-in, no cipher suite and no privilege negotiation. Being on the host is the authorisation, which is the specification working as designed and the reason section 10.7 matters outside a lab. Sections 10.5 and 10.7.
>>> The in-band path does not use the management network, so a controller made unreachable by its own network configuration is still reachable from the host it manages. The reverse fault, a host that is off or hung, is exactly what the network path is for. Section 10.8.
A controller can be reached two ways, and the difference is not a preference. It is what the controller looks like from where you are standing.
Out of band, the controller is a host on a network. It has an address, it listens on UDP port 623, and it will not answer until you have supplied a user name, a password and a cipher suite it supports. Every chapter so far has taken that path, and it works whether the managed host is running, hung or powered off.
In band, the controller is a device on the managed host own board. There is no address, because there is no network between the two. There is no sign-in, because there is no session to open. What there is instead is a hardware interface, a kernel driver that drives it, and a character device that userspace opens.
Start with the reading everything else is compared against, taken over the network from the seat.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 mc info output: Device ID : 0 Device Revision : 3 Firmware Revision : 1.05 IPMI Version : 2.0 Manufacturer ID : 0 Manufacturer Name : Unknown Product ID : 256 (0x0100) Product Name : Unknown (0x100) Device Available : yes Provides Device SDRs : yes Additional Device Support : Sensor Device SDR Repository Device SEL Device FRU Inventory Device IPMB Event Receiver Chassis Device Aux Firmware Rev Info : 0x00 0x00 0x00 0x00 hint: mc has an info subcommand. The address, the sign-in and the cipher suite are the same ones every chapter has used.
This is the controller Chapter 1 met, unchanged. Four fields out of it carry the whole of this chapter, and they are the four to keep: Device ID, Firmware Revision, Manufacturer ID and Product ID.
Objective 1 files the whole reading in ~/inband/lan-mcinfo.txt. Take it now, before anything is attached to a console, because the comparison in section 10.5.1 needs both halves and this is the half the seat can take.
Note what the command needed before it answered: -H an address, -U and -P an account, -C 3 a cipher suite. Four requirements. The in-band form has none of them.
The -I flag selects a transport, not a dialect. The same IPMI command set rides lanplus over RMCP+ on the network, and rides open over the Linux OpenIPMI device on a managed host. mc info is the same command either way; only the road under it changes.
The seat is not managed by this controller, so there is nothing for -I open to open here. Run it anyway. The refusal is worth meeting deliberately, because running the in-band form on the wrong machine is the most common way to meet it.
prompt: ops@mgmt:~$ answer: ipmitool -I open mc info 2>&1 | head -4 output: Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory hint: The same mc info, with -I open instead of the lanplus flags. Send standard error through the pipe with 2>&1 and keep the first four lines.
The seat is an ordinary Ubuntu workstation. It has no controller of its own, no IPMI kernel modules and no /dev/ipmi0, so -I open has nothing to open.
That is the cleanest proof that -I open is not a network client with the address filled in for you. A network client would have tried to reach something. This one failed at the device node, before any message existed, because the in-band path is local hardware or it is nothing.
The requirements, side by side, are the first thing to write down:
| Path | -I | Needs |
|---|---|---|
| Out of band | lanplus | An address, an account, a cipher suite, a reachable management network |
| In band | open | A running host with the IPMI modules loaded and /dev/ipmi0 present |
A comparison between two long outputs is hard to read and easy to fudge. Reduce the reading to the four fields that identify the controller, and the comparison becomes something a command can settle.
prompt: ops@mgmt:~$ answer: grep -E 'Device ID|Firmware Revision|Manufacturer ID|Product ID' ~/inband/lan-mcinfo.txt output: Device ID : 0 Firmware Revision : 1.05 Manufacturer ID : 0 Product ID : 256 (0x0100) hint: grep -E with the four field names separated by pipe characters, over the file objective 1 filed.
Four lines. Device ID 0, Firmware Revision 1.05, Manufacturer ID 0, Product ID 256 (0x0100).
Objective 2 files them in ~/inband/lan-identity.txt. Add the redirect to the same command: grep -E 'Device ID|Firmware Revision|Manufacturer ID|Product ID' ~/inband/lan-mcinfo.txt > ~/inband/lan-identity.txt.
These four are chosen rather than picked at random. Device ID and Device Revision identify the controller implementation, Firmware Revision identifies the build running on it, and the Manufacturer and Product identifiers are the two numbers a vendor tool keys off. Nothing in the set depends on how the reading was taken, which is exactly the property a comparison needs.
The in-band path runs inside node01, and node01 has no network of its own. The access route provided in this lab is the console the controller serves, which Chapter 7 studied as an object and this chapter uses as a route.
One precondition comes first. In band means inside a running host, so before anything else, establish that node01 is running.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is on hint: chassis power takes a status subcommand.
Chassis Power is on, and objective 4 files it in ~/inband/power.txt.
That objective is graded twice: once on the file, and once live from the controller at the moment you are graded. A machine handed back with node01 powered off is a machine nobody can do this chapter on, because there is no console to attach to and no kernel to load a driver.
Two more facts about the console, both from Chapter 7. This lab's available SOL payload instance accepts one attachment at a time. Other platforms can have different instance and sharing limits. If an attach is refused because this payload is occupied, check ownership and coordinate a release. With suitable access, ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 sol deactivate releases the payload. And the escape sequence out of a console is a tilde followed by a full stop.
Work done inside node01 leaves no trace on the seat, and node01 has no persistent storage: it runs from an initramfs, so nothing written inside it survives and nothing inside it can be a deliverable. A console session is only evidence if it is recorded on this side.
script records a terminal session to a file. It also gives ipmitool the pseudo-terminal it requires for Serial over LAN; without one it prints tcgetattr: Inappropriate ioctl for device and streams nothing. One command does both jobs.
prompt: ops@mgmt:~$ answer: script -qec 'ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 sol activate' ~/inband/session.log output: [ 3.848304] ipmi_si dmi-ipmi-si.0: ipmi_platform: probing via SMBIOS [ 3.849582] ipmi_platform: ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 5 [ 3.850434] ipmi_si: Adding SMBIOS-specified kcs state machine [ 3.855065] ipmi_si IPI0001:00: ipmi_platform: probing via ACPI [ 3.856187] ipmi_si IPI0001:00: ipmi_platform: [io 0x0ca2-0x0ca3] regsize 1 spacing 1 irq 5 [ 3.858214] ipmi_si dmi-ipmi-si.0: Removing SMBIOS-specified kcs state machine in favor of ACPI [ 3.858914] ipmi_si: Adding ACPI-specified kcs state machine [ 3.862863] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x20, irq 5 [ 3.904196] ipmi_si IPI0001:00: Using irq 5 [ 3.923414] ipmi_si IPI0001:00: IPMI message handler: Found new BMC (man_id: 0x000000, prod_id: 0x0100, dev_id: 0x00) [ 3.930966] ipmi_si IPI0001:00: IPMI kcs interface initialized ipmi_si loaded node01: /dev/ipmi0 present, the controller is reachable in band node01. This is the managed host, not the seat. There is no network here. The controller is reached over KCS, on this board:
ipmitool -I open mc info ipmitool -I open chassis status ipmitool -I open sel list
No address and no sign-in: the interface is a device on this machine. sh: can't access tty; job control turned off ~ # Script done on 2026-09-07 04:54:31+00:00 [COMMAND_EXIT_CODE="0"] hint: script -qec runs a command under a pty and records it. The command is the sol activate attach, in single quotes, and the last argument is the file the session lands in.
The banner is the controller telling you the payload is yours. Everything after it is node01 talking on a serial line: the tail of its boot, its own notice about where you are, and a shell prompt.
The prompt is ~ #, the root shell inside node01. Commands entered there are captured in ~/inband/session.log on mgmt. An exercise marked ops@mgmt:~$ runs on the management workstation instead; its file paths refer to mgmt. Read the prompt before entering a command, because the two machines have different files and interfaces.
Objective 5 is graded on that file, and specifically on it carrying the console banner. A file you typed the answers into by hand does not carry it, which is the point.
-q suppresses the start and end messages script normally writes, and -e makes script exit with the status of the command it ran.
Preview this extraction recipe now; run it on mgmt only after completing the host-side commands below and ending the recording. If mc info has not been recorded yet, this command cannot produce its evidence.
One console session produces one file holding everything you typed and everything node01 said back. The lab is graded on separate files, so the last step of the in-band work is cutting that one file into pieces.
The cut has an obvious shape: start at the line where the command was echoed, stop at the next prompt, and drop that prompt line. sed -n takes exactly that range, and head -n -1 drops the last line of it.
prompt: ops@mgmt:~$ answer: sed -n '/ipmitool -I open mc info/,/^~ # /p' ~/inband/session.log | head -n -1 > ~/inband/kcs-mcinfo.txt output: hint: sed -n with a range from the command line to the next prompt, p to print it, piped through head -n -1 to drop the prompt, redirected into the file.
Silent, like every redirect. cat ~/inband/kcs-mcinfo.txt shows what it kept.
This is the form every in-band deliverable uses, and only the command inside the range changes. Objectives 10 and 13 to 17 and 20 are seven files cut this way out of one session, and the sections below name the command each one starts at.
Four more deliverables come out of the same file with grep rather than sed, because they are lines scattered through the boot rather than the output of one command. Sections 10.3.1, 10.4.1 and 10.4.2 cover those.
Run the cuts after you have left the console. The file is complete only once the session ends.
You are at the ~ # prompt inside node01 now. Before reading the controller, look at what makes reading it possible.
The in-band path is built by three kernel modules, and each contributes exactly one thing. None of the three is a network driver, and nothing in the chain consults an address or a password.
prompt: ~ # answer: lsmod output: Module Size Used by Not tainted ipmi_si 86016 0 ipmi_devintf 16384 0 ipmi_msghandler 86016 2 ipmi_si,ipmi_devintf hint: One word. It lists the modules the running kernel has loaded, with their sizes and their dependency counts.
Three modules, and the dependency counts say how they are stacked.
ipmi_msghandler is the core message layer, version 39.2 here. It routes IPMI messages between the things that want to send them and the interface drivers that can carry them. Everything else depends on it, which is why it loads first and why its dependency count is not zero.
ipmi_devintf is the device interface. Its whole job is to expose the message layer as a character device, /dev/ipmi0, and nothing else.
ipmi_si is the system interface driver. It probes and drives the hardware interface between this host and its controller. IPMI 2.0 defines three such interfaces, KCS, SMIC and BT, and ipmi_si handles all three.
Two more exist on real servers and are not loaded here. ipmi_watchdog exposes the controller watchdog from Chapter 9 as /dev/watchdog, and ipmi_ssif does the ipmi_si
Practice In-Band Access and the KCS System Interface in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.