openbmc / phosphor-host-ipmid Goto Github PK

View Code? Open in Web Editor NEW

34.0 30.0 70.0 11.54 MB

dbus-based ipmid for host-endpoint IPMI commands

License: Apache License 2.0

Shell 0.10% C++ 98.01% Python 0.36% Meson 1.54%

phosphor-host-ipmid's People

Contributors

Stargazers

Watchers

Forkers

causten anoo1 shenki jk-ozlabs adamliyi nkskjames kenthliu shgoupf williamli80 hramasub tomjoseph83 ratagupt vishwabmc cyrilbur-ibm johnhcwang tpilukechen willenlee ken1029 doylehuang foxconn-bmc-ks geissonator bjh83 wak-google alexxnica kryndex lizkammer vincentsau herozyg mine260309 kuiyingw zhuysh1988 mlandryibm quanta-bmc miragesu yadro-kns sahudx nuvoton-israel junlinfeizixiao quadpixels huangchengjiu aaarrvhh manikandan-e felixcewu ivyyliu aimin-wang openbmcami ivyty hclopenbmc ya-mouse carpenter-zhanggya pcpartner-server simon-fan vejmarie vivekyuvan jayce3032 gato-11 cs-gitacc jzmaddock lukekungcj stanleytsai127 potinlai sffdaydayup 9elements liuzhongzhi nvidia

phosphor-host-ipmid's Issues

guid command not working

org.openbmc.control.Chassis doesn't have a method called "getID"

Need to use a different technique to get the uuid property from the dbus object

selected output from the system information could change between readings making the index read method invalid

See https://gerrit.openbmc-project.xyz/12130

Use consistent dbus path name.

I mentioned in the code review https://gerrit.openbmc-project.xyz/#/c/1984/26/configure.ac@86 that we should discuss the appropriate name for this object path. I believe we are suppose to have underscores here: soft_power_off.

      [SOFTOFF_OBJPATH="/xyz/openbmc_project/ipmi/internal/softpoweroff"])

Witherspoon: phosphor-ipmi-host.service: Failed with result 'core-dump'.

BMC at standby and host is off
Reset BMC in loop

After few iteration, we see this

Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: phosphor-ipmi-host.service: Main process exited, code=dumped, status=6/ABRT
Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: phosphor-ipmi-host.service: Failed with result 'core-dump'.
Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: Stopped Phosphor Inband IPMI.
Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: Stopped FRU Fault monitor service.
Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: Stopped Phosphor MBOX Daemon.
Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: witherspoon-fan-watchdog.service: Main process exited, code=killed, status=9/KILL
Nov 13 08:29:24 xx.xx.xx.xx systemd[1]: witherspoon-fan-watchdog.service: Failed with result 'signal'

After few iteration. The BMC reset to standby , we see the host IPMID crashed when the host is not running at all.

BMC version should be BCD encoded

According to IPMI spec, Firmware revision 2 has to be BCD encoded. For example, currently, if we set version to 11 in revision 2, version will show B not 11 as expected.

BMC aux revision doesn't match with the aux number in tag

Reproduce:
Setting tag version in /etc/os-release to: "v1.0.11-dirty"

IPMI raw response:
00 00 00 01 00 02 0d 41 a7 00 43 40 00 0b 01 00

It'll get confusion when user/designer get the version 1.0.B on a failure board and want to track the source code from the tag on GitHub. They can't find out the tag 1.0.B.
Should we get the improvement on this situation?

Re structure handle_ipmi_command function in ipmid.C

Currently, ipmitool hangs if it does not see a response packet for the IPMI message that was sent in that session.

It does not understand the return code of just 'rc' and mandates that a response packet be sent. This can not be always guaranteed in these scenarios.

1/. There is an error reading the user message itself into netfn,cmd tuple
2/. There is an error reading the user input buffer that is part of the message
3/. There is an error sending the ipmi response itself.

So we need to figureout if the change needs to go into ipmid.C -or- something for ipmitool itself.

Configure should fail when mapper is missing

Per comment in issue #99 the configure process should fail when mapper is not found.

Host inventory errors

Apr 05 15:04:03 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:03 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:03 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:03 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:05 witherspoon ipmid[1334]: Could not find sensor 12
Apr 05 15:04:05 witherspoon ipmid[1334]: Could not find sensor 13
Apr 05 15:04:05 witherspoon ipmid[1334]: Could not find sensor 14
Apr 05 15:04:05 witherspoon ipmid[1334]: Could not find sensor 15
Apr 05 15:04:05 witherspoon ipmid[1334]: Could not find sensor 16
Apr 05 15:04:05 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:05 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:05 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:05 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:07 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:07 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:07 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:07 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:07 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:07 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:07 witherspoon ipmid[1334]: Incomplete FRU file
Apr 05 15:04:07 witherspoon ipmid[1334]: Populating FRU areas failed
Apr 05 15:04:07 witherspoon ipmid[1334]: Unable to get the FRU info
Apr 05 15:04:07 witherspoon ipmid[1334]: Error updating inventory.
Apr 05 15:04:07 witherspoon ipmid[1334]: Invalid entry in byte-0
Apr 05 15:04:07 witherspoon ipmid[1334]: Failed to validate common header

Couple of mismatch seen in new
Missing cores: (In old, even if non functional it shows up but in latest it doesnt show up at all) Is this expected ?

Missing core 4,5,12,13,18,19 for cpu0
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core0
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core1
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core2
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core3
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core6
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core7
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core8
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core9
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core10
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core11
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core14
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core15
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core16
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core17
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core20
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core21
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core22
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core23


Missing core 12,13,14,1518,19 for cpu1
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core0
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core1
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core2
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core3
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core4
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core5
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core6
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core7
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core8
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core9
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core10
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core11
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core16
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core17
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core20
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core21
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core22
/xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core23

The Firmware Revision from 'ipmitool mc info' by OOB may be '0.00'

Hi,
I found the software redundancy interface was established a little late.
This caused the Firmware Revision from 'ipmitool mc info' by OOB may be '0.00'

In the handler of Get Dev ID command, the data is cached into static variable (dev_id) at the first executing.
Afterwards, the handler wouldn't call 'getActiveSoftwareVersionInfo()' again even it encountered 'No Obj has implemented the s/w redundancy interface' error previously.

Thus, the Firmware Revision would be '0.00' until next BMC reboot.

Currently, I add a workaround to fix the issue in the 'apphandler.cpp'.

