Re: [Ipmitool-devel] Questions regarding the lan interface implementation

[Duncan L. <du...@ic...>]

On Wed, 2004-04-14 at 11:08, Jeremy Ellington wrote:
> Hi,
> 
> I have some questions regarding the code implementing the LAN intferface
> in ipmitool.
> 
> 1) In ipmi_lan_activate_session(), I see a call to ipmi_lan_first() if
> "pedantic" is set.  This causes some mystery bytes to be sent over the
> wire before the real communication starts.  Can someone point me at
> relevant spec section so that I can understand why this is here?
> 

This was put in after I observed Intel's software sending these extra
packets while examining a network trace.  Surprisingly it seems to be
pretty effective getting certain BMCs on certain Intel boards to behave
better.  Its definately not part of any spec that I know of which is why
its only used if you specify -g on the command line.

FWIW recent versions of Ethereal (>0.9.12) can decode IPMI packets and
is useful if you're doing any debugging/testing of IPMI-over-LAN
interfaces.

> 2) ipmi_lan_activate_session() calls ipmi_get_auth_capabilities_cmd()
> twice, allowing it to possibly fail the first time.  Seems like a
> workaround for a BMC-specific issue.  Can you confirm this?
> 

Since the Get Authentication Capabilities is the first command in the
activation sequence it is not always received and answered in a timely
matter.  Often this happens if the box is off and the BMC is unable to
respond to ARP requests by itself.  In this case it is usually sending a
Gratuitous ARP every X seconds, but a local ARP cache is not always
populated until a request is sent.  With a reasonable interval between
gratuitous arps it is not uncommon for this first request to fail.

In theory it should send an RMCP ping first, but I have this commented
out right now because I have seen a BMC that not only does not answer
RMCP pings (this is allowed) but actually gets confused when it receives
one!

> 3) This question is about privilege levels in v1.5 sessions, and has 2 parts.
> A) It appears that IPMI tool only supports connecting as ADMIN level
> users. Is this correct?

Yep, though it shouldn't be hard to change it to allow the user to
specify on the command line.  Much of what ipmitool does should be
allowed at USER level, only a few things such as setting up LAN
configuration need to be ADMIN level.  (it could also be argued that
this shouldn't be done over lan anyway...)

A quick test after changing the level to USER showed that indeed most
things do work fine at this level.  Perhaps it would be best to default
to USER and only request ADMIN level if the user forces it?

> B) From reading the  Activate Session Command documentation (section
> 18.15) of the v1.5 spec, it appears that the user has to have
> foreknowledge of his privilege level before he attemtps to connect.  For
> you have to specify your privilege level in the Activate Session command
> (huh?), and if you specify a privilege level higher than allowed [for you
> or the channel], the command fails.  It seems as if the interface library
> should make multiple calls to activate session, in order to establish a
> session at the highest allowable privilege level.
> 

Since you have to specify privilege level in both the Get Channel Auth
and Activate Session commands you could keep re-sending the Get Channel
Auth with different levels till you get a response you're satisfied with
and proceed to activate the session with it.  Its also worth pointing
out that all of this specifying privilege level in these commands
doesn't actually make your session start out at the level you requested,
they all start at USER and you have to (once again) set it to the level
you want with Set Session Privlvl command.

-duncan