<div dir="ltr">FWIW - OpenBMC does seem to have a fork of ipmitool... I don't think we've done much to it.  <a href="https://github.com/openbmc/ipmitool">https://github.com/openbmc/ipmitool</a><div><br></div><div>However, that doesn't fix the problem you mention, that it's likely not the same version packaged with the host's image, and that that version is in burned-out-maintainer limbo.  That's why I'd prefer to do what we can to view ipmitool as immutable, to make it easier for someone to use OpenBMC with their system.</div><div><br></div><div>To flip one last time, though, at Google we use ipmitool as a library and wrap it in another internal utility, and so we can make changes either to ipmitool itself or two how we call it really easily.  I wonder whether many other OpenBMC users who care about IPMI are doing something similar to us.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 21, 2018 at 7:55 AM Alexander Amelkin <<a href="mailto:a.amelkin@yadro.com">a.amelkin@yadro.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just my 2 cents.<br>
<br>
I did previously some commits to the ipmitool project, and can tell that<br>
fixing ipmitool upstream now doesn't seem feasible as the only active<br>
project maintainer (Zdenek Styblik) has called it quits about a year<br>
ago. I've tried asking him to make me an admin of the project he doesn't<br>
want to maintain anymore, but he just stopped responding.<br>
<br>
I'm thinking about forking off (actually did it to YADRO organization on<br>
github) and starting to maintain our own version of ipmitool. That<br>
however doesn't solve the problem as the original ipmitool is a part of<br>
all the available Linux distros, and making their maintainers switch to<br>
our version I anticipate to be hell of a quest...<br>
<br>
Applying the changes with a timeout after the set-complete looks good to<br>
me as it both follows the specification and allows for addressing the<br>
incorrect behavior of the original ipmitool.<br>
<br>
Alexander.<br>
<br>
<br>
13.03.2018 18:36, Tom Joseph wrote:<br>
> Hello,<br>
><br>
> There is a patch up for applying the network settings, with this patch<br>
> it would not require set channel access command to apply the changes.<br>
> A timer kicks in everytime set-complete happens, and the network<br>
> settings are applied once the timer expires.<br>
><br>
> <a href="https://gerrit.openbmc-project.xyz/#/q/topic:2932" rel="noreferrer" target="_blank">https://gerrit.openbmc-project.xyz/#/q/topic:2932</a><br>
><br>
> Regards,<br>
> Tom<br>
><br>
> On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote:<br>
>> On 14-Feb-2018 12:32 PM, Patrick Venture wrote:<br>
>>> I thought you had to explicitly set in_progress with the ipmitool?  My<br>
>>> own ipmitool utility is implemented as you described where it doesn't<br>
>>> assume anything about your intent, just follows the actions.<br>
>><br>
>> Currently, ipmitool (incorrectly) sets the "set in progress" bit for<br>
>> every lan configuration parameter it sets. Given how the CLI<br>
>> interface only allows the user to specify a single parameter at a<br>
>> time, it might be smart to have ipmitool also expose controls for the<br>
>> "set in progress" bit. Alternately, providing a way to to specify<br>
>> multiple parameters in a single call would be good. Something like:<br>
>><br>
>> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1<br>
>> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp<br>
>><br>
>> and it would automatically set and use the set in progress bit<br>
>> correctly.<br>
>><br>
>> And ipmid could then take two actions, depending on how this bit is<br>
>> (ab)used:<br>
>> 1) if only a single command is wrapped up in the<br>
>> set-in-progress/set-complete, then employ a timeout so that after<br>
>> some amount of time, all the queued commands get applied.<br>
>> 2) if multiple commands get wrapped up in the<br>
>> set-in-progress/set-complete, then apply the command set when the<br>
>> set-complete is received.<br>
>><br>
>> Getting ipmitool changed to have correct behavior will take some<br>
>> doing, so we will need to be able to deal with its incorrect behavior<br>
>> for now. But also responding to correct behavior can make tools that<br>
>> employ that behavior work even better (with no timeout delays).<br>
>><br>
>> Just my $0.02.<br>
>><br>
>> --Vernon<br>
>><br>
>>> There's definitely the possibility of thrashing.<br>
>>><br>
>>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley<br>
>>> <<a href="mailto:david.j.cobbley@linux.intel.com" target="_blank">david.j.cobbley@linux.intel.com</a>> wrote:<br>
>>>> Do you have any concerns about ipmitool constantly flushing the<br>
>>>> network as<br>
>>>> it sets & unsets the complete bit inbetween parameters,<br>
>>>> i.e. if you are setting 4 different parameters from a script?<br>
>>>><br>
>>>> I'm not sure if this brings a lot of thrashing to the to the ipmi<br>
>>>> network<br>
>>>> stack or network manager.<br>
>>>><br>
>>>> Seems like it would be prudent to fix ipmitool upstream to allow<br>
>>>> you to set<br>
>>>> multiple parameters, in addition to the ipmi stack.<br>
>>>><br>
>>>><br>
>>>>> I personally have found this non-standard implementation a bit<br>
>>>>> unpleasant, as it requires using a different command to basically<br>
>>>>> flush it.  I am planning to implement it such that setting in<br>
>>>>> progress<br>
>>>>> before and complete after is how it all gets flushed instead of a<br>
>>>>> timeout, since that approach reads more correct given the<br>
>>>>> specification.  And really it's just about literally calling a<br>
>>>>> subroutine to flush everything when the in_progress bit is set to<br>
>>>>> completed, and removing the code from "access on"<br>
>>>>><br>
>>>>> If you're interested to do what I've just described, I don't think<br>
>>>>> you'll get any push-back.<br>
>>>>><br>
>>>>> Patrick<br>
>>>>><br>
>>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley<br>
>>>>> <<a href="mailto:david.j.cobbley@linux.intel.com" target="_blank">david.j.cobbley@linux.intel.com</a>> wrote:<br>
>>>>>><br>
>>>>>> I noticed that when using ipmitool lan set <channel> <parameter>,<br>
>>>>>> the<br>
>>>>>> openbmc stack does not apply the settings. This seems like a<br>
>>>>>> non-standard<br>
>>>>>> implementation. While using ipmitool as the standard is not quite<br>
>>>>>> correct,<br>
>>>>>> customers do expect it to work.<br>
>>>>>><br>
>>>>>> After sending any sort of lan set command with ipmitool, the changes<br>
>>>>>> don't<br>
>>>>>> appear to stick and this message shows up in the journal:<br>
>>>>>>      "Use Set Channel Access command to apply"<br>
>>>>>><br>
>>>>>> I know IPMI 2.0 is a little ambiguous about implementation<br>
>>>>>> specifics, but<br>
>>>>>> I<br>
>>>>>> believe the intention was to utilize the "Set In Progress" bit<br>
>>>>>> (Parameter<br>
>>>>>> 0)<br>
>>>>>> while doing work, and use "Set Complete" when you are finished to<br>
>>>>>> flush<br>
>>>>>> the<br>
>>>>>> changes.<br>
>>>>>><br>
>>>>>> To work around ipmitool constantly setting and unsetting the "Set In<br>
>>>>>> Progress" bit in between every parameter applied, some BMC stacks<br>
>>>>>> accumulate<br>
>>>>>> network changes over a period of time and apply after a timeout -<br>
>>>>>> this is<br>
>>>>>> also compatible with ipmitool's non-standard use of the "Set In<br>
>>>>>> Progress"<br>
>>>>>> bit.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Is there a plan to circle back and change this functionality to<br>
>>>>>> work with<br>
>>>>>> ipmitool in the future?<br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>> -Dave Cobbley<br>
>>>>>><br>
>>>><br>
>><br>
><br>
<br>
<br>
</blockquote></div>