Ah, that is a completely different story. This does work with recent versions of OpenIPMI, but it works only because the "send message" command on the IPMCs wisely handles this completely different than the shelf manager.
In your example, you can send a "send message" command to IPMC1 with the AMC's IPMB address as the destination. The IPMC will receive the send message, handle converting the sequence numbers, send it to the AMC, wait for the response, and send once response back. So you could do: mc msg s(0.86) 0 6 0x34 0x47 0x72 0x18 <csum1> 0x20 0x00 1 <csum2> and it should work. It will be wrapped in the send message response. See the AMC spec for more details. I need to add this as a FAQ.... -Corey Wenqiang Song wrote: >I didn't want to. But I thought I have to. The box I use is an Intel >Wainwright, which hosts two of my AMC modules that I want to send >messages to. It looks like this: > IPMB-L >OpenIPMI--------ShMC-------IPMC1--------MMC1 > LAN IPMB-0 | > |---------MMC2 > IPMB-L > >I want to send messages to MMC1 and MMC2 which are located on IPMB-L on >the ATCA board controlled by IPMC1 whose slave address on IPMB-0 is >0x86. > >OpenIPMI can't see MMC1 and MMC2 as mc. They are recognized as FRUs by >OpenIPMI. This is fine. But the problem here is that OpenIPMI doesn't >know the existence of IPMB-L. So I can't send message to MMC1 and MMC2 >without explicitly compose a "send message" command and send it to >IPMC1. > >Here the messages need to be bridged twice. Sine OpenIPMI doesn't know >there is an IPMB-L if I give it the slave address of MMC1, say 0x7a, it >will(my guess) assume this address belongs to IPMB-0 and compose a "send >message" and send it to ShMC. That's it. But what I need here is a >two-level nested "send message". > >Thanks >Wen > > >-----Original Message----- >From: Corey Minyard [mailto:[EMAIL PROTECTED] >Sent: Monday, April 03, 2006 9:09 PM >To: Wenqiang Song >Cc: [email protected] >Subject: Re: [Openipmi-developer] Question about the way that OpenIPMI >handles "send message" command > >OpenIPMI does not look into a message to see if it is a "send message". >It only does the special handling if you send it directly to the MC in >question. > >There are problems with doing it any other way. The sequence numbers >have to be assigned by a single place. If you have multiple senders, >you have to coordinate sequence numbers or things could get confused. > >My question is: "Why would you want to do this?" If you want to send >directly to an IPMB address, you are much better off using the >ipmi_send_command_addr() function, or "domain msg" in openipmish. > >-Corey > >Wenqiang Song wrote: > > > >>Hi, >> >>I'm having a problem when composing a "send message" command manually >> >> >>from openimpish command line. > > >>The configuration of my system is like: >>mc list >>Domain >> Name: s >> MCs >> Name: s(0.82) >> Name: s(0.86) >> Name: s(0.20) >> >>s(0.20) is the BMC. The other two are IPMCs on IPMB-0. I connect to the >>system through LAN interface. >> >>If I issue a command >>"mc msg s(0.86) 0 6 1 " >>It runs OK. OpenIPMI composes a "send message" command and sends it to >>mc s(0.86) through BMC which is s(0.20). But, if I issue a command >>"mc msg s(0.20) 0 6 0x34 0x40 0x86 0x18 0x62 0x20 0xc2 1 0x1d" >>which is essentially the same thing as the previous one, just that the >>sequence number is different. This time I get an error message "Dropped >>message seq 3 - netfn/cmd/addr mismatch". >> >>Here is the backtrace: >>(tgdb) bt >>#0 ipmi_handle_recv (ipmi=0x0, rspi=0x8102a60, orig_addr=0x8076264, >>orig_addr_len=8, orig_msg=0x807 >>6290, data=0xbfe7ec8e "\201\034c \001", data_len=23) at >>ipmi_payload.c:365 >>#1 0xb7ef7ed4 in handle_payload (ipmi=0x8071290, lan=0x80737c8, >>addr_num=0, payload_type=0, tmsg=0x >>bfe7ec8e "\201\034c \001", payload_len=23) at ipmi_lan.c:2916 >>#2 0xb7ef8bcf in handle_lan15_recv (ipmi=0x8071290, lan=0x80737c8, >>addr_num=0, data=0xbfe7ec70 "\00 >>6", len=0) at ipmi_lan.c:3280 >>#3 0xb7ef93eb in data_handler (fd=125, cb_data=0x8071370, >> >> >id=0x8071428) > > >>at ipmi_lan.c:3480 >>#4 0xb7e381ed in fd_handler (fd=125, data=0x7d) at posix_os_hnd.c:87 >>#5 0xb7e3a09d in process_fds (sel=0x80650d0, send_sig=0, thread_id=0, >>cb_data=0x0, timeout=0xbfe7ef >>a8) at selector.c:604 >>#6 0xb7e3a26b in sel_select (sel=0x80650d0, send_sig=0x7d, >> >> >thread_id=0, > > >>cb_data=0x7d, timeout=0x0) >>at selector.c:694 >>#7 0xb7e388ad in perform_one_op (os_hnd=0x7d, timeout=0x7d) at >>posix_os_hnd.c:357 >>#8 0x0804ba64 in main (argc=1, argv=0xbfe7f0c4) at ipmish.c:1046 >> >>The debug output is: >>DEBG: Dropped message seq 48 - netfn/cmd/addr mismatch >>netfn = 07, exp netfn = 07 >>cmd = 01, exp cmd = 34 >> >>Is that true that OpenIPMI doesn't look into a "send message" command >> >> >if > > >>this command is composed by the user not OpenIPMI itself? So when the >>response to the command embedded in "send message" command comes back, >>OpenIPMI will match it with the "send message", which is the original >>message in this scenario, and gets mismatch. But if the "send message" >>command is composed by OpenIPMI it will store the command the user >>provides as the original message and get a match when the response >> >> >comes > > >>back. >> >>Any comments? >> >>For limitations on the use and distribution of this message, please >> >> >visit www.sbs.com/emaildisclaimer. > > >>------------------------------------------------------- >>This SF.Net email is sponsored by xPML, a groundbreaking scripting >> >> >language > > >>that extends applications into web and mobile media. Attend the live >> >> >webcast > > >>and join the prime developer group breaking into this new coding >> >> >territory! > > >>http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >>_______________________________________________ >>Openipmi-developer mailing list >>[email protected] >>https://lists.sourceforge.net/lists/listinfo/openipmi-developer >> >> >> >> > > >***This message has been scanned for virus, spam, and undesirable >content.*** >***For further information, contact your mail administrator.*** > >For limitations on the use and distribution of this message, please visit >www.sbs.com/emaildisclaimer. > > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
