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 _______________________________________________ Freeipmi-devel mailing list Freeipmifirstname.lastname@example.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel