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
