RE: [Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to various Intel servers
Al, For the CTS_MASK, I'm not where I can pull this up, but I thought that this option was something that could be detected. IIRC, I think all BMCs will work with this FALSE, but only some support it with TRUE. For the status loop, I'd first assume a software bug, before pointing to the time-tested and fully validated firmware. The point of the get activation payload status is to prevent multiple activate payload commands from being issued from one client. Andy -Original Message- From: Al Chu [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 2:34 PM To: Cress, Andrew R Cc: freeipmi-devel@gnu.org Subject: RE: [Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to various Intel servers Hey Andrew, For fi4.log I see a return code of CCh = Invalid data field in Request for the Activate Payload command. Comparing FreeIPMI's code to your code in ipmiutil, I see: if (mfg == VENDOR_INTEL) ibuf[2] |= SOL_BMC_ASSERTS_CTS_MASK_TRUE; else ibuf[2] |= SOL_BMC_ASSERTS_CTS_MASK_FALSE; So I would assume this is yet another intel specific workaround? I can't (code auditting wise) see another difference in the packets. For fi3.log I definitely got a cycle in my state machine. I should (at minimum) monitor and exit after some number of failed attempts for this state- machine cycle. It seems that the get payload activation status request always returns that SOL is not active. But whenever the activate payload command is executed, it responds w/ 80h = payload already active. The current state machine moves back to get payload activation status to (hopefully) verify that the session is now active, so that it can then move on to deactivate payload. Since one of these commands is continuously returning bad data, the cycle results. So I assume there is a bug in the Intel firmware somewhere in here. Perhaps the fix to the activate payload command up above (from fi4.log) would be enough to make the activate payload command work? I'll put a fix in for these and e-mail you a beta link. Thanks for all the help. Al On Mon, 2008-12-08 at 10:35 -0800, Al Chu wrote: Hey Andrew, Cool. These logs show that we're fully authenticating, so the hard Intel IPMI 2.0 workarounds are over. So there is something in the libipmiconsole state machine that it is stuck on. Likely some corner case b/c I do things differently than ipmitool/ipmiutil. I'll take a look into it. Al On Mon, 2008-12-08 at 10:27 -0800, Cress, Andrew R wrote: Al, Oops. I forgot the -W intel20 option. Here are logs with that included, and debug. The problem seems to be with the Trailer now. It flags a BMC Error message to one system and repeats the cycle forever on another system. Both of these can activate SOL sessions via ipmitool and ipmiutil. It may be just one more tweak is needed. Andy -Original Message- From: Al Chu [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 1:13 PM To: Cress, Andrew R Cc: freeipmi-devel@gnu.org Subject: RE: [Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to various Intel servers Hey Andrew, Hmmm, the BMC Busy error seems justified. telco64: -- telco64: [ 93h] = message_tag[ 8b] telco64: [ 1h] = rmcpplus_status_code[ 8b] 1h = Insufficient resources to create a session So I think this error is legit given the response. Any idea why the board would respond with this type of error code? Could it be to many failed connection attempts? I remember an Intel IPMI 1.5 board I played with would not be very responsive if there were many failed connections in a row. telco64: = telco64: IPMI 2.0 Open Session Request telco64: = snip telco64: IPMI Command Data: telco64: -- telco64: [ C5h] = message_tag[ 8b] telco64: [ 0h] = requested_maximum_privilege_level[ 4b] telco64: = telco64: IPMI 2.0 Open Session Response telco64: = snip telco64: IPMI Command Data: telco64: -- telco64: [ C5h] = message_tag[ 8b] telco64: [ 0h] = rmcpplus_status_code[ 8b] telco64: [ 0h] = maximum_privilege_level[ 4b] (ipmiconsole_checks.c, ipmiconsole_check_open_session_response_privilege, 610): hostname=telco64; protocol_state=0x2: open session response privilege check failed; p = 3^M [error received]: privilege level cannot be obtained for this user I'll have to look into this. 0h = IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL, which should not be done for the Intel boards when the intel workaround is specified. /* IPMI Workaround * * Intel IPMI 2.0 implementations don't
[Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to various Intel servers
Retry, first send failed. -Original Message- From: Cress, Andrew R [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2008 8:43 AM To: Albert Chu; Bryan Henderson; Andy Cress; freeipmi-devel@gnu.org Subject: RE: [bug #24300] ipmiconsole cannot connect to various Intel servers Al, This was the first time I had tried ipmiconsole, so I don't know if it worked before or what changed. For an example of what is different with Intel boards, you can view the source to ipmitool or ipmiutil under the 'lanplus' protocol. It boils down to some different assumptions about defaults or special conditions. In ipmitool, the syntax requires specifying -o intelplus, but ipmiutil detects the manufacturer/product id first and doesn't need those options. From ipmiutil: lib/lanplus/lanplus.c:is_sol_partial_ack() has an intelplus special case, which probably should apply to all other boards too (?) lib/lanplus/lanplus.c:ipmi_lanplus_open_session() has an intelplus condition for privilege defaults lib/lanplus/lanplus_crypt.c:lanplus_rakp4_hmac_matches() has two intelplus cases lib/lanplus/lanplus_crypt.c:lanplus_generate_rakp3_authcode() has an intelplus case for privilege defaults That's all that is different. Andy -Original Message- From: Albert Chu [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 5:47 PM To: Albert Chu; Bryan Henderson; Andy Cress; freeipmi-devel@gnu.org Subject: [bug #24300] ipmiconsole cannot connect to various Intel servers Follow-up Comment #2, bug #24300 (project freeipmi): Sorry I didn't see these posts earlier. Hopefully I've fixed the config on Savannah so that bugs actually send out e-mails to the mailing list. I implemented the Intel workarounds a long time ago, but no longer have an Intel motherboard. So I've been forward porting the patches since then and praying they still work and I didn't mess anything up along the way. I guess something is messed up or there is something new to workaround. Hopefully I can find an Intel mobo to try and fix this on. I'm going through the code right now visually and can't see a workaround issue. Al P.S. Bryan, I can see how the wording of the manpage was misinterpreted to make you think I note the manual mentions this can happen with --workaround=intel20, but it doesn't mention anything to do about it. . I'm going to fix up the manpage to instead say: There are a number of Intel IPMI 2.0 bugs. These problems may cause username invalid, password invalid, or k_g invalid errors to occur. They can be worked around by specifying the intel20 workaround. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24300 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to various Intel servers
Al,
/* IPMI Workaround (achu)
*
* Discovered on SE7520AF2 with Intel Server Management Module
* (Professional Edition)
*
* The username must be padded despite explicitly not being
* allowed. No Null characters (00h) are allowed in the name.
* Table 13-11 in the IPMI 2.0 spec.
*/
Hmmm. This is because when the set username command is issued, the command
data is padded with nulls to 16 bytes, as shown in secion 22.28, and that is
common across most of the spec. But Table 13-11 is an exception to the rest of
IPMI username handling, in that it is not a fixed-length 16-byte entity. This
is implemented the same in most Intel BMCs that are currently available. In
ipmiutil, this RAKP1 stuff is handled the same way that ipmitool does, by ...
/* IPMI Workaround (achu)
*
* Discovered on SE7520AF2 with Intel Server Management Module
* (Professional Edition)
*
* When the authentication algorithm is HMAC-MD5-128 and the
* password is greater than 16 bytes, the Intel BMC truncates the
* password to 16 bytes when generating keys, hashes, etc. So we
* have to do the same when generating keys, hashes, etc.
*/
I doubt that the IMM firmware supported 20-byte passwords (the first Intel BMC
with IPMI 2.0), but some other Intel BMCs do, I believe. Ipmiutil currently
does not handle 20-byte passwords, and that could be done conditionally on
certain systems, but if we are talking about managing passwords for hundreds of
servers where some support 16 bytes and some support 20 bytes, all of the
passwords would be restricted to 16-bytes anyway, and the IPMI 2.0 spec
requires support/compatibility for 16-byte passwords for this reason. We don't
have any customers who have a use-case where 20-byte passwords would be used,
so I haven't implemented the logic for it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Chu
Sent: Friday, December 05, 2008 1:27 PM
To: Cress, Andrew R
Cc: freeipmi-devel@gnu.org
Subject: Re: [Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to
various Intel servers
Hey Andrew,
On Fri, 2008-12-05 at 09:14 -0800, Cress, Andrew R wrote:
Retry, first send failed.
-Original Message-
From: Cress, Andrew R [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 8:43 AM
To: Albert Chu; Bryan Henderson; Andy Cress; freeipmi-devel@gnu.org
Subject: RE: [bug #24300] ipmiconsole cannot connect to various Intel servers
Al,
This was the first time I had tried ipmiconsole, so I don't know if it worked
before or what changed.
For an example of what is different with Intel boards, you can view the
source to ipmitool or ipmiutil under the 'lanplus' protocol. It boils down
to some different assumptions about defaults or special conditions.
In ipmitool, the syntax requires specifying -o intelplus, but ipmiutil
detects the manufacturer/product id first and doesn't need those options.
From ipmiutil:
lib/lanplus/lanplus.c:is_sol_partial_ack() has an intelplus special case,
which probably should apply to all other boards too (?)
Yeah, I'm not quite sure why this would be an intel corner case. Does
intel return 0 for the accepted_character_count even if it accepted all
the data? So a return of 0 is just assumed to be equivalent to all
data accepted?? I don't currently handle this case in ipmiconsole.
The assumption is if you didn't accept any data, then you resend data
just as if there was a partial acceptance.
lib/lanplus/lanplus.c:ipmi_lanplus_open_session() has an intelplus condition
for privilege defaults
I handle this one:
/* IPMI Workaround
*
* Intel IPMI 2.0 implementations don't support the highest level
privilege.
*/
if (c-config.workaround_flags IPMICONSOLE_WORKAROUND_INTEL_2_0_SESSION)
privilege_level = c-config.privilege_level;
else
privilege_level = IPMI_PRIVILEGE_LEVEL_HIGHEST_LEVEL;
lib/lanplus/lanplus_crypt.c:lanplus_rakp4_hmac_matches() has two intelplus
cases
handle this one:
/* IPMI Workaround
*
* Intel IPMI 2.0 implementations respond with the integrity check
* value based on the integrity algorithm rather than the
* authentication algorithm.
*/
if (c-config.workaround_flags IPMICONSOLE_WORKAROUND_INTEL_2_0_SESSION)
{
if (c-config.integrity_algorithm == IPMI_INTEGRITY_ALGORITHM_NONE)
authentication_algorithm = IPMI_AUTHENTICATION_ALGORITHM_RAKP_NONE;
else if (c-config.integrity_algorithm ==
IPMI_INTEGRITY_ALGORITHM_HMAC_SHA1_96)
authentication_algorithm = IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA1;
else if (c-config.integrity_algorithm ==
IPMI_INTEGRITY_ALGORITHM_HMAC_MD5_128)
authentication_algorithm = IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_MD5;
else if (c-config.integrity_algorithm
RE: [Freeipmi-devel] PEF alert policy
Al, In a separate email, this problem was resolved by fixing the following 3 mis-configured parameters: PEF Alert Policy[1]: 01 10 11 00 Disabled(10-18 to enable this PEF policy) Lan Param(13) Def gateway MAC: 00 00 00 00 00 00 (set to the correct MAC) Lan Param(18) Dest type: 01 00 00 00 00 (dest disabled, should be enabled) With those fixed, he was able to make it work. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Chu Sent: Monday, December 03, 2007 11:46 AM To: Андрей Судаков Cc: freeipmi-devel@gnu.org Subject: Re: [Freeipmi-devel] PEF alert policy Hi, I don't know the ipmiutil output below. If you can send the output of pef-config, I might be able to see something that could be wrong in that. Al On Mon, 2007-12-03 at 11:45 +0300, Андрей Судаков wrote: Hello! I try to set up BMC alerting - i want setup my host (IBM server) with FreeBSD to sent alert to my IBM Director's host via snmp. I try following utilities ftom ports: freeipmi anf ipmitool I can set IP adreess of BMC controller, netmask, gw, i can set IP adress of destination host and alert type to PET, but i can't set PEF alert policy. 'ipmitool pef policy' in null I've try freeipmi - 'pef-config - o pef_file', setup policy in with file and load it to bmc controller via 'pef-config --commit -f pef_file', but nothing cange How can i enable alert policy? May be i can use RAW? This is my config, obtained via remote by pefconfig pefconfig ver 2.4 Opening connection to node 172.16.9.91 ... Connected to node 172.16.9.91 -- BMC version 1.27, IPMI version 2.0 pefconfig: GetPefEntry ... PEFilter(01): 01 Temperature event - enabled for alert PEFilter(02): 07 BIOS event - enabled for alert PEFilter(03): 08 Power Supply event - enabled for alert PEFilter(04): 08 Power Supply event - enabled for alert PEFilter(05): 02 Voltage event - enabled for alert PEFilter(06): 02 Voltage event - enabled for alert PEFilter(07): 02 Voltage event - enabled for alert PEFilter(08): 1b Other event - enabled for alert PEFilter(09): ff Other event - enabled for alert PEFilter(10): empty PEFilter(11): 12 System Restart event - enabled for alert PEFilter(12): 20 OS Critical Stop event - enabled for alert PEFilter(13): 09 Power Unit event - enabled for alert PEFilter(14): 09 Power Unit event - enabled for alert PEFilter(15): 09 Power Unit event - enabled for alert PEFilter(16): 09 Power Unit event - enabled for alert GetPefEntry(6/17): completion code=c9 GetPefEntry(17), ret = -1 GetPefEntry(6/18): completion code=c9 GetPefEntry(18), ret = -1 GetPefEntry(6/19): completion code=c9 GetPefEntry(19), ret = -1 GetPefEntry(6/20): completion code=c9 GetPefEntry(20), ret = -1 PEF Control: 03 PEFenable DoEventMsgs PEF Actions: 0e PwrDn Reset PwrCyc PEF Startup Delay: 60 sec PEF Alert Startup Delay: 60 sec PEF Alert Policy[1]: 01 10 11 00 Disabled PEF Alert Policy[2]: 02 00 00 00 Disabled PEF Alert Policy[3]: 03 00 00 00 Disabled PEF Alert Policy[4]: 04 00 00 00 Disabled pefconfig: GetLanEntry for channel 1 ... Lan Param(0) Set in progress: 01 Lan Param(1) Auth type support: 17 None MD2 MD5 Pswd Lan Param(2) Auth type enables: 17 17 17 17 00 Lan Param(3) IP address: 172 16 9 91 Lan Param(4) IP addr src: 01 Static Lan Param(5) MAC addr: 00 14 5e f9 eb ef Lan Param(6) Subnet mask: 255 255 0 0 Lan Param(7) IPv4 header: 40 40 10 Lan Param(10) BMC grat ARP : 03 Lan Param(11) grat ARP interval: 04 Lan Param(12) Def gateway IP: 172 16 0 1 Lan Param(13) Def gateway MAC: 00 00 00 00 00 00 Lan Param(14) Sec gateway IP: 0 0 0 0 Lan Param(15) Sec gateway MAC: 00 00 00 00 00 00 Lan Param(16) Community string: public Lan Param(17) Num dest: 04 Lan Param(18) Dest type: 01 00 00 00 00 Lan Param(18) Dest type: 02 00 00 00 00 Lan Param(18) Dest type: 03 80 00 00 00 Lan Param(18) Dest type: 04 00 00 00 00 Lan Param(19) Dest address: 01 00 00 [172 16 6 248] 00 1b fc a3 d0 27 Lan Param(19) Dest address: 02 00 00 [172 16 6 248] ff ff ff ff ff ff Lan Param(19) Dest address: 03 00 00 [0 0 0 0] ff ff ff ff ff ff Lan Param(19) Dest address: 04 00 00 [0 0 0 0] ff ff ff ff ff ff GetLanEntry: completion code=80 GetLanEntry(192), ret = -1 GetLanEntry: completion code=80 GetLanEntry(193), ret = -1 GetLanEntry: completion code=80 GetLanEntry(194), ret = -1 GetChanAcc(lan), ret = 0, new value = 02 Access = Always Avail, PEF Alerts Enabled Channel Access Mode(Lan): 02 04 GetSOL for channel 1 ... SOL Enable: 01 enabled SOL Auth: 82 User SOL Accum Interval: 1e c8 150 msec SOL Retry Interval: 07 30 480 msec SOL nvol Baud Rate: 07 19.2k SOL vol Baud Rate: 07 19.2k SOL Payload Access(1,1): 00 00 00 00 disabled SOL Payload Support(1): 03 00 3f 00 00 00 00 00 Get User Access(1): 04 04 01 34 IPMI, Admin () Get User Access(2): 04 04 01 34 IPMI, Admin (USERID) Get User Access(3): 04 04 01 13 IPMI, Operator
[Freeipmi-devel] ipmi_lan_sendto bug
This routine didn't seem to work at all in freeipmi-0.2.2-qa0 (would
call sendto with NULL pointer). The routine is below, with the two
changes are commented with ARC:.
Andy
---
ssize_t
ipmi_lan_sendto (int sockfd,
const void *buffer,
size_t buffer_size,
int flags,
const struct sockaddr *server_addr,
socklen_t server_addr_len)
{
void *packet = NULL;
size_t packet_length = 0;
ssize_t bytes_sent = 0;
int fusepad = 0;
if (buffer == NULL || buffer_size == 0 || server_addr == NULL)
{
errno = EINVAL;
return (-1);
}
/*
Note from Table 12-8, RMCP Packet for IPMI via Ethernet footnote
Some LAN adapter chips may have a problem where packets of overall
lengths 56, 84, 112, 128, or 156 are not handled correctly. The
PAD byte is added as necessary to avoid these overall
lengths. Remote console software must use the PAD byte when
formatting packets to any 10/100 Ethernet device that accepts RMCP
packets. -- Anand Babu
*/
if (buffer_size == 56 ||
buffer_size == 84 ||
buffer_size == 112 ||
buffer_size == 128 ||
buffer_size == 156)
{
packet_length = buffer_size + IPMI_LAN_PKT_PAD_SIZE;
packet = alloca (packet_length);
memset (packet, 0, packet_length);
memcpy (packet, buffer, buffer_size);
fusepad = 1;
} else { /* ARC: was missing */
packet_length = buffer_size;
packet = buffer;
}
bytes_sent = sendto (sockfd,
packet,
packet_length,
flags,
server_addr,
server_addr_len);
if (bytes_sent == -1)
return (-1);
if (fusepad) /* ARC: change condition */
return (bytes_sent - IPMI_LAN_PKT_PAD_SIZE);
return bytes_sent;
}
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] ipmi_lan_sendto bug
BTW, at ipmi-lan-interface:1541:
fd_set fd_set;
Gives FD_ZERO macro errors with several compiler versions, so
fd_set fd_set1;
Or similar should be used.
Andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Cress, Andrew R
Sent: Friday, July 07, 2006 4:35 PM
To: freeipmi-devel@gnu.org
Subject: [Freeipmi-devel] ipmi_lan_sendto bug
This routine didn't seem to work at all in freeipmi-0.2.2-qa0 (would
call sendto with NULL pointer). The routine is below, with the two
changes are commented with ARC:.
Andy
---
ssize_t
ipmi_lan_sendto (int sockfd,
const void *buffer,
size_t buffer_size,
int flags,
const struct sockaddr *server_addr,
socklen_t server_addr_len)
{
void *packet = NULL;
size_t packet_length = 0;
ssize_t bytes_sent = 0;
int fusepad = 0;
if (buffer == NULL || buffer_size == 0 || server_addr == NULL)
{
errno = EINVAL;
return (-1);
}
/*
Note from Table 12-8, RMCP Packet for IPMI via Ethernet footnote
Some LAN adapter chips may have a problem where packets of overall
lengths 56, 84, 112, 128, or 156 are not handled correctly. The
PAD byte is added as necessary to avoid these overall
lengths. Remote console software must use the PAD byte when
formatting packets to any 10/100 Ethernet device that accepts RMCP
packets. -- Anand Babu
*/
if (buffer_size == 56 ||
buffer_size == 84 ||
buffer_size == 112 ||
buffer_size == 128 ||
buffer_size == 156)
{
packet_length = buffer_size + IPMI_LAN_PKT_PAD_SIZE;
packet = alloca (packet_length);
memset (packet, 0, packet_length);
memcpy (packet, buffer, buffer_size);
fusepad = 1;
} else { /* ARC: was missing */
packet_length = buffer_size;
packet = buffer;
}
bytes_sent = sendto (sockfd,
packet,
packet_length,
flags,
server_addr,
server_addr_len);
if (bytes_sent == -1)
return (-1);
if (fusepad) /* ARC: change condition */
return (bytes_sent - IPMI_LAN_PKT_PAD_SIZE);
return bytes_sent;
}
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Need to issue commands to non-BMC slave addresses
In my utilities, there are a few cases where IPMI commands (for FRU) need to be sent to a slave address other than the BMC slave address (0x20). For instance, in our platforms the HotSwap Controller has IPMI FRU data at slave address 0xC0. I currently have no way of passing a different slave address to ipmi_kcs_cmd_interruptible() or ipmi_lan_cmd(). I noticed that fill_lan_msg_hdr() inserts a constant BMC slave address, but I didn't find where the kcs template had a place for the slave address. Comments/advice? Andy ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] Need to issue commands to non-BMC slave addresses
Al, Thanks for the tip about fidd_obj_set(). The IPMI FRU commands to the HSC are still SMS messages, just the target has a different slave address. (See IPMI 2.0 section 5, pg 37, Requester's ID) This problem becomes decidedly more acute with bladed systems. So, there needs to be a method for both local (KCS or SSIF) and remote (LAN or Serial) addressing to cover it. Perhaps adding a parameter to the functions, a field to the template, etc. Does this need a bugzilla to track it? Andy -Original Message- From: Albert Chu [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 25, 2005 12:12 PM To: Cress, Andrew R Cc: GNU FreeIPMI Developers Subject: Re: [Freeipmi-devel] Need to issue commands to non-BMC slave addresses Hey Andrew, Comments/advice? For lan, in the short term, I think the best thing to do is to use the fiid_obj_set() function to manually set the field rs_addr of the tmpl_lan_msg_hdr_rq template. I'm not quite sure what to for KCS though. As far as I can tell, it can only go to the BMC and nothing else. According to the IPMI 2.0 spec, beginning of Chapter 9. The KCS interface is specified solely for SMS messages indicating it can't be done?? AB, your thoughts? For the long term though, I believe this has to be fixed in the libfreeipmi library API somehow. We simply assume all transactions go to the BMC slave address, but its apparently not a correct assumption. I'll add it to the todo list. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Cress, Andrew R [EMAIL PROTECTED] Date: Wednesday, May 25, 2005 8:50 am Subject: [Freeipmi-devel] Need to issue commands to non-BMC slave addresses In my utilities, there are a few cases where IPMI commands (for FRU) need to be sent to a slave address other than the BMC slave address (0x20). For instance, in our platforms the HotSwap Controller has IPMIFRU data at slave address 0xC0. I currently have no way of passing a different slave address to ipmi_kcs_cmd_interruptible() or ipmi_lan_cmd(). I noticed that fill_lan_msg_hdr() inserts a constant BMC slave address,but I didn't find where the kcs template had a place for the slave address. Comments/advice? Andy ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
