IPMI LAN command story design - try 3rd send

Tom Joseph tomjose at linux.vnet.ibm.com
Thu Dec 14 22:23:35 AEDT 2017

On Wednesday 13 December 2017 08:38 AM, Jeremy Kerr wrote:
> Hi all,
> Digging up an old thread here, but I think this is important:
>> Thanks for the explanation.  With this website you pointed to and some
>> other investigation I've done, I am comfortable with us using the 'Set
>> Channel Access' as the time to apply the settings.  The documentation of
>> two competition products both seem to require an 'ipmitool mc reset
>> warm' for IP address changes to take effect, so we are at least better
>> than that.
> The two BMC implementations that I'm aware of do not require a mc reset
> for lan parameters to be applied. Both will apply settings without
> further commands. One will wait 10 seconds before applying settings, to
> allow multiple changes to be grouped into a single reconfiguration.
> Requiring non-standard command to be issued causes a disconnect between
> user expectations and our implementation. We'd have to document this
> difference in behaviour for every potential sysadmin interacting with
> OpenBMC.
  The command to apply BMC network settings on OpenBMC IPMI reference
  implementation is set channel access, which is a standard command
  mentioned in the IPMI specification.

  It is not clear to me from the IPMI specification, on which 
  the BMC network settings are applied. The BMC implementation that 
applies the
  settings after `10` sec does it after which parameter? It sounds like 
an OEM/custom
way of doing and not based on IPMI specification.

If you can provide more details on how it is done on the BMC 
implementation, we
can consider it as a way to implement this command.

>> Can you internally track down a contact on the xCAT team and verify that
>> this will be ok with them?
> Not just xCAT, but every other provisioning software that will support
> OpenBMC. Including ones that are custom-developed. That's not feasible.
> For cases like this, we should really reconsider before coming up with
> our own special interface requirements.
> Regards,
> Jeremy

More information about the openbmc mailing list