ipmi_ret_t ipmi_app_get_device_id(ipmi_netfn_t netfn, ipmi_cmd_t cmd,
                             ipmi_request_t request, ipmi_response_t response,
                             ipmi_data_len_t data_len, ipmi_context_t context)
{
...
                if( r >= 0 ) {
                        // bit7 identifies if the device is available
                        // 0=normal operation
                        // 1=device firmware, SDR update,
                        // or self-initialization in progress.
                        // our SDR is normal working condition, so mask:
                       dev_id.fw[0] = 0x7F & rev.major;

                       rev.minor = (rev.minor > 99 ? 99 : rev.minor);
                       dev_id.fw[1] = rev.minor % 10 + (rev.minor / 10) * 16;
                        memcpy(&dev_id.aux, rev.d, 4);
                }
		else{
			//Henbin Oem addition.
			rc = IPMI_CC_NOT_SUP_IN_CUR_STAT;
			return rc;
		}
...
}

Can anyone provide the suggestion?

Thanks.

ipmid ERROR opening and JSON file not found

Mar 21 16:17:50 witherspoon ipmid[1422]: ERROR opening
Mar 21 16:17:53 witherspoon ipmid[1422]: JSON file not found

VERSION_ID="2.7.0-dev-135-gb0afcc1"
OPENBMC_TARGET_MACHINE="witherspoon"

Linux xx.xx.xx.xx 5.0.3-b94b74e8b52db91fe4e99e0bb481ec8bf2b5b47c #1 Thu Mar 21 13:38:45 UTC 2019 armv6l GNU/Linux

{
	"__CURSOR" : "s=a6a147c081d94b24937ac2aee97f14b1;i=64b2;b=68dcc5ce887943d0a3063ed38fc22dba;m=4fca65b;t=5849d145f8dcc;x=93423674b34670b4",
	"__REALTIME_TIMESTAMP" : "1553185070091724",
	"__MONOTONIC_TIMESTAMP" : "83666523",
	"_BOOT_ID" : "68dcc5ce887943d0a3063ed38fc22dba",
	"_TRANSPORT" : "journal",
	"_SYSTEMD_SLICE" : "system.slice",
	"_MACHINE_ID" : "ac27d5c72a6e4197bf4c14e667e757f6",
	"_HOSTNAME" : "xx.xx.xx.xx",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"CODE_LINE" : "105",
	"CODE_FUNC" : "helper_log",
	"CODE_FILE" : "/tmp/openbmc/work/armv6-openbmc-linux-gnueabi/phosphor-ipmi-host/1.0+gitAUTOINC+1bb0c7fc55-r1/recipe-sysroot/usr/include/phosphor-logging/log.hpp",
	"PRIORITY" : "3",
	"MESSAGE" : "ERROR opening",
	"TRANSACTION_ID" : "2851025156",
	"HANDLER" : "/usr/lib/host-ipmid/libusercmds.so.0",
	"ERROR" : "/usr/lib/host-ipmid/libusercmds.so.0: undefined symbol: _ZN4ipmi24convertCurrentChannelNumEh",
	"SYSLOG_IDENTIFIER" : "ipmid",
	"_PID" : "1422",
	"_COMM" : "ipmid",
	"_EXE" : "/usr/sbin/ipmid",
	"_CMDLINE" : "ipmid",
	"_SYSTEMD_CGROUP" : "/system.slice/phosphor-ipmi-host.service",
	"_SYSTEMD_UNIT" : "phosphor-ipmi-host.service",
	"_SYSTEMD_INVOCATION_ID" : "64ebd6232b51448e88b726b2b99bd304",
	"_SOURCE_REALTIME_TIMESTAMP" : "1553185070091629"
}

{
	"__CURSOR" : "s=a6a147c081d94b24937ac2aee97f14b1;i=64c8;b=68dcc5ce887943d0a3063ed38fc22dba;m=52f9e18;t=5849d14928589;x=5fe780dd24d4451f",
	"__REALTIME_TIMESTAMP" : "1553185073431945",
	"__MONOTONIC_TIMESTAMP" : "87006744",
	"_BOOT_ID" : "68dcc5ce887943d0a3063ed38fc22dba",
	"_TRANSPORT" : "journal",
	"_SYSTEMD_SLICE" : "system.slice",
	"_MACHINE_ID" : "ac27d5c72a6e4197bf4c14e667e757f6",
	"_HOSTNAME" : "xx.xx.xx.xx",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"CODE_LINE" : "105",
	"CODE_FUNC" : "helper_log",
	"CODE_FILE" : "/tmp/openbmc/work/armv6-openbmc-linux-gnueabi/phosphor-ipmi-host/1.0+gitAUTOINC+1bb0c7fc55-r1/recipe-sysroot/usr/include/phosphor-logging/log.hpp",
	"PRIORITY" : "3",
	"TRANSACTION_ID" : "2851025156",
	"SYSLOG_IDENTIFIER" : "ipmid",
	"_PID" : "1422",
	"_COMM" : "ipmid",
	"_EXE" : "/usr/sbin/ipmid",
	"_CMDLINE" : "ipmid",
	"_SYSTEMD_CGROUP" : "/system.slice/phosphor-ipmi-host.service",
	"_SYSTEMD_UNIT" : "phosphor-ipmi-host.service",
	"_SYSTEMD_INVOCATION_ID" : "64ebd6232b51448e88b726b2b99bd304",
	"MESSAGE" : "JSON file not found",
	"_SOURCE_REALTIME_TIMESTAMP" : "1553185073431844"
}

Sensor capabilites aren't reported in full sensor records

ipmitool reports 'Readable thresholds : No thresholds' for all full sensors:

$ ipmitool -v -H vesnin -I lanplus -P 0penBmc sdr get RTC_temp1
Using best available cipher suite 17
Invalid Get PICMG Properties response length 1
Running Get VSO Capabilities my_addr 0x20, transit 0, target 0x20
Invalid response length 1
Discovered IPMB address 0x0
Sensor ID              : RTC_temp1 (0x43)
 Entity ID             : 0.0 (Unspecified)
 Sensor Type (Threshold)  : Temperature (0x01)
 Sensor Reading        : 27 (+/- 0) degrees C
 Status                : ok
 Positive Hysteresis   : Unspecified
 Negative Hysteresis   : Unspecified
 Minimum sensor range  : Unspecified
 Maximum sensor range  : -127,000
 Event Message Control : Per-threshold
 Readable Thresholds   : No Thresholds
 Settable Thresholds   : No Thresholds

At the same time reading a specific sensor using 'ipmitool sensor' command that disregards the sensor capabilities and just forcefully reads the thresholds, shows that the thresholds are present:

