Hello, Jim,
MC Device Locator is a mandatory record for PICMG systems. And this is
where the slave address of the controller is got for comparison.
For systems that do not provide MC Locators, the default IPMITool
behavior (as it is currently implemented) could be retained.
Regards,
Dmitry
12.09.2012 20:00, Jim Mankovich пишет:
> Hi Dmitry,
>
> Where does the slave address of the target IPMC on a PICMG system come
> from that
> you will be using to compare against the sensor owner to determine
> bridging is not necessary?
>
> FYI: Not all platforms contain an MC Device Locator and some platforms
> contain more than one.
>
> Thanks in Advance,
> Jim
>
> -- Jim Mankovich | jm...@hp.com (MST) --
>
> On 9/10/2012 1:48 AM, Dmitry Bazhenov wrote:
>> Hello, Jim,
>>
>> Thanks for you comments.
>>
>> The thing is that when doing "sdr" and "sensor" command against PICMG
>> systems, IPMITool tries to bridge sensor commands to another channel
>> (primary IPMB) instead of just sending them directly to IPMC.
>>
>> This is because PICMG IPMCs have slave addresses different from 20h on
>> IPMB-0, but still have 20h for LAN access.
>>
>> Nevertheless, I agree that the proposed workaround might break the
>> sensor reading for some useful cases.
>>
>> After some thinking I have come to a conclusion, that IPMITool shall
>> read the Management Controller Device Locator record to get the IPMB-0
>> slave address of the controller before sending sensor commands.
>> If the slave address of the target IPMC is the same as the sensor
>> owner, than bridging shall not be used, and vice versa.
>>
>> There should be also a restriction for the case when the target IPMC
>> is already accessed via double bridging. In this case, if sensors
>> reside on another IPMC and the access channel is not the same as to
>> access target IPMC, they can be inaccessible since triple bridging is
>> impossible. IPMITool shall also send Get Channel Info command to the
>> target IPMC to check this.
>>
>> I'll come up with the updates soon.
>>
>> Regards,
>> Dmitry
>>
>> 07.09.2012 22:29, Jim Mankovich пишет:
>>> Dimitry,
>>>
>>> I took at look at your bugfix patch and found that it has a dependency
>>> on your 4th patch. This needs to be resolved. Each of these patches
>>> should be able to be be applied independently, even if a later patch
>>> depends
>>> on a prior patch already having been applied.
>>>
>>> I would like to understand why you want to inhibit bridging sensor
>>> requests
>>> more than one level. You mention in your comment that it is a
>>> workaround for
>>> PICMG systems, but the change is not specific to PICMG systems. Won't
>>> this
>>> cause problems on systems that support more than a single level of
>>> bridging?
>>> I no expert on how IPMI bridging works, but the code as written
>>> (before your
>>> change) would support multiple levels of bridging.
>>>
>>> Also, I don't believe the save/restore logic you are using will work
>>> correctly if you
>>> are actually bridging to a different target address. Your logic is as
>>> follow:
>>>
>>> if (intf->target_addr == intf->my_addr) {
>>> save_addr = intf->target_addr;
>>> intf->target_addr = target;
>>> save_channel = intf->target_channel;
>>> intf->target_channel = channel;
>>> }
>>> ..... (sendrecv) ...
>>>
>>> if (intf->target_addr == intf->my_addr) {
>>> intf->target_addr = save_addr;
>>> intf->target_channel = save_channel;
>>> }
>>>
>>> If the intf->target_addr is changed to a value different than
>>> intf->my_addr in the
>>> first if block, then the restore will never happen in the second if
>>> block. This is because
>>> when you get to the second if, intf->target_addr won't equal
>>> intf->my_addr anymore so
>>> the intf restore of target_addr/target_channel won't happen.
>>>
>>> -- Jim Mankovich |jm...@hp.com (MST) --
>>>
>>> On 9/7/2012 6:31 AM, Dmitry Bazhenov wrote:
>>>> Hello, IPMITool maintainers,
>>>>
>>>> On behalf of Pigeon Point Systems company,
>>>> I would like to contribute the following patches which contains
>>>> IPMITool bug-fixes and some new functionality.
>>>>
>>>> Below is the description for the attached patches:
>>>>
>>>> 1. pps-bugfixes.diff:
>>>> o lib/ipmi_sel.c
>>>> - zero data before making request to avoid reading of
>>>> uninitialized
>>>> data
>>>> o lib/ipmi_mc.c
>>>> - do not print AUX info, if IPMC return 12-byte Get Device ID
>>>> response
>>>> o lib/ipmi_sdr.c
>>>> - do not bridge sensor requests when interface bridging is already
>>>> used. Is workaround for PICMG systems (ATCA/MicroTCA).
>>>> o lib/ipmi_picmg.c
>>>> - add support for hexadecimal and octal formats for the
>>>> command-line
>>>> parameters
>>>> o configure.in
>>>> - fixed build for the newer autotool releases
>>>> - fixed cross-compilation
>>>> 2. pps-oem.diff
>>>> o Add support for PPS H8 evaluation board BMC which contains Intel
>>>> 82751 GbE MAC. RMCP+ support for this MAC controller has several
>>>> deviations.
>>>> 3. pps-sol-instance.diff
>>>> o Add support for SOL instances other than 1.
>>>> 4. pps-long-packets.diff
>>>> o Add support for HPM.2 compliant long packets. The
>>>> implementation is
>>>> made against the HPM.2 0.9.2 draft specification, and requires
>>>> update for the HPM.2 1.0 release version. Pigeon Point Systems is
>>>> going to provide the update later.
>>>> o HPM.1 upgrade and FRU Inventory commands were modified to reuse
>>>> the
>>>> long packet support.
>>>> o Access to FRU inventory devices with the length restrictions is
>>>> made as a command-line option.
>>>> o Kontron OEM large packet support is now optional and enabled by
>>>> the
>>>> corresponding OEM command-line parameter.
>>>> 5. pps-serial-drivers.diff
>>>> o Add support for Terminal Mode and Basic Mode direct serial
>>>> drivers.
>>>>
>>>> The patches with greater numbers depend on patches with lesser numbers
>>>> and must be applied in the ascending order.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>
>>>>
>>>> _______________________________________________
>>>> Ipmitool-devel mailing list
>>>> Ipmitool-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>>>
>>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
