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
>>>
>>>
>
>
-------------------------------------------------------------------------
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