$ src/ipmitool -H vesnin -P 0penBmc -I lanplus sensor get RTC_temp1
Locating sensor record...
Sensor ID              : RTC_temp1 (0x43)
 Entity ID             : 0.0
 Sensor Type (Threshold)  : Temperature
 Sensor Reading        : 28 (+/- 0) degrees C
 Status                : ok
 Lower Non-Recoverable : na
 Lower Critical        : na
 Lower Non-Critical    : na
 Upper Non-Critical    : 75,000
 Upper Critical        : 80,000
 Upper Non-Recoverable : na
 Positive Hysteresis   : Unspecified
 Negative Hysteresis   : Unspecified

The expected behavior is that verbose version of 'sdr get' prints 'Readable thresholds : unc uc'.

Inspecting the sensorhandler.cpp code revealed that SensorDataFullRecordBody::sensor_capabilities is never set to anything meaningful and remains alway zero.

I believe that ipmi_sen_get_sdr() must fill that field from the existing D-Bus thresholds for the sensor.

Extra Bytes in response data for chassis Identify command

root@wolfpass:~# ipmitool raw 0x00 0x04 0x02 0x00
00 00

From IPMI spec, response should be complete code only.

The root cause is a bug in community code.
The data_len is not assigned to 0. It keeps as 2 which is request length.

root@wolfpass:~# ipmitool raw 0x00 0x04 0x02 0x00
00 00

From IPMI spec, response should be complete code only.

The root cause is a bug in routine ipmi_chassis_identify.
The data_len is not assigned to 0. It keeps as 2 which is request length.

Add support for multiple interfaces in sensorhandler

Right now there is no good way to manage multiple interfaces for a given sensor in the sensorhandler codebase. We generate a dbus_interface_t based on an ipmi::sensor::Info, but where ipmi::sensor::Info can support many DBus interfaces, dbus_interface_t represents only one of those. We need to be able to determine which interface is appropriate for requested operation.

In a code review I have in progress (https://gerrit.openbmc-project.xyz/#/c/3526/), this issue is worked around by simply taking the first interface available from the ipmi::sensor::Info, but as Ratan G pointed out in the review, this will not work for some sensors currently handled by legacy codepath when they are moved out of skeleton.

Issues with commit 13fb441

There are two issues with commit 13fb441 that escaped the code review process:

13fb441?diff=unified#diff-87a9c9a47212626ff55cd8c4b1378ae4L360

The comment indicates "we only support channel 1" but this code changed added support for "channel 8". Need the comment correctly updated.

Is there any reason why we are not allowing any channel?

13fb441?diff=unified#diff-44d0d8d3be3e961e202a4ab3f261859bL270

This change removed the 'return -1' from this function, which is obviously an error path. I suspect this was done because messages were never responded to in the error path and left "hanging" until timeout. But, this change is not the appropriate one either. We now are responding with a response data in undetermined state. If we are going to respond after an error by the ipmi-plugin we need to have a well-defined error response.

Disabled IPMI root user is able to run IPMI command

Disabled IPMI root user is still able to run IPMI command.
With same root user, if we try to login to bmc via Redfish then it fails. So it seem like disabled IPMI root user is still usable via IPMI.

Step to recreate

Disable IPMI root user(userid 1).

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user disable 1

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> channel getaccess 1 1
Maximum User IDs     : 15
Enabled User IDs     : 1

User ID              : 1
User Name            : root
Fixed Name           : No
Access Available     : callback
Link Authentication  : enabled
IPMI Messaging       : enabled
Privilege Level      : ADMINISTRATOR
Enable Status        : enabled    <--- IPMI disabled root user is still reflected as enable via IPMI. But via Redfish it coming as disabled

bash-4.1$ curl -k -H "X-Auth-Token: $bmc_token" -X GET https://${BMC_IP}/redfish/v1/AccountService/Accounts/root
{
  "@odata.context": "/redfish/v1/$metadata#ManagerAccount.ManagerAccount",
  "@odata.id": "/redfish/v1/AccountService/Accounts/root",
  "@odata.type": "#ManagerAccount.v1_0_3.ManagerAccount",
  "Description": "User Account",
  "Enabled": false,         <--- root user is coming as disabled via Redfish.
  "Id": "root",
  "Links": {
    "Role": {
      "@odata.id": "/redfish/v1/AccountService/Roles/Administrator"
    }
  },
  "Locked": false,
  "Name": "User Account",
  "Password": null,
  "RoleId": "Administrator",
  "UserName": "root"
}bash-4.1$

We are unable to login system via Redfish with this disabled root user(this is expected).

bash-4.1$ curl -k -H Content-Type: application/json" -X POST https://${BMC_IP}/login -d '{"username" :  "root", "password" :  "0penBmc"}'
Unauthorizedbash-4.1
$

But we are able to run IPMI command with this disabled root user(this is not expected).

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user list
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1   root             false   true       true       ADMINISTRATOR
2                    true    false      false      NO ACCESS
3   newuser          true    true       true       ADMINISTRATOR
4                    true    false      false      NO ACCESS
5                    true    false      false      NO ACCESS
6                    true    false      false      NO ACCESS
7                    true    false      false      NO ACCESS
8                    true    false      false      NO ACCESS
9                    true    false      false      NO ACCESS
10                   true    false      false      NO ACCESS
11                   true    false      false      NO ACCESS
12                   true    false      false      NO ACCESS
13                   true    false      false      NO ACCESS
14                   true    false      false      NO ACCESS
15                   true    false      false      NO ACCESS

Investigate poll and cache for sensor values instead of on-demand reads

With both the aspeed fantach sensors and the 1-wire temperature sensors, we encountered long sensor read times leading to timeouts all the way up in btbridge, causing hard-to-diagnose failures from the host side IPMI handling.

These sensors may not be the only very slow sensors we run across. An arbitrary 5-second timeout in btbridge may eventually prove too short for another sensor. And reads appear very slow to the host when they may not need to be.

Joel and Cyril suggested polling sensors with a background thread and reading the most recent value out over IPMI to reduce latency, and I agree that this is the correct approach if we can ensure that the polling thread will time out appropriately if the sensor is unresponsive.

(host-ipmid maybe isn't the right place for this, but it's the area that's being affected with sneaky failures, so it seemed like as good a place as any.)

ipmi host services need to follow plugin architecture

Today, start_host_service() is hard bound to ipmid. However, the idea is to have this implemented as any ipmid plugin like any other ipmi command handlers.

phosphor-host-ipmid does not build in SDK - sensor-gen.cpp:147:1: error: could not convert

I tried this on a few different systems and fails seems to be the same. A bunch of warnings and then this final error:

/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc: In member function \u2018void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long int, long long unsigned int, double, std::allocator, nlohmann::adl_serializer>}; _Tp = nlohmann::basic_json<>; _Alloc = std::allocator<nlohmann::basic_json<> >]\u2019:
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc:394:7: note: parameter passing for argument of type \u2018std::vector<nlohmann::basic_json<>, std::allocator<nlohmann::basic_json<> > >::iterator {aka __gnu_cxx::__normal_iterator<nlohmann::basic_json<>*, std::vector<nlohmann::basic_json<>, std::allocator<nlohmann::basic_json<> > > >}\u2019 changed in GCC 7.1
       vector<_Tp, _Alloc>::
       ^~~~~~~~~~~~~~~~~~~
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc: In member function \u2018void nlohmann::detail::parser<BasicJsonType>::parse_internal(bool, BasicJsonType&) [with BasicJsonType = nlohmann::basic_json<>]\u2019:
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc:105:21: note: parameter passing for argument of type \u2018__gnu_cxx::__normal_iterator<nlohmann::basic_json<>*, std::vector<nlohmann::basic_json<>, std::allocator<nlohmann::basic_json<> > > >\u2019 changed in GCC 7.1
    _M_realloc_insert(end(), std::forward<_Args>(__args)...);
    ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  CXX      libipmi20_la-ipmisensor.lo
  CXX      libipmi20_la-storageaddsel.lo
  CXX      libipmi20_la-transporthandler.lo
