tree 9a2e4a5fe7cfe58298fc9ab2d64f6d29e0ed6cf9
parent a6695a8441445e441009ad64ff04c732f2538426
author Andrew Geissler <geissonator@yahoo.com> 1680798461 -0600
committer Ed Tanous <ed@tanous.net> 1684512226 +0000

redfish: network protocol fix for multiple interfaces

Some OpenBMC systems may have multiple ethernet interfaces available but
choose to only enable a subset of them. In these situations, the bmcweb
code needs to ensure it has the proper logic to determine if a
particular protocol is enabled under the redfish API:
  redfish/v1/Managers/bmc/NetworkProtocol

For example, to determine if the IPMI service is enabled, bmcweb looks
at systemd units (phosphor-ipmi-net@<eth>.socket) that are instantiated
based on the ethernet interfaces in the system.

This commit changes the logic which determines if a particular protocol
is enabled to look to see if the systemd service is enabled on _any_
network interface. If it is found on any interface then it is considered
to be enabled. For example, if the netipmid application is running
against any of the available network interfaces then it should be
returned to the user that the IPMI protocol is enabled.

The current behavior of the code is somewhat undefined in that it just
uses the state of the last phosphor-ipmi-net@ethX.socket to determine
what it returns to the user.

Tested:
- Confirmed on system with netipmid running on eth0 and not on eth1 that
  response was IPMI enabled
- Confirmed on same system that a POST to disable IPMI worked, netipmid
  was stopped, and the NetworkProtocol response indicated IPMI disabled*
- Confirmed on same system that a POST to enable IPMI worked, netipmid
  was running on eth0, and the NetworkProtocol response indicated IPMI
  enabled
- Confirmed on system with both eth0 and eth1 enabled that we got
  expected behavior
- No issues in Redfish Validator

* Testing showed an issue introduced with 5c3e927 where a default of
  "Disabled" is no longer returned when services like IPMI and SSH are
  disabled. The protocol is simply not shown in the NetworkProtocol
  response. It can still be enabled via a PATCH operation. As this issue
  is unrelated to this patch, I'll submit a separate commit to discuss
  whether we should go back to a default when protocols are disabled.

Change-Id: Ib55914b1403ca96ed7ace450f79af3b47b5c8e59
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>