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: Al Chu
Subject: Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds for ruby implementation
Date: Sun, 29 Jul 2012 22:36:57 -0700

On Sun, 2012-07-29 at 12:22 -0700, Corey Osman wrote:
> Al,
> 
> 
> Why does ipmitool work correctly then without sending additional
> workarounds?

I can't say for sure, b/c the invalidly formatted packet back from the
HP system can affect things in different ways.

Although I do not know ipmitool perfectly, different assumptions are
made in various parts of the code.  FreeIPMI tends to be a tad more
strict on IPMI compliance, electing to error out to the user instead
guessing what a system wants to do when it isn't in compliance.

Could you recompile freeipmi w/ --enable-debug and --enable-trace?  We
can see a full error trace of what's going on when you try to do your
ipmi-chassis-config --checkout.

Al


> 
> 
> Thanks,
> 
> 
> Corey Osman
> address@hidden
> 
> 
> Green IT and Data Center Automation Specialist
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Jul 29, 2012, at 12:18 PM, Al Chu <address@hidden> 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]