To know if a message is waiting in the asyncronous queue, the interface will generally set some flag so that the user may immediately know. The software will then send a Get Message Flags command (table 3.6) to know find out what is up. A bit will be set in the response to tell it something is in the queue.
Request - Response 0
Completion code Flags. The bits are:
0 1 2 3 4 5 6 7
message(s) in the receive message queue.
Event message buffer is full
Table 3.6: Get Message Flags Command, NetFN App (06h), Cmd 31h
Interface to IPMB
For bridging from a system interface to IPMB, format an IPMB message as described in section 3.5 and set the requester LUN to 2. Then issue a Send Message command with the IPMB message as the data to the proper IPMB channel; the message will be routed out onto the IPMB bus.
The response will come back to the MC with the requester LUN set to 2. This will route the message back to the system interface, where it will be put into the receive message queue. The software running on the system must receive the message from the queue using the Get Message command described in section 3.4.4.
The response data will be in the same IPMB format.
LAN to IPMB Bridging
Unfortunately, the description in the spec of the LAN protocol is very confusing. An errata was introduced that, instead of clearing things up, added another possibile interpretation. Four popular interpretations are common. Fortunately, one piece of software can be written to work with three of these possibilities, and the fourth possibility is rather broken. The three main possibilities are:
Response comes back in the Send Message response
Separate Send Message and IPMB responses
Separate Send Message and Translated responses
One might also infer from the spec that you implement the receive message queue on the LAN interface and poll it with the Get Message command. It is yet another possible interpretation, but the side effects of this are very bad. This will not be discussed any more.