freeipmi-devel
[Top][All Lists]
Advanced

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

[Freeipmi-devel] IPMI power control utility description


From: Albert Chu
Subject: [Freeipmi-devel] IPMI power control utility description
Date: Wed, 22 Oct 2003 11:09:44 -0700

I hope everyone is on the mailing list now.

AB, I couldn't find too much IPMI code on the FreeIPMI website, for 
the most part, I wrote an IPMI library from scratch (of course caring
only for those packets and functionality I required for power control).  
The API allows the user to:

- set data in individual packets
- get packet data values from packet responses
- dump packet data to stderr
- check packets for correct completion code, network function response,  
  command type, checksums, outbound sequence numbers, and requester  
  sequence numbers.

Based on the library, the tool creates appropriate packets, checks
responses for correctness, deals with errors, polls/sends packets, and
gives a snazzy command line interface.  Due to lack of creativity, I
called the tool ipmipower too.

The tool has two "modes", interactive and non-interactive.  If you
specify some power command on the command line (--on, --off, --stat,
--reset, --cycle) ipmipower runs the command on specified remote nodes
then exits.  

If no power commands are specified on the command line, an "interactive
mode" is entered, where you get a command prompt and can type in various
power commands.  This was specifically implemented for ipmipower to work
with powerman.
 
As for the actual IPMI protocol, I setup a session, run a power command,
then close the session.  Due to various design/implementation/time
reasons, I elected not to program our tool to keep IPMI sessions open.
 
Packet responses are checked for proper checksums, completion code,
network function, command, outbound sequence number, and requester
sequence number.  Right now, I use the requester sequence number to
store both a "transaction id" and a "sequence number", although I'm
debating if this should be changed.  Old packets or corrupted packets
are ignored and assumed to be junk.  Error codes are handled
appropriately when possible.
 
Packets will be resent if a proper response doesn't arrive within a
certain timeout.  The overall power control attempt times out after a
much larger time period.

That's a general overview, but perhaps not so general b/c this e-mail is
way long.

Al







reply via email to

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