IPMI LAN command story design - try 3rd send
vernon.mauery at linux.intel.com
Fri Dec 15 03:26:08 AEDT 2017
On 14-Dec-2017 10:45 PM, Jeremy Kerr wrote:
>>> Adding the 10-second delay allows users to "batch" multiple changes,
>>> meaning that network connectivity isn't lost between those changes. This
>>> is purely to allow ipmitool (which doesn't have a facility to make
>>> multiple changes before indicating that the change is complete) to be
>>> used over the network to change the lan configuration (which is a bit
>>> risky regardless...).
>> Yeah all this lack of clarity, arises from a lack of mechanism in IPMI to
>> apply multiple changes (IP address, netmask gateway) together.
>No, the specification provides a way to do exactly that:
> 1) Change set-complete to 0x01
> 2) Send Set LAN Configuration command to update the actual LAN
> configuration parameters. If more than one parameter is changed, then
> multiple commands can be sent.
> 3) Change set-complete to 0x00
>It's just that ipmitool only has code to change one parameter at a time
>at (2). It still does the set-complete process.
I would agree. ipmitool is broken. It should have a
network-start-configure mechanism that would set the set-complete bit.
The you could send any number of its network configuration parameters.
Then it should have a network-finish-configure command that would clear
the set-complete bit.
In the case where people forget to send the final command, the BMC
should implement a timeout so it can automatically apply the settings
and clear the flag after a certain amount of time (10 seconds or more).
It appears that ipmitool had a short period of activity there at the
beginning of 2017, but not a peep since. I pushed a fix for a bug
several weeks back and have not heard anything.
>>> To implement something complying to a "principle of least surprise", I'd
>>> suggest that we should:
>>> - batch changes, and have them applied after 10 seconds from clearing
>>> the set-in-progress flag
>>> - submit patches to ipmitool to allow multiple changes to be applied
>>> at once (ie, one clearing of the set-in-progress flag).
>> I prefer the second option of allowing ipmitool to explicitly clear the
>> set-in-progress flag.
>They're not "or" options. We'd need to do both.
>> The first option is really "unusual way" to get this done, to overcome
>> a specification shortcoming.
>It's not a specification shortcoming; the specification explicitly
>supports this, it's just that ipmitool doesn't.
>The 10-second delay is a server-side workaround for that, and is present
>on other BMC implementations out there. We should implement that
>workaround, because asking everyone to update to a new ipmitool version
>isn't feasible either.
More information about the openbmc