Re: [Freeipmi-devel] Different LAN authentication support checked in

[Albert Chu]

> Do you think you can add your MDx option here?. You can take extra 
> args if needed?

It can be added.  All I need to do is add a auth_code_len parameter. 
I'll add it ... 

I assume I'll end up breaking fish if I do this??

> I am still not completely convinced to modify fiid_obj_t as
> struct. Keeping it as simple byte array gives lot of flexibility. How
> ever on the other side, number of arguments passed are reduced.

I guess my primary problem is with functions like

assemble_ipmi_lan_pkt (fiid_obj_t obj_hdr_rmcp, fiid_obj_t
obj_hdr_session, fiid_template_t tmpl_hdr_session, fiid_obj_t
obj_msg_hdr, fiid_obj_t obj_cmd, fiid_template_t tmpl_cmd, u_int8_t
*pkt, u_int32_t pkt_len)

Here, you pass in obj_hdr_rmcp and obj_msg_hdr without any information
on the length of the buffer.  If we don't have a length stored within
the fiid_obj_t pointer, then perhaps we should force passing a template
everywhere.

> What about daemon services, like Jim pointed out?

True.  As I have continued programming, I am beginning to wonder if we
should move to having a "freeipmi-errno" set of error codes rather than
just setting the libc errno.  There are situations I've found that there
is no appropriate errno to return to the user.  
 
Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Monday, February 23, 2004 5:24 pm
Subject: Re: [Freeipmi-devel] Different LAN  authentication support
checked in

> ,----[ Albert Chu <address@hidden> ]
> | Hey everyone,
> | 
> | Major modifications throughout to add support for varying
> | authentication types, including none, md2, and md5.  I have done
> | limited testing with md2/md5, so I'm not sure how much of it 
> works at
> | this time, but the normal password authentication still works.
> | 
> | Note that ipmi_lan_cmd() (and those functions that depend on it) now
> | only supports password or no authentication.  Md2 or Md5 just don't
> | make any sense for these functions.
> `----
> In the past I had ipmi_lan_cmd and ipmi_lan_cmd_auth separately. I
> then merged them together and added
> 
>  if (auth_type == IPMI_SESSION_AUTH_TYPE_NONE)
>    tmpl_hdr_session_ptr = &tmpl_hdr_session;
>  else if (auth_type == IPMI_SESSION_AUTH_TYPE_STRAIGHT_PASSWD_KEY)
>    tmpl_hdr_session_ptr = &tmpl_hdr_session_auth;
>  else
>    {
>      errno = EINVAL;
>      return (-1);
>    }
> 
> 
> Do you think you can add your MDx option here?. You can take extra 
> args if needed?
> 
> Or lets propose a new interface.
> 
> ,----[ Albert Chu <address@hidden> ]
> | - debugging prefixes
> `----
> You can extended fiid_obj_dump to fiid_obj_dump_XXXX.
> 
> ,----[ Albert Chu <address@hidden> ]
> | - Need to add dumping for lan packets
> `----
> Something like this?
> 
> fiid_lan_pkt_dump (u_int8_t *pkt, u_int32_t pkt_len, 
>                  fiid_template_t tmpl_hdr_session, 
>                  fiid_template_t tmpl_cmd);
> 
> Indices into *pkt can be calculated internally by using
> fiid_obj_len_bytes () of tmpl_hdr_session, tmpl_lan_msg_hdr_rq,
> tmpl_hdr_session, tmpl_cmd, tmpl_lan_msg_trlr.
> 
> ,----[ Albert Chu <address@hidden> ]
> | - auth_code check code, for all authentication types.  Maybe other
> | checking type code.  I dunno.
> `----
> There are lot of field type checking to be done. They some times
> appear redundant or unnecessary. We can do this before official 0.1.0
> release.
> ,----[ Albert Chu <address@hidden> ]
> | 
> | Handful of thoughts/ideas while working with the new fiid library.
> | 
> | 1) At some point in the future, I believe we should alter the the
> | fiid_obj_t and fiid_template_t types.  There are just too many 
> corner| cases that can be hit in the library right now.
> `----
> I am still not completely convinced to modify fiid_obj_t as
> struct. Keeping it as simple byte array gives lot of flexibility. How
> ever on the other side, number of arguments passed are reduced.
> 
> We will get a better understanding between 0.1.0 and 0.2.0 official
> releases.
> 
> ,----[ Albert Chu <address@hidden> ]
> | 2) I added an "ERR_EXIT" macro to ipmi-error.h.  I believe we 
> needed a
> | "fatal-error" exit routine for very very bad internal errors.
> `----
> What about daemon services, like Jim pointed out?
> 
> I have new features in queue for FreeIPMI project. I will start
> adding them after bmc-config and sensors are officially
> accepted by LLNL.
> 
> bmc-config and sensors are already put to use/testing under Xeon 32-
> bit and
> IA64 platform by some of our other customers.
> 
> Both Joe and Doug already started using Savannah online features like
> Bug tracking, Support, Patch... systems.
> 
> Happy Hacking,
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
>