If this is true, then there's a more fundamental problem.  We see that
OpenIPMI is dropping incoming SendMessage payload responses because of an
address mismatch, specifically in the expected LUN.

DEBG: jas 0 outgoing seq 39
 addr = 02 00 02 6f c0 3d c9 a8 00 00 00 00 00 00 00 00
   00 00 00 00 00 00 00 00 00 00 00 00
 msg  = netfn=s/e(c):04 cmd=SetSensEvEna:28 data_len=6.
 data =
   06 00 ff 07 06 00 f8 27 f5 4d e4 03 00 00 15 00
   20 18 c8 81 9c 34 40 82 10 6e 20 9e 28 58 d0 40
   00 40 00 72 6f 
DEBG: incoming
 addr =  02 00 02 6f c0 3d c9 a8 00 00 00 00 00 00 00 00
 data =
   06 00 ff 07 06 00 01 00 00 00 3f 04 00 00 08 00
   81 1c 63 20 9c 34 00 10 
DEBG: incoming
 addr =  02 00 02 6f c0 3d c9 a8 00 00 00 00 00 00 00 00
 data =
   06 00 ff 07 06 00 01 00 00 00 40 04 00 00 08 00
   20 14 cc 82 9e 28 00 b8 
DEBG: Dropped message seq 39 - netfn/cmd/addr mismatch
 netfn     = 05, exp netfn = 05
 cmd       = 28, exp cmd   = 28
 addr      = 01 00 00 00 00 00 82 02
 exp addr= 01 00 00 00 00 00 82 00
 data     =
   20 14 cc 82 9e 28 00 b8 01 00 00 00 00 00 82 02

Should the expected LUN really be 0?  This would imply that the IPMI stack
is incorrectly handling the response message -- it should be changing the
original LUN from 2 to 0.  From the looks of things, the IPMI stack is
simply turning around the response using the LUN from the original request. 

> -----Original Message-----
> From: Corey Minyard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 8:01 AM
> To: Sievert, James A
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Openipmi-developer] Question about ipmi_format_msg()...
> 
> OpenIPMI is correct here, but the spec does not explain this very well.
> 
> A LUN of 0 means "deliver the message to the BMC". A LUN of 2 means
> "deliver the message to the software connected to the BMC".
> 
> The LUN in question on line 142 is the requester LUN on a message routed
> to IPMB, meaning that this is where it wants the remote BMC on the IPMB
> to return the response. Thus, it must be 2 to go back to the LAN. If it
> was 0, the message to be delivered to the BMC directly and not go out
> the LAN. The LUN on line 127 is the destination for the send message,
> which should be the BMC since it is the one that sends the message. The
> LUN on line 130 is meaningless, BTW.
> 
> -corey
> 
> Jim Sievert wrote:
> >
> > OpenIPMI-2.0.11, Function ipmi_format_msg, in file ipmi_payload.c,
> > line 142 reads as follows:
> >
> > tmsg[pos++] = (seq << 2) | 2; /* add 2 as the SMS LUN */
> >
> > Consider a SendMessage request being issued from a LAN channel. Given
> > such a request, the hard-coded LUN of 2 is incorrect.
> >
> > It's interesting that line 142 is coded using LUN 2 while line 127 is
> > coded using LUN 0:
> >
> > tmsg[pos++] = (IPMI_APP_NETFN << 2) | 0;
> >
> > It would seem that determining the correct LUN would be based on
> > channel from which the request originates. It's not clear to me that
> > such information is available.
> >
> > Any suggestions on a fix would be appreciated.
> >
> > Thanks.
> >
> > ------------------------------------------------------------------------
> >
> > ------------------------------------------------------------------------
> -
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Openipmi-developer mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/openipmi-developer
> >



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Openipmi-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Reply via email to