以下內容取自 https://github.com/ipmitool/ipmitool README
概觀
========
ipmitool是一個用於管理和配置於有 support IPMI (Intelligent Platform Management Interface, 智能平台管理界面) 之設備的實用程序。 IPMI是用於監視(monitoring)，記錄(logging)，恢復(recovery)，庫存(inventory)和控制硬體的開放標準，它獨立實現於主CPU，BIOS和OS之外。 服務處理器（或底板管理控制器，Baseboard Management Controller - BMC）是平台管理的核心，其主要目的是處理獨立存在(autonomous)之sensor監控和事件記錄(event logging)功能。
ipmitool程序為此BMC提供了一個簡單的命令行(command-line)介面。
它具有以下功能:
- 讀取sensor數據存儲庫（SDR）
- 印出sensor值，
- 顯示系統事件日誌（SEL）的內容，
- 印出Field Replaceable Unit（FRU）庫存訊息，
- 讀取和設置LAN配置參數以及執行遠程，
- 機箱電源控制。
需求
============
顯然，最大的需求是具有支持IPMI規範的服務處理器的硬體。 許多基於x86的服務器現在都支持IPMI，請向您的硬體供應商諮詢可用產品。
一旦確定擁有所需的硬體，就需要決定如何訪問BMC。 最常見的情況涉及通過系統介面(System Interface)或LAN進行訪問。 （或Serial，但目前ipmitool不支持Serial介面）
系統介面
----------------
有多種類型的系統介面，但它們都很相似到足以允許一個精心設計的驅動程序支持它們。
不同類型的系統介面包括Keyboard Controller Style
(KCS), Block Transfer (BT), System Management Interface Chip (SMIC) 和SMBus。 不同的硬體供應商將有不同的偏好和實現。
在Linux上，OpenIPMI kernel driver應該支持所有這些系統介面，它應該是一個加載正確kernel modules和設置device node以使用系統介面的簡單個體。 不同kernel版本的driver的module名稱略有不同，但對於所有版本，您需要以下兩個modules：
ipmi_msghandler：傳入和傳出訊息處理程序 (incoming and outgoing message handler)
ipmi_devintf：IPMI driver的字符設備介面 (character device interface to IPMI driver)
對於2.4.x和早期2.6.x kernel，您需要根據硬體支持的系統介面類型選擇module。例如：
ipmi_kcs_drv：Keyboard Controller Style (鍵盤控制器樣式) driver
最新的2.6.x kernel已將這些整併到一個module中：
ipmi_si：通用的IPMI系統介面driver
有關於需要哪些kernel modules的更多訊息，請參閱發行版和/或kernel隨附的文件。一旦載入了所需的modules並且driver找到了適合BMC的系統介面，那麼您需要確保/dev/ipmi0的device node指向正確的主編號(major number)。
這是因為OpenIPMI在被載入時會被賦予一個動態分配的主編號，但是由於其他module的存在，這個數字可能是從254開始的任何地方。最簡單的方法是檢查/ proc/devices的輸出，並查看“ipmidev”device所分配的主編號。
ipmitool中包含一個名為ipmi.init的sample script，可用於在bootup時自動執行此過程。
LAN介面
-------------
這通常被稱為“IPMI-over-LAN”，並定義如何將IPMI訊息發送到封裝在遠程管理控制協議（RMCP）數據包中的BMC以及從BMC發送，然後將其作為UDP數據報傳輸。(原文: how IPMI messages can be sent to and from the BMC encapsulated in Remote Management Control Protocol (RMCP) packets which are then transferred as UDP datagrams)
IPMI-over-LAN僅支持1.5及更高版本的IPMI規範。 RMCP的打包格式由Alert Standard Forum (警報標準論壇) 定義，並且已經跟進了添加加密(encryption)和有效負載(payload) 支持的RMCP + 協議。 IPMIv2規範已相應更新，以支持RMCP +協議，並通過加密帶來增強的安全性以及對Serial over LAN的支持(?)。
還有不同類型的LAN介面。某些系統具有共享管理網絡(shared management networks)，其中NIC將攔截UDP數據包到port 623並通過SMBUS將它們重定向到BMC。此類LAN介面要求BMC配置與系統使用的相同settings。僅通過與正常流量共享該介面的性質，它也會增加安全風險。-> 應該是: 即使只是在正常流量下共享該介面, 也會增加安全風險 (原文: It also suffers from an increased security risk just by the nature of sharing that interface with normal traffic.)
我還看到一些實作裡的錯誤，使得在某些情況下IPMI-over-LAN功能被“危險” 啟用。 （特別是RPC可能存在問題，因為它有時會選擇使用port 623而你會丟失response數據包...）
ipmitool中包含一個名為bmclanconf的sample shell script，可藉由使用系統介面去配置設定，以簡化LAN設定的配置過程。 在某些情況下，硬體也會附帶一個utility（通常是DOS bootable CD），用於配置(configuring)啟用(enabling)LAN介面。
為了支持IPMIv2.0介面，您必須具有帶有所需加密功能的OpenSSL library。 最新的發行版應該沒有問題。 IPMIv1.5介面將嘗試在編譯時使用OpenSSL for MD5 hash function，但如果找不到，它將使用內部library。
IPMITOOL中的IPMB Dual Bridging
-------------------------------
IPMI提供標準的訊息介面。
以下概念與此訊息介面相關：
頻道類型 (Channel type)：通信頻道類型（SMS / KCS，IPMB，LAN）
頻道號碼 (Channel number)：頻道描述符(descriptor)
請求者 (Requester)：請求者的地址address
響應者 (Responder)：響應者的地址address
NetFN：請求/響應的邏輯功能(logical function)。
命令 (Command)：命令編號
序列 (Sequence)：標識請求/響應對(pair) 的ID
訊息追踪 (Message tracking)：匹配請求/響應對(pair)的能力(ability)。
當通過任何通道發出通信時，應用程序會格式化一個請求(request)，並期望一個響應(response)。
直接命令 (Direct Command)
--------------
最簡單的通信形式是使用SMS / KCS的“直接命令”
例：
ipmitool raw 6 4
55 00
這將netfn 6（應用程序）的raw command 4（selftest自我測試）發送到KCS，driver負責“訊息追踪 (message tracking)”並提供答案。
充滿希望地告訴各位，該應用程序還包括API的“人類可讀 (human readable)”instance實例：
ipmitool mc selftest
Selftest: passed
橋接命令 (Bridged Command)
---------------
一種稍微複雜的通信模式就是使用IPMB、大家所謂的“橋接命令”。
例：
ipmitool -m 0x94 -t 0x9a raw 6 4
55 00
或者
ipmitool -m 0x94 -t 0x9a mc selftest
Selftest: passed
這仍然從netfn 6（應用程序）向目標target發送相同的命令4（selftest）。 但是，為此，命令（由驅動程序）封裝，並使用command 0x34（發送message）從netfn 6（應用程序）發送到KCS。
然後，驅動程序輪詢(poll) KCS，直到收到message，然後驅動程序使用命令0x33（獲得message）。 驅動程序還追踪message並確保響應與請求匹配。然後它解封message並將響應返回給應用程序。
雙橋命令 (Dual Bridged Command)
--------------------
當應用程序需要到達不直接連接到BMC / IPMC的介面（或通道）上的管理控制器時，事情變得更加醜陋。這是在應用程序必須封裝其消息本身，並請求IPMC處理消息追踪本身的情況下。
它在LAN接口上與IPMITOOL一起運行良好：
ipmitool -H <ip> -U <user> -P <password> -B 0 -T 0x8a -m 0x20 -t 0x7a -b 7
mc selftest
但是，嘗試在本地使用雙橋命令：
ipmitool -B 0 -T 0x9a -m 0x94 -t 0x7a -b 7 mc selftest不起作用
（它返回與ipmitool -m 0x20 -t 0x7a -b 7 mc selftest相同的數據）
原因是“openipmi”接口插入沒有封裝/解封消息，甚至沒有檢測到雙重橋接請求的意圖。
./src/ipmitool -B 0 -T 0x8a -m 0x94 -t 0x7a -b 7 mc selftest
-B 0：第一個橋接級別的傳輸通道（通道0：IPMB-0）
-T 0x8a：轉接目標地址（遠程IPMC地址）
-m 0x94：源地址（IPMB-0上的本地IPMC地址）
-t 0x7a：遠程目標（AMC IPMB-L地址）
-b 7：遠程通道（通道7：IPMB-L）
傳輸源地址（遠程通道上的遠程IPMC地址）由遠程IPMC自動分配。
有效載荷大小限制 (Payload Size Limit)
------------------
因為某些命令會返回大量數據（fru read / get sdr），並且由於使用了2級封裝，因此某些命令將失敗。
例如，這是有效的。
ipmitool -H <ip> -U <user> -P <password> -B 0 -T 0x8a -m 0x94 -t 0x7a -b 7
mc selftest
但這則否：
ipmitool -H <ip> -U <user> -P <password> -B 0 -T 0x8a -m 0x94 -t 0x7a -b 7
fru print
留言列表
