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 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;
Al
On Mon, 2008-12-08 at 06:38 -0800, Cress, Andrew R wrote:
> Al,
>
> Attached are the debug logs of the two errors I get.
> Same errors for any Intel server, the "BMC Busy" error in fi.log is the most
> common.
>
> Andy
>
>
> -----Original Message-----
> From: Al Chu [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2008 5:41 PM
> To: Cress, Andrew R
> Subject: RE: [Freeipmi-devel] FW: [bug #24300] ipmiconsole cannot connect to
> various Intel servers
>
> Hey Andrew,
>
> If you have time, do you think you could sanity check this tar.gz's
> ipmiconsole and some of the other stuff (ipmipower and ipmi-sensors
> would hit all the ipmi 2.0 "implementations") against an Intel machine.
> I'd appreciate it.
>
> http:// ftp.zresearch.com/pub/freeipmi/qa-
> release/freeipmi-0.7.4.beta0.tar.gz
>
> Al
>
> On Fri, 2008-12-05 at 11:31 -0800, Cress, Andrew R wrote:
> > Yep, I meant to save the draft and go finish that part but hit send
> > instead. :-)
> >
> > Andy
> >
> > -----Original Message-----
> > From: Al Chu [mailto:[EMAIL PROTECTED]
> > Sent: Friday, December 05, 2008 2:29 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 10:54 -0800, Cress, Andrew R wrote:
> > > 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 ...
> >
> > Forgot to write the end to this part? :-)
> >
> > Looking through the ipmiutil code, it doesn't seem like any padding is
> > done. I wrote the Intel 2.0 workarounds a long time ago and probably
> > added things to "just make them work", not seeing if there was a cleaner
> > way to deal with it.
> >
> > Al
> >
> > >
> > > /* 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 ==
> > > IPMI_INTEGRITY_ALGORITHM_MD5_128)
> > > /* achu: I have not been able to reverse engineer this. So
> > > accept it */
> > > return 1;
> > > }
> > > else
> > > authentication_algorithm = c->config.authentication_algorithm;
> > >
> > > > lib/lanplus/lanplus_crypt.c:lanplus_generate_rakp3_authcode() has an
> > > > intelplus case for privilege defaults
> > >
> > > Ahh, this might be it. In ipmipower and libfreeipmi's ipmi 2.0 code I
> > > handle this properly. But in ipmiconsole I seem to have accidentally
> > > put this code in the RAKP1 section. That might be the reason that I'm
> > > checking the return value from the RAKP2 incorrectly.
> > >
> > > I'll do some more auditing to see if I can find why the other fellow's
> > > example isn't working on the INTELs. I noticed he is using a NULL
> > > username/password. You mind given my next tar.gz a test run to see if I
> > > caught everything?
> > >
> > > BTW, it seems as though ipmiutil does not implement all of the Intel
> > > workarounds I found. There were a number of corner cases for
> > > username/password lengths. Here's what I have in my comments.
> > >
> > > /* 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.
> > > */
> > >
> > > /* 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.
> > > */
> > >
> > > Does ipmiutil handle these too? Or is it possible Intel fixed some
> > > issues but not others in newer firmware?
> > >
> > > Al
> > >
> > > > 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
> > > >
--
Albert Chu
[EMAIL PROTECTED]
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
