IPMI Set LAN Configuration Parameters

IPMI Set LAN Configuration Parameters

[Dave Cobbley]

I noticed that when using ipmitool lan set <channel> <parameter>, the 
openbmc stack does not apply the settings. This seems like a 
non-standard implementation. While using ipmitool as the standard is not 
quite correct, customers do expect it to work.

After sending any sort of lan set command with ipmitool, the changes 
don't appear to stick and this message shows up in the journal:
     "Use Set Channel Access command to apply"

I know IPMI 2.0 is a little ambiguous about implementation specifics, 
but I believe the intention was to utilize the "Set In Progress" bit 
(Parameter 0) while doing work, and use "Set Complete" when you are 
finished to flush the changes.

To work around ipmitool constantly setting and unsetting the "Set In 
Progress" bit in between every parameter applied, some BMC stacks 
accumulate network changes over a period of time and apply after a 
timeout - this is also compatible with ipmitool's non-standard use of 
the "Set In Progress" bit.


Is there a plan to circle back and change this functionality to work 
with ipmitool in the future?

Thanks,
-Dave Cobbley

Re: IPMI Set LAN Configuration Parameters

[Patrick Venture]

I personally have found this non-standard implementation a bit
unpleasant, as it requires using a different command to basically
flush it.  I am planning to implement it such that setting in progress
before and complete after is how it all gets flushed instead of a
timeout, since that approach reads more correct given the
specification.  And really it's just about literally calling a
subroutine to flush everything when the in_progress bit is set to
completed, and removing the code from "access on"

If you're interested to do what I've just described, I don't think
you'll get any push-back.

Patrick

On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley
<david.j.cobbley@linux.intel.com> wrote:
> I noticed that when using ipmitool lan set <channel> <parameter>, the
> openbmc stack does not apply the settings. This seems like a non-standard
> implementation. While using ipmitool as the standard is not quite correct,
> customers do expect it to work.
>
> After sending any sort of lan set command with ipmitool, the changes don't
> appear to stick and this message shows up in the journal:
>     "Use Set Channel Access command to apply"
>
> I know IPMI 2.0 is a little ambiguous about implementation specifics, but I
> believe the intention was to utilize the "Set In Progress" bit (Parameter 0)
> while doing work, and use "Set Complete" when you are finished to flush the
> changes.
>
> To work around ipmitool constantly setting and unsetting the "Set In
> Progress" bit in between every parameter applied, some BMC stacks accumulate
> network changes over a period of time and apply after a timeout - this is
> also compatible with ipmitool's non-standard use of the "Set In Progress"
> bit.
>
>
> Is there a plan to circle back and change this functionality to work with
> ipmitool in the future?
>
> Thanks,
> -Dave Cobbley
>

Re: IPMI Set LAN Configuration Parameters

[Dave Cobbley]

Do you have any concerns about ipmitool constantly flushing the network 
as it sets & unsets the complete bit inbetween parameters,
i.e. if you are setting 4 different parameters from a script?

I'm not sure if this brings a lot of thrashing to the to the ipmi 
network stack or network manager.

Seems like it would be prudent to fix ipmitool upstream to allow you to 
set multiple parameters, in addition to the ipmi stack.

> I personally have found this non-standard implementation a bit
> unpleasant, as it requires using a different command to basically
> flush it.  I am planning to implement it such that setting in progress
> before and complete after is how it all gets flushed instead of a
> timeout, since that approach reads more correct given the
> specification.  And really it's just about literally calling a
> subroutine to flush everything when the in_progress bit is set to
> completed, and removing the code from "access on"
>
> If you're interested to do what I've just described, I don't think
> you'll get any push-back.
>
> Patrick
>
> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley
> <david.j.cobbley@linux.intel.com> wrote:
>> I noticed that when using ipmitool lan set <channel> <parameter>, the
>> openbmc stack does not apply the settings. This seems like a non-standard
>> implementation. While using ipmitool as the standard is not quite correct,
>> customers do expect it to work.
>>
>> After sending any sort of lan set command with ipmitool, the changes don't
>> appear to stick and this message shows up in the journal:
>>      "Use Set Channel Access command to apply"
>>
>> I know IPMI 2.0 is a little ambiguous about implementation specifics, but I
>> believe the intention was to utilize the "Set In Progress" bit (Parameter 0)
>> while doing work, and use "Set Complete" when you are finished to flush the
>> changes.
>>
>> To work around ipmitool constantly setting and unsetting the "Set In
>> Progress" bit in between every parameter applied, some BMC stacks accumulate
>> network changes over a period of time and apply after a timeout - this is
>> also compatible with ipmitool's non-standard use of the "Set In Progress"
>> bit.
>>
>>
>> Is there a plan to circle back and change this functionality to work with
>> ipmitool in the future?
>>
>> Thanks,
>> -Dave Cobbley
>>

Re: IPMI Set LAN Configuration Parameters

[Patrick Venture]

I thought you had to explicitly set in_progress with the ipmitool?  My
own ipmitool utility is implemented as you described where it doesn't
assume anything about your intent, just follows the actions.

There's definitely the possibility of thrashing.

On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley
<david.j.cobbley@linux.intel.com> wrote:
> Do you have any concerns about ipmitool constantly flushing the network as
> it sets & unsets the complete bit inbetween parameters,
> i.e. if you are setting 4 different parameters from a script?
>
> I'm not sure if this brings a lot of thrashing to the to the ipmi network
> stack or network manager.
>
> Seems like it would be prudent to fix ipmitool upstream to allow you to set
> multiple parameters, in addition to the ipmi stack.
>
>
>> I personally have found this non-standard implementation a bit
>> unpleasant, as it requires using a different command to basically
>> flush it.  I am planning to implement it such that setting in progress
>> before and complete after is how it all gets flushed instead of a
>> timeout, since that approach reads more correct given the
>> specification.  And really it's just about literally calling a
>> subroutine to flush everything when the in_progress bit is set to
>> completed, and removing the code from "access on"
>>
>> If you're interested to do what I've just described, I don't think
>> you'll get any push-back.
>>
>> Patrick
>>
>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley
>> <david.j.cobbley@linux.intel.com> wrote:
>>>
>>> I noticed that when using ipmitool lan set <channel> <parameter>, the
>>> openbmc stack does not apply the settings. This seems like a non-standard
>>> implementation. While using ipmitool as the standard is not quite
>>> correct,
>>> customers do expect it to work.
>>>
>>> After sending any sort of lan set command with ipmitool, the changes
>>> don't
>>> appear to stick and this message shows up in the journal:
>>>      "Use Set Channel Access command to apply"
>>>
>>> I know IPMI 2.0 is a little ambiguous about implementation specifics, but
>>> I
>>> believe the intention was to utilize the "Set In Progress" bit (Parameter
>>> 0)
>>> while doing work, and use "Set Complete" when you are finished to flush
>>> the
>>> changes.
>>>
>>> To work around ipmitool constantly setting and unsetting the "Set In
>>> Progress" bit in between every parameter applied, some BMC stacks
>>> accumulate
>>> network changes over a period of time and apply after a timeout - this is
>>> also compatible with ipmitool's non-standard use of the "Set In Progress"
>>> bit.
>>>
>>>
>>> Is there a plan to circle back and change this functionality to work with
>>> ipmitool in the future?
>>>
>>> Thanks,
>>> -Dave Cobbley
>>>
>

Re: IPMI Set LAN Configuration Parameters

[Vernon Mauery]

On 14-Feb-2018 12:32 PM, Patrick Venture wrote:
>I thought you had to explicitly set in_progress with the ipmitool?  My
>own ipmitool utility is implemented as you described where it doesn't
>assume anything about your intent, just follows the actions.

Currently, ipmitool (incorrectly) sets the "set in progress" bit for 
every lan configuration parameter it sets. Given how the CLI interface 
only allows the user to specify a single parameter at a time, it might 
be smart to have ipmitool also expose controls for the "set in progress" 
bit. Alternately, providing a way to to specify multiple parameters in a 
single call would be good. Something like:

ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1 dns 1.2.1.1 
ipmitool lan set 1 ipsrc dhcp

and it would automatically set and use the set in progress bit 
correctly.

And ipmid could then take two actions, depending on how this bit is 
(ab)used:
1) if only a single command is wrapped up in the 
set-in-progress/set-complete, then employ a timeout so that after some 
amount of time, all the queued commands get applied.
2) if multiple commands get wrapped up in the 
set-in-progress/set-complete, then apply the command set when the 
set-complete is received.

Getting ipmitool changed to have correct behavior will take some doing, 
so we will need to be able to deal with its incorrect behavior for now. 
But also responding to correct behavior can make tools that employ that 
behavior work even better (with no timeout delays).

Just my $0.02.

--Vernon

