Z,
This change will make ipmitool work as it is currently documented so no new 
documentation is required.

The current ipmitool man page for -m <local_address> and -t <target_address> is 
as follows:
    -m <local_address>
               Set  the  local  IPMB  address.   The  default is 0x20 and there
               should be no need to change it for normal operation.
-t <target_address>
               Bridge IPMI requests to the remote target address.

The current man page documentation indicates that to bridge requests you need 
to specify -t, and if you
want to specify a local IPMB address different than 0x20 you use -m.

The proposed code change is to make -m do what the documentation states.
Note: The code change will only change ipmitools behavior when -m is specified 
without -t.

With the code as currently written, specification of -m 0x34 will cause 
bridging from 0x20 to 0x34.  This
is not what the man page states.   Note that people have learned they can work 
around the unwanted
bridging by specifying the the exact same local IPMB address for both -m and 
-t.    The change below will
not change the current behavior when both -m and -t are specified.

With the proposed change below, specification of -m 0x34 will access the local 
IPMB using address 0x34 (no
bridging).  This is what the man page says it should do.


 From f8f354de4c4e1910acafc697915ecf2731c41af8 Mon Sep 17 00:00:00 2001
From: Jim Mankovich <jm...@hp.com>
Date: Wed, 27 Feb 2013 07:31:41 -0700
Subject: [PATCH] only bridge when -t specified

---
  ipmitool/src/plugins/open/open.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipmitool/src/plugins/open/open.c b/ipmitool/src/plugins/open/open.c
index 6accb9e..729afe9 100644
--- a/ipmitool/src/plugins/open/open.c
+++ b/ipmitool/src/plugins/open/open.c
@@ -384,5 +384,5 @@ struct ipmi_intf ipmi_open_intf = {
      close:        ipmi_openipmi_close,
      sendrecv:    ipmi_openipmi_send_cmd,
      my_addr:    IPMI_BMC_SLAVE_ADDR,
-    target_addr:    IPMI_BMC_SLAVE_ADDR,
+    target_addr:    0, /* init so -m local_addr does not cause bridging */
  };
-- 
1.7.9.5


-- Jim Mankovich | jm...@hp.com (MST) --

On 2/27/2013 5:26 AM, Zdenek Styblik wrote:
> Jim,
>
> I have two questions for you.
> 1] can you post a diff of changes?
> 2] Is there any plan to document(= real use example?) this "feature"
> or how it works? Also, perhaps document change in behaviour as well?
> Perhaps, it's done already. This feature is already documented, I
> mean, not the changes.
>
> Thanks,
> Z.
>
> On Tue, Feb 26, 2013 at 10:58 PM, Jim Mankovich <jm...@hp.com> wrote:
>> All,
>> If anyone has an objection to my proposed change to have -m <local_address> 
>> be all that is
>> necessary to modify the local IPMB address, let me know by the end of the 
>> week.
>>
>> With the code as currently written, you have to specify both -m 
>> <local_address> and
>> -t <target_address> with both local_address and target_address set to the  
>> exact same IPMB
>> address to actually accomplish setting only the local IPMB address.
>>
>> Thanks,
>> Jim
>>
>> -- Jim Mankovich | jm...@hp.com --
>>
>> On 2/20/2013 7:41 AM, Jim Mankovich wrote:
>>> Corey,
>>>
>>> When you specify -m 0x54 and -t 0x54 on the ipmitool command line,  the 
>>> message will
>>> be correctly routed to the local MC.    But, if you only specify -m 0x54, 
>>> the message will
>>> be bridged to 0x20 from 0x54 because the default target address in the 
>>> OpenIPMI interface
>>> in ipmptool is set to a default of 0x20 instead of zero. This bridging to 
>>> 0x20 from 0x54
>>> when you only specify -m 0x54 on the command line has caused confusion for 
>>> more than
>>> one person.
>>>
>>> -- Jim Mankovich | jm...@hp.com --
>>>
>>> On 2/19/2013 5:59 PM, Corey Minyard wrote:
>>>> So you are saying that if you set the local address to, say -m 0x54, and
>>>> then send a messages with -t 0x54, it will not route it to the local MC,
>>>> and the message just gets lost?  That may be the case, I'm not that
>>>> familiar with ipmitool.  One would expect that would work properly, but
>>>> the driver does not catch this (perhaps it should) and perhaps ipmitool
>>>> doesn't (perhaps it should).  The openipmi library does do this.
>>>>
>>>> Am I correct?
>>>>
>>>> -corey
>>>>
>>>> On 02/19/2013 03:43 PM, Jim Mankovich wrote:
>>>>> All,
>>>>>
>>>>> I recently discovered that the in band ipmitool OpenIPMI Interface did 
>>>>> now work as I
>>>>> expected when I attempted to specify different local IPMB address via the 
>>>>> -m switch.
>>>>>
>>>>> My expectation was that local system interface would be used with the 
>>>>> address I
>>>>> specified on the command line, but instead ipmitool attempted to bridge 
>>>>> my request because
>>>>> the interface target address was 0x20 and my specified address via -m was 
>>>>> not 0x20.   I tracked
>>>>> the issue down to the fact that bridging will occur in the OpenIPMI 
>>>>> interface whenever there
>>>>> is a non zero target address and the target address is not equal to the 
>>>>> interface address.  I
>>>>> believe this logic is reasonable, but I think the intent was that the 
>>>>> target address would always
>>>>> be zero unless it was specified on the command line with the -t option 
>>>>> (in which case you want
>>>>> bridging).    The problem I am seeing crops up because the OpenIPMI 
>>>>> interface in ipmitool initializes
>>>>> both the target address and the interface address to 0x20 instead of only 
>>>>> initializing the interface
>>>>> address to 0x20 and setting the target address to zero.  Does anyone 
>>>>> happen to know whether my
>>>>> interpretation of intended usages for -m and -t are correct?
>>>>>
>>>>> Thanks in Advance,
>>>>> Jim
>>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>>> _______________________________________________
>>>> Ipmitool-devel mailing list
>>>> Ipmitool-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_feb
>>> _______________________________________________
>>> Ipmitool-devel mailing list
>>> Ipmitool-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Ipmitool-devel mailing list
>> Ipmitool-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to