Re: [Freeipmi-devel] FreeIPMI Issues

[Levi Pearson]

On Thu, 2007-04-19 at 15:51 -0700, Al Chu wrote:

> > 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?

Patching bmc-config to support either does seem tricky.  The Dell
utilities to read/set the key deal only in hex.  Allowing both opens the
possibility for two different keys to be specified simultaneously.
Allowing only text cuts a big chunk of the possible key space out, and
may cause errors if a key set with another utility that contains
nonprintable characters (or nulls, even) is checked out and then checked
back in.  The only other option I can think of right now is a special
syntax to print/read it with if there are unprintable characters.  This
doesn't seem particularly great, either.

> > 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.

Sorry, those are indeed there.  I just missed them last time.  They
wouldn't have helped me change them anyway, since per-message auth was
off and bmc-config wouldn't work at all until I switched it another way.
It's working great now, though.

> 
> 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.
> 

No, the Dell BMCs handle user-level auth and per-message auth according
to the spec.

> > 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?

That was my initial idea for supporting it as well, but I thought you
may have been purposefully keeping that kind of state out of that layer
of the machinery.  It does seem to work well, though, so I have no
complaints.

> 
> > 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.
> 

We'd definitely be interested in splitting the workload with you if Bala
is open to it.


                --Levi