>There's definitely the possibility of thrashing.
>
>On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley
><david.j.cobbley@linux.intel.com> wrote:
>> Do you have any concerns about ipmitool constantly flushing the network as
>> it sets & unsets the complete bit inbetween parameters,
>> i.e. if you are setting 4 different parameters from a script?
>>
>> I'm not sure if this brings a lot of thrashing to the to the ipmi network
>> stack or network manager.
>>
>> Seems like it would be prudent to fix ipmitool upstream to allow you to set
>> multiple parameters, in addition to the ipmi stack.
>>
>>
>>> I personally have found this non-standard implementation a bit
>>> unpleasant, as it requires using a different command to basically
>>> flush it.  I am planning to implement it such that setting in progress
>>> before and complete after is how it all gets flushed instead of a
>>> timeout, since that approach reads more correct given the
>>> specification.  And really it's just about literally calling a
>>> subroutine to flush everything when the in_progress bit is set to
>>> completed, and removing the code from "access on"
>>>
>>> If you're interested to do what I've just described, I don't think
>>> you'll get any push-back.
>>>
>>> Patrick
>>>
>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley
>>> <david.j.cobbley@linux.intel.com> wrote:
>>>>
>>>> I noticed that when using ipmitool lan set <channel> <parameter>, the
>>>> openbmc stack does not apply the settings. This seems like a non-standard
>>>> implementation. While using ipmitool as the standard is not quite
>>>> correct,
>>>> customers do expect it to work.
>>>>
>>>> After sending any sort of lan set command with ipmitool, the changes
>>>> don't
>>>> appear to stick and this message shows up in the journal:
>>>>      "Use Set Channel Access command to apply"
>>>>
>>>> I know IPMI 2.0 is a little ambiguous about implementation specifics, but
>>>> I
>>>> believe the intention was to utilize the "Set In Progress" bit (Parameter
>>>> 0)
>>>> while doing work, and use "Set Complete" when you are finished to flush
>>>> the
>>>> changes.
>>>>
>>>> To work around ipmitool constantly setting and unsetting the "Set In
>>>> Progress" bit in between every parameter applied, some BMC stacks
>>>> accumulate
>>>> network changes over a period of time and apply after a timeout - this is
>>>> also compatible with ipmitool's non-standard use of the "Set In Progress"
>>>> bit.
>>>>
>>>>
>>>> Is there a plan to circle back and change this functionality to work with
>>>> ipmitool in the future?
>>>>
>>>> Thanks,
>>>> -Dave Cobbley
>>>>
>>

Re: IPMI Set LAN Configuration Parameters

[Tom Joseph]

Hello,

There is a patch up for applying the network settings, with this patch 
it would not require set channel access command to apply the changes.
A timer kicks in everytime set-complete happens, and the network 
settings are applied once the timer expires.

https://gerrit.openbmc-project.xyz/#/q/topic:2932

Regards,
Tom

