Chris,
In the IPMI 2.0 spec it requires that all IPMI 2.0 firmware must
support an IPMI 1.5 GetChannelAuthCap command. Section 22.13 says:
BMC implementations of IP-based channels must support the Get
Channel Authentication Capabilities Command
using the IPMI v1.5 packet format. BMCs that support IPMI v2.0
RMCP+ must also support the command using
the IPMI
v2.0/RMCP+ format.
So the HP iLO 2 firmware isn’t fully compliant with the IPMI 2.0
spec in this case.
Andy
From:
address@hidden
[mailto:address@hidden On
Behalf Of Christopher Maestas
Sent: Sunday, August 29, 2010 11:12 PM
To: Albert Chu
Cc: address@hidden
Subject: Re: [Freeipmi-devel] ipmi support with HP iLO2 servers
initialsuccess! - Email found in subject
I guess another question I would ask, is when will ipmi 1.5
be deprecated and the default be 2.0? I was just curious when defaults
should move away.
This server is a proliant
dl385g5 server (amd barcelona quad core). I have also tested on a bl460g6
(proliant blade Intel 6 core).
On Wed, Aug 25, 2010 at 11:07 AM, Albert Chu <address@hidden> wrote:
Hey Chris,
(Moving this to freeipmi-devel, since this is more of a devel
discussion)
> I'm sorry I should have tagged that first case of using ipmipower as
> an error.
Does HP believe this to be a bug in their firmware?
Many of the tests
in the freeipmi-testing document use IPMI 1.5 specifically (instead of
IPMI 2.0), so we'll want to get this bug fixed so you can pass those
tests too.
Also, as an FYI, what motherboard are you testing on? So that I can
document this stuff.
Al
On Tue, 2010-08-24 at 19:38 -0700, Christopher Maestas wrote:
> Al,
>
>
> I'm sorry I should have tagged that first case of using ipmipower as
> an error. Once I added "-D LAN_2_0 " things worked great.
I think I
> also figured out the freeipmi.conf parameter (driver-type LAN_2_0) to
> change to make it work by default and still talk to lo100 and iLO
> devices without any issue at first glance
>
>
> Things are running fine now. I will continue to do some more testing
> tomorrow with SOL, sensor gatherings. In addition I will try and
> report back on conman/powerman using their ipmi drivers work against
> the iLO server as well.
>
>
> Finally I will try and take a look at some tests specified here:
>
>
> http://*www.*gnu.org/software/freeipmi/freeipmi-testing.txt
>
>
> and report back.
>
> -cdm
>
>
> On Tue, Aug 24, 2010 at 5:11 PM, Albert Chu <address@hidden> wrote:
> Hi Chris,
>
> > For freeipmi (ipmipower) I found the
following combination
> worked:
> > ---
> > # ipmipower -h cut0iogw1-ilo -s
> > cut0iogw1-ilo: authentication type
unavailable for attempted
> privilege level
>
>
> This isn't good. It suggests that the HP
firmware might be
> returning
> bad/poor information in the Get Authentication
Capabilities
> phase of
> IPMI. Does ipmipower work if you also
specify the authcap
> workaround?
> (-W authcap).
>
> If it does work, then there is a bug.
Perhaps you can send me
> a --debug
> output and we can take a look to figure out
what the bug is.
>
> Al
>
>
> On Tue, 2010-08-24 at 15:29 -0700, Christopher
Maestas wrote:
> > Hello,
> >
> > With the recent update of the 2.00 iLO2
firmware, we can now
> support:
> >
> >
> > - "IPMI over LAN"
functionality. The IPMI 2.0 RMCP+ (or
> Linux ipmitool
> > "lanplus")
protocol is supported with this release.
> > - IPMI Serial Over LAN (SOL)
> > - Data Center Manageability
Interface (DCMI) v1.0
> specification
> > - Enhanced the "in
band" Intelligent Platform Management
> Interface (IPMI)
> > to comply with the IPMI
specification version 2.0
> >
> > I've been able to use ipmitool to test
this successfully
> (power, SOL and
> > sensor gathering). Here's what I do
with ipmitool:
> > ---
> > # rpm -q ipmitool
> > ipmitool-1.8.11-1
> > # ipmitool -I lanplus -H cut0iogw1-ilo -U
USER -P PASS power
> status
> > Chassis Power is off
> > # ipmitool -I lanplus -H cut0iogw1-ilo -U
USER -P PASS power
> on
> > Chassis Power Control: Up/On
> > # ipmitool -I lanplus -H cut0iogw1-ilo -U
USER -P PASS power
> status
> > Chassis Power is on
> > ---
> >
> > For freeipmi (ipmipower) I found the
following combination
> worked:
> > ---
> > # ipmipower -h cut0iogw1-ilo -s
> > cut0iogw1-ilo: authentication type
unavailable for attempted
> privilege level
> > # ipmipower -h cut0iogw1-ilo -D LAN_2_0
-s
> > cut0iogw1-ilo: on
> > # ipmipower -h cut0iogw1-ilo -D LAN_2_0
-f
> > cut0iogw1-ilo: ok
> > # ipmipower -h cut0iogw1-ilo -D LAN_2_0
-s
> > cut0iogw1-ilo: off
> > # ipmipower -h cut0iogw1-ilo -D LAN_2_0
-n
> > cut0iogw1-ilo: ok
> > # ipmipower -h cut0iogw1-ilo -D LAN_2_0
-s
> > cut0iogw1-ilo: on
> > ---
> >
> > I set the following in /etc/freeipmi.conf:
> > ---
> > driver-type LAN_2_0
> > ---
> >
> > and it seems to work ok for the lo100 and
ilo2 servers just
> fine.
> > ---
> > # ipmipower -h cut0iogw1-ilo -s
> > cut0iogw1-ilo: on
> > # ipmipower -h cut0admin1-lo -s
> > cut0admin1-lo: on
> > ---
> >
> > I figure there may be other functional
tests for ipmi
> compliance I can run
> > now that the initial flags have been
worked around for
> freeipmi's ipmipower
> > command. Then I figure on changing
powerman/conman to use
> ipmi drivers for
> > ilo devices and see how that works.
> >
> > Thanks,
> > -cdm
>
> >
_______________________________________________
> > Freeipmi-users mailing list
> > address@hidden
> > http://**lists.gnu.org/mailman/listinfo/freeipmi-users
> >
> --
> Albert Chu
> address@hidden
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
>
>
>
--
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
WARNING - This e-mail or its attachments may contain controlled technical data or controlled technology within the definition of the International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR), and are subject to the export control laws of the U.S. Government. Transfer of this data or technology by any means to a foreign person, whether in the United States or abroad, without an export license or other approval from the U.S. Government, is prohibited. The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments.
|