[Freeipmi-devel] gcrypt
AB, Bala, Argh! So libgcrypt doesn't implement md2. According to the docs: GCRY_MD_MD2 This is an reserved identifier for MD-2; there is no implementation yet. After thinking about it for a minute or two on the best way deal with this, I've decided to keep the current code for IPMI 1.5. In other words, we'll stick with the MD2 and MD5 libraries I added into libfreeipmi from ipmipower. I'll be removing my SHA1 and HMAC code in favor of gcrypt for all IPMI 2.0 stuff. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] gcrypt
,[ Albert Chu <[EMAIL PROTECTED]> ] | AB, Bala, | | Argh! So libgcrypt doesn't implement md2. According to the docs: | | GCRY_MD_MD2 This is an reserved identifier for MD-2; there is no | implementation yet. | | After thinking about it for a minute or two on the best way deal | with this, I've decided to keep the current code for IPMI 1.5. In | other words, we'll stick with the MD2 and MD5 libraries I added into | libfreeipmi from ipmipower. | | I'll be removing my SHA1 and HMAC code in favor of gcrypt for all | IPMI 2.0 stuff. | | Al ` Sounds good to me. May be you should contribute your MD2 and MD5 to libgcrypt project. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] ipmi 2.0 branch
,[ Albert Chu <[EMAIL PROTECTED]> ] | Ab, Bala, etc., | I'm starting some development in the branch 'al_ipmi_2_0_branch'. ` I am thinking if you should start IPMI-2.0 work in the current branch itself. We can always say 2.0 support as experimental. Otherwise you will still have to go thru the pain of merging at some point. I should have made a test release 2 weeks ago. But Bala got struck with the new LAN stack as he is developing on a remote system. It has a bug. It seems to lock the BMC for auth-types other than AUTH_TYPE_NONE and the system needs physical power-cycle (removing the power chord). Can you continue his work and see what went wrong in the new code. I suspect it has to do with session and session-auth header. After you fix this bug, I want add support for per-message-auth-disable. This means if lan-channel-auth-caps reports per-message-auth as disabled, then session-auth will be used only during session initiation. Bala will take care of this. Immediately after finishing this we will make a test release. I am still travelling and should be back on 11th. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] SMBus support ?
,[ "Cress, Andrew R" <[EMAIL PROTECTED]> ] | I have a customer who wants to do IPMI with SMBus interface on a SCO | UnixWare system. | | I know that you folks were working on adding the SMBus interface. | If it is far enough along, I'm available to test/debug it. Has a | port of FreeIPMI been attempted on SCO? ` GNU FreeIPMI should be fairly easy to port to SCO UnixWare. Current CVS implementation has SMBus driver in it. But not even tested once. I will be making a test release with in a month which will include SMBus support. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] SMBus support ?
,[ "Cress, Andrew R" <[EMAIL PROTECTED]> ] | I have a customer who wants to do IPMI with SMBus interface on a SCO | UnixWare system. | | I know that you folks were working on adding the SMBus interface. If it | is far enough along, I'm available to test/debug it. | Has a port of FreeIPMI been attempted on SCO? ` Can you please give me remote access (as root) to a system that has SMBus support in it. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] ipmiping 2.0 patch
,[ Albert Chu <[EMAIL PROTECTED]> ] | Does someone out there have a ipmi 2.0 machine[1] that could sanity | check this patch?? After applying and compiling, try: ` I cannot find the patch! -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] ipmiping 2.0 patch
Hmmm, gnu.org didn't forward my patch along. Ok, here it is cut & pasted.
Al
-
Index: ipmiping/src/ipmiping.c
===
RCS file: /cvsroot/freeipmi/freeipmi/ipmiping/src/ipmiping.c,v
retrieving revision 1.2
diff -u -p -r1.2 ipmiping.c
--- ipmiping/src/ipmiping.c 25 Jan 2005 17:34:47 - 1.2
+++ ipmiping/src/ipmiping.c 31 Oct 2005 16:46:16 -
@@ -75,15 +75,18 @@ int
createpacket(char *buffer,
int buflen,
unsigned int seq_num_count,
+ int version,
int debug)
{
fiid_obj_t obj_hdr_rmcp = NULL;
fiid_obj_t obj_hdr_session = NULL;
fiid_obj_t obj_msg_hdr = NULL;
fiid_obj_t obj_cmd = NULL;
+ fiid_field_t *tmpl_cmd_get_channel_auth_caps_ptr = NULL;
int len;
assert(buffer != NULL);
+ assert(version == IPMI_PING_VERSION_1_5 || version ==
IPMI_PING_VERSION_2_0);
if (buflen < 0)
return -1;
@@ -91,10 +94,15 @@ createpacket(char *buffer,
if (buflen == 0)
return 0;
+ if (version == IPMI_PING_VERSION_1_5)
+tmpl_cmd_get_channel_auth_caps_ptr = (fiid_field_t
*)&tmpl_cmd_get_channel_auth_caps_rq[0];
+ else
+tmpl_cmd_get_channel_auth_caps_ptr = (fiid_field_t
*)&tmpl_cmd_get_channel_auth_caps_v20_rq[0];
+
obj_hdr_rmcp = Fiid_obj_alloc(tmpl_hdr_rmcp);
obj_hdr_session = Fiid_obj_alloc(tmpl_hdr_session_auth_calc);
obj_msg_hdr = Fiid_obj_alloc(tmpl_lan_msg_hdr_rq);
- obj_cmd = Fiid_obj_alloc(tmpl_cmd_get_channel_auth_caps_rq);
+ obj_cmd = Fiid_obj_alloc(tmpl_cmd_get_channel_auth_caps_ptr);
if (fill_hdr_rmcp_ipmi(obj_hdr_rmcp) < 0)
ipmi_ping_err_exit("fill_hdr_rmcp_ipmi: %s", strerror(errno));
@@ -108,12 +116,22 @@ createpacket(char *buffer,
seq_num_count % (IPMI_RQ_SEQ_MAX+1),
obj_msg_hdr) < 0)
ipmi_ping_err_exit("fill_lan_msg_hdr: %s", strerror(errno));
- if (fill_cmd_get_channel_auth_caps(IPMI_PRIV_LEVEL_USER, obj_cmd) < 0)
-ipmi_ping_err_exit("fill_cmd_get_channel_auth_caps: %s",
strerror(errno));
+ if (version == IPMI_PING_VERSION_1_5)
+{
+ if (fill_cmd_get_channel_auth_caps(IPMI_PRIV_LEVEL_USER, obj_cmd)
< 0)
+ipmi_ping_err_exit("fill_cmd_get_channel_auth_caps: %s",
strerror(errno));
+}
+ else
+{
+ if (fill_cmd_get_channel_auth_caps_v20(IPMI_PRIV_LEVEL_USER,
+
IPMI_GET_IPMI_V20_EXTENDED_DATA,
+ obj_cmd) < 0)
+ipmi_ping_err_exit("fill_cmd_get_channel_auth_caps_v20: %s",
strerror(errno));
+}
if ((len = assemble_ipmi_lan_pkt(obj_hdr_rmcp, obj_hdr_session,
tmpl_hdr_session_auth_calc,
obj_msg_hdr,
- obj_cmd,
tmpl_cmd_get_channel_auth_caps_rq,
+ obj_cmd,
tmpl_cmd_get_channel_auth_caps_ptr,
(u_int8_t *)buffer, buflen)) < 0)
ipmi_ping_err_exit("assemble_ipmi_lan_pkt: %s", strerror(errno));
@@ -123,7 +141,7 @@ createpacket(char *buffer,
if (fiid_obj_dump_lan(STDERR_FILENO, "Request", NULL,
(u_int8_t *)buffer, len,
tmpl_hdr_session_auth_calc,
tmpl_lan_msg_hdr_rq,
-tmpl_cmd_get_channel_auth_caps_rq) < 0)
+tmpl_cmd_get_channel_auth_caps_ptr) < 0)
ipmi_ping_err_exit("fiid_obj_dump_lan: %s", strerror(errno));
}
#endif
@@ -141,7 +159,9 @@ parsepacket(char *buffer,
int buflen,
const char *from,
unsigned int seq_num_count,
-int verbose, int debug)
+int verbose,
+int version,
+int debug)
{
fiid_obj_t obj_hdr_rmcp = NULL;
fiid_obj_t obj_hdr_session = NULL;
@@ -150,10 +170,13 @@ parsepacket(char *buffer,
fiid_obj_t obj_msg_trlr = NULL;
u_int64_t req_seq, none, md2, md5, straight_passwd_key, oem,
anonymous_login, null_username, non_null_username,
-user_level_auth, per_message_auth;
+user_level_auth, per_message_auth,
+ipmi_v20_extended_capabilities_available, ipmi_v15, ipmi_v20;
+ fiid_field_t *tmpl_cmd_get_channel_auth_caps_ptr = NULL;
int ret, retval = -1;
assert(buffer != NULL && from != NULL);
+ assert(version == IPMI_PING_VERSION_1_5 || version ==
IPMI_PING_VERSION_2_0);
if (buflen < 0)
return -1;
@@ -161,10 +184,15 @@ parsepacket(char *buffer,
if (buflen == 0)
return 0;
+ if (version == IPMI_PING_VERSION_1_5)
+tmpl_cmd_get_channel_auth_caps_ptr = (fiid_field_t
*)&tmpl_cmd_get_channel_auth_caps_rs[0];
+ else
+tmpl_cmd_get_channel_auth_caps_ptr = (fiid_field_t
*)&tmpl_cmd_get_channel_auth_caps_v20_rs[0];
+
obj_hdr_rmcp = Fiid_obj_alloc(tmpl_hdr_rmcp);
obj_hdr_session = Fiid_obj_alloc(tmpl_hdr_session_auth_calc);
obj_msg_hdr = Fiid_obj_alloc(tmpl_lan_msg_hdr_rs);
- obj_cmd = Fiid_obj_alloc(tmpl_cmd_g
Re: [Freeipmi-devel] ipmi 2.0 branch
> I am thinking if you should start IPMI-2.0 work in the current branch > itself. We can always say 2.0 support as experimental. Otherwise you > will still have to go thru the pain of merging at some point. I think I'll keep it in a branch. I guess it's development philosophy differences. I'm not a big fan of dumping very new untested experimental code into a soon to be new release. Remember, I release this code into our production environment :-) > I should have made a test release 2 weeks ago. But Bala got struck > with the new LAN stack as he is developing on a remote system. It has > a bug. It seems to lock the BMC for auth-types other than > AUTH_TYPE_NONE and the system needs physical power-cycle (removing the > power chord). Can you continue his work and see what went wrong in the > new code. Are you referring to the unified driver stuff? I can take a look. Just point me in the direction of what new API calls/options/whatever aren't working. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Anand Babu <[EMAIL PROTECTED]> Date: Thursday, November 3, 2005 6:50 pm Subject: Re: [Freeipmi-devel] ipmi 2.0 branch > ,[ Albert Chu <[EMAIL PROTECTED]> ] > | Ab, Bala, etc., > | I'm starting some development in the branch 'al_ipmi_2_0_branch'. > ` > I am thinking if you should start IPMI-2.0 work in the current branch > itself. We can always say 2.0 support as experimental. Otherwise you > will still have to go thru the pain of merging at some point. > > I should have made a test release 2 weeks ago. But Bala got struck > with the new LAN stack as he is developing on a remote system. It has > a bug. It seems to lock the BMC for auth-types other than > AUTH_TYPE_NONE and the system needs physical power-cycle (removing the > power chord). Can you continue his work and see what went wrong in the > new code. > > I suspect it has to do with session and session-auth header. > > After you fix this bug, I want add support for > per-message-auth-disable. This means if lan-channel-auth-caps reports > per-message-auth as disabled, then session-auth will be used only > during session initiation. Bala will take care of this. Immediately > after finishing this we will make a test release. > > I am still travelling and should be back on 11th. > > -- > Anand Babu > GPG Key ID: 0x62E15A31 > Blog [http://ab.freeshell.org] > The GNU Operating System [http://www.gnu.org] > ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] ipmi_lan_open_session() question
,[ Albert Chu <[EMAIL PROTECTED]> ] | AB, I'm not doubting that it has a number of enhancements. However, | with all APIs, as you abstract away details you remove flexibility from | the programmer. For example, the strength of ipmipower is its protocol | parallelism. Its protocol parallelism comes from its "manual" | management of the ipmi protocol across all nodes. How can I still | achieve the performance of the old ipmipower if ipmipower is forced to | move to the UDM? ` Only those who wants to develop tools that needs to work both inband and outband seamlessly has to use UDM. Otherwise you are free to access any APIs at any layer. Only the redundant obsolete APIs are removed. UDM is not completely ready yet to accommodate all needs. Protocol parallelism should be achievable thru UDM too. Performance difference will not even be noticeable. I am planning to inline the calls. ,[ Albert Chu <[EMAIL PROTECTED]> ] | Another example. You assume in the UDM that users are willing to block | on a recvfrom() waiting for a reply from an IPMI cmd request. What if a | user doesn't want this?? ` UDM APIs will support non-blocking calls too. During UDM open call, you pass this option. ,[ Albert Chu <[EMAIL PROTECTED]> ] | I think if you can let us know what API functions may or may not | disappear, that would help things alot. I just don't believe its | correct to just assume that the UDM will be better than what currently | exists. ` If you notice, certain new functions will be prefixed with 2. Only those calls will be replaced. I will rename the old calls with new name or using a macro like FREEIPMI_FORCE_0_1_3_API. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