In file included from /esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/vector:69:0,
                 from /esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/experimental/bits/fs_path.h:39,
                 from /esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/experimental/filesystem:39,
                 from transporthandler.cpp:11:
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc: In member function \u2018void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long int, long long unsigned int, double, std::allocator, nlohmann::adl_serializer>}; _Tp = nlohmann::basic_json<>; _Alloc = std::allocator<nlohmann::basic_json<> >]\u2019:
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc:394:7: note: parameter passing for argument of type \u2018std::vector<nlohmann::basic_json<>, std::allocator<nlohmann::basic_json<> > >::iterator {aka __gnu_cxx::__normal_iterator<nlohmann::basic_json<>*, std::vector<nlohmann::basic_json<>, std::allocator<nlohmann::basic_json<> > > >}\u2019 changed in GCC 7.1
       vector<_Tp, _Alloc>::
       ^~~~~~~~~~~~~~~~~~~
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc: In member function \u2018void nlohmann::detail::parser<BasicJsonType>::parse_internal(bool, BasicJsonType&) [with BasicJsonType = nlohmann::basic_json<>]\u2019:
/esw/san5/openbmc/sdk/witherspoon/latest/sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/7.3.0/bits/vector.tcc:105:21: note: parameter passing for argument of type \u2018__gnu_cxx::__normal_iterator<nlohmann::basic_json<>*, std::vector<nlohmann::basic_json<>, std::allocator<nlohmann::basic_json<> > > >\u2019 changed in GCC 7.1
    _M_realloc_insert(end(), std::forward<_Args>(__args)...);
    ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  CXX      libipmi20_la-globalhandler.lo
  CXX      libipmi20_la-groupext.lo
  CXX      libipmi20_la-utils.lo
  CXX      libipmi20_la-selutility.lo
  CXX      libipmi20_la-ipmi_fru_info_area.lo
  CXX      libipmi20_la-read_fru_data.lo
  CXX      libipmi20_la-sensordatahandler.lo
  CXX      libipmi20_la-sensor-gen.lo
sensor-gen.cpp:147:1: error: could not convert \u2018{{96, {7, "/org/open_power/control/occ0", "org.open_power.OCC.Status", 111, 1, 0, 0, 0, ipmi::sensor::set::assertion, ipmi::sensor::get::assertion, (ipmi::sensor::Mutability)1, {{"org.open_power.OCC.Status", {{"OccActive", {<brace-enclosed initializer list>(), {{6, {NONE, false, true}}}}}}}}}}, {97, {4, "/system/chassis/motherboard/dimm1", "xyz.openbmc_project.Inventory.Manager", 111, 1, 0, 0, 0, ipmi::sensor::notify::assertion, ipmi::sensor::inventory::get::assertion, (ipmi::sensor::Mutability)1, {{"xyz.openbmc_project.State.Decorator.OperationalStatus", {{"Functional", {{{4, {false, true}}}, {{6, {NONE, true, false}}}}}}}, {"xyz.openbmc_project.Inventory.Item", {{"Present", {<brace-enclosed initializer list>(), {{4, {NONE, false, true}}}}}}}}}}, {98, {195, "/xyz/openbmc_project/state/host1", "xyz.openbmc_project.Control.Boot.RebootAttempts", 111, 1, 0, 0, 0, readingAssertion<uint32_t>, readingAssertion<uint32_t>, (ipmi::sensor::Mutability)1, {{"xyz.openbmc_project.Control.Boot.RebootAttempts", {{"AttemptsLeft", {<brace-enclosed initializer list>(), {{255, <brace-enclosed initializer list>()}}}}}}}}}, {99, {195, "/xyz/openbmc_project/state/host0", "xyz.openbmc_project.Control.Boot.RebootAttempts", 111, 1, 0, 0, 0, readingAssertion<uint32_t>, readingAssertion<uint32_t>, (ipmi::sensor::Mutability)1, {{"xyz.openbmc_project.Control.Boot.RebootAttempts", {{"AttemptsLeft", {<brace-enclosed initializer list>(), {{255, <brace-enclosed initializer list>()}}}}}}}}}, {84, {7, "/system/chassis/motherboard/cpu0/core22", "xyz.openbmc_project.Inventory.Manager", 111, 1, 0, 0, 0, ipmi::sensor::notify::assertion, ipmi::sensor::inventory::get::assertion, (ipmi::sensor::Mutability)1, {{"xyz.openbmc_project.State.Decorator.OperationalStatus", {{"Functional", {{{7, {true, false}}}, {{8, {NONE, false, true}}}}}}}, {"xyz.openbmc_project.Inventory.Item", {{"Present", {<brace-enclosed initializer list>(), {{7, {DEASSERT, true, false}}}}}}}}}}, {208, {1, "/xyz/openbmc_project/sensors/temperature/fleeting0", "xyz.openbmc_project.Sensor.Value", 1, 511, 0, 0, 0, readingData<int64_t>, readingData<int64_t>, ipmi::sensor::operator|((ipmi::sensor::Mutability)2, (ipmi::sensor::Mutability)1), {{"xyz.openbmc_project.Sensor.Value", {{"Value", {<brace-enclosed initializer list>(), {{255, <brace-enclosed initializer list>()}}}}}}}}}}\u2019 from \u2018<brace-enclosed initializer list>\u2019 to \u2018const IdInfoMap {aka const std::map<unsigned char, ipmi::sensor::Info>}\u2019
 };
 ^
