FRUs on other controllers than the BMC are read from the BMC: FRU Device Locator access address and LUN ignored #193

Where: src/main/java/org/metricshub/ipmi/client/FruReader.java (read(), inventory()).

What happens: frus() reads every logical FRU Device Locator record (IPMI 2.0 table 43-7) by its FRU device ID alone, with Get FRU Inventory Area Info and Read FRU Data sent to LUN 0 of the BMC. The record's other addressing fields are parsed but never used:

• Device access address (byte 6, FruDeviceLocatorRecord.getDeviceAccessAddress()): the controller that holds the logical FRU. For a FRU on another controller, the library reads the BMC's FRU with the same ID instead. That FRU may be absent (the FRU comes back with a problem) or unrelated (the FRU comes back with another device's inventory). This is the FRU counterpart of Get Sensor Reading ignores sensor owner ID / LUN / channel (no bridging to satellite controllers) #84, which Read each sensor from its owner: Send Message bridging, LUN and Device SDRs (#84, #105) #192 fixed for sensors.
• Access LUN (byte 8, bits 4:3, getAccessLun()): a logical FRU at LUN 1 to 3 of the BMC is read at LUN 0.
• The primary FRU of the other controllers (device 0 at LUN 0): table 43-7 says it "is not reported via this FRU Device Locator record". It is flagged by the FRU Inventory Device bit of that controller's Management Controller Device Locator record (table 43-8, ManagementControllerDeviceLocatorRecord.isSupportsFruInventoryDevice()). The library reads FRU 0 of the BMC only.

Not reproduced on real hardware. A survey of the SDR repositories of 37 lab BMCs on 2026-10-16 (Dell iDRAC 6/8/F200, HPE iLO 5, Lenovo IMM/XCC, Cisco IMC, Fujitsu iRMC, Supermicro, GIGABYTE) found no logical FRU locator on another controller or LUN. The controllers behind the iLO 5 (44h, 2Ch, 28h) and the Intel ME behind the GIGABYTE BMC (2Ch, channel 6) do not flag a FRU inventory. The only locators off 20h/channel 0 were:

• Supermicro/ATEN (ipmi-hci-stg-, ipmi-netapphci-, ipmi-svp-pc, com-prox-01-mgt): the BMC's own "BMC FRU", logical, at 20h but on channel 2. Today it is read correctly as FRU 0 of the BMC.
• Dell iDRAC 8/F200: physical locators at 00h (CPU, DIMM SLOT, Front Panel), which FruReader skips by design (non-intelligent devices behind Master Write-Read).

Suggested fix: route the two FRU commands like IpmiClient.sendToOwner() routes the sensor reads since #192: build them at the record's access LUN, and wrap them in SendMessage (channel, 8-bit address) when the access address is not the BMC's. Optionally, read FRU 0 of each controller whose MC Device Locator record flags a FRU inventory. Two cautions:

• Decide on the access address alone, not on the channel: the Supermicro "BMC FRU" at 20h on channel 2 must keep being read from the BMC. The FRU Device Locator does not carry the channel of the controller the way sensor records do (byte 9 is the channel of the device).
• Send Message needs Operator privilege (table G-1, note 2); the AMI GIGABYTE BMC requires Administrator. At User privilege, such FRUs would come back with a D4h problem, like the bridged sensors of Read each sensor from its owner: Send Message bridging, LUN and Device SDRs (#84, #105) #192.

Test with FakeRmcpPlusBmc.satellite() (from #192). On real hardware, look for a blade or ATCA/MicroTCA chassis with FRUs on IPMB controllers.