IPMI Set LAN Configuration Parameters

[Emily Shaffer]

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 at 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 at 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 at 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
> >>>>>>
> >>>>
> >>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180322/3edf5cc6/attachment-0001.html>