I appreciate the information, Corey. We'll make another change to the stack.
Thanks again. > -----Original Message----- > From: Corey Minyard [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 12, 2007 10:59 AM > To: Sievert, James A > Cc: [EMAIL PROTECTED] > Subject: Re: [Openipmi-developer] Question about ipmi_format_msg()... > > Yes, still a problem. > > The outgoing IPMB header is: > > 82 10 6e 20 9e 28 > > > The incoming LAN header is: > > 20 14 cc 82 9e 28 > > You need to swap the LUNs in the response. The first LUN (rsLUN) in the > outgoing message (the request) is 0, the second LUN (rqLUN) is 2. That > means the first LUN (rqLUN) in the incoming message (the response) > should be 2 and the second LUN (rsLUN) should be 0. See section 13.8 > (IPMI LAN Mesage Format) of the 2.0 spec for details. I know, this is > confusing the way the rqLUN and rsLUN are switched around, but the > formatting changes depending on whether the NetFN is odd or even. > > However, just to confuse things even more, this is incorrect due to an > errata issued to the IPMI spec. See the clarification named "Section > 6.12.4, Bridged Request Example" to the IPMI 1.5 spec, or carefully read > section 6.13.4 of the IPMI 2.0 spec. The LAN header for the incoming > IPMB message is supposed to be the same one as for the original LAN > message. Most older systems work as you are doing it, putting the IPMB > header in there. But that's not actually the way it is supposed to work. > > -Corey > > Jim Sievert wrote: > > 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 > >>> > >>> > > > >
<<attachment: winmail.dat>>
------------------------------------------------------------------------- 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