On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote:
> On 14-Feb-2018 12:32 PM, Patrick Venture wrote:
>> I thought you had to explicitly set in_progress with the ipmitool?  My
>> own ipmitool utility is implemented as you described where it doesn't
>> assume anything about your intent, just follows the actions.
>
> Currently, ipmitool (incorrectly) sets the "set in progress" bit for 
> every lan configuration parameter it sets. Given how the CLI interface 
> only allows the user to specify a single parameter at a time, it might 
> be smart to have ipmitool also expose controls for the "set in 
> progress" bit. Alternately, providing a way to to specify multiple 
> parameters in a single call would be good. Something like:
>
> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1 
> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp
>
> and it would automatically set and use the set in progress bit correctly.
>
> And ipmid could then take two actions, depending on how this bit is 
> (ab)used:
> 1) if only a single command is wrapped up in the 
> set-in-progress/set-complete, then employ a timeout so that after some 
> amount of time, all the queued commands get applied.
> 2) if multiple commands get wrapped up in the 
> set-in-progress/set-complete, then apply the command set when the 
> set-complete is received.
>
> Getting ipmitool changed to have correct behavior will take some 
> doing, so we will need to be able to deal with its incorrect behavior 
> for now. But also responding to correct behavior can make tools that 
> employ that behavior work even better (with no timeout delays).
>
> Just my $0.02.
>
> --Vernon
>
>> There's definitely the possibility of thrashing.
>>
>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley
>> <david.j.cobbley@linux.intel.com> wrote:
>>> Do you have any concerns about ipmitool constantly flushing the 
>>> network as
>>> it sets & unsets the complete bit inbetween parameters,
>>> i.e. if you are setting 4 different parameters from a script?
>>>
>>> I'm not sure if this brings a lot of thrashing to the to the ipmi 
>>> network
>>> stack or network manager.
>>>
>>> Seems like it would be prudent to fix ipmitool upstream to allow you 
>>> to set
>>> multiple parameters, in addition to the ipmi stack.
>>>
>>>
>>>> I personally have found this non-standard implementation a bit
>>>> unpleasant, as it requires using a different command to basically
>>>> flush it.  I am planning to implement it such that setting in progress
>>>> before and complete after is how it all gets flushed instead of a
>>>> timeout, since that approach reads more correct given the
>>>> specification.  And really it's just about literally calling a
>>>> subroutine to flush everything when the in_progress bit is set to
>>>> completed, and removing the code from "access on"
>>>>
>>>> If you're interested to do what I've just described, I don't think
>>>> you'll get any push-back.
>>>>
>>>> Patrick
>>>>
>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley
>>>> <david.j.cobbley@linux.intel.com> wrote:
>>>>>
>>>>> I noticed that when using ipmitool lan set <channel> <parameter>, the
>>>>> openbmc stack does not apply the settings. This seems like a 
>>>>> non-standard
>>>>> implementation. While using ipmitool as the standard is not quite
>>>>> correct,
>>>>> customers do expect it to work.
>>>>>
>>>>> After sending any sort of lan set command with ipmitool, the changes
>>>>> don't
>>>>> appear to stick and this message shows up in the journal:
>>>>>      "Use Set Channel Access command to apply"
>>>>>
>>>>> I know IPMI 2.0 is a little ambiguous about implementation 
>>>>> specifics, but
>>>>> I
>>>>> believe the intention was to utilize the "Set In Progress" bit 
>>>>> (Parameter
>>>>> 0)
>>>>> while doing work, and use "Set Complete" when you are finished to 
>>>>> flush
>>>>> the
>>>>> changes.
>>>>>
>>>>> To work around ipmitool constantly setting and unsetting the "Set In
>>>>> Progress" bit in between every parameter applied, some BMC stacks
>>>>> accumulate
>>>>> network changes over a period of time and apply after a timeout - 
>>>>> this is
>>>>> also compatible with ipmitool's non-standard use of the "Set In 
>>>>> Progress"
>>>>> bit.
>>>>>
>>>>>
>>>>> Is there a plan to circle back and change this functionality to 
>>>>> work with
>>>>> ipmitool in the future?
>>>>>
>>>>> Thanks,
>>>>> -Dave Cobbley
>>>>>
>>>
>

Re: IPMI Set LAN Configuration Parameters

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 5961 bytes --]

Just my 2 cents.

I did previously some commits to the ipmitool project, and can tell that
fixing ipmitool upstream now doesn't seem feasible as the only active
project maintainer (Zdenek Styblik) has called it quits about a year
ago. I've tried asking him to make me an admin of the project he doesn't
want to maintain anymore, but he just stopped responding.

I'm thinking about forking off (actually did it to YADRO organization on
github) and starting to maintain our own version of ipmitool. That
however doesn't solve the problem as the original ipmitool is a part of
all the available Linux distros, and making their maintainers switch to
our version I anticipate to be hell of a quest...

Applying the changes with a timeout after the set-complete looks good to
me as it both follows the specification and allows for addressing the
incorrect behavior of the original ipmitool.

Alexander.


