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
> > 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.
Freeipmi-devel mailing list