make[2]: *** [libipmi20_la-sensor-gen.lo] Error 1
make[2]: Leaving directory `/esw/san5/andrewg/Code/phosphor-host-ipmid'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/esw/san5/andrewg/Code/phosphor-host-ipmid'
make: *** [all] Error 2
[andrewg@gfwa180 phosphor-host-ipmid]$

I'm on commit 1e12112 using an SDK from 8/26 (https://openpower.xyz/job/openbmc-build-sdk/distro=ubuntu,target=witherspoon/)

front_panel_button_cap_status is not supported in ipmi_get_chassis_status command

SetFrontPanelButtonEnables command need it is fixed ASAP.

https://github.com/openbmc/phosphor-host-ipmid/blob/master/chassishandler.cpp#L951

Boot override doesn't appear on host

@stewart-ibm found while using op-test that bootdev overrides don't appear to make it to the host, eg:
BMC:

curl -s  -b cjar  -c cjar   -k  -H  'Content-Type: application/json'  -X GET https://10.61.161.105///xyz/openbmc_project/control/host0/boot
{
  "data": {
    "BootMode": "xyz.openbmc_project.Control.Boot.Mode.Modes.Setup", 
    "BootSource": "xyz.openbmc_project.Control.Boot.Source.Sources.Default"
  }, 
  "message": "200 OK", 
  "status": "ok"
}%

Host:

/ # head -40 /var/log/petitboot/pb-discover.log
[22:07:39] IPMI: netfn(0->1), cmd(9->9)
[22:07:39] IPMI get_bootdev response:
[22:07:39] 0 [22:07:39] 1 [22:07:39] 5 [22:07:39] 80 [22:07:39] 0 [22:07:39] 0 [22:07:39] 0 [22:07:39] 0 ...
[22:07:40]   IPMI boot device 0x00

/ # ipmitool raw 0x00 0x09 0x05 0x00 0x00
 01 05 80 00 00 00 00

If a 'setup' override is set then byte three should read 0x06 instead of 0x00.

This is on a palmetto running:

root@palm8-bmc:~# cat /etc/os-release 
ID="openbmc-phosphor"
NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
VERSION="v2.3-848"
VERSION_ID="v2.3-848-gb6898b5"
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) v2.3-848"
BUILD_ID="v2.3"

and

/ # lsprop /proc/device-tree/ibm,firmware-versions/
skiboot          "v6.1-169-gba0af421d7d3"
bmc-firmware-version
		 "0.00"
occ              "p8-28f2cec"
hostboot         "p8-c8a08f1-p05edae4"
buildroot        "2018.08.1-7-g4264b62"
capp-ucode       "p9-dd2-v4"
machine-xml      "e0fae90-p19553ad"
hostboot-binaries
		 "hw091818a.930"
open-power       "palmetto-v2.1-186-gddcd63b"
petitboot        "1.9.1"
phandle          10000087 (268435591)
linux            "4.19-openpower1-pf40b583"
name             "ibm,firmware-versions"

Using busctl monitor org.openbmc.HostIpmi it looks like the IPMI daemon isn't filling the response buffer properly:

‣ Type=method_call  Endian=l  Flags=0  Version=1  Priority=0 Cookie=57323
  Sender=:1.54  Destination=:1.17  Path=/org/openbmc/HostIpmi/1  Interface=org.openbmc.HostIpmi  Member=sendMessage
  UniqueName=:1.54
  MESSAGE "yyyyyay" {
          BYTE 163;
          BYTE 1;
          BYTE 0;
          BYTE 9;
          BYTE 0;
          ARRAY "y" {
                  BYTE 1;
                  BYTE 5;
                  BYTE 128;
                  BYTE 0;
                  BYTE 0;
                  BYTE 0;
                  BYTE 0;
          };
  };

Watchdog requests are not retried if the cache is stale

On zaius and other openpower platforms, the phosphor-watchdog is started as part of the host being powered on or reset. This means that the cached bus address for the watchdog is stale upon first access. When hostboot tries to do the initial watchdog setup the command will fail because the ipmid will try and access the old watchdog location. It doesn't bother to do a lookup and retry after the command fails in the case where it has the service cached. Instead. the ipmid just returns an error to the host, and hostboot continues booting anyway. All future resets fail since the watchdog never got initialized and eventually the watchdog goes off, resetting the machine.

Hostboot and skiboot need to be fixed to properly deal with watchdog initialization and command failures, but we can reduce the failures with some simple retry logic inside the BMC to reduce the number of IPMI commands required.

C++ code mixed throughout

I know this is probably just me nit-picking, but there's a few bits of C++ code scattered throughout this repo, in .c files. Can the cpp files be changed to a .cpp extension to reflect this more clearly? There are some namespaces and C++ headers used here and there.

IPMI out-of-band "user list/summary" command fails without channel number

With recent master, IPMI out-of-band "user list" command is failing without channel number. If we try the same with channel number, it works fine.

Same is also seen with "user summary" command. Both use to work with older builds without channel number.

Without Channel number:

bash-4.1$ ipmitool -I lanplus -H <BMC_IP> -U root -P 0penBmc  user list
IPMI command failed: Invalid data field in request
bash-4.1$ ipmitool -I lanplus -H <BMC_IP> -U root -P 0penBmc  user summary
IPMI command failed: Invalid data field in request

With Channel number:

bash-4.1$ ipmitool -I lanplus -H <BMC_IP> -U root -P 0penBmc  user list 1
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1   root             false   true       true       ADMINISTRATOR
2                    true    false      false      NO ACCESS
3                    true    false      false      NO ACCESS
4                    true    false      false      NO ACCESS
5                    true    false      false      NO ACCESS
6                    true    false      false      NO ACCESS
7                    true    false      false      NO ACCESS
8                    true    false      false      NO ACCESS
9                    true    false      false      NO ACCESS
10                   true    false      false      NO ACCESS
11                   true    false      false      NO ACCESS
12                   true    false      false      NO ACCESS
13                   true    false      false      NO ACCESS
14                   true    false      false      NO ACCESS
15                   true    false      false      NO ACCESS
bash-4.1$ ipmitool -I lanplus -H <BMC_IP> -U root -P 0penBmc  user summary 1
Maximum IDs         : 15
Enabled User Count  : 1
Fixed Name Count    : 0
bash-4.1$

OpenBMC build info:

root@witherspoon:~# cat /etc/os-release
ID="openbmc-phosphor"
NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
VERSION="2.7.0-dev"
VERSION_ID="2.7.0-dev-222-g4b8d2d036"
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.7.0-dev"
BUILD_ID="2.7.0-dev"
OPENBMC_TARGET_MACHINE="witherspoon"
root@witherspoon:~#

Returning correct value from handle_ipmi_command in ipmid.C

Currently, ipmid.C code has :

// Now that we have parsed the entire byte array from the caller
// we can call the ipmi router to do the work...
r = ipmi_netfn_router(netfn, cmd, (void *)request, (void *)response, &resplen);
if(r != 0)
{
    fprintf(stderr,"ERROR:[0x%X] handling NetFn:[0x%X], Cmd:[0x%X]\n",r, netfn, cmd);
}

Since "return -1" has been heavily used inside the plugin code that handles the commands, we need to re map that to something appropriate that is per IPMI spec.

This is what I was suggesting :
r = ipmi_netfn_router(netfn, cmd, (void *)request, (void *)response, &resplen);
if(r != 0)
{
fprintf(stderr,"ERROR:[0x%X] handling NetFn:[0x%X], Cmd:[0x%X]\n",r, netfn, cmd);
}

if (r == -1)
{

r = IPMI_CC_INVALID;  ( Or anything more meaningful in  ipmid-api.h )

}
memcpy(response, &r, IPMI_CC_LEN);

IPMI tool allowing to set different privilege for root user

IPMI tool allowing to set different privilege(e.g. callback, operator) for root user. This should not be allowed as we will loose admin access user.

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user list
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1   root             false   true       true       ADMINISTRATOR
2                    true    false      false      NO ACCESS
3                    true    false      false      NO ACCESS
4                    true    false      false      NO ACCESS
5                    true    false      false      NO ACCESS
6                    true    false      false      NO ACCESS
7                    true    false      false      NO ACCESS
8                    true    false      false      NO ACCESS
9                    true    false      false      NO ACCESS
10                   true    false      false      NO ACCESS
11                   true    false      false      NO ACCESS
12                   true    false      false      NO ACCESS
13                   true    false      false      NO ACCESS
14                   true    false      false      NO ACCESS
15                   true    false      false      NO ACCESS

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user priv 1 1 1
Set Privilege Level command successful (user 1)

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user list
Set Session Privilege Level to ADMINISTRATOR failed: Unknown (0x81)
Error: Unable to establish IPMI v2 / RMCP+ session

Unable to enable IPMI user with recent build

Unable to enable IPMI user with recent openbmc build.

Step to recreate

Create a IPMI user(e.g. user id 9 in below case). And set channel access for the user.

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> channel setaccess 1 9 link=on ipmi=on privilege=4
Set User Access (channel 1 id 9) successful.

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user list
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1   root             false   true       true       ADMINISTRATOR
2                    true    false      false      NO ACCESS
3                    true    false      false      NO ACCESS
4                    true    false      false      NO ACCESS
5                    true    false      false      NO ACCESS
6                    true    false      false      NO ACCESS
7                    true    false      false      NO ACCESS
8                    true    false      false      NO ACCESS
9   AErAQkpi         true    true       true       ADMINISTRATOR
10                   true    false      false      NO ACCESS
11                   true    false      false      NO ACCESS
12                   true    false      false      NO ACCESS
13                   true    false      false      NO ACCESS
14                   true    false      false      NO ACCESS
15  NIDONLKc         true    false      true       NO ACCESS

Enable newly created IPMI user.

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> user enable 9

Check status for enabled user IPMI user. (Here it will still be showing disable).

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> channel getaccess 1 9
Maximum User IDs     : 15
Enabled User IDs     : 1

User ID              : 9
User Name            : AErAQkpi
Fixed Name           : No
Access Available     : call-in / callback
Link Authentication  : enabled
IPMI Messaging       : enabled
Privilege Level      : ADMINISTRATOR
Enable Status        : disabled             <---- Status is still disabled
bash-4.1$

BMC build info:

root@witherspoon:~# cat /etc/os-release
ID="openbmc-phosphor"
NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
VERSION="2.6.0-rc1"
VERSION_ID="2.6.0-rc1-307-gadb83b2"
PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 2.6.0-rc1"
BUILD_ID="2.6.0-rc1"
OPENBMC_TARGET_MACHINE="witherspoon"
root@witherspoon:~#

Compile failure with later gcc version

Using gcc v5.4 uncovered the following compile failure

chassishandler.cpp: In function 'int dbus_get_property(const char*, char**)': chassishandler.cpp:127:34: error: ignoring return value of 'int asprintf(char**, const char*, ...)', declared with attribute warn_unused_result [-Werror=unused-result] asprintf(buf, "%s", temp_buf);

yocto build warning

WARNING: QA Issue: /usr/lib/host-ipmid/libstrgfnhandler.so_host-ipmid-fru contained in pack
age host-ipmid-fru requires libwritefrudata.so, but no providers found in its RDEPENDS [fil
e-rdeps]

Building the host-ipmid recipe generates this warning. It can be fixed by adding a proper -soname to the library and installing a symlink. For an example:

https://github.com/bradbishop/skeleton/blob/refactoring/libopenbmc_intf/Makefile

User list command without channel number is failing with inband IPMI

User list command without channel number is failing with inband IPMI.

Output of "user list" command without channel number:

root@system:~# ipmitool user list
IPMI command failed: Invalid data field in request
root@system:~#

Output of "user list" command with channel number:

root@system:~# ipmitool user list 1
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1   root             false   true       true       ADMINISTRATOR
2                    true    false      false      NO ACCESS
3                    true    false      false      NO ACCESS
4                    true    false      false      NO ACCESS
5                    true    false      false      NO ACCESS
6                    true    false      false      NO ACCESS
7                    true    false      false      NO ACCESS
8                    true    false      false      NO ACCESS
9                    true    false      false      NO ACCESS
10                   true    false      false      NO ACCESS
11                   true    false      false      NO ACCESS
12                   true    false      false      NO ACCESS
13                   true    false      false      NO ACCESS
14                   true    false      false      NO ACCESS
15                   true    false      false      NO ACCESS

Memory leaks in phosphor-host-ipmid

There are a few sd_bus_message objects leaked:

ipmi_app_get_device_guid - 'reply' is not unref'd.
ipmi_app_set_watchdog - 'reply' is not unref'd twice.
ipmi_app_reset_watchdog - 'reply' is not unref'd.
ipmi_transport_set_lan - 'reply' is not unref'd, 'm' is not unref'd, and 'req'/'res' are not unref'd in at least one code path.
ipmi_transport_get_lan - 'reply' and 'm' are not unref'd.

handle errors finding openbmc_path

These code paths in ipmid.C needs to handle the error on resolving the openbmc path.

int set_sensor_dbus_state_s(uint8_t number, const char *method, const char *value) {

r = find_openbmc_path("SENSOR", number, &a);

<< Error handling needs to go here >>

r = sd_bus_message_new_method_call(bus,&m,a.bus,a.path,a.interface,method);
if (r < 0) {

int set_sensor_dbus_state_y(uint8_t number, const char *method, const uint8_t value) {
r = find_openbmc_path("SENSOR", number, &a);

<< Error handling needs to go here >>

r = sd_bus_message_new_method_call(bus,&m,a.bus,a.path,a.interface,method);
if (r < 0) {

File : Storageaddsec.C

int create_esel_association(const uint8_t _buffer, char *_m) {

find_openbmc_path("SENSOR", sensor, &dbusint);

<< Do we need to check if r || this strlen ?? >>

// Simply no associations if the sensor can not be found
if (strlen(dbusint.path) < 1) {

sensorhandler.C

ipmi_ret_t ipmi_sen_get_sensor_reading(ipmi_netfn_t netfn, ipmi_cmd_t cmd,
r = find_openbmc_path("SENSOR", reqptr->sennum, &a);
<< Validation needs to go here >>
type = find_sensor(reqptr->sennum);

Commands returning c1 completion code

There are some commands showing c1 completion code (Command not supported). I found the respective source codes of the commands in this repository. Are these commands are fully implemented or partially that some configuration settings are required from my side?!

Request to get power limit information failed

| devdesc                  : Request to get power limit information failed     |
| moduleid                 : IPMI::MOD_IPMIDCMI                                |
| reasoncode               : IPMI::RC_DCMI_CMD_FAILED                          |
| userdata1                : BMC IPMI Completion code.

Mar 25 15:59:14 witherspoon phosphor-fru-fault-monitor[1415]: /xyz/openbmc_project/logging/entry/14 created
Mar 25 15:59:14 witherspoon ipmid[1416]: A host system event with a procedure callout
Mar 25 15:59:15 witherspoon phosphor-log-manager[1139]: Failed to find metadata
Mar 25 15:59:15 witherspoon phosphor-fru-fault-monitor[1415]: /xyz/openbmc_project/logging/entry/15 created
Mar 25 15:59:15 witherspoon ipmid[1416]: A host system event was received
Mar 25 15:59:15 witherspoon phosphor-fru-fault-monitor[1415]: /xyz/openbmc_project/logging/entry/16 created
Mar 25 15:59:16 witherspoon ipmid[1416]: A host system event with a procedure callout
Mar 25 15:59:16 witherspoon phosphor-fru-fault-monitor[1415]: /xyz/openbmc_project/logging/entry/17 created

{
	"__CURSOR" : "s=00807c6a70c74315806f24e2d8d304f2;i=de4e;b=f5cbb2cec356409d808d49b94e9c3426;m=1947b25f;t=584ed4941ec32;x=eece2147dc4b6e40",
	"__REALTIME_TIMESTAMP" : "1553529554725938",
	"__MONOTONIC_TIMESTAMP" : "424129119",
	"_BOOT_ID" : "f5cbb2cec356409d808d49b94e9c3426",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"_SYSTEMD_SLICE" : "system.slice",
	"_MACHINE_ID" : "c97507b417f747a98859858826898743",
	"_HOSTNAME" : "witherspoon",
	"PRIORITY" : "6",
	"_TRANSPORT" : "journal",
	"CODE_LINE" : "105",
	"CODE_FUNC" : "helper_log",
	"CODE_FILE" : "/tmp/openbmc/work/armv6-openbmc-linux-gnueabi/phosphor-led-manager/1.0+gitAUTOINC+555a279efd-r1/recipe-sysroot/usr/include/phosphor-logging/log.hpp",
	"MESSAGE" : "/xyz/openbmc_project/logging/entry/14 created",
	"TRANSACTION_ID" : "3175474994",
	"SYSLOG_IDENTIFIER" : "phosphor-fru-fault-monitor",
	"_PID" : "1415",
	"_COMM" : "phosphor-fru-fa",
	"_EXE" : "/usr/sbin/phosphor-fru-fault-monitor",
	"_CMDLINE" : "phosphor-fru-fault-monitor",
	"_SYSTEMD_CGROUP" : "/system.slice/obmc-fru-fault-monitor.service",
	"_SYSTEMD_UNIT" : "obmc-fru-fault-monitor.service",
	"_SYSTEMD_INVOCATION_ID" : "60dc80d033764eaeb9c059f2bd4c53c8",
	"_SOURCE_REALTIME_TIMESTAMP" : "1553529554725839"
}

Able to run IPMI command with user with IPMI messaging disabled and no access privilege

Able to run IPMI command with user with IPMI messaging disabled and no access privilege. We should not be allowed to run IPMI command with such user.

Step to recreate:

Created a user with name "newuser" and id "2"
Enable the user and set password to 0penBmc1
Check info of newly create user with "channel getaccess" command.

bash-4.1$ ipmitool -I lanplus -C 3 -U root -P 0penBmc -H <BMC_IP> channel getaccess 1 2
Maximum User IDs     : 15
Enabled User IDs     : 2

User ID              : 2
User Name            : newuser
Fixed Name           : No
Access Available     : call-in / callback
Link Authentication  : disabled
IPMI Messaging       : disabled                   <---- Messaging set to disabled
Privilege Level      : NO ACCESS                <---- Privilege set to NO access
Enable Status        : enabled

Now run IPMI command to check sel info using this user. Here we don't see any error.

bash-4.1$ ipmitool -I lanplus -C 3 -U newuser -P 0penBmc1 -H <BMC_IP> sel info
SEL Information
Version          : 1.5 (v1.5, v2 compliant)
Entries          : 1
Free Space       : 0 bytes
Percent Used     : 100%
Last Add Time    : 02/22/2019 05:31:45
Last Del Time    : Not Available
Overflow         : false
Supported Cmds   : 'Delete' 'Reserve'

Enhance support for multi-interface sensors

This work will help enable further work on set-sensor.

Reorganize yaml to more clearly denote read and write interfaces, and provide one interface per offset instead of multiple offsets per interface.
Reorganize code to generalize based on the interfaces and offsets available. Add offset parameter to find_openbmc_path(). Use offsets and all interfaces given to read and write bytes for Get Sensor Reading and Set Sensor Reading.

how to support user manage

how to support usr manage，so that， can use cmd of ipmitool user 。

Optimize SDR generation, transmission, and storage

After https://gerrit.openbmc-project.xyz/#/c/4138 there are a few issues with the SDR remaining:

The full record is transmitted even if the bytes-to-read field is specified in the request for Get SDR. This wastes time transmitting bytes that are thrown away by the consumer.
The full record is generated every time Get SDR is called, even though it is slow-moving and suitable for cache.

I propose caching the SDR by the reservation ID, ensuring that the device ID requested matches the device ID in the cached SDR, and checking the bytes-to-read field and only sending the amount requested. If we want we can cache SDRs longer and not regenerate them each time 'sensor list' is called from ipmitool, but for now my suggestion would cache them only to eliminate generating the entire SDR twice for a single 'get sensor' call from ipmitool (once for the header read and once again for reading the remainder of the body).

Refactor code to eliminate floating-point math in IPMI sensor handling

Beginning with https://gerrit.openbmc-project.xyz/#/c/4135, floating-point math (pow() and *) is used in sensorhandler.cpp to scale DBus readings down to a single byte for transmission over IPMI.

Witherspoon : IPMID Inventory update error

[email protected]:~# journalctl --no-pager -b | grep -e Incomplete -e " Populating FRU areas failed" -e "Unable to get the fru info" -e "Error updating inventory"
Nov 13 03:57:26 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:26 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:26 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:26 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:28 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:28 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:29 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:29 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Incomplete Fru file
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Populating FRU areas failed
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Unable to get the fru info
Nov 13 03:57:31 xx.xx.xx.xx ipmid[1262]: Error updating inventory.
[email protected]:~#
```
Journald meta data
```
{
	"__CURSOR" : "s=72a0e07855c24c12af67d3de60b7414e;i=a5d41;b=5c9af445a01a493d88dfabcd16906c6e;m=fb0908f;t=57a83d1215bed;x=98e86c3f2f947891",
	"__REALTIME_TIMESTAMP" : "1542081451482093",
	"__MONOTONIC_TIMESTAMP" : "263229583",
	"_BOOT_ID" : "5c9af445a01a493d88dfabcd16906c6e",
	"_TRANSPORT" : "journal",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"_MACHINE_ID" : "f971e87fd1544bdd83d266f384407285",
	"_HOSTNAME" : "xx.xx.xx.xx",
	"CODE_FILE" : "/usr/include/phosphor-logging/log.hpp",
	"CODE_LINE" : "102",
	"CODE_FUNC" : "helper_log",
	"_SYSTEMD_SLICE" : "system.slice",
	"TRANSACTION_ID" : "4088698828",
	"SYSLOG_IDENTIFIER" : "ipmid",
	"_PID" : "1262",
	"_COMM" : "ipmid",
	"_EXE" : "/usr/sbin/ipmid",
	"_CMDLINE" : "ipmid",
	"_SYSTEMD_CGROUP" : "/system.slice/phosphor-ipmi-host.service",
	"_SYSTEMD_UNIT" : "phosphor-ipmi-host.service",
	"_SYSTEMD_INVOCATION_ID" : "5596e907227f4448a3785dd2eb64fdc8",
	"PRIORITY" : "3",
	"MESSAGE" : "Error updating inventory.",
	"_SOURCE_REALTIME_TIMESTAMP" : "1542081451479627"
}
```

