IPMI NetFn 相关表项详情
更新时间：2025/06/26
在Gitcode上查看源码修订记录
| openUBMC版本号 | 修订日期 | 修订人 | 修订内容 |
|---|---|---|---|
| 25.06 | 2025/06/26 | pengqiang-gs | 初稿，新增 |
Network Function Codes
| Value(s) | Name | Meaning | Description |
|---|---|---|---|
| 00h, 01h | Chassis | Chassis Device Requests and Responses | 00h identifies the message as a command/request and 01h as a response, relating to the common chassis control and status functions. |
| 02h, 03h | Bridge | Bridge Requests and Responses | 02h (request) or 03h (response) identifies the message as containing data for bridging to the next bus. This data is typically another message, which may also be a bridging message. This function is present only on bridge nodes. |
| 04h, 05h | Sensor/Event | Sensor and Event Requests and Responses | This functionality can be present on any node. 04h identifies the message as a command/request and 05h as a response, relating to the configuration and transmission of Event Messages and system Sensors. |
| 06h, 07h | App | Application Requests and Responses | 06h identifies the message as an application command/request and 07h a response. The exact format of application messages is implementation-specific for a particular device, with the exception of App messages that are defined by the IPMI specifications. Note that it is possible that new versions of this specification will identify new App commands. To avoid possible conflicts with future versions of this specification, it is highly recommended that the OEM/Group network functions be used for providing ‘value added’ functions rather than the App network function code. |
| 08h, 09h | Firmware | Firmware Transfer Requests and Responses | The format of firmware transfer requests and responses matches the format of Application messages. The type and content of firmware transfer messages is defined by the particular device. |
| 0Ah, 0Bh | Storage | Non-volatile storage Requests and Responses | This functionality can be present on any node that provides non-volatile storage and retrieval services. |
| 0Ch, 0Dh | Transport | Media-specific configuration & control | Requests (0Ch) and responses (0Dh) for IPMI-specified messages that are media-specific configuration and operation, such as configuration of serial and LAN interfaces. |
| 0Eh-2Bh | Reserved | -- | reserved (30 Network Functions [15 pairs]) |
| 2Ch, 2Dh | Group Extension | Non-IPMI group Requests and Responses | The first data byte position in requests and responses under this network function identifies the defining body that specifies command functionality. Software assumes that the command and completion code field positions will hold command and completion code values. The following values are used to identify the defining body: 00h** PICMG - PCI Industrial Computer Manufacturer’s Group. (www.picmg.com) 01h DMTF Pre-OS Working Group ASF Specification (www.dmtf.org) 02h Server System Infrastructure (SSI) Forum (www.ssiforum.org) 03h VITA Standards Organization (VSO) (www.vita.com) DCh DCMI Specifications (www.intel.com/go/dcmi) all other Reserved When this network function is used, the ID for the defining body occupies the first data byte in a request, and the second data byte (following the completion code) in a response. |
| 2Eh, 2Fh | OEM/Group | OEM/NonIPMI group Requests and Response | The first three data bytes of requests and responses under this network function explicitly identify the OEM or non-IPMI group that specifies the command functionality. While the OEM or non-IPMI group defines the functional semantics for the cmd and remaining data fields, the cmd field is required to hold the same value in requests and responses for a given operation in order to be supported under the IPMI message handling and transport mechanisms. When this network function is used, the IANA Enterprise Number for the defining body occupies the first three data bytes in a request, and the first three data bytes following the completion code position in a response. |
| 30h-3Fh | Controller-specific OEM/Group | -- | Vendor specific (16 Network Functions [8 pairs]). The Manufacturer ID associated with the controller implementing the command identifies the vendor or group that specifies the command functionality. While the vendor defines the functional semantics for the cmd and data fields, the cmd field is required to hold the same value in requests and responses for a given operation in order for the messages to be supported under the IPMI message handling and transport mechanisms. |