freeipmi-users
[Top][All Lists]
Advanced

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

Re: [Freeipmi-users] IPMI-DCMI Q


From: Albert Chu
Subject: Re: [Freeipmi-users] IPMI-DCMI Q
Date: Wed, 20 Jul 2016 16:13:36 -0700

I'll put it on the todo, dunno when I can get to it though.

Could you perhaps create a ticket on github

https://github.com/chu11/freeipmi-mirror

we can discuss which packets to support in there.  I wouldn't want to
support all of them, since some are clearly more useful than others
(e.g. all "info" ones vs activate session) in the ping command.

Al

On Wed, 2016-07-20 at 10:34 -0700, dan farmer wrote:
> 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 
> support…
> 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….
> 
> dan
> 
> > 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
> >> https://lists.gnu.org/mailman/listinfo/freeipmi-users
> > 
> > -- 
> > Albert Chu
> > address@hidden
> > Computer Scientist
> > High Performance Systems Division
> > Lawrence Livermore National Laboratory
> > 
> > 
> > 
> > _______________________________________________
> > 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





reply via email to

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