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

[Anand Babu]

,---- Albert Chu <address@hidden> writes:
| 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?
`----
No body should trust the configure and other build scripts that comes
along with CVS. Better way is to remove these scripts from CVS.

You are supposed to run the ./refresh which updates these build
scripts every time you checkout.

I kept them in the CVS for convenience purpose. It doesn't matter at
all if they are broken.

In terms of sticking to a particular version of
automake/autoconf/libtool, I would like to keep them compatible with
multiple versions.

,----
| 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.
`----
We currently do nothing about "retry". I tried it outside the
libfreeipmi (ie from fish), but didn't like the implementation. So
I removed it and decide to finish the IPMI specific stuff first.

Session Approach
================
[Refer to Appendix A of IPMI 1.5 spec]

ipmi-recvfrom will receive these packets into a pool of IPMI packets
and the application will pick them from there. No packets will be
ignored, but garbaged out when the pool fills up.

Call-back approach:
call-back structure - function ptrs to every ipmi response call.
Library will do the session tracking and call appropriately the
response handlers.

Session Helper calls:
libfreeipmi will provide helper calls to implement session tracking
and let the application own the control.

Daemon approach:
A separate process acts as a bridge between the BMC/UDP and
Management-APP/TCP. Application connects to this daemon over a TCP
session and never worries about session tracking.

No Session Approach
===================
Do we really need session tracking?
 - Yes, session sequence number is the only way to connect the
 request and response.

 But why not ignore everything that doesn't match the last sent
 command. [ THIS IS WHAT YOU ARE TALKING ABOUT ]

 - No, if we do not run the management app across multiple routers
   (like Intranet/Internet).

+-------------+
| Lets debate |
+-------------+
--
Anand Babu
CaliforniaDigital.com
Office# +1-510-687-7045
Cell# +1-510-396-0717
Home# +1-510-894-0586

Free as in Freedom <www.gnu.org>