| So,
Step 1: inform HP with what they need to do? Step 2: Get some work around going until firmware can be updated that fixes the core issue.
Can we tell freeipmi to ignore checksums when setting values? It sounds like impipower downloads the config, and inserts the new key/pair values passed in, then uploads the entire configuration.
This downloading of the current config is the problem though. Is there anyway to just send the the new config and assume things worked.
Would sending a configuration file be any different than sending the key/value pairs specified on the command line.
Thanks,
Corey Osman
Green IT and Data Center Automation Specialist
Hey Corey,
Ok, I think I see the core issue now. B/c of the invalid length
returned packet from the HP system, the checksumming calculation is
changed, packets are deemed invalid and thrown out. It could be tweaked
to "pass", but at the core of all this is the HP system is returning a
payload that ultimately FreeIPMI does not feel it can trust.
I grepped through the ipmitool code for 'checksum' and as far as I can
tell, they do not check checksums on response packets. So that may be
part of the reason it works with ipmitool. But I don't know their code
as well, so I'm not 100% sure.
Al
On Mon, 2012-07-30 at 10:59 -0700, Corey Osman wrote:
Al
Here is the output after recompiling with the debug and trace
options.
http://pastebin.com/u2BfpNjb
Thanks,
Corey Osman
address@hidden
Green IT and Data Center Automation Specialist
On Jul 30, 2012, at 7:05 AM, Al Chu <address@hidden> wrote:
On Mon, 2012-07-30 at 06:16 -0700, Jim Mankovich wrote:
Al, Corey,
FYI, The DL380 G5 only supports IPMI 2.0.
Well that's an IPMI compliance issue as well.
Could one of you summarize which IPMI command or commands that
you are having issues with? Maybe I can help out.
The issue is the Get System Boot Options IPMI command and the "boot
flags" parameter selector. See Corey's previous link:
http://pastebin.com/6E9R9VNG
which shows a packet trace.
Al
-- Jim Mankovich | address@hidden --
On 7/29/2012 1:18 PM, Al Chu wrote:
On Sun, 2012-07-29 at 11:48 -0700, Corey Osman wrote:
On Jul 29, 2012, at 11:05 AM, Al Chu <address@hidden> wrote:
Hey Corey,
For some reason, on your system, HP motherboard sends extra
data for
this particular IPMI payload.
192.168.1.22: Payload Unexpected Data:
192.168.1.22: ------------------------
192.168.1.22: [ BYTE ARRAY ... ] = unexpected_data[12B]
192.168.1.22: [ 00h 00h 00h 00h 00h 00h 00h 00h ]
192.168.1.22: [ 00h 00h 00h F5h ]
FreeIPMI reasonably determines this payload is bogus and
throws it
out.
I'm not really sure how to work around this. Can you do a
--checkout
with IPMI 1.5? i.e. --driver-type=LAN
I can't because of the following error which is fixed by
specifying
LAN_2_0
authentication type unavailable for attempted privilege level
Your system simply may not be configured to allow the currently
used
authentication level. You can experiment with different ones
using the
'-a' option.
Additionally,
I just tried the ipmitool method to set the boot device and it
worked. However the difference is that it sets the boot
device
instead of retrieving the information
I am going to try and just set the boot device instead of
performing a
checkout. I would assume it freeipmi is better sending data
than
querying.
The issue is that FreeIPMI will send the data in the format it
knows of,
which may not work with whatever data format the HP motherboard
is
working with.
I suppose it's also worth trying inband communication on the
motherboard
to see if reading the chassis config works that way.
At the minimum, please send this information to HP. They should
definitely fix their board.
Al
Corey
Al
On Sun, 2012-07-29 at 10:20 -0700, Corey Osman wrote:
Please ignore my previous post as I forgot to plugin my
ipmi
device.
Here is the corrected output:
ipmi-chassis-config --username=admin
--password=password--hostname=192.168.1.22
--driver-type=LAN_2_0
--debug --section=Chassis_Boot_Flags --checkout
http://pastebin.com/6E9R9VNG
Note: this is an HP DL380 G5 with ilo 2 - version 2.0
firmware
Thanks,
Corey Osman
address@hidden
Green IT and Data Center Automation Specialist
On Jul 29, 2012, at 9:57 AM, Corey Osman
<address@hidden>
wrote:
Here is the out of running the following command (There
were 9
total
attempts with the output below):
ipmi-chassis-config --username=admin
--password=password--hostname=192.168.1.22
--driver-type=LAN_2_0
--debug --section=Chassis_Boot_Flags --checkout
192.168.1.22:
=====================================================
192.168.1.22: IPMI 1.5 Get Channel Authentication
Capabilities
Request
192.168.1.22:
=====================================================
192.168.1.22: RMCP Header:
192.168.1.22: ------------
192.168.1.22: [ 6h] = version[ 8b]
192.168.1.22: [ 0h] = reserved[ 8b]
192.168.1.22: [ FFh] = sequence_number[ 8b]
192.168.1.22: [ 7h] =
message_class.class[ 5b]
192.168.1.22: [ 0h] =
message_class.reserved[ 2b]
192.168.1.22: [ 0h] =
message_class.ack[ 1b]
192.168.1.22: IPMI Session Header:
192.168.1.22: --------------------
192.168.1.22: [ 0h] =
authentication_type[ 8b]
192.168.1.22: [ 0h] =
session_sequence_number[32b]
192.168.1.22: [ 0h] = session_id[32b]
192.168.1.22: [ 9h] = ipmi_msg_len[ 8b]
192.168.1.22: IPMI Message Header:
192.168.1.22: --------------------
192.168.1.22: [ 20h] = rs_addr[ 8b]
192.168.1.22: [ 0h] = rs_lun[ 2b]
192.168.1.22: [ 6h] = net_fn[ 6b]
192.168.1.22: [ C8h] = checksum1[ 8b]
192.168.1.22: [ 81h] = rq_addr[ 8b]
192.168.1.22: [ 0h] = rq_lun[ 2b]
192.168.1.22: [ 1Eh] = rq_seq[ 6b]
192.168.1.22: IPMI Command Data:
192.168.1.22: ------------------
192.168.1.22: [ 38h] = cmd[ 8b]
192.168.1.22: [ Eh] = channel_number[ 4b]
192.168.1.22: [ 0h] = reserved1[ 3b]
192.168.1.22: [ 1h] =
get_ipmi_v2.0_extended_data[ 1b]
192.168.1.22: [ 4h] =
maximum_privilege_level[ 4b]
192.168.1.22: [ 0h] = reserved2[ 4b]
192.168.1.22: IPMI Trailer:
192.168.1.22: --------------
192.168.1.22: [ 3Dh] = checksum2[ 8b]
ipmi-chassis-config: connection timeout
Thanks,
Corey Osman
address@hidden
Green IT and Data Center Automation Specialist
On Jul 22, 2012, at 10:57 PM, Al Chu <address@hidden>
wrote:
Hi Corey,
On Sun, 2012-07-22 at 13:20 -0700, Corey Osman wrote:
Hi,
My ruby implementation is off to a great start but I
had a
few
questions with regards to driver types and inband
configuration.
Since I will have no idea as to what kind of IPMI
device
needs
to be
controlled I need to make sure that everything
appears
automatic
with
regards to driver types and any kind of workarounds.
My goal is to automatically detect driver type and
workarounds
to ease
the pain for folks who use the ruby-freeipmi
library.
I admit I'm not sure of the best way to handle this
and make
sure
the
code is super-portable. It's sort of an unfortunate
side-effect/consequence of IPMI being implemented by
so many
vendors.
ipmitool is no different, as you select an interface
if the
default
doesn't work.
My current test device is an HP DL380 G5. I was
hoping to
have
this
device automatically detected but it appears I need
to
supply
the
--driver-type=LAN_2_0.
Although this is not really a problem as I am
planning on
doing
some
testing up front as to which driver to explicitly
assign.
However, I have noticed that when I call
ipmi-chassis-config
--checkout the command appears to stall and doesn't
provide
all
the
information. Output below
Could you provide the --debug output from the below?
Use the
--section=Chassis_Boot_Flags so we can isolate the
debug
output to
just
he bad section below.
How do I set the bios to boot from cdrom, usb and
network?
Also
do I
have a choice of which network device I can boot
from?
Once we get this section working, you'll see the full
list of
options.
## Possible values:
NO-OVERRIDE/PXE/HARD-DRIVE/HARD-DRIVE-SAFE-MODE/
##
DIAGNOSTIC_PARTITION/CD-DVD/BIOS-SETUP/REMOTE-FLOPPY
##
PRIMARY-REMOTE-MEDIA/REMOTE-CD-DVD/REMOTE-HARD-DRIVE/FLOPPY
Boot_Device
NO-OVERRIDE
Can someone supply or document the commands I would
use to
set
the
boot device? What boot options do I have available,
as only
Floppy is
in the output?
Additionally, is this a one time boot setting or
will it
boot
from
the device after every reboot.
It should be configurable via
## Possible values: Yes/No (Yes = All Future
Boots; No =
Next Boot Only)
Boot_Flags_Persistent No
once we get it to output.
Also, do I need to supply an inband option here?
Inband communication is usually auto-discovered, but
every
simple
is
different and its certainly possible a auto-discovery
can fail
in
some
systems. Some HP motherboards have a known inband
defect,
which
may
require use of a workaround (see manpage).
Hope this helps get things going for you,
Al
Please feel free to have a look at my code and
provide any
suggestions. I have written a README file to
explain how
things
will work.
https://github.com/logicminds/ruby-freeipmi
Command line examples would be great as I can easily
convert
them to ruby calls.
#
# Section Chassis_Front_Panel_Buttons Comments
#
# The following configuration options are for
enabling or
disabling button
# functionality on the chassis. Button may refer to
a
pushbutton, switch, or
# other front panel control built into the system
chassis.
#
# The value of the below may not be able to be
checked out.
Therefore we
# recommend the user configure all four fields
rather than a
subset of them,
# otherwise some assumptions on configure may be
made.
#
Section Chassis_Front_Panel_Buttons
## Possible values: Yes/No
Enable_Standby_Button_For_Entering_Standby Yes
## Possible values: Yes/No
Enable_Diagnostic_Interrupt_Button Yes
## Possible values: Yes/No
Enable_Reset_Button Yes
## Possible values: Yes/No
Enable_Power_Off_Button_For_Power_Off_Only Yes
EndSection
#
# Section Chassis_Power_Conf Comments
#
# The following configuration options are for
configuring
chassis power
# behavior.
#
# The "Power_Restore_Policy" determines the behavior
of the
machine when AC
# power returns after a power loss. The behavior can
be set
to
always power on
# the machine ("On_State_AC_Apply"), power off the
machine
# ("Off_State_AC_Apply"), or return the power to the
state
that
existed before
# the power loss ("Restore_State_AC_Apply").
#
# The "Power_Cycle_Interval" determines the time the
system
will
be powered down
# following a power cycle command.
#
Section Chassis_Power_Conf
## Possible values:
Off_State_AC_Apply/Restore_State_AC_Apply/On_State_AC_Apply
Power_Restore_Policy
Restore_State_AC_Apply
## Give value in seconds
## Power_Cycle_Interval
EndSection
#
# Section Chassis_Boot_Flags Comments
#
# The following configuration options are for
configuring
chassis boot behavior.
# Please note that some fields may apply to all
future boots
while some may only
# apply to the next system boot.
#
# "Boot_Flags_Persistent" determines if flags apply
to the
next
boot only or all
# future boots.
#
# "Boot_Device" allows the user to configure which
device
the
BIOS should boot
# off of. Most users may wish to select NO-OVERRIDE
to
select
the configuration
# currently determined by the BIOS. Note that the
configuration
value BIOS-SETUP
# refers to booting *into* the BIOS Setup, not from
it.
FLOPPY
may refer to any
# type of removeable media.
#
----- This is all that is returned
Corey Osman
address@hidden
Green IT and Datacenter Automation Specialist
_______________________________________________
Freeipmi-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
--
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
--
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
|