IPMI Set LAN Configuration Parameters
Alexander Amelkin
a.amelkin at yadro.com
Sat Mar 24 00:07:43 AEDT 2018
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 at yadro.com
> <mailto: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
> <mailto: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
> <mailto: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/20180323/c540e276/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180323/c540e276/attachment-0001.sig>
More information about the openbmc
mailing list