Re: [Freeipmi-users] IPMI-DCMI Q

[Albert Chu]

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
> https://lists.gnu.org/mailman/listinfo/freeipmi-users

-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory