FreeIPMI Bugs, Issues, and Workarounds
by
Albert Chu
chu11@llnl.gov
These are some short descriptions of the bugs, issues, and (if
relevant) workarounds I've found and discovered while developing
FreeIPMI on various motherboards. When it was documented (or I
remember them), the motherboards these issues were found on are also
documented.
This is mostly to document compliance issues I've discovered. When I
talk to vendors and they say, "IPMI is 100% compliant, we don't know
what you're talking about.", well, here's this document :-)
I have also listed a set of other issues that, while not compliance
issues, are either interpretation issues I've found between multiple
motherboards, a poor choice of implementation that makes it difficult
to work with, or functionally limiting/annoying. I have placed a
label of [INTERPRETATION], [NICETOHAVE], or [FUNCTIONAL] next to these
issues respectively.
Naturally the motherboards I have much more access to and am capable
of working on will probably have more issues discovered. As I develop
FreeIPMI and know more about IPMI, I am more likely to find more
issues on the most recent motherboard I worked on. Possible
bugs/compliance issues on other manufacturer's motherboards may be
masked by workarounds added to earlier motherboards.
I have worked extensively on:
Intel SR870BR2/Tiger 2
Intel SR870BN4/Tiger 4
Supermicro H8QME with SIMSO daughter card
Sun X4140
Inventec 5441/Dell Xanadu II
Dell Poweredge R610
Dell Poweredge R710
Inventec 5442/Dell Xanadu III
Quanta S99Q/Dell FS12-TY
Intel S5500WBV/Penguin Relion 700
Supermicro X8DTG
Supermicro X8DTU
I have had some short term access to the following:
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition)
Sun Fire 4100 with ILOM
Tyan S4811 with SMDC daughter card
Supermicro X6-DHR-1G with BMC2.0 daughter card
Supermicro X8DTH
The remaining motherboards (and subsequent bugs/issues/workarounds)
listed below are from interaction with users in the community and I
never personally accessed (atleast at the time of documentation of the
bug/workaround).
For the record, I have nothing against the companies and these issues.
I am just as prone to programming bugs as they are. The IPMI
specification is gigantic and mistakes will happen. I expect some
design decisions were made for time to release, cost, customer needs,
etc. too. This is more documentation for historical purposes, people
searching for information, and to document the difficulty of
developing portable IPMI code.
Authentication Issues
---------------------
Intel SR870BN4/Tiger 4: BMCs would not respond to retransmissions of a
Get Session Challenge Request if a previous Get Session Challenge
response was lost. Resolved by sending retransmitted Get Session
Challenge requests from a different source port.
Forgotten/Undocumented Motherboard(s): The only authentication
supported by the motherboard is an OEM specific authentication. No
resolution implemented. (Al comment: This was a really old Supermicro
motherboard, but I can't remember which one.)
Intel SE7520JR2 with National Semiconductor PC87431M mBMC: The initial
outbound sequence number on activate session response is off by one.
The activate session response packet is supposed to contain the
initial outbound sequence number passed during the request.
Supermicro H8QME with SIMSO daughter card: The IPMI 2.0 packet
responses for RAKP 2 have payload lengths that are off by 1. Resolved
with a workaround to adjust this length. This bug is confirmed to be
fixed on newer firmware.
Asus P5M2/P5MT-R/S162-E4/RX4: Username capabilities and/or K_g status
are not reported properly by the Get Authentication Capabilities
response. Resolved with a workaround ignoring those flags.
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition): The IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL flag does not work in
the Open Session phase of IPMI 2.0 connections. The Open Session
response seems to simply return the privilege level passed in the
request (i.e. the IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL flag rather than
the actual highest level privilege that can be used). Resolved with a
workaround to look for this situation.
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition): The username field is incorrectly padded during IPMI 2.0
authentication. Resolved with a workaround to adjust the
username field.
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition): When the authentication algorithm is HMAC-MD5-128 and the
password is greater than 16 bytes, the Intel BMC truncates the
password to 16 bytes when generating keys, hashes, etc. Resolved with
a workaround to adjust the hash data.
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition): During the RAKP4 response, the integrity check value is
incorrectly calculated based on the integrity algorithm instead of the
authentication algorithm. Resolved with a workaround to adjust the
hash calculation.
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition): During the RAKP3 request, the name_only_lookup field must be
disabled. Resolved with a workaround to adjust the hash calculation.
Forgotten/Undocumented Motherboard(s): Cipher suite IDs are are
attached to specific privilege levels rather than a maximum privilege
level limit. So you can only authenticate at the configured privilege
level rather than a privilege level <= to it. Resolved by passing
IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL during the session establishment
instead of the specific privilege level. (Al comment: I think this
was a really old Tyan motherboard, but I'm not 100% sure.)
Sun Fire 4100 with ILOM: During a RAKP2 response, the key exchange
authentication code is the wrong length. Resolved with a workaround
to adjust this length.
Sun Fire X4150: The remote BMC (seems to) incorrectly calculates keys
using the privilege specified in the open session stage rather than
the privilege used during the RAKP1 stage. This can be problematic if
you specify IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL during that stage
instead of a real privilege level. Resolved with a workaround to
handle this specific situation.
Sun Fire X4150/X4450: Username capabilities are not reported properly
by the Get Authentication Capabilities response. Resolved with a
workaround ignoring those flags.
Intel SR1520ML/X38ML: Username capabilities and/or K_g status are not
reported properly by the Get Authentication Capabilities response.
Resolved with a workaround ignoring those flags.
Inventec 5441/Dell Xanadu II: The remote BMC incorrectly calculates keys
using the privilege specified in the open session stage rather than
the privilege used during the RAKP1 stage. This can be problematic if
you specify IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL during that stage
instead of a real privilege level. Resolved with a workaround to
handle this specific situation. This bug is confirmed to be fixed on
newer firmware.
Inventec 5441/Dell Xanadu II: Given specific configuration of IPMI 1.5
authentication types, certain user privileges are not specified
correctly during Get Authentication Capabilities and a CCh = "Invalid
data field in request" is returned during Activiate Session. This bug
is confirmed to be fixed on newer firmware.
Supermicro X8DTH, X8DTG, X8DTU: The remote BMC incorrectly calculates
keys using the privilege specified in the open session stage rather
than the privilege used during the RAKP1 stage. This can be
problematic if you specify IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL during
that stage instead of a real privilege level. Resolved with a
workaround to handle this specific situation.
Forgotten/Undocumented Motherboard(s): The maximum privilege level
assigned to a cipher suite ID require authentication with that
specific privilege level, rather than a privilege level less than or
equal to it.
Supermicro X8DTG, X8DTU: Disabling a specific cipher suite ID does not
prohibit a user from continuing to use that cipher suite ID. No
current resolution.
Supermicro X8DTG, X8DTU: Cipher suites 0 fails to authenticate.
During the RAKP4 communication, an integrity key is returned, when it
in fact should be 0 length. Resolved with a workaround to handle this
specific situation. This bug is confirmed to be fixed on newer
firmware.
Supermicro X8DTG, X8DTU: Cipher suites 7 and 8 fail to establish a
session. It appears authentication codes are not returned for session
packets, therefore packets are dropped as they are viewed as
malformed. This bug is confirmed to be fixed on newer firmware.
Supermicro X8DTG, X8DTU: Cipher suites 11 and 12 fail to establish a
session. Authentication codes appear to be incorrect. This bug is
confirmed to be fixed on newer firmware.
Supermicro X8DTG: Using only IPMI 2.0, the maximum privilege level
allowed returned via the Open Session Response, is sometimes invalid.
Will cause privilege checks to fail. No current resolution.
Supermicro X8DTG: When attempting to authenticate with a disabled
Cipher Suite ID, a 0Ah status ("Unauthorized role or privelege level
requested.") is returned instead of 11h ("No Cipher Suite match with
proposed security algorithms."). No current resolution.
Intel S5500WBV/Penguin Relion 700: Cipher suites 0 fails to
authenticate. During the RAKP4 communication, an integrity key is
returned, when it in fact should be 0 length. Resolved with a
workaround to handle this specific situation.
Intel S5500WBV/Penguin Relion 700: The remote BMC incorrectly
calculates keys using the privilege specified in the open session
stage rather than the privilege used during the RAKP1 stage. This can
be problematic if you specify IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL
during that stage instead of a real privilege level. Resolved with a
workaround to handle this specific situation.
Session Issues
--------------
Intel SR870BN4/Tiger 4: There is no response from the IPMI close
command if a RESET is executed. Resolved by closing the session
early.
Tyan S2882 with m3289 BMC: After the IPMI session is brought up,
packet responses return empty session IDs (i.e. 00000000h) to the
client. Resolved with a workaround allowing empty session IDs to be
accepted by the client. This problem is reported to be fixed in newer
firmware.
Dell PowerEdge 2850,SC1425: When Per-Message Authentication is
disabled, packet responses contain non-null authentication data (when
it should in fact be null). Resolved with a workaround allowing
unexpected non-null authcodes to be checked as though they were
expected. This bug is confirmed to be fixed on newer
firmware.
IBM eServer 325: The remote BMC will advertise that Per Message
Authentication is disabled, but actually require it for the protocol.
Resolved with a workaround to force Per Message Authentication to be
used no matter what is advertised by the remote BMC.
Supermicro H8QME with SIMSO daughter card: The remote BMC will
advertise that Per Message Authentication is disabled, but actually
require it for the protocol. Resolved by noticing this condition and
re-enabling Per Message Authentication. This bug is confirmed to be
fixed on newer firmware.
Sun Fire 4100 with ILOM: Returns session sequence numbers with the
wrong endian during IPMI 1.5 sessions. Resolved with a workaround
that switches the endian of the received session sequence number.
Intel SE7520AF2 with Intel Server Management Module (Professional
Edition): The initial outbound sequence number on an Activate Session
response is off by one. Resolved automatically because session
sequence number is within range.
HP Proliant DL 145 server: IPMI 1.5 sessions are not supported, only
IPMI 2.0 sessions are supported.
SDR Issues
----------
Fujitsu RX 100: The record count reported by a Get SDR Repository Info
command is not consistent to the number of records that exist on the
motherboard. Resolved with workaround to handle situation.
Supermicro X6-DHR-1G with BMC2.0 daughter card: The record ID returned
from a Get SDR Record command would be different from the record ID
passed in. No resolution in FreeIPMI required. Resolved in IPMItool
with workaround to detect issue and use input record ID instead of
output record ID.
Misc IPMI
---------
Sun Fire 4100 with ILOM: The tag bits for some of the cipher records
are wrong. Resolved with a workaround to parse cipher records
properly.
Supermicro X8DTH: The manufacturer ID specified by the motherboard was
invalid (i.e. not a valid IANA Enterprise number). Resolved with
special workaround to handle this case.
Tool Issues
-----------
ipmiconsole/libipmiconsole
--------------------------
Forgotten/Undocumented Motherboard(s): Serial breaks are not supported
(Al comment: I think this was a really old Tyan motherboard, but I'm
not 100% sure.)
Asus P5M2/P5MT-R/S162-E4/RX4: SOL payload sizes are reported
incorrectly. Resolved with a workaround to skip payload size checks.
Asus P5M2/P5MT-R: A non-default SOL port is specified but not
functional. Resolved with a workaround to ignore this port and use
the default SOL port anyways.
Sun Fire 4100 with ILOM: The Get Channel Payload Support command is
not supported. Resolved with a workaround to skip this point in the
state machine (and pray things still work). Note that while this
command is listed as optional in the IPMI spec, it is not optional if
SOL is supported.
Supermicro H8QME with SIMSO daughter card: SOL sessions are not
deactivated after a Deactivate Payload request, despite the response
indicating success. This could lead to a looping state machine that
continually believes a SOL session is active, tries to deactivate it,
believes it is deactivated, then checks again if it is active.
Resolved by exiting after a number of failed deactivations. This
bug is confirmed to be fixed on newer firmware.
Supermicro H8QME with SIMSO daughter card: When a SOL session is
closed by another session, the initial SOL session is not given a "SOL
is deactivating" flag in a BMC to Remote Console packet. Not a severe
issue, since the SOL session will eventually time out, but it isn't
clean. Resolved with firmware fix.
Intel SR1520ML/X38ML: SOL payload sizes are reported incorrectly.
Resolved with a workaround to skip payload size checks.
Tyan S4811 with SMDC daughter card: During a reboot, SOL packets
appear to be temporarily internally dropped, leading to large
increases in sequence numbers once the SOL session is "re-connected".
While the SOL session is technically alive, the inability to
predict/handle the sequence number jump makes the SOL session useless.
To workaround this, libipmiconsole will close a session after a large
number of consecutive invalid packets are received.
Intel SR1520ML/X38ML: After a reboot, the SOL session appears to
"disconnect" from the motherboard. While the SOL session is
technically alive, and character data input from the user is accepted
by the remote BMC, no character data is sent back from the remote
motherboard. The SOL session is subsequently useless. There is
currently no workaround in place to handle this. The session must be
closed and restarted.
Intel Unknown Motherboard: The Activate Payload requires the "BMC
asserts CTS and DCD/DSR to baseboard upon activation" flag to be set.
Resolved with an Intel specific workaround.
Inventec 5441/Dell Xanadu II: SOL payload sizes are reported
incorrectly. Resolved with a workaround to skip payload size checks.
This bug is confirmed to be fixed on newer firmware.
Inventec 5441/Dell Xanadu II: When a SOL session is closed by another
session, the initial SOL session is not given a "SOL is deactivating"
flag in a BMC to Remote Console packet. Not a severe issue, since the
SOL session will eventually time out, but it isn't clean. This bug is
confirmed to be fixed on newer firmware.
Inventec 5441/Dell Xanadu II: If the remote system requires encryption,
but the user attempts to connect without encryption, an error response
other than "Cannot activate payload without encryption." is returned.
Not a severe issue, since the SOL session will connect with another
error. This bug is confirmed to be fixed on newer firmware.
Supermicro X8DTH: SOL payload sizes are reported incorrectly.
Resolved with a workaround to skip payload size checks.
Dell Poweredge R610, R710: When a SOL session is closed by another
session, the initial SOL session is not given a "SOL is deactivating"
flag in a BMC to Remote Console packet. Not a severe issue, since the
SOL session will eventually time out, but it isn't clean. No current
resolution.
Supermicro X8SIL-F: The Get Payload Activation Status command appears
to not be supported (or not implemented correctly, it is unclear given
the completion code CCh = "Invalid data field in request"). Resolved
with a workaround to skip this point in the state machine (and pray
things still work). Note that while this command is listed as
optional in the IPMI spec, it is not optional if SOL is supported.
This bug is reported to be fixed on newer firmware.
Supermicro X8DTH-iF: SOL payload sizes are reported incorrectly.
Resolved with a workaround to skip payload size checks. This bug is
reported to be fixed on newer firmware.
Supermicro X8DTH-iF: The reported SOL port is specified w/ the wrong
endian. Resolved with a workaround to ignore this port and use the
default SOL port anyways. This bug is reported to be fixed on newer
firmware.
Inventec 5442/Dell Xanadu III: When a SOL session is closed by another
session, the initial SOL session is not given a "SOL is deactivating"
flag in a BMC to Remote Console packet. Not a severe issue, since the
SOL session will eventually time out, but it isn't clean. This bug is
confirmed to be fixed on newer firmware.
Quanta S99Q/Dell FS12-TY: When a SOL session is closed by another
session, the initial SOL session is not given a "SOL is deactivating"
flag in a BMC to Remote Console packet. Not a severe issue, since the
SOL session will connect with another error. No current resolution.
Quanta S99Q/Dell FS12-TY: The Get Payload Activation Status command
does not properly indicate if a previous SOL session was created. No
current resolution.
Supermicro X8DTG, X8DTU: SOL payload sizes are reported incorrectly.
Resolved with a workaround to skip payload size checks.
Supermicro X8DTG, X8DTU: When a SOL session is closed by another
session, the initial SOL session is not given a "SOL is deactivating"
flag in a BMC to Remote Console packet. Not a severe issue, since the
SOL session will eventually time out, but it isn't clean. No current
resolution.
Intel S5500WBV/Penguin Relion 700: SOL payload sizes are reported
incorrectly. Resolved with a workaround to skip payload size checks.
bmc-config
----------
Sun X4140: BMCs require that a password must be passed to the Set User
Password command even if you are just trying to enable/disable a user.
Resolved by retrying a failed Set User Password command with a dummy
password.
Supermicro H8QME with SIMSO daughter card: Users cannot be
enabled/disabled via Set User Password. No workaround in FreeIPMI
implemented. Worked with vendor to implement fix in firmware.
Supermicro H8QME with SIMSO daughter card: Test passwords
via Set User Password not supported. No workaround in FreeIPMI
implemented. Worked with vendor to implement fix in firmware.
Supermicro H8QME with SIMSO daughter card: SOL privilege level,
Character_Send_Threshold, SOL_Retry_Count, and SOL_Retry_interval
cannot be modified. No workaround in FreeIPMI
implemented. Worked with vendor to implement fix in firmware.
Supermicro H8QME with SIMSO daughter card: User
access parameters Enable_IPMI_Msgs and Privilege_Limit are not
changeable via Set User Access. No workaround in FreeIPMI
implemented. Worked with vendor to implement fix in firmware.
Supermicro H8QME with SIMSO daughter card: Default Channel
configuration had a privilege limit of OEM. However, the motherboard
did not support an OEM privilege, and any subsequent configuration of
them results in a parameter out of range error (0xC9). No workaround
in FreeIPMI implemented. Worked with vendor to implement fix in
firmware.
Supermicro H8QME with SIMSO daughter card: Setting a channel privilege
limit (e.g. LAN channel privilege limit) does not seem to affect
authentication and/or execution of IPMI commands. No current
resolution.
Supermicro H8QME with SIMSO daughter card: When commiting large
amounts of data to the motherboard, some data does not get stored or
written properly. It appears that the BMC may lose data if
overwhelmed with data written to the BMC. Resolved with workaround to
slow down BMC commits. [FUNCTIONAL]
Tyan S4811 with SMDC daughter card: The ability to authenticate under
IPMI 1.5 is tied to it being supported as an OEM authentication type.
Resolved via different configuration w/ bmc-config.
Sun X4140: Get Username and Get User Payload commands fail with CCh =
"Invalid data field in request" if a username was not set previously.
Added workaround for this specific case. [FUNCTIONAL]
Inventec 5441/Dell Xanadu II: Get Username and Get User Payload commands
fail with CCh = "Invalid data field in request" if a username was not
set previously. Added workaround for this specific case. [FUNCTIONAL]
Inventec 5441/Dell Xanadu II: User access parameters Enable_IPMI_Msgs
and Privilege_Limit are not changeable via Set User Access for some
users. The values are not changeable until a username has been set.
No current resolution. [FUNCTIONAL]
Inventec 5441/Dell Xanadu II: When disabling IPMI via Enable_IPMI_Msgs,
IPMI over LAN still works for a user. This bug is confirmed to be
fixed on newer firmware.
Inventec 5441/Dell Xanadu II: Setting a channel privilege limit
(e.g. LAN channel privilege limit) does not seem to affect
authentication and/or execution of IPMI commands. No current
resolution.
Inventec 5441/Dell Xanadu II: Setting Non-volatile settings also
changes Volatile settings for channel configuration. No current
resolution.
Inventec 5441/Dell Xanadu II: ARP response configuration is not
functional even though the BMC ARP responds. This bug is confirmed to
be fixed on newer firmware.
Supermicro X8DTH: User access parameters Enable_IPMI_Msgs and
Privilege_Limit are not changeable via Set User Access for some users.
The values are not changeable until a username has been set. No
current resolution. [FUNCTIONAL]
Supermicro X8DTH: Setting Non-volatile settings also changes Volatile
settings for channel configuration. No current resolution.
Forgotten/Undocumented Motherboard(s): Setting a password using IPMI
2.0 extensions (i.e. up to 20 bytes in length) does not appear to
work. User must configure password using IPMI 1.5 formatted payloads.
Dell Poweredge R610, R710: User cannot be enabled/disabled until after
a non-null password has been configured. Added workaround for this
specific case. [FUNCTIONAL]
Dell Poweredge R610, R710: Default Authentication Type Enables
configure several OEM authentications on. However, the motherboard
does not support these OEM authentications, and any subsequent
configuration of them results in a bad parameter completion code
(0xCC). Added workaround to aid in configuration of these fields by
allowing bmc-config to "absorb" future configuration values, so that
multiple fields can be configured simultaneously instead of just one
field.
Dell Poweredge R610, R710: Read only fields return an error code of
0xD5 (request parameter not supported) instead of 0x82 (read only
parameter). No current resolution.
Dell Poweredge R610, R710: User IPMI messaging being enabled/disabled
does not seem to affect authentication and/or execution of IPMI
commands. No current resolution.
Dell Poweredge R610, R710: ARP response configuration is not available
even though the BMC ARP responds. No current resolution.
Inventec 5441/Dell Xanadu II: Configuring the Subnet Mask will also lead
to the "Default Gateway IP Address" to be configured (i.e. there is
some type of memory corruption, memory something that causes both to
be configured via one IPMI command). No current resolution.
Inventec 5441/Dell Xanadu II: Several configuration fields, most notably
several SOL configuration fields, are stored in volatile memory rather
than non-volatile memory. These particular configuration fields were
not required by IPMI to be stored in non-volatile memory, but
ultimately is an issue b/c it requires users to reconfigure IPMI on
every system boot. [NICETOHAVE]
Quanta S99Q/Dell FS12-TY: Gratuitous ARPs can be enabled, but is not
available. No current resolution.
Supermicro X8DTG, X8DTU: Default ADMIN username cannot be changed. No
current resolution. [FUNCTIONAL]
Supermicro X8DTG, X8DTU: User access parameters configured via Set
User Access does not work for some users. No current resolution.
Supermicro X8DTG, X8DTU: Despite Cipher Suites 6, 7, 8, 11, and 12 not
being available on the board, these Cipher Suite's Maximum Privilege
Level are configurable, suggesting to the user they are available. No
current resolution.
Intel S5500WBV/Penguin Relion 700: Default root username cannot be
changed. No current resolution. [FUNCTIONAL]
Intel S5500WBV/Penguin Relion 700: User access parameters
Enable_IPMI_Msgs and Privilege_Limit are not changeable via Set User
Access for some users. The values are not changeable until a username
has been set. No current resolution. [FUNCTIONAL]
Intel S5500WBV/Penguin Relion 700: Usernames are not reconfigurable
after they have been set atleast once. Set User Name command responds
with error code CCh = 'Invalid data field in Request'. No current
resolution. [FUNCTIONAL]
Intel S5500WBV/Penguin Relion 700: Setting Non-volatile settings also
changes Volatile settings for channel configuration. No current
resolution.
ipmi-pef-config
---------------
Inventec 5441/Dell Xanadu II: Alert Policy configurations cannot be
configured "piecemeal". If it's not configured perfectly and
simultaneously, every configuration will result in a completion code
of 0xCC (Invalid data field in Request). This isn't a compliance
issue, however it leads to difficult development. [NICETOHAVE]
[CONFIG-1]
Fujitsu RX 100: Alert Policy configurations cannot be configured
"piecemeal". If it's not configured perfectly and simultaneously,
every configuration will result in a completion code of 0xCC (Invalid
data field in Request). This isn't a compliance issue, however it
leads to difficult development. [NICETOHAVE] [CONFIG-1]
ipmi-fru
--------
Inventec 5441/Dell Xanadu II: Some FRU data has invalid checksums.
Resolved with workaround to ignore the checksum (and pray for the
best).
Dell Poweredge R610, R710: Some FRU data has invalid checksums.
Resolved with workaround to ignore the checksum (and pray for the
best).
Forgotten/Undocumented Motherboard(s): Some FRU data has invalid
checksums. Resolved with workaround to ignore the checksum (and pray
for the best). (Al comment: I know this was either an Intel Tiger 2
or Intel Tiger 4 motherboard, but I can't remember which one.)
Quanta S99Q/Dell FS12-TY: A FRU Chassis Info Area reports an
unspecified chassis type. No current resolution.
ipmi-sensors/ipmimonitoring
---------------------------
Dell 2950: Some sensors don't return a sensor state (16 bit field)
although only half of the sensor state (8 bit field) is optional.
Resolved by assuming the sensor state is 0 (i.e. no sensor states have
been asserted).
Dell 2950: Some sensors return sensor states that are invalid
(e.g. return 0xC0 if only 0x1 through 0x20 are supported). Resolved by
ignoring sensor states that are unknown.
Dell 2950: Some sensors return
IPMI_COMP_CODE_REQUEST_SENSOR_DATA_OR_RECORD_NOT_PRESENT (0xCB)
completion codes for unknown reasons. Resolved by ignoring sensors
that return this return code. [SENSORS-1]
Sun V20Z: Some sensors return
IPMI_COMP_CODE_COMMAND_ILLEGAL_FOR_SENSOR_OR_RECORD_TYPE (0xCD) for
unknown reasons. Resolved by ignoring sensors that return this return
code. [SENSORS-1]
Dell 2650: Some sensors return IPMI_COMP_CODE_PARAMETER_OUT_OF_RANGE
(0xC9) completion codes for unknown reasons. Resolved by ignoring
sensors that return this return code. [SENSORS-1]
HP ProLiant DL145 G2: Some sensors return
IPMI_COMP_CODE_COMMAND_CANNOT_RESPOND (0xCE) completion codes for
unknown reasons. Resolved by ignoring sensors that return this return
code. [SENSORS-1]
Sun X4140: The Get Sensor Event Enable command always returns "sensor
scanning disabled" bit. No current resolution.
Supermicro H8QME with SIMSO daughter card: Some sensors do not return
sensor event bitmasks in accordance to the IPMI specification. This
bug is confirmed to be fixed on newer firmware.
Inventec 5441/Dell Xanadu II: Several sensors have bogus Entity IDs. In
other words, not in the valid Entity ID range, or OEM defined range.
No resolution required, output alternate text appropriately.
Inventec 5441/Dell Xanadu II: Sensor bridging over IPMI 1.5 fails b/c
IPMB respones have invalid authentication codes. No current
resolution.
Inventec 5441/Dell Xanadu II: Some sensors don't return a sensor state
(16 bit field) although only half of the sensor state (8 bit field) is
optional. Resolved by assuming the sensor state is 0 (i.e. no sensor
states have been asserted).
Sun Fire X4450 w/ ELOM 3.0.0: Some sensors return
IPMI_COMP_CODE_REQUEST_PARAMETER_NOT_SUPPORTED (0xD5) completion codes
for unknown reasons. Resolved by ignoring sensors that return this
return code. [SENSORS-1]
Intel SR2500, Intel SR1500SAS, Intel S5000PAL: Some sensors report
invalid event bitmasks. For example, when the lower critical
threshold has *not* been crossed, the lower critical threshold event
bitmask is set. No current resolution.
HP Proliant DL140 G1: Sensors on the motherboard are owned by the BMC,
but the SDR does not indicate this. Thus, sensors cannot be read as
bridging fails. No current resolution.
Various Motherboards: Sensors do not assert state bits (i.e. sensor
event bitmask) consistently to indicate that a sensor is "doing good".
For example, for a "Power Supply" sensor, offset 00h (i.e. state 0 or
bitmask 0x0001) indicates "Presence Detected". On some motherboards
this is considered the "good" result to see from a "Power Supply"
sensor reading. On some other motherboards, the motherboards have
elected to not return any offset (i.e. no states set or bitmask
0x0000) when the power supply is fine, electing to only return an
offset when an actual failure occurs. This results in one of two
possible "good" scenarios for ipmi-sensors to output. [INTERPRETATION]
Inventec 5442/Dell Xanadu III: Sensor bridging over IPMI 1.5 fails b/c
IPMB respones have invalid authentication codes. This bug is
confirmed to be fixed on newer firmware.
ipmi-sel
--------
Supermicro H8QME with SIMSO daughter card: It appears that SEL records
incorrectly report the generator_id slave address. Resolved with
special case handling.
Supermicro H8QME with SIMSO daughter card: It appears different record
ids (e.g. 280 vs. 281) can be used to retrieve identical SEL records.
No workaround provided, assumed to be a non-issue.
HP DL 585: The Get SEL Entry command is not supported. No current
resolution.
HP DL 380 G5: Some SEL records report a record type of 0x00, which is
illegal. Resolved with workaround to assume a valid record type.
Inventec 5441/Dell Xanadu II: The SEL contains sensor numbers and sensor
owner IDs which are not listed in the SDR. While this is not a
compliance issue, it leads to an output that ultimately contains less
useful information. In particular, instead of a reasonable sensor
name, ipmi-sel must output "Sensor #8". [NICETOHAVE]
Sun Fire X4150: The SEL contains sensor numbers and sensor owner IDs
which are not listed in the SDR. While this is not a compliance
issue, it leads to an output that ultimately contains less useful
information. In particular, instead of a reasonable sensor name,
ipmi-sel must output "Sensor #8". [NICETOHAVE]
bmc-watchdog
------------
Sun x4100, x4200, x4500: The timer is running/stopped flag appears to
be stuck on "stopped" regardless if the timer is running or not.
Subsequent bmc-watchdog functionality is limited. Resolved with
workaround to analyze countdown rather than flag for running vs
stopped state.
ipmi-dcmi
---------
General Issue: The DCMI spec indicates a potential completion code for
the "Get Power Limit" command as "No Set Power Limit" (0x80).
FreeIPMI interpreted this to mean the "Set Power Limit" command was
not available. Atleast one vendor interpreted this to mean "No Power
Limit Set". One can consider this an English interpretation issue of
'No set *POWER LIMIT*' vs. 'No *SET POWER LIMIT*' (i.e. is "set" a
noun or a verb here). Confounding this issue is the fact that the
example implementation in Intel's DCMItool implements the former,
while the DCMI Conformance test suite implements the later. In
addition to this, with the later interpretation, it need not be an
indication of an error, but rather a flag. So the rest of the packet
can be completely full of legitimate data. Resolved by handling both
interpretations. [INTERPRETATION]
Appendix
--------
[CONFIG-1]
To see a discussion on why this implementation is poor, please see
"Configuration tool callback design" in the freeipmi-coding.txt
document.
[FUNCTIONAL]
This is not an IPMI compliance issue, but rather a poor implementation
that limits software development or gives the user a poor experience.
[INTERPRETATION]
This is not an IPMI compliance issue, but rather a interpretation
issue in the specification that has lead to multiple implementations
by vendors.
[NICETOHAVE]
This is not an IPMI compliance issue, but choice of implementation
makes for (in our opinion) a poor user experience or poor development
experience.
[SENSORS-1]
In all liklihood, these are all circumstances that the vendor wanted
to say "this sensor isn't available on this motherboard". (It is
ironic that there are so many error codes vendors are returning for
this circumstance, but I digress.)
I get the impression vendors try to put the same SDR on multiple
motherboards, regardless of whether a motherboard can even have a
sensor reading/event represented by that SDR entry. IMO, the best
thing vendors could do is have an SDR for each motherboard that is
actually legit. The IPMI spec strongly suggests this as well:
"Sensor Data Records are data records that contain information about
the type and number of sensors in the platform ..." (1.7.7).
"The SDR Repository is intended to hold information indicating the set
of management controllers, sensors, and FRU Devices that is expected
to be in the system ... For example, suppose the baseboard had
connectors for five fans, but only the first four were supposed to be
populated. The SDRs for the system would report four fan sensors ..."
(33)
