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

[DeRamus, Chris]

I ran this against our 500 M600 blades and am happy to report it's working 
flawlessly. The only other Dell hardware that we have are 1U/2U rack mountable 
PowerEdge servers and when ran against those nothing is returned which is what 
I would expect :).

PowerEdge 2950:
#> ipmi-raw 0 6 59 0 0xDC 0 0 -h 192.168.100.140
rcvd: 59 80

Thanks again for all of your help on this guys. Enjoy your holiday season.

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Ryan Cox
Sent: Tuesday, December 20, 2011 7:00 PM
To: Albert Chu
Cc: address@hidden
Subject: Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot 
availability?

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