freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds


From: Albert Chu
Subject: Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds for ruby implementation
Date: Mon, 30 Jul 2012 11:36:27 -0700

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]