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 <[email protected]> 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 > >> [email protected] > >> https://lists.gnu.org/mailman/listinfo/freeipmi-users > > > > -- > > Albert Chu > > [email protected] > > Computer Scientist > > High Performance Systems Division > > Lawrence Livermore National Laboratory > > > > > > > > _______________________________________________ > > Freeipmi-users mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/freeipmi-users > -- Albert Chu [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-users