13.03.2018 18:36, Tom Joseph wrote:
> Hello,
>
> There is a patch up for applying the network settings, with this patch
> it would not require set channel access command to apply the changes.
> A timer kicks in everytime set-complete happens, and the network
> settings are applied once the timer expires.
>
> https://gerrit.openbmc-project.xyz/#/q/topic:2932
>
> Regards,
> Tom
>
> On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote:
>> On 14-Feb-2018 12:32 PM, Patrick Venture wrote:
>>> I thought you had to explicitly set in_progress with the ipmitool?  My
>>> own ipmitool utility is implemented as you described where it doesn't
>>> assume anything about your intent, just follows the actions.
>>
>> Currently, ipmitool (incorrectly) sets the "set in progress" bit for
>> every lan configuration parameter it sets. Given how the CLI
>> interface only allows the user to specify a single parameter at a
>> time, it might be smart to have ipmitool also expose controls for the
>> "set in progress" bit. Alternately, providing a way to to specify
>> multiple parameters in a single call would be good. Something like:
>>
>> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1
>> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp
>>
>> and it would automatically set and use the set in progress bit
>> correctly.
>>
>> And ipmid could then take two actions, depending on how this bit is
>> (ab)used:
>> 1) if only a single command is wrapped up in the
>> set-in-progress/set-complete, then employ a timeout so that after
>> some amount of time, all the queued commands get applied.
>> 2) if multiple commands get wrapped up in the
>> set-in-progress/set-complete, then apply the command set when the
>> set-complete is received.
>>
>> Getting ipmitool changed to have correct behavior will take some
>> doing, so we will need to be able to deal with its incorrect behavior
>> for now. But also responding to correct behavior can make tools that
>> employ that behavior work even better (with no timeout delays).
>>
>> Just my $0.02.
>>
>> --Vernon
>>
>>> There's definitely the possibility of thrashing.
>>>
>>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley
>>> <david.j.cobbley@linux.intel.com> wrote:
>>>> Do you have any concerns about ipmitool constantly flushing the
>>>> network as
>>>> it sets & unsets the complete bit inbetween parameters,
>>>> i.e. if you are setting 4 different parameters from a script?
>>>>
>>>> I'm not sure if this brings a lot of thrashing to the to the ipmi
>>>> network
>>>> stack or network manager.
>>>>
>>>> Seems like it would be prudent to fix ipmitool upstream to allow
>>>> you to set
>>>> multiple parameters, in addition to the ipmi stack.
>>>>
>>>>
>>>>> I personally have found this non-standard implementation a bit
>>>>> unpleasant, as it requires using a different command to basically
>>>>> flush it.  I am planning to implement it such that setting in
>>>>> progress
>>>>> before and complete after is how it all gets flushed instead of a
>>>>> timeout, since that approach reads more correct given the
>>>>> specification.  And really it's just about literally calling a
>>>>> subroutine to flush everything when the in_progress bit is set to
>>>>> completed, and removing the code from "access on"
>>>>>
>>>>> If you're interested to do what I've just described, I don't think
>>>>> you'll get any push-back.
>>>>>
>>>>> Patrick
>>>>>
>>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley
>>>>> <david.j.cobbley@linux.intel.com> wrote:
>>>>>>
>>>>>> I noticed that when using ipmitool lan set <channel> <parameter>,
>>>>>> the
>>>>>> openbmc stack does not apply the settings. This seems like a
>>>>>> non-standard
>>>>>> implementation. While using ipmitool as the standard is not quite
>>>>>> correct,
>>>>>> customers do expect it to work.
>>>>>>
>>>>>> After sending any sort of lan set command with ipmitool, the changes
>>>>>> don't
>>>>>> appear to stick and this message shows up in the journal:
>>>>>>      "Use Set Channel Access command to apply"
>>>>>>
>>>>>> I know IPMI 2.0 is a little ambiguous about implementation
>>>>>> specifics, but
>>>>>> I
>>>>>> believe the intention was to utilize the "Set In Progress" bit
>>>>>> (Parameter
>>>>>> 0)
>>>>>> while doing work, and use "Set Complete" when you are finished to
>>>>>> flush
>>>>>> the
>>>>>> changes.
>>>>>>
>>>>>> To work around ipmitool constantly setting and unsetting the "Set In
>>>>>> Progress" bit in between every parameter applied, some BMC stacks
>>>>>> accumulate
>>>>>> network changes over a period of time and apply after a timeout -
>>>>>> this is
>>>>>> also compatible with ipmitool's non-standard use of the "Set In
>>>>>> Progress"
>>>>>> bit.
>>>>>>
>>>>>>
>>>>>> Is there a plan to circle back and change this functionality to
>>>>>> work with
>>>>>> ipmitool in the future?
>>>>>>
>>>>>> Thanks,
>>>>>> -Dave Cobbley
>>>>>>
>>>>
>>
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: IPMI Set LAN Configuration Parameters

[Emily Shaffer]

[-- Attachment #1: Type: text/plain, Size: 6926 bytes --]

FWIW - OpenBMC does seem to have a fork of ipmitool... I don't think we've
done much to it.  https://github.com/openbmc/ipmitool

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.

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.

On Wed, Mar 21, 2018 at 7:55 AM Alexander Amelkin <a.amelkin@yadro.com>
wrote:

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

[-- Attachment #2: Type: text/html, Size: 9671 bytes --]

Re: IPMI Set LAN Configuration Parameters

[Alexander Amelkin]

[-- Attachment #1.1.1: Type: text/plain, Size: 8382 bytes --]

Emily, you at Google must have heavily refactored ipmitool to use it as
a library because 'as is' it is completely thread-unsafe, non-reentrant,
and overall... ehm... low quality. From my experience, OpenIPMI is much
more useful as a library.

Thanks for pointing to the openbmc ipmitool repo.

Alexander.

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


[-- Attachment #1.1.2: Type: text/html, Size: 13050 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]