[Freeipmi-devel] More FreeIPMI Changes + Issues to Contend with

[Albert Chu]

Hey AB,

Made some changes, highlights are:

1) *** I TEMPORARILY BROKE THE BUILD! *** .. Currently, I only updated
the Makefile.am in libfreeipmi/src/ for new files, but no
configure/Makefile.in/etc.  So the build is going to break until you do
a refresh.  See issue #1 below ...

2) Renamed ipmi-errno.[ch] to ipmi-error.[ch].  Found a few tiny errors
in the code and changed them.

3) Moved network function codes to ipmi-netfn-spec.h b/c we are starting
to split the ipmi messages into different files.

4) Added various parameter checking to ipmi packet creation functions. 
Sets errno to EINVAL and returns -1 when parameters are incorrect.

5) Various minor changes, see Changelog for details ...

New Issues:

1) I think we need to sync up on automake/autoconf/libtool packages,
otherwise we're going to keep on clobbering each other's
aclocals/Makefile.ins with various versions.  Since thunder will be
running RHEL3, I'd like to suggest we move to:

automake-1.6.3-5
autoconf-2.57-3
libtool-1.4.3-6

What do ya think?

2) ipmi_recvfrom

I have been (logically) doing the following in ipmipower

char buffer[4096];
len = recvfrom(fd, buffer, 4096);
if (len < min_ipmi_get_channel_auth_packet_size)
   /* what the heck is this, ignore this packet */
if (len > max_ipmi_get_channel_auth_packet_size)
   /* what the heck is this, ignore this packet */

The reason code like this is necessary is b/c we can retry-packets, and
(b/c it is UDP) packets can returned in strange orders.  For example,
set_privilege_level_response = 35 bytes, activate_session_response = 44
bytes.  Perhaps we sent several activate_session_request messages, then
(after finally getting a response back) we send a
set_privilegel_level_request and call
ipmi_recvfrom(set_privilege_level_response).  ipmi_recvfrom may read an
old activate_session response and leave 9 bytes in the socket buffer.  

Is this a user issue?  Are they responsible for passing in a huge buffer
and dealing with packet lengths themselves??  I dunno, I haven't thought
of the proper way yet, but I think we should discuss this.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratories