Ok Jim, sounds good to me.
Thanks,
Z.
--
Zdenek Styblik
email: zdenek.styb...@gmail.com
jabber: zdenek.styb...@gmail.com
On Wed, Feb 27, 2013 at 7:14 PM, Jim Mankovich <jm...@hp.com> wrote:
> 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
