[Top][All Lists]

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

Re: [Freeipmi-users] IPMI-DCMI Q

From: dan farmer
Subject: Re: [Freeipmi-users] IPMI-DCMI Q
Date: Wed, 20 Jul 2016 10:34:22 -0700

Thanks Al -

Yes, get auth, system guid, channel auth capabilities, cipher suites, pet ack 
and of course activate session all should be good w/o auth or sessions being
involved. I’ve written code for all those, but it’d be great to have native 
on my to do list was always brute forcing all the ipmi commands w/o auth
to see if a vendor forgot to put that check in ;)

If I was a C-guy I’d try to hack it in, but….


> On Jul 20, 2016, at 10:24 AM, Albert Chu <address@hidden> wrote:
> Hi Dan,
> I've personally never tried that packet session-less so I'm not sure
> about support in general.
> Here's an idea, ipmi-ping is based on get authentication capabilities
> session-less/un-authenticated.  Perhaps options could be added to try
> alternate un-authenticated packets?  Off the top of my head, I remember
> one of the "get device id" or "get device guid" is also supposed to
> support unauthenticated.  I've never tried that one session-less before
> either.
> Looking through the code, I might have to tweak it a bit to support
> other packets, and some hackery would have to be done to maintain
> backwards support with the -r option, but should be very doable.
> Al
> On Tue, 2016-07-19 at 23:01 -0700, dan farmer wrote:
>> Hi folks -
>> I recently came across something that is implemented and documented in
>> freeipmi, but I had a question or two about it nonetheless.
>> It appears that the Get DCMI Capabilities Info Command (from the DCMI
>> spec) is intended to be similar to the get auth of IPMI; indeed the
>> spec says "The command is session-less and can be called similar to
>> the Get Authentication Capability command.” Session-ess being the key
>> here… and again in the platform command table (chapter 6 in v1.1 &
>> 1.5) they specifically call it out as being session-less and "Command
>> can be executed at any privilege level and is available before and
>> after establishing a session.”
>> Does anyone ask if this un-authenticated call is generally implemented
>> that way or not?  It certainly works fine with authentication. Or does
>> anyone know of a tool or example that does this in an unauthenticated
>> fashion?
>> The reason I’m asking is because I *think* I’m sending the correct
>> packet out RE: the spec, but I’m not getting a response… and it could
>> be my packets suck and there’s a byte transposed or something, but I’m
>> finding it difficult to tell because (a) I can’t find a sniffer who
>> understands the protocol to see if I’m sending it correctly, (b) I
>> can’t (easily, and in general) get onto the BMC that is receiving the
>> packet and see what’s going on there, and (c) freeipmi/ipmi-dcmi
>> doesn’t appear to allow you to send packets without starting up a
>> session first (please add unauthenticated packet sending, and I’m not
>> talking auth type NONE!), so while I see the packets from the tool
>> they’re authenticated and hence different.
>> The difference in the packets is in two places; the auth info,
>> sequence #, and the checksum at the end (all one stream with some
>> spacing to hopefully help readability:
>> Working authenticated ipmi-dcmi payload:
>>      0600ff07 02ce808500510000000ca9369cb60f13a2c4a7ece6dcb5d6ce0 
>> 920b030811c01dc0185
>>               ^^^     this is the authtype and auth info     ^^^^
>> My lame payload:
>>      0600ff07                0000000000000000000                  
>> 920b030810001dc01a1
>> Anyway, in the hopes that someone sees something obvious or knows more about 
>> it… I only have a server or two to test this with as some just don’t support 
>> the protocol.
>> Thanks and hope all is well in ipmi-land -
>> dan
>> _______________________________________________
>> Freeipmi-users mailing list
>> address@hidden
> -- 
> Albert Chu
> address@hidden
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
> _______________________________________________
> Freeipmi-users mailing list
> address@hidden

reply via email to

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