legacy (and unsupported) org.openbmc.settings.Host still references in this repoistory

Need to switch over to new settings interface in xyz.openbmc_project namespace (or just delete some unused code maybe?):

chassishandler.cpp

const char* host_intf_name = "org.openbmc.settings.Host";

Cleanup needed in storageaddsel.C

1: send_esel_to_dbus returns an integer value but its not consumed by send_esel.

2: In getfilestream API, need to handle errors during file IO. Currently, it assumes everything will go right.

Witherspoon : org.freedesktop.DBus.Error.UnknownObject: Unknown object

ipmitool -I lanplus -H xx.xx.xx.xx -P 0penBmc fru print -N 50

Nov 13 04:30:13 xx.xx.xx.xx netipmid[2642]: E> Unspecified error for command 0x2810 - sd_bus_call: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card2'.
Nov 13 04:30:13 xx.xx.xx.xx netipmid[2642]: E> Unspecified error for command 0x2810 - sd_bus_call: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card5'.

Old namespace /org/openbmc/settings/host0 required for chassishandler

It appears that the chassishandler relies on an older namespace. Likely this update will be blocked on the other portions. In the immediate, phosphor-settings/.../settings_manager.py is providing /org/openbmc/settings/host0.

changes to cache_restricted_mode()

Currently, IPMID is watching for any kind signal from settings.Host and whenever there is one, its going and making a call back to settingsd to read the value of restricted_mode.

