Re: [Freeipmi-devel] FreeIPMI Issues
Hi Levi, > > We'd definitely be interested in splitting the workload with you if Bala > is open to it. > Fantastic. It will be great help for us. The current status of ipmi-pef tool is, it just dumps Event Filter Table and Alert Policy Table in commented texts in stdout or filename like bmc-config. Some of the value in the checkout are in meaningful and some are just in Hex. Current status is, the tool is not very much useful for the end users. To drive to that, we have to modify the tool to provide configuration management/relationship of Event Filter Table, Alert Policy Table, Alert Strings, LAN configuration settings of destination IP addresses and PET if it needed. I guess, we don't support Serial/Modem configuration specific to PEF. I guess, I have covered all missing things here and please go through the current ipmi-pef code and refer IPMI Spec 2.0 Page #230 if anything missed out here. Thanks, Regards, Bala ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
Hi Levi, Firstly, I would say thanks for your appreciation. > > We'd also like some more extensive PEF configuration options in > bmc-config, but I haven't looked into that with any detail yet. > In the current FreeIPMI development CVS branch has separate tool called ipmi-pef. The tool is under development to support pretty much all PEF configuration (Please refer IPMI Spec 2.0 Page #230). A complete pef tool will be ready in mid of May. Thanks, Regards, Bala ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
On Mon, 2007-04-23 at 21:30 +0200, Ingo van Lil wrote: > All characters up to the first '\0' should be printable (function > isprint()), all subsequent characters must be '\0'. Otherwise you should > fall back to hex syntax to be on the safe side. Maybe non-ascii > characters (>127) should be forbidden as well to avoid character > encoding problems. Another possibility: A colleague of mine suggested we output hex all the time, since the string form is perhaps something we want to hide. That would be somewhat consistent with the output of the IPMI Passwords (which aren't output since they are not retrievable). However, it just seems not right to me ... Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
Al Chu wrote: > Here's an idea. How about if the user prefixes his input with a '0x', > then we assume the user wants to do up to 20 bytes of hex. If not > prefixed by '0x', then we assume the user is inputting a string? You could use the syntax that's used for specifying WEP keys in iwconfig: The key is interpreted as hex (with optional '-' delimiters) unless it is prefixed with 's:'. E.g. "s:password" would be equivalent to "7061-7373-6f72-640a". > This would lead to some difficulty with the checkout of the K_g. We > would have to add some logic to check on hex vs. string. At the minimum > we'd have to check if all of the bytes after the first NULL byte are > also NULL. Perhaps some logic checks to ascii character ranges is > needed too? Hmmm ... All characters up to the first '\0' should be printable (function isprint()), all subsequent characters must be '\0'. Otherwise you should fall back to hex syntax to be on the safe side. Maybe non-ascii characters (>127) should be forbidden as well to avoid character encoding problems. Cheers, Ingo ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
On Mon, 2007-04-23 at 13:04 -0600, Levi Pearson wrote: > 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. I agree it would be a non-perfect interface. I was assuming that users would understand what they're doing, but that may not be the case. Here's an idea. How about if the user prefixes his input with a '0x', then we assume the user wants to do up to 20 bytes of hex. If not prefixed by '0x', then we assume the user is inputting a string? This would lead to some difficulty with the checkout of the K_g. We would have to add some logic to check on hex vs. string. At the minimum we'd have to check if all of the bytes after the first NULL byte are also NULL. Perhaps some logic checks to ascii character ranges is needed too? Hmmm ... Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
On Mon, 2007-04-23 at 11:54 -0700, Al Chu wrote: > Cool. Perhaps we could add the K_g fixes you need (are working on??), > then we could roll out 0.3.3. > I'll be working on a patch for the K_g key today; I'll post it sometime in the next few days for your review. --Levi ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
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 Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
On Mon, 2007-04-23 at 12:37 -0600, Levi Pearson wrote: > On Thu, 2007-04-19 at 22:18 -0700, Albert Chu wrote: > > 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:[EMAIL PROTECTED]:/sources/freeipmi co > > freeipmi > > > > our 0.3.X maintenance line > > > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/freeipmi co -r > > Release-0_3_0_branch freeipmi > > > > Al > > I've tested both branches, and they both work with per-message > authentication enabled or disabled now. Thanks for the quick fix! Cool. Perhaps we could add the K_g fixes you need (are working on??), then we could roll out 0.3.3. A.B., Bala, what do you think about that plan? Al > --Levi -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
On Thu, 2007-04-19 at 22:18 -0700, Albert Chu wrote: > 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:[EMAIL PROTECTED]:/sources/freeipmi co > freeipmi > > our 0.3.X maintenance line > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/freeipmi co -r > Release-0_3_0_branch freeipmi > > Al I've tested both branches, and they both work with per-message authentication enabled or disabled now. Thanks for the quick fix! --Levi ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
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:[EMAIL PROTECTED]:/sources/freeipmi co freeipmi our 0.3.X maintenance line cvs -z3 -d:pserver:[EMAIL PROTECTED]:/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 f
Re: [Freeipmi-devel] FreeIPMI Issues
On Thu, 2007-04-19 at 13:21 -0600, Levi Pearson wrote: > With the exception of ipmipower and ipmiconsole, the FreeIPMI utilities > have issues dealing with having Per-Message Authentication and > User-Level Authentication disabled. Hi Levi, One other thought. If the user-level authentication disabled leads to problems, I think you need to bring this up with Dell. From the wording in the IPMI spec, my understanding is that if per-msg-authentication is disabled, you must not send authentication fields with later packets. However, with user-level auth disabled, it is optional to send later user level packets w/o an authentication field. If you don't have good contacts at Dell to get this moving, I can point you in the right direction to some folks. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI Issues
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 t
Re: [Freeipmi-devel] FreeIPMI Issues
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 > Freeipmi-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore Nationa
