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