Instead, it can do:

1/. Look for PropertiesChanged method in the FILTER
2/. On the arrival of signal, parse the dictionary and use the data instead of making a call back.

joel@aurora ~/dev/obmc/phosphor-host-ipmid :master 
$ ./bootstrap.sh 
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:26: error: possibly undefined macro: LT_LIB_DLLOAD
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
Run "./configure ${CONFIGURE_FLAGS} && make"
joel@aurora ~/dev/obmc/phosphor-host-ipmid :master 
$ ./configure 
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

If I run bootstrap.sh a second time:

joel@aurora ~/dev/obmc/phosphor-host-ipmid :master 
$ ./bootstrap.sh 
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:11: installing './ar-lib'
configure.ac:10: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:5: installing './missing'
Makefile.am: installing './depcomp'
Run "./configure ${CONFIGURE_FLAGS} && make"
joel@aurora ~/dev/obmc/phosphor-host-ipmid :master 
$ ./configure 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
./configure: line 3690: syntax error near unexpected token `noext'
./configure: line 3690: `AX_CXX_COMPILE_STDCXX_14(noext)'

Investigate move to sdbusplus

Moving to sdbusplus within phosphor-host-ipmid may improve code quality and testability. We should determine whether we want to switch away from sdbus API to use sdbusplus instead.