freeipmi-devel
[Top][All Lists]
Advanced

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

Re: [Freeipmi-devel] adding md2/md5 support


From: Anand Babu
Subject: Re: [Freeipmi-devel] adding md2/md5 support
Date: Thu, 12 Feb 2004 20:47:18 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hi Al,
,----[ Albert Chu <address@hidden> ]
| Hey everyone,
| 
| The current API is not perfect for md2/md5 checksum support.  The
| reason is that in order to calculate md2/md5 checksums, we need the
| lan_msg_hdr, command, and packet checksums to be filled in *first*.
| Then, the md2/md5 authcode is calculated *last*.  This won't work in
| the current API b/c we call fill_hdr_session() before calling
| assemble_lan_packet().
| 
| I see several ways to add md2/md5 support:
| 
| 1) Pass authtype and password to assemble_lan_packet instead of
|    fill_hdr_session(): Pro: Easiest Con: Messes up nice API
| 
| 2) fill_hdr_session() copies "password" into the authcode buffer.
|    Within assemble_lan_packet(), recalculate the authentication code
|    if the authtype is md2 or md5.  You can think of this as a "hidden"
|    way to pass the password from fill_hdr_session to
|    assemble_lan_packet.  Pro: Keeps API nice Con: A "work around"
|    solution.  Doesn't sit well with me.  But in some respects it is
|    still "clean".  I might feel better if someone else feels this is
|    ok.
| 
| 3) Add a "lan_msg_hdr" and "obj_cmd" parameters to fill_hdr_session().
|    Pro: Easy and keeps API relatively clean Con: Requires user to call
|    fill_lan_msg_hdr and fill_X_cmd before fill_hdr_session.
| 
| Al
`----
I will do the (2)nd way. It keeps the APIs clean, uniform and
simple.

,----[ Albert Chu <address@hidden> ]
| P.S. There are a number of subtle authtype checks that need to be put
| into fill_hdr_sessino() and assemble_lan_packet() to handle this and
| pre-msg-authentication.  I will add that whenever i do this ... Also I
| think assemble_lan_packet() should return the length of the buffer
| written into the packet buffer.  The length will vary depending on the
| authentication type.
`----
Go ahead and try different auth types and make necessary changes.
Returning buffer-len in assemble_XXXX_pkt() makes sense too. Right now
its done using MACROs.

-- 
 _.|_ 
(_||_)
Free as in Freedom <www.gnu.org>




reply via email to

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