Re: [Freeipmi-devel] FreeIPMI Issues

[Albert Chu]

Hi Levi,

I think it's done.  PLMK if it works for you on the dell's.

our CVS head (our 0.4.0 eventual release)

cvs -z3 -d:pserver:address@hidden:/sources/freeipmi co
freeipmi

our 0.3.X maintenance line

cvs -z3 -d:pserver:address@hidden:/sources/freeipmi co -r
Release-0_3_0_branch freeipmi

Al

> Levi,
>
> As I'm looking at the code now, I think I can hammer out permsgauth
> support in the tools pretty quick.  Gimme a day or so.
>
> Al
>
> On Thu, 2007-04-19 at 15:51 -0700, Al Chu wrote:
>> Hi Levi,
>>
>> On Thu, 2007-04-19 at 13:21 -0600, Levi Pearson wrote:
>> > I'd like to work with the core developers so that any fixes and new
>> > features we make are acceptable to you, so we don't have to maintain a
>> > separate branch.
>>
>> Sounds good.  Glad to have additional support from others.
>>
>> > With ipmiconsole, I discovered that the internal handling of the Kg
>> key
>> > is done with string manipulation functions, and that there is also an
>> > off-by-one error.
>>
>> I thought I had caught every corner case.  But perhaps not :-)  Just
>> point me in the right direction, I'd be glad to get it fixed.
>>
>> > I'd like the ability to enter the key in hexadecimal
>> > and have it treated as a 20-byte binary field instead of a string,
>> which
>> > matches how the key is handled in the Dell utilities.
>>
>> I faced a similar issue/dilemma early on.  Honestly, I went with strings
>> b/c it was easier.  Perhaps a patch for bmc-config, ipmipower, and
>> ipmiconsole would be best.  Not sure how to do it for bmc-config.
>> Perhaps two options.  One for strings and one for hex??  Hmmm...
>> comments anyone else?
>>
>> > I'd also like to integrate libfreeipmi with conman, and I'd appreciate
>> > hearing if anything has been done in that direction yet.
>>
>> Chris Dunlap (author of Conman) sits down the hall from me.  There is
>> support w/ ipmiconsole (in a soon to be released Conman), where Conman
>> runs it in a separate process.  Conman 2.0 is planned for integration
>> with libipmiconsole (which uses libfreeipmi).  I'm unsure of the
>> timeline.  How about starting a thread in the conman mailing list, and
>> we can discuss it more in there along w/ Chris.
>>
>> > With the exception of ipmipower and ipmiconsole, the FreeIPMI
>> utilities
>> > have issues dealing with having Per-Message Authentication and
>> > User-Level Authentication disabled.
>>
>> I could have swore it did.  But looking through the code in FreeIPMI 2.0
>> and 3.0, it doesn't seem to be there.
>>
>> > nor does there seem to be an option to change it in bmc-config yet.
>>
>> It should be supported for you guys.  The fields to configure it are:
>>
>> Volatile_Enable_User_Level_Auth              Yes
>> Volatile_Enable_Per_Message_Auth             Yes
>>
>> and there are non-volatile equivalents too.
>>
>> Do you not see these when you run bmc-config --checkout?  It's possible
>> Dell did not make them readable/writeable.
>>
>> Do you have to run ipmipower with the --check-unexpected-authcode
>> option?  I'm wondering if these Dells have the same problems that led me
>> to write that workaround.
>>
>> > I've done some investigation into the best place to put checks for
>> those
>> > options.  Right now, it seems like the best way would be to have
>> > ipmi_cmd_get_channel_authentication_capabilities set some flags or new
>> > struct members in the ipmi_device_t that is passed to it. Then,
>> > ipmi_lan_open_session could change the authentication type in the
>> > ipmi_device_t to NONE after it finishes authenticating the session (if
>> > the appropriate flags are set, of course, and barring the need for the
>> > workaround present in ipmipower).  Any thoughts on this?
>>
>> I admit I haven't looked at this code in quite some time, so I could be
>> wrong on the best approach.  I thikn the best way is to add two things
>> into the ipmi_device_t.
>>
>> 1) flag indicating per_msg_auth set/unset
>> 2) a "state" variable indicating what state the lan session is in. (i.e.
>> get auth caps, get session challenge, activate session, set session
>> privilege, fully activated session, close session).  This could be a set
>> of enums in ipmi-udm-device.h.
>>
>> Then, within _ipmi_lan_cmd_send(), depending on the flags and state, use
>> a different authentication type/password/etc as needed.
>>
>> Then in ipmi_lan_cmd(), based on the flags and state, adjust the check
>> authentication field appropriately.
>>
>> Sound good?
>>
>> I might be able to find time to do it soon.  But given I haven't looked
>> at this in awhile, you might be ahead of me in finishing it :-)
>>
>> Since I would consider this a bug rather than a feature, I think it
>> should go into the 0.3.X line and released in 0.3.3 as a bug fix.  Same
>> with the new options for a hex based input.
>>
>> > We'd also like some more extensive PEF configuration options in
>> > bmc-config, but I haven't looked into that with any detail yet.
>>
>> Bala is currently working on an ipmi-pef tool for PEF configuration.  It
>> was supposed to be done quite some time ago, but other projects of his
>> have taken him away from it.  He thinks he'll be able to work on it full
>> time starting Friday.  Perhaps if workload can be split, and you have
>> time, you guys could collaborate on it?  I'll let Bala speak on the
>> mailing list concerning that.
>>
>> Thanks,
>> Al
>>
>> > Anyway, thanks for the excellent software, and let me know what you
>> > think about my ideas above.
>> >
>> >            --Levi
>> >
>> >
>> >
>> > _______________________________________________
>> > Freeipmi-devel mailing list
>> > address@hidden
>> > http://lists.gnu.org/mailman/listinfo/freeipmi-devel
> --
> Albert Chu
> address@hidden
> 925-422-5311
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
>
>
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/freeipmi-devel
>


-- 
Albert Chu
address@hidden
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory