Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?

[Albert Chu]

Hey Ryan,

Hmmmm.  You're pretty deep into the set selectors by that point.  I'm
wondering if you may have wandered into a region of data that we
normally shouldn't wander into (i.e. the IPMI get system info command
may just be reading memory at whatever pointer it is told).  In this
particular case, there's a lot of the 0xD4 data earlier on that we're
still not clear about what it is.

Al

On Tue, Dec 20, 2011 at 4:00 PM, Ryan Cox <address@hidden> wrote:
> Al,
>
> Sounds good.  Just so you know, 0xDA and "ipmi-oem dell get-system-info
> mac-addresses" don't return anything useful for 11G systems.  The ipmi-oem
> command does work on an M600 (which it gets from 0xCB based on my reading of
> the source code).
>
> The MAC address for an M610 is actually at 0xD4:
>
>
> 0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00  => "
>    "
> 0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00  => "
>    "
> 0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0F 00 00 23 AE FC  => "
>  # � � "
> 0xD4 13 0: rcvd: 59 00 11 E6 D4 1F 00 00 23 AE FC E6 D5 0F 01  => "� �    #
> � � � �    "
> 0xD4 14 0: rcvd: 59 00 11 00 23 AE FC E6 D6 1F 01 00 23 AE FC  => " # � � �
> �      # � � "
> 0xD4 15 0: rcvd: 59 00 11 E6 D7 17 00 00 00 00 00 00 00 17 00  => "� �
>      "
> 0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 17 00 00 00 00 00  => "
>     "
> 0xD4 17 0: rcvd: 59 00 11 00 00 17 00 00 00 00 00 00 00 17 00  => "
>     "
>
> <Name> <Presence> <BMC MAC Address> <NIC1 MAC Address> <NIC2 MAC Address>
> Server-16   Present       00:23:AE:FB:8D:FF   00:23:AE:FC:E6:D4
> 00:23:AE:FC:E6:D6
>
>
>
> It appears consistent for an M600 and may be a more portable option:
>
>
> 0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00  => "
>    "
> 0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00  => "
>    "
> 0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0E 00 00 22 19 7B  => "
>  "   { "
> 0xD4 13 0: rcvd: 59 00 11 25 93 1E 00 00 22 19 7B 25 94 0E 01  => "% �    "
>   { % �    "
> 0xD4 14 0: rcvd: 59 00 11 00 22 19 7B 25 95 1E 01 00 22 19 7B  => " "   { %
> �      "   { "
> 0xD4 15 0: rcvd: 59 00 11 25 96 16 00 00 00 00 00 00 00 16 00  => "% �
>      "
> 0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 16 00 00 00 00 00  => "
>     "
> 0xD4 17 0: rcvd: 59 00 11 00 00 16 00 00 00 00 00 00 00 1F 00  => "
>     "
>
> Server-15   Present       00:22:19:7B:2C:58   00:22:19:7B:25:93
> 00:22:19:7B:25:95
>
>
> I'm going to be out of the office for the holidays starting now, so I may or
> may not be able to respond to any emails for a while.  I also need to
> investigate higher numbered set selectors more.  I'm getting results for
> some up to 0x30 that I spot checked.
>
>
> Ryan
>
>
> On 12/20/2011 04:18 PM, Albert Chu wrote:
>>
>> Hey Ryan,
>>
>> On Tue, 2011-12-20 at 14:34 -0800, Ryan Cox wrote:
>>>
>>> Al,
>>>
>>> I should have caught that it was ASCII :)
>>>
>>> Please pardon the horrific line noise.... Here's the output for an M610
>>> using a very ugly command I strung together:
>>> ================================================
>>>
>>> # for a in {0..9} A B C D E F; do for selector in {0..15}; do for
>>> blocksel in {0..15}; do echo -ne "\n0xD$a $selector $blocksel: ";
>>> ipmi-raw 0 6 59 0 0xD$a $selector $blocksel | perl -e '$s =<>; chomp
>>> $s; print "$s =>  \""; @bytes = split /\s+/, $s; @bytes; if($bytes[2] ne
>>> "00") { print "Error code $bytes[2] returned\n"; exit; } for($a=4;
>>> $a<$#bytes+1; $a++) { printf "%s ", chr(hex($bytes[$a])); } print
>>> "\"\n";'; done; done; done |grep -v Error |grep -a rcvd
>>> 0xD1 0 0: rcvd: 59 00 11 00 00 0F 50 6F 77 65 72 45 64 67 65 20 4D 36 31
>>> 30 =>  " P o w e r E d g e M 6 1 0"
>>> 0xD1 1 0: rcvd: 59 00 11 01 00 =>  " "
>>> 0xD1 2 0: rcvd: 59 00 11 02 =>  " "
>>> 0xD1 3 0: rcvd: 59 00 11 03 =>  " "
>>> 0xD2 0 0: rcvd: 59 00 11 01 =>  " "
>>> 0xD3 0 0: rcvd: 59 00 11 00 00 =>  ""
>>> 0xD4 1 0: rcvd: 59 00 11 02 01 C2 06 02 00 50 5F 53 31 00 00 =>  "   �
>>>   P _ S 1 "
>>> 0xD4 2 0: rcvd: 59 00 11 02 02 C2 06 02 00 50 5F 53 31 00 00 =>  "   �
>>>   P _ S 1 "
>>> 0xD4 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 5 0: rcvd: 59 00 11 01 00 00 00 00 00 00 00 00 00 00 00 =>  " "
>>> 0xD4 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =>  ""
>>> 0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 05 00 00 26 B9 FC =>  "  &  �
>>> � "
>>> 0xD4 13 0: rcvd: 59 00 11 B2 7C 15 00 00 26 B9 FC B2 7D 05 01 =>  "� |  &
>>>  � � � }   "
>>> 0xD4 14 0: rcvd: 59 00 11 00 26 B9 FC B2 7E 15 01 00 26 B9 FC =>  "&  � �
>>> � ~    &  � � "
>>> " 0: rcvd: 59 00 11 B2 7F 0D 00 00 00 00 00 00 00 0D 00 =>  "�  0xD5 1 0:
>>> rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 2 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 5 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD5 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> =>  ""
>>> 0xD6 0 0: rcvd: 59 00 11 00 01 0F 00 =>  "  "
>>> 0xDC 0 0: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 36 00 00 00 00 00 00
>>> 00 =>  "   S L O T - 0 6"
>>> 0xDC 1 0: rcvd: 59 00 11 01 00 00 =>  " "
>>> 0xDC 2 0: rcvd: 59 00 11 02 =>  " "
>>> 0xDC 3 0: rcvd: 59 00 11 03 =>  " "
>>> 0xDD 0 0: rcvd: 59 00 11 00 00 27 00 01 C0 A8 D2 8A 00 00 00 00 00 00 00
>>> 00 =>  " '   � � � �"
>>> 0xDD 1 0: rcvd: 59 00 11 01 00 00 00 00 33 2E 30 35 20 28 42 75 69 6C 64
>>> 20 =>  "  3 . 0 5 ( B u i l d"
>>> 0xDD 2 0: rcvd: 59 00 11 02 31 29 00 00 00 00 00 00 0B =>  "  1 )
>>> "
>>> 0xDD 3 0: rcvd: 59 00 11 03 00 00 00 00 D8 3A 8D BE D7 39 8D BE 00 00 00
>>> 00 =>  "  � : � � � 9 � �"
>>> 0xDD 4 0: rcvd: 59 00 11 04 02 00 00 00 24 7A 2A 40 DC 72 02 00 01 00 00
>>> 00 =>  "    $ z * @ � r    "
>>> 0xDE 0 0: rcvd: 59 00 11 00 00 1B 68 74 74 70 73 3A 2F 2F 31 39 32 2E 31
>>> 36 =>  "   h t t p s : / / 1 9 2 . 1 6"
>>> 0xDE 1 0: rcvd: 59 00 11 01 38 2E 32 31 30 2E 31 33 38 3A 34 34 33 =>  "
>>> 8 . 2 1 0 . 1 3 8 : 4 4 3 "
>>> 0xDE 2 0: rcvd: 59 00 11 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 =>  " "
>>> 0xDE 3 0: rcvd: 59 00 11 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 =>  " "
>>> 0xDE 4 0: rcvd: 59 00 11 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 =>  " "
>>> 0xDE 5 0: rcvd: 59 00 11 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 00 =>  ""
>>> 0xDE 6 0: rcvd: 59 00 11 06 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00
>>> 00 =>  "   "
>>> 0xDF 0 0: rcvd: 59 00 11 00 00 29 00 01 C0 A8 D0 5F 00 00 00 00 00 00 00
>>> 00 =>  " )   � � � _"
>>> 0xDF 1 0: rcvd: 59 00 11 01 00 00 00 00 33 2E 30 33 00 00 00 00 00 00 00
>>> 00 =>  "  3 . 0 3"
>>> 0xDF 2 0: rcvd: 59 00 11 02 00 00 00 00 00 00 00 00 09 01 03 =>  "     "
>>> 0xDF 3 0: rcvd: 59 00 11 03 =>  " "
>>>
>>>
>>>
>>> ================================================
>>>
>>>
>>> Observations::
>>> 0xD1 - the system type
>>> 0xD4 - shows something... not sure what it is
>>> 0xDC - the slot number
>>> 0xDD - the iDRAC version including build number
>>> 0xDE - the iDRAC web interface URL (IP and port)
>>> 0xDF - the enclosure's CMC version
>>>
>>> * These observations are consistent for: M610, M910, M600, M610x (M610x
>>> requires both 0 and 1 sets for 0xD1 so that the "x" shows up).
>>> * It does NOT work at all on an R200 (fairly old iDRAC firmware)
>>> * An R710 shows 0xD1, 0xD4 (no clue what it is) and 0xDE only, though
>>> the R710's iDRAC firmware is much older. The R710 returns zero bytes for
>>> most of the others but doesn't error out.
>>
>> Cool.  0xD1 is already done in ipmi-oem as well as 0xDA (MAC address).
>>
>> Going through and re-learning this code in ipmi-oem, it seems a number
>> of these map to this format:
>>
>>    * Parameter data response formatted:
>>    *
>>    * Set Selector 0:
>>    *
>>    * 1st byte = set selector
>>    * 2nd byte = encoding
>>    * 3rd byte = string length
>>    * ? bytes = string
>>    *
>>    * Set Selector>  0
>>    *
>>    * 1st byte = set selector
>>    * ? bytes = string
>>
>> I'm in the middle of something right now, but I'll try to get this into
>> ipmi-oem sometime soon and send you link to a code tree w/ beta code.
>> I'll probably need your guy's help to write the manpage entries and such
>> since you guys know the hardware better :-)
>>
>> Al
>>
>> P.S. the FreeIPMI 1.1.1 beta is about to come out, so I doubt it'll get
>> into that.  1.1.2 is a more likely target.
>>
>>> Multiple set selectors (correct term?) are required for at least 0xDD
>>> and 0xDE. The block selector seemed to do nothing.
>>>
>>>
>>> Ryan
>>>
>>> On 12/20/2011 02:47 PM, Albert Chu wrote:
>>>>
>>>> [moving thread to freeipmi-devel]
>>>>
>>>> Hey Ryan,
>>>>
>>>> This looks very interesting.  0xDC isn't one I know of yet.  It could
>>>> totally be available and just not published by Dell yet.
>>>>
>>>> rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00
>>>>
>>>> the 0x59 is the command byte (same as in the input command line).  The
>>>> next 0x00 is the completion code (0 = success).
>>>>
>>>> In similar formats from Dell (see ipmi-oem-dell.c), the byte afterwards
>>>> is typically a length/count of some sort, 0x11 = 17, which does equal
>>>> the remaining number of bytes.  So we're on the right track.
>>>>
>>>> I took a guess that this might be ascii, lookie at what it maps too.
>>>>
>>>> 53 = S
>>>> 4C = L
>>>> 4F = O
>>>> 54 = T
>>>> 2D = -
>>>> 31 = 1
>>>> 36 = 6
>>>>
>>>> only the 0x10 = DLE is an oddity.  Do 0xD1 - 0xDF output anything
>>>> similar?  I'm wondering if this data is a part of additional data.
>>>> Could you also fiddle with:
>>>>
>>>> /usr/sbin/ipmi-raw 0 6 59 0 0xDC XX YY
>>>>
>>>> the XX&   YY bytes.  They are the set selector/block selector fields.
>>>> Perhaps there is additional string data surrounding this.
>>>>
>>>> If it's consistent across all slots, systems, and we can figure this all
>>>> out, we can get this into ipmi-oem.  Chris can you also verify on your
>>>> systems?
>>>>
>>>> Al
>>>>
>>>> On Tue, 2011-12-20 at 12:43 -0800, Ryan Cox wrote:
>>>>>
>>>>> Al,
>>>>>
>>>>> I just found this on 0xDC for a blade in slot 16:
>>>>> # ipmi-raw 0 6 59 0 0xDC 0 0
>>>>> rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00
>>>>>
>>>>> You'll have to bear with me on this since I'm not sure of what the
>>>>> standard is for counting bytes when referring to the data returned from
>>>>> ipmi-raw, so I'll assume the "59" is byte 0.
>>>>>
>>>>> Bytes 11 and 12 ("31" and "36" above) have the slot number for each of
>>>>> the M610s, M910s, M600s, and M610X that I tested.  It's a weird way of
>>>>> encoding it but it has worked everywhere I have tested.  Bit 0 of byte
>>>>> 11 is the first *decimal* digit of the slot number (i.e. 0 or 1).  I
>>>>> assume that other bits could be used if Dell comes out with a chassis
>>>>> that holds more blades but, of course, have no way to test that.  Bits
>>>>> 0-3 of byte 12 are the second decimal digit of the slot number (i.e.
>>>>> 0-9).
>>>>>
>>>>> I've tested on close to 100 blades and it is consistent.
>>>>>
>>>>> Examples:
>>>>>
>>>>> Slot 15:  rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 35 00 00 00 00 00
>>>>> 00 00
>>>>> Slot 05:  rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 35 00 00 00 00 00
>>>>> 00 00
>>>>> Slot 02:  rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 32 00 00 00 00 00
>>>>> 00 00
>>>>> Slot 14:  rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 34 00 00 00 00 00
>>>>> 00 00
>>>>>
>>>>> Ryan
>>>>>
>>>>> On 12/20/2011 12:50 PM, Albert Chu wrote:
>>>>>>
>>>>>> On Tue, 2011-12-20 at 11:20 -0800, Ryan Cox wrote:
>>>>>>>
>>>>>>> Al,
>>>>>>>
>>>>>>> I tried iterating from 0xC0 through 0xCF on some Dell M610s and
>>>>>>> didn't
>>>>>>> find the slot number.  I compared the results of several that were in
>>>>>>> the same chassis so that most of the information would be the same.
>>>>>>>  I
>>>>>>> saw no differences that seemed to indicate the slot number.  The only
>>>>>>> differences at all that I saw from blades in the same chassis were at
>>>>>>> 0xC3 and 0xC5 (expected).  We don't have asset tags set or I would
>>>>>>> expect to see differences in 0xC4.
>>>>>>
>>>>>> Sorry it didn't work.  It was worth a shot :-)
>>>>>>
>>>>>> Al
>>>>>>
>>>>>>> Ryan
>>>>>>>
>>>>>>> On 12/19/2011 11:04 AM, Albert Chu wrote:
>>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> I might be misunderstanding your question, but it seems you want to
>>>>>>>> figure out what type of board is inside each slot?  I assume the
>>>>>>>> ipmi-oem Dell command 'get-system-info' isn't enough b/c you only
>>>>>>>> get
>>>>>>>> the board name and not the slot number?
>>>>>>>>
>>>>>>>> I don't know of any OEM commands for this, so the first thing is I'd
>>>>>>>> bug
>>>>>>>> Dell, b/c someone there might be able to provide it (you will have
>>>>>>>> to
>>>>>>>> fight them to get to the right people, the first line support will
>>>>>>>> likely have no idea).  If you get something from them, please let
>>>>>>>> the
>>>>>>>> list know and we can put it in ipmi-oem.
>>>>>>>>
>>>>>>>> Depending on your willingness to try and reverse engineer something,
>>>>>>>> there might be a way to determine it.  The following is an ipmi-raw
>>>>>>>> that
>>>>>>>> should implement the same thing as "ipmi-oem dell get-system-info
>>>>>>>> asset-tag"
>>>>>>>>
>>>>>>>> /usr/sbin/ipmi-raw 0 6 59 0 0xC4 0 0
>>>>>>>>
>>>>>>>> In ipmi-oem here's a comment on the parameter numbers:
>>>>>>>>
>>>>>>>>       * guid parameter = 0xC3
>>>>>>>>       * asset-tag parameter = 0xC4
>>>>>>>>       * service-tag parameter = 0xC5
>>>>>>>>       * chassis-service-tag parameter = 0xC6
>>>>>>>>       * chassis-related-service-tag parameter = 0xC7
>>>>>>>>       * board-revision parameter = 0xC8
>>>>>>>>
>>>>>>>> This is what we know of or have been told.  It wouldn't be hard to
>>>>>>>> imagine that 0xC9, 0xCA ,0xCB might return your slot number.
>>>>>>>>
>>>>>>>> Al
>>>>>>>>
>>>>>>>> On Sun, 2011-12-18 at 06:39 -0800, DeRamus, Chris wrote:
>>>>>>>>>
>>>>>>>>> I've just learned about the wonders of IPMI this past month and
>>>>>>>>> have re-written our inventory system from scratch to take advantage 
>>>>>>>>> of the
>>>>>>>>> data the FreeIPMI suite of tools provides easy access to. Right now 
>>>>>>>>> the only
>>>>>>>>> drawback is that I have to run a secondary script at each co-location 
>>>>>>>>> to
>>>>>>>>> access each of our Dell M1000e chassis, running proprietary racadm 
>>>>>>>>> command
>>>>>>>>> over SSH to correlate which 10g/11g PowerEdge blades are running in 
>>>>>>>>> the
>>>>>>>>> various slots. I've been digging through the documentation in hopes of
>>>>>>>>> finding either a oem command that I can run or even a ipmi-raw 
>>>>>>>>> command that
>>>>>>>>> can be passed to each blade to pull this data, but so far I've come up
>>>>>>>>> short.
>>>>>>>>>
>>>>>>>>> Has anyone on this list been able to identify a method to capture
>>>>>>>>> this particular information? Dell's OMSA utility also provides the 
>>>>>>>>> slot
>>>>>>>>> information as seen in the output below.
>>>>>>>>>
>>>>>>>>> #>     omreport chassis info
>>>>>>>>> Chassis Information
>>>>>>>>>
>>>>>>>>> Index                                    : 0
>>>>>>>>> Chassis Name                             : Main System Chassis
>>>>>>>>> Host Name                                : xxxxxxxxxxxx
>>>>>>>>> iDRAC6 Version                           : 1.60
>>>>>>>>> Chassis Model                            : PowerEdge M600
>>>>>>>>> Chassis Lock                             : Not Present
>>>>>>>>> Chassis Service Tag                      : XX11YY2
>>>>>>>>> Server Module Service Tag                : YY11XX2
>>>>>>>>> Server Module Location                   : Slot 14<-- This is what
>>>>>>>>> I need
>>>>>>>>> Flash chassis identify LED state         : Off
>>>>>>>>> Flash chassis identify LED timeout value : 300
>>>>>>>>>
>>>>>>>>> Thanks in advance for the time guys.
>>>>>>>>>
>>>>>>>>> --Chris
>>>>>>>>> _______________________________________________
>>>>>>>>> Freeipmi-users mailing list
>>>>>>>>> address@hidden
>>>>>>>>> https://lists.gnu.org/mailman/listinfo/freeipmi-users
>>>>>>>>>
>>>
>>> --
>>> Ryan Cox
>>> Systems Administrator
>>> Fulton Supercomputing Lab
>>> Brigham Young University
>>>
>>> http://tech.ryancox.net
>
>
>
> --
> Ryan Cox
> Systems Administrator
> Fulton Supercomputing Lab
> Brigham Young University
>
> http://tech.ryancox.net
>
>
>
> _______________________________________________
> Freeipmi-users mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/freeipmi-users