[Ipmitool-devel] ipmitool bridging on PICMG systems

Hello, Jim,

Your understanding is correct. Moreover, we already have a patch which
solves the issue (in our local IPMITool repo). We are going to submit
the patch for this issue shortly.

And to the topic raised.

The sensor owner ID in the SDR in my opinion shall match with the IPMC
slave address on the primary IPMB bus (channel #0).

Since there are cases when the IPMC accessed from other channels (than
channel #0), like LAN, the slave address of the IPMC on that channel may
not match with the primary IPMB address.

We solved this problem as follows:
- introduced a BMC address which can be overridden by "-m" command-line
parameter (default valuse is 20h). This address is used to access the
IPMC on which a session to establish a session (for LAN).
- then using Get PICMG Properties to check whether the board is a
PICMG-based system.
- use either Get Address Info for FRU #0 or fetch the Management
Controller Locator Record to query the IPMC slave address on the primary
IPMB.
- store the fetched slave address. it then used to match the sensor
owner ID to decide if the bridging to sensor is required on not.
- for the case when bridging is used, the stored slave address is used
to compose the Send Message command is return address.

Regards,
Dmitry

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool bridging on a PICMG
system and I wouldappreciate some help with understanding what the actual intended
use of the bridging command line arguments was. There are two different bridging
argument specifications, -t target_address/-b target_channel (single bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read the SDR repository
if the address specified by -t is not equivalent to the ipmitool identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of 0x20, or specified
on the command line via the -m address switch, or discovered via PICMG get address
info.
In addition to -t, you may also specify a transit address via -T.If a transit address is
specified, dual bridging will be used to read the SDR repository(via the transit address
to get to the target identified via -t). The specification of a transit address without a
target address is meaningless as the transit address is not used unless there is a target
address specification with -t.
Does my description agree with your understanding of these switches and their use?
Now, in addition to bridging to read the SDR repository, bridging will also occur to access
an individual sensor if the sensor owner id identified in the SDR repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have been using when
addressing sensors whose owner id and channel specification in the SDR repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7), the sensor can't
be accessed with the current code because the sensor will be addressed via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR repository, the bridged SDR
repository destination may actually identify another IPMB-0 at the bridged destination.
If this is the case, then the sensor can simply be read using the same bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor owner id/channel
number from the SDR repository.If the sensor owner id is equal to the target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar with PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Jim Mankovich

2013-04-15 17:12:13 UTC

Hi Dmitry,

I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a patch I've
been using to resolve the issue I was having and would appreciate any feedback you
might have on my approach. The patch is for the CVS ipmitool source code at TOB
this morning.

I changed ipmi_main() to always open the interface using either 0x20 or the address
specified with the "-m" switch. With the code as it exists today, open is sometimes
done in main and sometimes done when the first IPMI request is made. I found the
defer of the open quire problematic, so I changed the code to always do the open prior
to the first IPMI request. After the initial open, I use the PICMG get address info to
get the IPMB-0 address. If I was able to discover an address, I close and re-open
the interface with the discovered IPMB-0 address as I found this was necessary to make
sure that the open ipmi driver had the correct address of the target IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address and store that away to
determine when bridging is necessary for sensors identified in the SDR repository accessed via
the bridging command line arguments.

Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your understanding is correct. Moreover, we already have a patch which
solves the issue (in our local IPMITool repo). We are going to submit
the patch for this issue shortly.
And to the topic raised.
The sensor owner ID in the SDR in my opinion shall match with the IPMC
slave address on the primary IPMB bus (channel #0).
Since there are cases when the IPMC accessed from other channels (than
channel #0), like LAN, the slave address of the IPMC on that channel may
not match with the primary IPMB address.
- introduced a BMC address which can be overridden by "-m" command-line
parameter (default valuse is 20h). This address is used to access the
IPMC on which a session to establish a session (for LAN).
- then using Get PICMG Properties to check whether the board is a
PICMG-based system.
- use either Get Address Info for FRU #0 or fetch the Management
Controller Locator Record to query the IPMC slave address on the primary
IPMB.
- store the fetched slave address. it then used to match the sensor
owner ID to decide if the bridging to sensor is required on not.
- for the case when bridging is used, the stored slave address is used
to compose the Send Message command is return address.
Regards,
Dmitry

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool bridging on a PICMG
system and I wouldappreciate some help with understanding what the actual intended
use of the bridging command line arguments was. There are two different bridging
argument specifications, -t target_address/-b target_channel (single bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of 0x20, or specified
on the command line via the -m address switch, or discovered via PICMG get address
info.
In addition to -t, you may also specify a transit address via -T.If a transit address is
specified, dual bridging will be used to read the SDR repository(via the transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless there is a target
address specification with -t.
Does my description agree with your understanding of these switches and their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have been using when
addressing sensors whose owner id and channel specification in the SDR repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7), the sensor can't
be accessed with the current code because the sensor will be addressed via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR repository, the bridged SDR
repository destination may actually identify another IPMB-0 at the bridged destination.
If this is the case, then the sensor can simply be read using the same bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor owner id/channel
number from the SDR repository.If the sensor owner id is equal to the target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar with PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Dmitry Bazhenov

2013-04-16 05:01:30 UTC

Hello, Jim,

Your approach has technical and logical flaws.

In technical part, all interface drivers shall be ensured to use correct
IPMB address when establishing or closing session/interface. This
especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired address
must be used in sensor owner ID comparison to decide if bridging is
required or not. It might be, if double bridging is used to access the
target IPMC, that sensor values are unreachable.
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a patch I've
been using to resolve the issue I was having and would appreciate any feedback you
might have on my approach. The patch is for the CVS ipmitool source code at TOB
this morning.
I changed ipmi_main() to always open the interface using either 0x20 or the address
specified with the "-m" switch. With the code as it exists today, open is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do the open prior
to the first IPMI request. After the initial open, I use the PICMG get address info to
get the IPMB-0 address. If I was able to discover an address, I close and re-open
the interface with the discovered IPMB-0 address as I found this was necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool bridging on a PICMG
system and I wouldappreciate some help with understanding what the actual intended
use of the bridging command line arguments was. There are two different bridging
argument specifications, -t target_address/-b target_channel (single bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches and their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have been using when
addressing sensors whose owner id and channel specification in the SDR repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR repository, the bridged SDR
repository destination may actually identify another IPMB-0 at the bridged destination.
If this is the case, then the sensor can simply be read using the same bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor owner id/channel
number from the SDR repository.If the sensor owner id is equal to the target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar with PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Jim Mankovich

2013-04-16 20:21:34 UTC

Dmitry,

See my comments below.

Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use correct IPMB address when establishing or closing session/interface. This especially regards to LAN and LAN+ drivers. Since some library functionality may close and re-open the interface during its work (as does HPM.1), this may cause problems. Also, a correct address must be used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct IPMB when establishing or closing session/interface. But, I did need to close/re-open to connect to the discovered IPMB address when I ran across the issue with OpenIPMI. See my answer to your specific question associated with OpenIPMI below.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address retrieval procedure not only on the IPMC on which the interface was opened, but on the target IPMC as well. And the second acquired address must be used in sensor owner ID comparison to decide if bridging is required or not. It might be, if double bridging is used to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for bridging was my intent with the change I made. Did you see something that indicated this was not what I was doing? Also, the channel number has to be used in the comparison as well since it is part of addressing identified in the sensor entries in the SDR repository.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use the Get Address Info command for the target IPMC address retrieval. It is better to fetch the Management Controller Locator record instead (implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it possible that there could be more than one Management Controller Locator record in the target SDR repository? If there can be more than one, how do you know which one to use?

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set another IPMC address without closing and re-opening interface? Other interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid the close/re-open. Did your fix to resolve bridging issues work correctly with OpenIPMI?

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool bridging on a PICMG
system and I wouldappreciate some help with understanding what the actual intended
use of the bridging command line arguments was. There are two different bridging
argument specifications, -t target_address/-b target_channel (single bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches and their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have been using when
addressing sensors whose owner id and channel specification in the SDR repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR repository, the bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor owner id/channel
number from the SDR repository.If the sensor owner id is equal to the target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar with PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Hank Bruning

2013-04-17 01:48:38 UTC

Jim, Dmitry,

You are getting into a gray area of IPMI. SDR's allow a single channel but
IPM Controllers allows multiple IPMI Buses, each with their own channel.

Management Controller Locator Record do not have a provision for which IPMI
channel is perfered or active(in the case where there are redundant IPMB
buses which are not the round robin PICMG IPMI-A, IPMI-B on a single
channel).

I don't know how you are going to resolve this without using information
that is vendor specific. But there might be a way.
If you come up with an answer, I'll be happy to add it to our ipmitool
equivalent that is in Java(Our Hemi software).
Hank Bruning
JBlade

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use correct

IPMB address when establishing or closing session/interface. This
especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as does
HPM.1), this may cause problems. Also, a correct address must be used for
bridging (when composing a Send Message request).
I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need to
close/re-open to connect to the discovered IPMB address when I ran across
the issue with OpenIPMI. See my answer to your specific question
associated with OpenIPMI below.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address

retrieval procedure not only on the IPMC on which the interface was opened,
but on the target IPMC as well. And the second acquired address must be
used in sensor owner ID comparison to decide if bridging is required or
not. It might be, if double bridging is used to access the target IPMC,
that sensor values are unreachable.
Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something that
indicated this was not what I was doing? Also, the channel number has to
be used in the comparison as well since it is part of addressing identified
in the sensor entries in the SDR repository.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use

the Get Address Info command for the target IPMC address retrieval. It is
better to fetch the Management Controller Locator record instead (implement
this retrieval in ipmi_sdr.c or ipmi_sensor.c).
I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one, how
do you know which one to use?

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set

another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.
The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid the
close/re-open. Did your fix to resolve bridging issues work correctly
with OpenIPMI?

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a patch I've
been using to resolve the issue I was having and would appreciate any feedback you
might have on my approach. The patch is for the CVS ipmitool source code at TOB
this morning.
I changed ipmi_main() to always open the interface using either 0x20 or the address
specified with the "-m" switch. With the code as it exists today, open is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do
the open prior
to the first IPMI request. After the initial open, I use the PICMG
get address info to
get the IPMB-0 address. If I was able to discover an address, I close and re-open
the interface with the discovered IPMB-0 address as I found this was
necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

may

Post by Dmitry Bazhenov
not match with the primary IPMB address.
- introduced a BMC address which can be overridden by "-m" command-line
parameter (default valuse is 20h). This address is used to access the
IPMC on which a session to establish a session (for LAN).
- then using Get PICMG Properties to check whether the board is a
PICMG-based system.
- use either Get Address Info for FRU #0 or fetch the Management
Controller Locator Record to query the IPMC slave address on the

primary

Post by Dmitry Bazhenov
IPMB.
- store the fetched slave address. it then used to match the sensor
owner ID to decide if the bridging to sensor is required on not.
- for the case when bridging is used, the stored slave address is used
to compose the Send Message command is return address.
Regards,
Dmitry

the

Post by Jim Mankovich
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used

unless

Post by Jim Mankovich
there is a target
address specification with -t.
Does my description agree with your understanding of these switches

and

Post by Jim Mankovich
their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have

been

Post by Jim Mankovich
using when
addressing sensors whose owner id and channel specification in the SDR
repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel

7),

Post by Jim Mankovich
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR repository,

the

Post by Jim Mankovich
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the
IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor
owner id/channel
number from the SDR repository.If the sensor owner id is equal to the
target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed
using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar

with

Post by Jim Mankovich
PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--

------------------------------------------------------------------------------

Post by Jim Mankovich
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free

account!

Post by Jim Mankovich
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

------------------------------------------------------------------------------

Post by Dmitry Bazhenov
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Dmitry Bazhenov

2013-04-17 06:35:05 UTC

Hello, Hank,

You are correct, IPMI spec does not determine how to handle SDRs over
various channels. Neither the PICMG spec somehow specifies that.

My understanding is as follows:

The sensor owner ID (IPMB slave address) in SDRs stands for the IPMC
address on its primary IPMB channel (channel #0). It is IPMB-0 for PICMG
ATCA boards and Carrier IPMCs, IPMB-L for AMC modules, etc.

On other channels __any__ IPMC is accessed over 20h address (I can't
find an example where it is not the case).

So, the issue mostly in that: what IPMB address has an IPMC over its
primary IPMB channel (#0).

Having answered this question we cab determine whether a sensors reside
on the target IPMC or bridging is required.

And using that address we can correctly compose bridging requests over
primary IPMB channel (requester address field in the Send Message command).

Regards,
Dmitry

Post by Hank Bruning
Jim, Dmitry,
You are getting into a gray area of IPMI. SDR's allow a single channel
but IPM Controllers allows multiple IPMI Buses, each with their own channel.
Management Controller Locator Record do not have a provision for which
IPMI channel is perfered or active(in the case where there are redundant
IPMB buses which are not the round robin PICMG IPMI-A, IPMI-B on a
single channel).
I don't know how you are going to resolve this without using information
that is vendor specific. But there might be a way.
If you come up with an answer, I'll be happy to add it to our ipmitool
equivalent that is in Java(Our Hemi software).
Hank Bruning
JBlade
Dmitry,
See my comments below.
Thanks,
Jim
Time) --

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use

correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work
(as does HPM.1), this may cause problems. Also, a correct address
must be used for bridging (when composing a Send Message request).
I did not intended to do anything which would invalidate using
"correct IPMB when establishing or closing session/interface. But,
I did need to close/re-open to connect to the discovered IPMB
address when I ran across the issue with OpenIPMI. See my answer
to your specific question associated with OpenIPMI below.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the

address retrieval procedure not only on the IPMC on which the
interface was opened, but on the target IPMC as well. And the second
acquired address must be used in sensor owner ID comparison to
decide if bridging is required or not. It might be, if double
bridging is used to access the target IPMC, that sensor values are
unreachable.
Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see
something that indicated this was not what I was doing? Also, the
channel number has to be used in the comparison as well since it is
part of addressing identified in the sensor entries in the SDR
repository.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct

to use the Get Address Info command for the target IPMC address
retrieval. It is better to fetch the Management Controller Locator
record instead (implement this retrieval in ipmi_sdr.c or
ipmi_sensor.c).
I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller
Locator record in the target SDR repository? If there can be more
than one, how do you know which one to use?

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to

set another IPMC address without closing and re-opening interface?
Other interface drivers seem not require such procedure.
The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to
avoid the close/re-open. Did your fix to resolve bridging issues
work correctly with OpenIPMI?

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not

find the

Post by Jim Mankovich
need to do
anything different the the "-m" command line switch. I've

attached a

Post by Jim Mankovich
patch I've
been using to resolve the issue I was having and would

appreciate any

Post by Jim Mankovich
feedback you
might have on my approach. The patch is for the CVS ipmitool

source

Post by Jim Mankovich
code at TOB
this morning.
I changed ipmi_main() to always open the interface using either

0x20 or

Post by Jim Mankovich
the address
specified with the "-m" switch. With the code as it exists

today, open

Post by Jim Mankovich
is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to

always do

Post by Jim Mankovich
the open prior
to the first IPMI request. After the initial open, I use the

PICMG

Post by Jim Mankovich
get address info to
get the IPMB-0 address. If I was able to discover an address,

I close

Post by Jim Mankovich
and re-open
the interface with the discovered IPMB-0 address as I found this was
necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0

address

Post by Jim Mankovich
and store that away to
determine when bridging is necessary for sensors identified in

the SDR

Post by Jim Mankovich
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Mountain Time) --

Post by Dmitry Bazhenov
Hello, Jim,
Your understanding is correct. Moreover, we already have a

patch which

Post by Dmitry Bazhenov
solves the issue (in our local IPMITool repo). We are going to

submit

Post by Dmitry Bazhenov
the patch for this issue shortly.
And to the topic raised.
The sensor owner ID in the SDR in my opinion shall match with

the IPMC

Post by Dmitry Bazhenov
slave address on the primary IPMB bus (channel #0).
Since there are cases when the IPMC accessed from other

channels (than

Post by Dmitry Bazhenov
channel #0), like LAN, the slave address of the IPMC on that

channel may

Post by Dmitry Bazhenov
not match with the primary IPMB address.
- introduced a BMC address which can be overridden by "-m"

command-line

Post by Dmitry Bazhenov
parameter (default valuse is 20h). This address is used to

access the

Post by Dmitry Bazhenov
IPMC on which a session to establish a session (for LAN).
- then using Get PICMG Properties to check whether the board is a
PICMG-based system.
- use either Get Address Info for FRU #0 or fetch the Management
Controller Locator Record to query the IPMC slave address on

the primary

is used

Post by Dmitry Bazhenov
to compose the Send Message command is return address.
Regards,
Dmitry

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool

bridging

Post by Jim Mankovich
on a PICMG
system and I wouldappreciate some help with understanding what the
actual intended
use of the bridging command line arguments was. There are two
different bridging
argument specifications, -t target_address/-b target_channel

(single

Post by Jim Mankovich
bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used

to read

Post by Jim Mankovich
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the

default of

Post by Jim Mankovich
0x20, or specified
on the command line via the -m address switch, or discovered

via PICMG

Post by Jim Mankovich
get address
info.
In addition to -t, you may also specify a transit address via

-T.If a

Post by Jim Mankovich
transit address is
specified, dual bridging will be used to read the SDR

repository(via the

Post by Jim Mankovich
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not

used unless

Post by Jim Mankovich
there is a target
address specification with -t.
Does my description agree with your understanding of these

switches and

Post by Jim Mankovich
their use?
Now, in addition to bridging to read the SDR repository,

bridging will

Post by Jim Mankovich
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will

override

Post by Jim Mankovich
the specified target address
identified via the -t switch, but will make use of the transit

address

Post by Jim Mankovich
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I

have been

Post by Jim Mankovich
using when
addressing sensors whose owner id and channel specification in

the SDR

Post by Jim Mankovich
repository do
not identify the exact same addressing that was used to read

the SDR

Post by Jim Mankovich
repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L

(channel 7),

Post by Jim Mankovich
the sensor can't
be accessed with the current code because the sensor will be

addressed

Post by Jim Mankovich
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from

the -b

Post by Jim Mankovich
channel specification).
The problem is that when using bridging to access an SDR

repository, the

Post by Jim Mankovich
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using

the same

Post by Jim Mankovich
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by

getting the

Post by Jim Mankovich
IPMB-0 address
of the target and compare this target IPMB-0 address with the

sensor

Post by Jim Mankovich
owner id/channel
number from the SDR repository.If the sensor owner id is equal

to the

Post by Jim Mankovich
target IPMB-0
address and the sensor channel is 0, then the sensor can be

accessed

Post by Jim Mankovich
using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor
bridging issue
I've described, but I need some insight from someone more

familiar with

Post by Jim Mankovich
PICMG and
sensor bridging to make sure my analysis of the problem I'm

seeing is

Post by Jim Mankovich
correct.
Thanks in advance,
Jim
--

Mountain Time) --
------------------------------------------------------------------------------

Post by Jim Mankovich
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for
building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free

account!

------------------------------------------------------------------------------

account!

Post by Dmitry Bazhenov
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Dmitry Bazhenov

2013-04-17 05:58:34 UTC

Hello, Jim,

Please, see my comments mixed in.

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use
correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need
to close/re-open to connect to the discovered IPMB address when I ran
across the issue with OpenIPMI. See my answer to your specific
question associated with OpenIPMI below.

Understood. But, still, there is an issue with the Send Message request
when performing bridging or double bridging using the LAN interfaces.
Though, it is a separate issue.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired
address must be used in sensor owner ID comparison to decide if
bridging is required or not. It might be, if double bridging is used
to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something
that indicated this was not what I was doing? Also, the channel
number has to be used in the comparison as well since it is part of
addressing identified in the sensor entries in the SDR repository.

You're right. I have missed it at the first time.

But still, there are issues with checking if bridging is needed:

First: in my opinion, the channel comparison is wrong in the
BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC may
not match with the channel number used to access the target IPMC
(intf->target_channel).

For example, for PICMG-defined Carrier IPMC, the channel for accessing
an AMC module is 7, while for the AMC module, the same channel is 0.

I understand that it is likely for PICMG systems that the first check in
the macro succeeds and the second check does not really matter.
But I am not sure that there will be no problem with other system types.

Second, the target address and channel substitution may be wrong too.
This works only if intf->target_channel can be used to access the sensor
owner, but it may not be the case. So, in some situation, additional
bridging step is needed. If a double bridging is already used, such
sensors may not be even reachable.

However, I can not imaging systems where such situation is possible. So,
this is rather theoretical issue.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one,
how do you know which one to use?

There can be several MC locators for non-PICMG systems. PICMG-systems
contain only one MC locator and several FRU Device locators for
subsidiary FRUs.

I suggest fetching the target_ipmb_addr only for PICMG-based systems.

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid
the close/re-open. Did your fix to resolve bridging issues work
correctly with OpenIPMI?

We do not actively use the OpenIPMI driver, so we are not aware of its
issues.
My point is that no other interface drivers need this additional
close/open. So, it might be worth to do it only for the OpenIPMI interface.

No more comments.

Regards,
Dmitry

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a patch I've
been using to resolve the issue I was having and would appreciate any feedback you
might have on my approach. The patch is for the CVS ipmitool source code at TOB
this morning.
I changed ipmi_main() to always open the interface using either 0x20 or the address
specified with the "-m" switch. With the code as it exists today, open is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do the open prior
to the first IPMI request. After the initial open, I use the PICMG
get address info to
get the IPMB-0 address. If I was able to discover an address, I close and re-open
the interface with the discovered IPMB-0 address as I found this was necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool bridging on a PICMG
system and I wouldappreciate some help with understanding what the actual intended
use of the bridging command line arguments was. There are two different bridging
argument specifications, -t target_address/-b target_channel (single bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR
repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches
and
their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have
been
using when
addressing sensors whose owner id and channel specification in the SDR
repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR
repository, the
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the
IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor
owner id/channel
number from the SDR repository.If the sensor owner id is equal to the target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar
with
PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Jim Mankovich

2013-04-17 18:01:12 UTC

Hi Dmitry,

I've attached an update patch which removes the need to close/re-open the interface when
the PICMG discovered IPMB address is found to be different than the IPMB address used to
open the interface. A new per interface function was added to enable setting the IPMB
address (if the interface supports it), and the OpenIPMI interface was modified to provide this
interface. See the patch for details.

In putting together the BRIDGE_TO_SENSOR macro, I was working under the assumption that channel
0 was always used to identify the primary IPMB Channel (per the IPMI specification). This
is why I first qualify that the SDR sensor record channel is equal to zero before I compare the
target_ipmb_addr (which is only set on PICMG platforms), with the SDR sensor record address.
This comparison is intended to be true when the sensor is on an IPMB and the target IPMB (as returned
by PICMG Get Address Info) matches the sensor address. If this is the case, then this sensor does
not require any extra bridging beyond what was used to address the SDR repository (PICMG
platforms only). If you would like me to explicitly run time verify in the macro that this condition is PICMG
only, I can qualify it with intf->picmg_avail in addition to the target_ipmb_addr test.

The second condition in the BRIDGE_TO_SENSOR macro simply looks to see if the sensor record
address and channel exactly match the argument specified target address and channel (-t <address>
-b <channel>). If this is true, then the sensor does not require any extra bridging beyond what
was used to address the SDR repository (any platform). This second condition check doesn't change
the current logic from what exists today, it just clarifies the case in which no extra bridging is
necessary beyond what was specified on the ipmitool command line. If this test really confuses folks, it
could be removed.

NOTE: With the code that currently exists today in ipmitool, the address of the sensor from the SDR repository
always overwrites the interface target address and target channel prior to accessing the sensor
via the interface sendrecv routine. Then in the interface sendrecv routines, bridging requests will be
built using the target address (target_addr) and channel (target_channel) if the target_addr doesn't match the
interface address (my_addr).

I did not intend to change how sensors are addressed via bridging on non PICMG platforms.

Thanks in Advance,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Please, see my comments mixed in.

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use
correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need
to close/re-open to connect to the discovered IPMB address when I ran
across the issue with OpenIPMI. See my answer to your specific
question associated with OpenIPMI below.

Understood. But, still, there is an issue with the Send Message request when performing bridging or double bridging using the LAN interfaces. Though, it is a separate issue.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired
address must be used in sensor owner ID comparison to decide if
bridging is required or not. It might be, if double bridging is used
to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something
that indicated this was not what I was doing? Also, the channel
number has to be used in the comparison as well since it is part of
addressing identified in the sensor entries in the SDR repository.

You're right. I have missed it at the first time.
First: in my opinion, the channel comparison is wrong in the BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC may not match with the channel number used to access the target IPMC (intf->target_channel).
For example, for PICMG-defined Carrier IPMC, the channel for accessing an AMC module is 7, while for the AMC module, the same channel is 0.
I understand that it is likely for PICMG systems that the first check in the macro succeeds and the second check does not really matter.
But I am not sure that there will be no problem with other system types.
Second, the target address and channel substitution may be wrong too. This works only if intf->target_channel can be used to access the sensor owner, but it may not be the case. So, in some situation, additional bridging step is needed. If a double bridging is already used, such sensors may not be even reachable.
However, I can not imaging systems where such situation is possible. So, this is rather theoretical issue.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one,
how do you know which one to use?

There can be several MC locators for non-PICMG systems. PICMG-systems contain only one MC locator and several FRU Device locators for subsidiary FRUs.
I suggest fetching the target_ipmb_addr only for PICMG-based systems.

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid
the close/re-open. Did your fix to resolve bridging issues work
correctly with OpenIPMI?

We do not actively use the OpenIPMI driver, so we are not aware of its issues.
My point is that no other interface drivers need this additional close/open. So, it might be worth to do it only for the OpenIPMI interface.
No more comments.
Regards,
Dmitry

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a patch I've
been using to resolve the issue I was having and would appreciate any feedback you
might have on my approach. The patch is for the CVS ipmitool source code at TOB
this morning.
I changed ipmi_main() to always open the interface using either 0x20 or the address
specified with the "-m" switch. With the code as it exists today, open is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do
the open prior
to the first IPMI request. After the initial open, I use the PICMG
get address info to
get the IPMB-0 address. If I was able to discover an address, I close and re-open
the interface with the discovered IPMB-0 address as I found this was
necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool bridging on a PICMG
system and I wouldappreciate some help with understanding what the
actual intended
use of the bridging command line arguments was. There are two
different bridging
argument specifications, -t target_address/-b target_channel (single bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG
get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR
repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches
and
their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have
been
using when
addressing sensors whose owner id and channel specification in the SDR
repository do
not identify the exact same addressing that was used to read the SDR repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR
repository, the
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the
IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor
owner id/channel
number from the SDR repository.If the sensor owner id is equal to the
target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed
using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor bridging issue
I've described, but I need some insight from someone more familiar
with
PICMG and
sensor bridging to make sure my analysis of the problem I'm seeing is correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Dmitry Bazhenov

2013-04-19 06:47:50 UTC

Hello, Jim,

Unfortunately, we can not change my_addr after discovering that the IPMC
address on the primary IPMB is different from what was used to connect
the IPMC.

Consider an example. A board is accessed via LAN using 20h as a slave
addres while the slave address on the primary IPMB is 90h. If we set
my_addr to 90h, all subsequent RMCP packets will be incorrectly composed
and discarded by the board.

For this case we should set another address value, e.g. my_ipmb_addr,
which defaults to my_addr but then can be changed via PICMG discovery.

Regarding to the BRIDGE_TO_SENSOR macro, I am now convinced that it
should work as needed.

There is one more thing. Please, add PICMG Extension 5.0 (05h) for
MicroTCA.0 base specification.

Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I've attached an update patch which removes the need to close/re-open the interface when
the PICMG discovered IPMB address is found to be different than the IPMB address used to
open the interface. A new per interface function was added to enable setting the IPMB
address (if the interface supports it), and the OpenIPMI interface was
modified to provide this
interface. See the patch for details.
In putting together the BRIDGE_TO_SENSOR macro, I was working under the
assumption that channel
0 was always used to identify the primary IPMB Channel (per the IPMI specification). This
is why I first qualify that the SDR sensor record channel is equal to
zero before I compare the
target_ipmb_addr (which is only set on PICMG platforms), with the SDR
sensor record address.
This comparison is intended to be true when the sensor is on an IPMB and
the target IPMB (as returned
by PICMG Get Address Info) matches the sensor address. If this is the
case, then this sensor does
not require any extra bridging beyond what was used to address the SDR repository (PICMG
platforms only). If you would like me to explicitly run time verify
in the macro that this condition is PICMG
only, I can qualify it with intf->picmg_avail in addition to the target_ipmb_addr test.
The second condition in the BRIDGE_TO_SENSOR macro simply looks to see if the sensor record
address and channel exactly match the argument specified target address
and channel (-t <address>
-b <channel>). If this is true, then the sensor does not require any
extra bridging beyond what
was used to address the SDR repository (any platform). This second
condition check doesn't change
the current logic from what exists today, it just clarifies the case in
which no extra bridging is
necessary beyond what was specified on the ipmitool command line. If
this test really confuses folks, it
could be removed.
NOTE: With the code that currently exists today in ipmitool, the address
of the sensor from the SDR repository
always overwrites the interface target address and target channel prior
to accessing the sensor
via the interface sendrecv routine. Then in the interface sendrecv
routines, bridging requests will be
built using the target address (target_addr) and channel
(target_channel) if the target_addr doesn't match the
interface address (my_addr).
I did not intend to change how sensors are addressed via bridging on non PICMG platforms.
Thanks in Advance,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Please, see my comments mixed in.

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use
correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need
to close/re-open to connect to the discovered IPMB address when I ran
across the issue with OpenIPMI. See my answer to your specific
question associated with OpenIPMI below.

Understood. But, still, there is an issue with the Send Message
request when performing bridging or double bridging using the LAN
interfaces. Though, it is a separate issue.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired
address must be used in sensor owner ID comparison to decide if
bridging is required or not. It might be, if double bridging is used
to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something
that indicated this was not what I was doing? Also, the channel
number has to be used in the comparison as well since it is part of
addressing identified in the sensor entries in the SDR repository.

You're right. I have missed it at the first time.
First: in my opinion, the channel comparison is wrong in the
BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC
may not match with the channel number used to access the target IPMC
(intf->target_channel).
For example, for PICMG-defined Carrier IPMC, the channel for accessing
an AMC module is 7, while for the AMC module, the same channel is 0.
I understand that it is likely for PICMG systems that the first check
in the macro succeeds and the second check does not really matter.
But I am not sure that there will be no problem with other system types.
Second, the target address and channel substitution may be wrong too.
This works only if intf->target_channel can be used to access the
sensor owner, but it may not be the case. So, in some situation,
additional bridging step is needed. If a double bridging is already
used, such sensors may not be even reachable.
However, I can not imaging systems where such situation is possible.
So, this is rather theoretical issue.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one,
how do you know which one to use?

There can be several MC locators for non-PICMG systems. PICMG-systems
contain only one MC locator and several FRU Device locators for
subsidiary FRUs.
I suggest fetching the target_ipmb_addr only for PICMG-based systems.

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid
the close/re-open. Did your fix to resolve bridging issues work
correctly with OpenIPMI?

We do not actively use the OpenIPMI driver, so we are not aware of its issues.
My point is that no other interface drivers need this additional
close/open. So, it might be worth to do it only for the OpenIPMI interface.
No more comments.
Regards,
Dmitry

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a patch I've
been using to resolve the issue I was having and would appreciate any feedback you
might have on my approach. The patch is for the CVS ipmitool source code at TOB
this morning.
I changed ipmi_main() to always open the interface using either
0x20 or
the address
specified with the "-m" switch. With the code as it exists today,
open
is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do
the open prior
to the first IPMI request. After the initial open, I use the PICMG
get address info to
get the IPMB-0 address. If I was able to discover an address, I
close
and re-open
the interface with the discovered IPMB-0 address as I found this was
necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool
bridging
on a PICMG
system and I wouldappreciate some help with understanding what the
actual intended
use of the bridging command line arguments was. There are two
different bridging
argument specifications, -t target_address/-b target_channel (single
bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG
get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR
repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches
and
their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have
been
using when
addressing sensors whose owner id and channel specification in the SDR
repository do
not identify the exact same addressing that was used to read the SDR
repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR
repository, the
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the
IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor
owner id/channel
number from the SDR repository.If the sensor owner id is equal to the
target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed
using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor
bridging issue
I've described, but I need some insight from someone more familiar
with
PICMG and
sensor bridging to make sure my analysis of the problem I'm
seeing is
correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Dan Gora

2013-04-24 01:47:48 UTC

Hi guys,

I'm working on coming up with a set of test cases to test this patch,
but I'm going to need some help with making sure that everything is
sane and valid.

First off, can you describe, Jim, what was the problem was initially
in 1.8.12 exactly? What were you trying to read and how were you
connecting and what arguments were you using? I'd like to include
that in the test cases below.

What I have available is a 2U PICMG system which consists of an ASIS
2U chassis which contains the following:

Shelf Manager - PPS ShMM- 500
Slot 1 - Adax PacketRunner with PPS ATCA carrier IPMC software with 2
Adax ATM4 AMC cards in AMC slots 2 and 3 with PPS AMC IPMC software
Slot 2 - DTI fabric switch with ??? IPMC software

There are a few different places from which we would want to run ipmitool:
1)

Jim Mankovich

2013-04-24 15:52:20 UTC

Dan,

I was initially attempting to understand why I could not access specific entities
using the bridging command line arguments (-t, -b, -T, -B,) and the -m switch. This
led me to the discovery that you had to specify -m 0 to get the PICMG discovery
code to run, then to how the target and transit addresses specified on the command
line were being used to do addressing in ipmitool. The confusion I had with
interpretation of what I was seeing when I used these switches to address entities
was very similar to what you are seeing using the switches. Also, there was the more
subtle issue that I could not address sensors in an SDR repository that I addressed
using the bridging command line arguments due to the issues I outlined in my email
thread with Dmitry.

The first major difference between TOB (What you call CVS ROOT) and TOB plus my
patch is the fact that on a PICMG platform, my patch will always perform a PICMG
address discovery, whereas TOB would only do this if you specified '-m 0'. This is
why you get a different answer for ipmitool fru with my patch vrs TOB and also why
you found TOB would get you the same result as my patch when you specified '-m 0'
with TOB.

The other thing you found with my patch is that you can no longer address
the "Asis ATCA IPMI Shelf Manager". This is due to the change to always do PICMG
discovery of the IPMB address and utilize the discovered address instead of having
-m override the discovered address. With the TOB code, an address specified with
-m or the default IPMB address 0x20 would always be used unless you specified '-m 0'
to force discovery. To fully enable prior functionality, I would have to make the
specification of any address with -m <address> inhibit default PICMG discovery. I
think this is the right thing to do and I'll update my patch to do this unless folks have
any issues with this change. I would also change the man page for -m to state the
following:
Set the local IPMB address. The default is 0x20 or auto discovered on PICMG
platforms so there should be no need to change it for normal operation.

With the above change, you will be able to address the Shelf Manager again, but you
would have to specify -m 0x20 to do so.

Now, when you get down to trying to address specific entities via the bridging command
line arguments you will find that certain things just don't get you what you would expect unless
you understand the internal implementation of -m, and the bridging command line switches.

You showed one example when you tried to address 0x28 with the TOB version. This fails on
your system because you didn't specify -m 0 to have ipmitool use the PICMG discovered address
instead of the default 0x20 address.

You should probably verify that when you add '-m 0' to the following command line you get
the same answer as the patched version. Also, you can use -v to see the PICMG discovered
address (which I assume is not 0x20 on your platform).

a)CVS ROOT:
dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 fru
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed

I did my best to answer your questions, but I'm sure I missed something. Let me
know if you need more clarification or details.

Thanks for help testing this out,
Jim

Post by Dan Gora
Hi guys,
I'm working on coming up with a set of test cases to test this patch,
but I'm going to need some help with making sure that everything is
sane and valid.
First off, can you describe, Jim, what was the problem was initially
in 1.8.12 exactly? What were you trying to read and how were you
connecting and what arguments were you using? I'd like to include
that in the test cases below.
What I have available is a 2U PICMG system which consists of an ASIS
Shelf Manager - PPS ShMM- 500
Slot 1 - Adax PacketRunner with PPS ATCA carrier IPMC software with 2
Adax ATM4 AMC cards in AMC slots 2 and 3 with PPS AMC IPMC software
Slot 2 - DTI fabric switch with ??? IPMC software
1)

Dan Gora

2013-04-24 18:27:25 UTC

Post by Jim Mankovich
The first major difference between TOB (What you call CVS ROOT) and TOB plus my
patch is the fact that on a PICMG platform, my patch will always perform a PICMG
address discovery, whereas TOB would only do this if you specified '-m 0'.
This is
why you get a different answer for ipmitool fru with my patch vrs TOB and also why
you found TOB would get you the same result as my patch when you specified '-m 0'
with TOB.

<rant>
ugh.. This is (just one of many reasons) why I _hate_ CVS. I think
that probably your TOB is different from mine. I just got a patch
committed a few days ago which would default to doing the PICMG addr
discovery if you didn't specify any -m option. That was different
from the 1.8.12 behavior where you had to explicitly specify '-m 0' to
force it to do address discovery.

If we were using something sensible like 'git' we could talk about
commit SHAs and actually know what we were talking about...
</rant>

Post by Jim Mankovich
The other thing you found with my patch is that you can no longer address
the "Asis ATCA IPMI Shelf Manager". This is due to the change to always do PICMG
discovery of the IPMB address and utilize the discovered address instead of having
-m override the discovered address. With the TOB code, an address specified with
-m or the default IPMB address 0x20 would always be used unless you specified '-m 0'
to force discovery. To fully enable prior functionality, I would have to make the
specification of any address with -m <address> inhibit default PICMG discovery. I
think this is the right thing to do and I'll update my patch to do this unless folks have
any issues with this change. I would also change the man page for -m to state the
Set the local IPMB address. The default is 0x20 or auto discovered on PICMG
platforms so there should be no need to change it for normal operation.
With the above change, you will be able to address the Shelf Manager again, but you
would have to specify -m 0x20 to do so.

Actually I am still able to access the "Asis ATCA IPMI Shelf Manager"
with your patch both with and without -m 0x20.

Post by Jim Mankovich
Now, when you get down to trying to address specific entities via the bridging command
line arguments you will find that certain things just don't get you what you
would expect unless
you understand the internal implementation of -m, and the bridging command line switches.

Right.. It's very very confusing...

Post by Jim Mankovich
You showed one example when you tried to address 0x28 with the TOB version.
This fails on
your system because you didn't specify -m 0 to have ipmitool use the PICMG
discovered address
instead of the default 0x20 address.

Nope, the TOB still fails even specifying -m 0.

dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 0 fru
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed

dg:speedy:build => src/ipmitool -v -I lan -H 192.168.1.8 -A none -t
0x82 -m 0 fru
Running PICMG GetDeviceLocator
Discovered PICMG Extension 2.3
Discovered IPMB address = 0x12
Get Auth Capabilities command failed
Get Auth Capabilities command failed
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed

Post by Jim Mankovich
You should probably verify that when you add '-m 0' to the following command line you get
the same answer as the patched version. Also, you can use -v to see the PICMG discovered
address (which I assume is not 0x20 on your platform).

It seems to be the opposite for the TOB. You have to specify any
non-zero -m value to get it to _skip_ the PICMG addr discover to get
it to give the same output when I try and target my APR (ie address
0x82):

dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 123 fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146

FRU Device Description : ADAX PR
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146

FRU Device Description : ADAX ATMiv-AMC (ID 3)
Board Mfg Date : Wed Oct 28 14:12:00 2009
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000354
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 6A
Product Serial : 0000354
Product Asset Tag : COMM

FRU Device Description : ADAX ATMiv-AMC (ID 4)
Board Mfg Date : Tue Dec 14 14:12:00 2010
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000289
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 7
Product Serial : 0000289
Product Asset Tag : COMM

dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82
-m 0x20 fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146

FRU Device Description : ADAX PR
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146

FRU Device Description : ADAX ATMiv-AMC (ID 3)
Board Mfg Date : Wed Oct 28 14:12:00 2009
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000354
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 6A
Product Serial : 0000354
Product Asset Tag : COMM

FRU Device Description : ADAX ATMiv-AMC (ID 4)
Board Mfg Date : Tue Dec 14 14:12:00 2010
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000289
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 7
Product Serial : 0000289
Product Asset Tag : COMM

dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82
-m 0x12 fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146

FRU Device Description : ADAX PR
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146

FRU Device Description : ADAX ATMiv-AMC (ID 3)
Board Mfg Date : Wed Oct 28 14:12:00 2009
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000354
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 6A
Product Serial : 0000354
Product Asset Tag : COMM

FRU Device Description : ADAX ATMiv-AMC (ID 4)
Board Mfg Date : Tue Dec 14 14:12:00 2010
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000289
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 7
Product Serial : 0000289
Product Asset Tag : COMM

I really don't get this to be honest.

All this with the new patch seems to be fine to me. However there are
a couple of things I still don't really understand:

1) What do you use double bridging for in a PICMG system?
2) How (and can you) access AMC cards from an external system manager.

For example to read the FRU information from my ATM4 AMC card on the
APR I would expect that you'd do something like:

With Jim's patch
================
dg:speedy:build(master) => src/ipmitool -v -I lan -H 192.168.1.8 -A
none -t 0x78 -b 7 -T 0x82 -B 0 fru
Running PICMG GetDeviceLocator
Discovered PICMG Extension 2.3
Discovered IPMB-0 address = 0x12
FRU Device Description : Builtin FRU Device (ID 0)
FRU Read failed
FRU Read failed

TOB
====
dg:speedy:build => src/ipmitool -v -I lan -H 192.168.1.8 -A none -t
0x78 -b 7 -T 0x82 -B 0 fru
Running PICMG GetDeviceLocator
Discovered PICMG Extension 2.3
Discovered IPMB address = 0x12
Get Auth Capabilities command failed
Get Auth Capabilities command failed
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed

Maybe this is just not possible from the external system manager...

thanks
dan

Dan Gora

2013-04-24 20:03:11 UTC

Hi Jim,

Please ignore the results from my last email.. I think that I have your
patch applied to the wrong version of the source.... Let me start this
all over again before we go any further..

Sorry about that.

thanks
dan

Dan Gora

2013-04-24 20:20:16 UTC

Ok, sorry about _this_ email.... The previous results were accurate after all...

thanks
dan

Post by Dan Gora
Hi Jim,
Please ignore the results from my last email.. I think that I have your
patch applied to the wrong version of the source.... Let me start this
all over again before we go any further..
Sorry about that.
thanks
dan

Jim Mankovich

2013-04-25 19:11:47 UTC

Dan,

Here is what I can tell you about the test differences between TOB and TOB with
my patch applied. For both versions, the interface is opened with the
the default IPMB address of 0x20 and not using the address specified on the command
line via the -m switch. Another subtle but important point is that with the patch, the
interface open will always be done in the main program at the exact same place. With
the TOB version, open gets done in a nested fashion due to the fact that any attempt to
do an IPMI request prior to open will cause an invocation of open on behalf of the
caller.

No Bridging test
./ipmitool/build/src/ipmitool -I lan -H 192.168.1.8 -A none fru

In the TOB version, the lan interface open routine is called inside the ipmi_main_intf->sendrecv
which is done in ipmi_main to do the the PICMG_GET_PICMG_PROPERTIES_CMD. This open
is done using 0x20 as the IPMB address and upon completion, the PICMG discovery code gets
an IPMB address of 0x12 and sets this as the default address.

The difference in output between the two different ipmitool versions is due
to TOB using the PICMG Discovered IPMB address (0x12) to address the IPMB immediately
after the first complete open. Using 0x12 yields only two fru records whereas using 0x20 yields
11 fru records.

Single Level Bridging Test
./ipmitool/build/src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 fru

The open happens the same way as in the prior example, but, because there is a specified
target address, another open on the lan interface is attempted and this open is using 0x12
which will cause the Get Channel Authentication Capabilities (0x38) in lan open to time out
due to no response. I don't think doing the open a second time was ever the intent. With the
patch, 0x20 is for the single open and then 0x82 is used for subsequent bridged requests.

Single Level Bridging with a bogus default IPMB address
./ipmitool/build/src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 34 fru

In both cases, the open is done with 0x20 and the specified target address (0x82) is used post
open for bridging. This is why both get the exact same results. Note that the address 34 is
never used because post open all requests are bridged directly to 0x82. For the TOB version 34
will keep the PICMG discovery code from running which is why it doesn't fail like the prior Single
Level Bridging Test.

With the new code (patched version), there is only a single open in one place in ipmitool which
I think is what really should be happening. After all the time spent analyzing these few cases,
I'm starting to think it would be good for me to remove all code in sendrecv routines which causes
an interface to be automatically opened on the first request. Every time I've run across a case
where the open happens in sendrecv, I've seen problems. It's interesting to note that some interfaces
don't do a second open if the interface was already opened prior whereas in lan for example it is
perfectly happy to try to do the open again. I doubt the lan interface code was really written to support
the ability to open the interface multiple times given the fact that there is a single global interface
structure.

Overall, I think the patch resolves many more issues than it may cause, but we need to do some more
testing to feel better about it.

I'm still thinking that any specification of a -m address command line option should inhibit PICMG
address discover for the primary IPMB and that the specified address should be used for open instead
of the default address of 0x20. Does anyone object? If this were done, you would never be able to
successfully open an interface if you specify a bogus IPMB address.

This took me way to long to figure out what was going on with the TOB version, and I don't really
think I have the time to do this for every test case.

Thanks,
Jim

Post by Dan Gora

<rant>
ugh.. This is (just one of many reasons) why I _hate_ CVS. I think
that probably your TOB is different from mine. I just got a patch
committed a few days ago which would default to doing the PICMG addr
discovery if you didn't specify any -m option. That was different
from the 1.8.12 behavior where you had to explicitly specify '-m 0' to
force it to do address discovery.
If we were using something sensible like 'git' we could talk about
commit SHAs and actually know what we were talking about...
</rant>

Actually I am still able to access the "Asis ATCA IPMI Shelf Manager"
with your patch both with and without -m 0x20.

Right.. It's very very confusing...

Nope, the TOB still fails even specifying -m 0.
dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 0 fru
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed
dg:speedy:build => src/ipmitool -v -I lan -H 192.168.1.8 -A none -t
0x82 -m 0 fru
Running PICMG GetDeviceLocator
Discovered PICMG Extension 2.3
Discovered IPMB address = 0x12
Get Auth Capabilities command failed
Get Auth Capabilities command failed
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed

Post by Jim Mankovich
You should probably verify that when you add '-m 0' to the following command line you get
the same answer as the patched version. Also, you can use -v to see the
PICMG discovered
address (which I assume is not 0x20 on your platform).

It seems to be the opposite for the TOB. You have to specify any
non-zero -m value to get it to _skip_ the PICMG addr discover to get
it to give the same output when I try and target my APR (ie address
dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82 -m 123 fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146
FRU Device Description : ADAX PR
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146
FRU Device Description : ADAX ATMiv-AMC (ID 3)
Board Mfg Date : Wed Oct 28 14:12:00 2009
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000354
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 6A
Product Serial : 0000354
Product Asset Tag : COMM
FRU Device Description : ADAX ATMiv-AMC (ID 4)
Board Mfg Date : Tue Dec 14 14:12:00 2010
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000289
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 7
Product Serial : 0000289
Product Asset Tag : COMM
dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82
-m 0x20 fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146
FRU Device Description : ADAX PR
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146
FRU Device Description : ADAX ATMiv-AMC (ID 3)
Board Mfg Date : Wed Oct 28 14:12:00 2009
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000354
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 6A
Product Serial : 0000354
Product Asset Tag : COMM
FRU Device Description : ADAX ATMiv-AMC (ID 4)
Board Mfg Date : Tue Dec 14 14:12:00 2010
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000289
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 7
Product Serial : 0000289
Product Asset Tag : COMM
dg:speedy:build => src/ipmitool -I lan -H 192.168.1.8 -A none -t 0x82
-m 0x12 fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146
FRU Device Description : ADAX PR
Board Mfg Date : Thu Sep 20 21:00:00 2012
Board Mfg : ADAX, Inc.
Board Product : PacketRunner
Board Serial : 0000146
Board Part Number : 90-4000-00
Product Manufacturer : ADAX, Inc.
Product Name : PacketRunner
Product Part Number : 000000
Product Version : MRL 15
Product Serial : 0000146
FRU Device Description : ADAX ATMiv-AMC (ID 3)
Board Mfg Date : Wed Oct 28 14:12:00 2009
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000354
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 6A
Product Serial : 0000354
Product Asset Tag : COMM
FRU Device Description : ADAX ATMiv-AMC (ID 4)
Board Mfg Date : Tue Dec 14 14:12:00 2010
Board Mfg : ADAX
Board Product : ATM4-AMC
Board Serial : 0000289
Board Part Number : A
Product Manufacturer : ADAX
Product Name : ATM4-AMC
Product Part Number : 82-6000
Product Version : MRL 7
Product Serial : 0000289
Product Asset Tag : COMM
I really don't get this to be honest.
All this with the new patch seems to be fine to me. However there are
1) What do you use double bridging for in a PICMG system?
2) How (and can you) access AMC cards from an external system manager.
For example to read the FRU information from my ATM4 AMC card on the
With Jim's patch
================
dg:speedy:build(master) => src/ipmitool -v -I lan -H 192.168.1.8 -A
none -t 0x78 -b 7 -T 0x82 -B 0 fru
Running PICMG GetDeviceLocator
Discovered PICMG Extension 2.3
Discovered IPMB-0 address = 0x12
FRU Device Description : Builtin FRU Device (ID 0)
FRU Read failed
FRU Read failed
TOB
====
dg:speedy:build => src/ipmitool -v -I lan -H 192.168.1.8 -A none -t
0x78 -b 7 -T 0x82 -B 0 fru
Running PICMG GetDeviceLocator
Discovered PICMG Extension 2.3
Discovered IPMB address = 0x12
Get Auth Capabilities command failed
Get Auth Capabilities command failed
Error: Unable to establish LAN session
FRU Device Description : Builtin FRU Device (ID 0)
Get Device ID command failed
Maybe this is just not possible from the external system manager...
thanks
dan

Jim Mankovich

2013-04-24 17:42:57 UTC

Dmitry,

See below,

Post by Dmitry Bazhenov
Hello, Jim,
Unfortunately, we can not change my_addr after discovering that the IPMC address on the primary IPMB is different from what was used to connect the IPMC.
Consider an example. A board is accessed via LAN using 20h as a slave addres while the slave address on the primary IPMB is 90h. If we set my_addr to 90h, all subsequent RMCP packets will be incorrectly composed and discarded by the board.
For this case we should set another address value, e.g. my_ipmb_addr, which defaults to my_addr but then can be changed via PICMG discovery.

I agree that the scenario you present above will cause failures for lan interfaces if it it were to occur, but I don't believe it
would ever make sense for PICMG discovery over lan to return anything except 20h if the interface were opened using 20h.

Nothing I did should change the way in which the lan interfaces work IPMB addressing and PICMG discovery.

With my changes, the only interface which supports re-setting my_addr to the IPMB discovered address is OpenIPMI.

Post by Dmitry Bazhenov
Regarding to the BRIDGE_TO_SENSOR macro, I am now convinced that it should work as needed.

Good

Post by Dmitry Bazhenov
There is one more thing. Please, add PICMG Extension 5.0 (05h) for MicroTCA.0 base specification.

Is this another version like PICMG_AMC_MAJOR_VERSION. If so, should it be,
PICMG_MICROTCA_MAJOR_VERSION or is something else more appropriate?

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I've attached an update patch which removes the need to close/re-open the interface when
the PICMG discovered IPMB address is found to be different than the IPMB address used to
open the interface. A new per interface function was added to enable setting the IPMB
address (if the interface supports it), and the OpenIPMI interface was
modified to provide this
interface. See the patch for details.
In putting together the BRIDGE_TO_SENSOR macro, I was working under the
assumption that channel
0 was always used to identify the primary IPMB Channel (per the IPMI
specification). This
is why I first qualify that the SDR sensor record channel is equal to
zero before I compare the
target_ipmb_addr (which is only set on PICMG platforms), with the SDR
sensor record address.
This comparison is intended to be true when the sensor is on an IPMB and
the target IPMB (as returned
by PICMG Get Address Info) matches the sensor address. If this is the
case, then this sensor does
not require any extra bridging beyond what was used to address the SDR repository (PICMG
platforms only). If you would like me to explicitly run time verify
in the macro that this condition is PICMG
only, I can qualify it with intf->picmg_avail in addition to the target_ipmb_addr test.
The second condition in the BRIDGE_TO_SENSOR macro simply looks to see
if the sensor record
address and channel exactly match the argument specified target address
and channel (-t <address>
-b <channel>). If this is true, then the sensor does not require any
extra bridging beyond what
was used to address the SDR repository (any platform). This second
condition check doesn't change
the current logic from what exists today, it just clarifies the case in
which no extra bridging is
necessary beyond what was specified on the ipmitool command line. If
this test really confuses folks, it
could be removed.
NOTE: With the code that currently exists today in ipmitool, the address
of the sensor from the SDR repository
always overwrites the interface target address and target channel prior
to accessing the sensor
via the interface sendrecv routine. Then in the interface sendrecv
routines, bridging requests will be
built using the target address (target_addr) and channel
(target_channel) if the target_addr doesn't match the
interface address (my_addr).
I did not intend to change how sensors are addressed via bridging on non PICMG platforms.
Thanks in Advance,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Please, see my comments mixed in.

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use
correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need
to close/re-open to connect to the discovered IPMB address when I ran
across the issue with OpenIPMI. See my answer to your specific
question associated with OpenIPMI below.

Understood. But, still, there is an issue with the Send Message
request when performing bridging or double bridging using the LAN
interfaces. Though, it is a separate issue.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired
address must be used in sensor owner ID comparison to decide if
bridging is required or not. It might be, if double bridging is used
to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something
that indicated this was not what I was doing? Also, the channel
number has to be used in the comparison as well since it is part of
addressing identified in the sensor entries in the SDR repository.

You're right. I have missed it at the first time.
First: in my opinion, the channel comparison is wrong in the
BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC
may not match with the channel number used to access the target IPMC
(intf->target_channel).
For example, for PICMG-defined Carrier IPMC, the channel for accessing
an AMC module is 7, while for the AMC module, the same channel is 0.
I understand that it is likely for PICMG systems that the first check
in the macro succeeds and the second check does not really matter.
But I am not sure that there will be no problem with other system types.
Second, the target address and channel substitution may be wrong too.
This works only if intf->target_channel can be used to access the
sensor owner, but it may not be the case. So, in some situation,
additional bridging step is needed. If a double bridging is already
used, such sensors may not be even reachable.
However, I can not imaging systems where such situation is possible.
So, this is rather theoretical issue.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one,
how do you know which one to use?

There can be several MC locators for non-PICMG systems. PICMG-systems
contain only one MC locator and several FRU Device locators for
subsidiary FRUs.
I suggest fetching the target_ipmb_addr only for PICMG-based systems.

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid
the close/re-open. Did your fix to resolve bridging issues work
correctly with OpenIPMI?

We do not actively use the OpenIPMI driver, so we are not aware of its issues.
My point is that no other interface drivers need this additional
close/open. So, it might be worth to do it only for the OpenIPMI interface.
No more comments.
Regards,
Dmitry

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not find the need to do
anything different the the "-m" command line switch. I've attached a
patch I've
been using to resolve the issue I was having and would appreciate any
feedback you
might have on my approach. The patch is for the CVS ipmitool source
code at TOB
this morning.
I changed ipmi_main() to always open the interface using either
0x20 or
the address
specified with the "-m" switch. With the code as it exists today,
open
is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do
the open prior
to the first IPMI request. After the initial open, I use the PICMG
get address info to
get the IPMB-0 address. If I was able to discover an address, I
close
and re-open
the interface with the discovered IPMB-0 address as I found this was
necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool
bridging
on a PICMG
system and I wouldappreciate some help with understanding what the
actual intended
use of the bridging command line arguments was. There are two
different bridging
argument specifications, -t target_address/-b target_channel (single
bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG
get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR
repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches
and
their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have
been
using when
addressing sensors whose owner id and channel specification in the SDR
repository do
not identify the exact same addressing that was used to read the SDR
repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L (channel 7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR
repository, the
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the
IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor
owner id/channel
number from the SDR repository.If the sensor owner id is equal to the
target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed
using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor
bridging issue
I've described, but I need some insight from someone more familiar
with
PICMG and
sensor bridging to make sure my analysis of the problem I'm
seeing is
correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Dmitry Bazhenov

2013-04-25 13:24:16 UTC

Hello, Jim,

I need to think it through.
Since double bridging is used to access AMC modules, then I guess, it
maybe not worth to bother with the discovered PICMG address in LAN or
other interfaces.

Regards,
Dmitry

Post by Jim Mankovich
Dmitry,
See below,

Post by Dmitry Bazhenov
Hello, Jim,
Unfortunately, we can not change my_addr after discovering that the
IPMC address on the primary IPMB is different from what was used to
connect the IPMC.
Consider an example. A board is accessed via LAN using 20h as a slave
addres while the slave address on the primary IPMB is 90h. If we set
my_addr to 90h, all subsequent RMCP packets will be incorrectly
composed and discarded by the board.
For this case we should set another address value, e.g. my_ipmb_addr,
which defaults to my_addr but then can be changed via PICMG discovery.

I agree that the scenario you present above will cause failures for lan
interfaces if it it were to occur, but I don't believe it
would ever make sense for PICMG discovery over lan to return anything
except 20h if the interface were opened using 20h.
Nothing I did should change the way in which the lan interfaces work
IPMB addressing and PICMG discovery.
With my changes, the only interface which supports re-setting my_addr to
the IPMB discovered address is OpenIPMI.

Post by Dmitry Bazhenov
Regarding to the BRIDGE_TO_SENSOR macro, I am now convinced that it
should work as needed.

Good

Post by Dmitry Bazhenov
There is one more thing. Please, add PICMG Extension 5.0 (05h) for
MicroTCA.0 base specification.

Is this another version like PICMG_AMC_MAJOR_VERSION. If so, should it be,
PICMG_MICROTCA_MAJOR_VERSION or is something else more appropriate?

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I've attached an update patch which removes the need to close/re-open
the interface when
the PICMG discovered IPMB address is found to be different than the IPMB
address used to
open the interface. A new per interface function was added to enable
setting the IPMB
address (if the interface supports it), and the OpenIPMI interface was
modified to provide this
interface. See the patch for details.
In putting together the BRIDGE_TO_SENSOR macro, I was working under the
assumption that channel
0 was always used to identify the primary IPMB Channel (per the IPMI
specification). This
is why I first qualify that the SDR sensor record channel is equal to
zero before I compare the
target_ipmb_addr (which is only set on PICMG platforms), with the SDR
sensor record address.
This comparison is intended to be true when the sensor is on an IPMB and
the target IPMB (as returned
by PICMG Get Address Info) matches the sensor address. If this is the
case, then this sensor does
not require any extra bridging beyond what was used to address the SDR
repository (PICMG
platforms only). If you would like me to explicitly run time verify
in the macro that this condition is PICMG
only, I can qualify it with intf->picmg_avail in addition to the target_ipmb_addr test.
The second condition in the BRIDGE_TO_SENSOR macro simply looks to see
if the sensor record
address and channel exactly match the argument specified target address
and channel (-t <address>
-b <channel>). If this is true, then the sensor does not require any
extra bridging beyond what
was used to address the SDR repository (any platform). This second
condition check doesn't change
the current logic from what exists today, it just clarifies the case in
which no extra bridging is
necessary beyond what was specified on the ipmitool command line. If
this test really confuses folks, it
could be removed.
NOTE: With the code that currently exists today in ipmitool, the address
of the sensor from the SDR repository
always overwrites the interface target address and target channel prior
to accessing the sensor
via the interface sendrecv routine. Then in the interface sendrecv
routines, bridging requests will be
built using the target address (target_addr) and channel
(target_channel) if the target_addr doesn't match the
interface address (my_addr).
I did not intend to change how sensors are addressed via bridging on non
PICMG platforms.
Thanks in Advance,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Please, see my comments mixed in.

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use
correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need
to close/re-open to connect to the discovered IPMB address when I ran
across the issue with OpenIPMI. See my answer to your specific
question associated with OpenIPMI below.

Understood. But, still, there is an issue with the Send Message
request when performing bridging or double bridging using the LAN
interfaces. Though, it is a separate issue.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired
address must be used in sensor owner ID comparison to decide if
bridging is required or not. It might be, if double bridging is used
to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something
that indicated this was not what I was doing? Also, the channel
number has to be used in the comparison as well since it is part of
addressing identified in the sensor entries in the SDR repository.

You're right. I have missed it at the first time.
First: in my opinion, the channel comparison is wrong in the
BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC
may not match with the channel number used to access the target IPMC
(intf->target_channel).
For example, for PICMG-defined Carrier IPMC, the channel for accessing
an AMC module is 7, while for the AMC module, the same channel is 0.
I understand that it is likely for PICMG systems that the first check
in the macro succeeds and the second check does not really matter.
But I am not sure that there will be no problem with other system types.
Second, the target address and channel substitution may be wrong too.
This works only if intf->target_channel can be used to access the
sensor owner, but it may not be the case. So, in some situation,
additional bridging step is needed. If a double bridging is already
used, such sensors may not be even reachable.
However, I can not imaging systems where such situation is possible.
So, this is rather theoretical issue.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address
retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one,
how do you know which one to use?

There can be several MC locators for non-PICMG systems. PICMG-systems
contain only one MC locator and several FRU Device locators for
subsidiary FRUs.
I suggest fetching the target_ipmb_addr only for PICMG-based systems.

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid
the close/re-open. Did your fix to resolve bridging issues work
correctly with OpenIPMI?

We do not actively use the OpenIPMI driver, so we are not aware of its issues.
My point is that no other interface drivers need this additional
close/open. So, it might be worth to do it only for the OpenIPMI interface.
No more comments.
Regards,
Dmitry

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I have a similar approach to what you outlined, but I did not
find the
need to do
anything different the the "-m" command line switch. I've attached a
patch I've
been using to resolve the issue I was having and would appreciate any
feedback you
might have on my approach. The patch is for the CVS ipmitool source
code at TOB
this morning.
I changed ipmi_main() to always open the interface using either
0x20 or
the address
specified with the "-m" switch. With the code as it exists today,
open
is sometimes
done in main and sometimes done when the first IPMI request is made.
I found the
defer of the open quire problematic, so I changed the code to always do
the open prior
to the first IPMI request. After the initial open, I use the PICMG
get address info to
get the IPMB-0 address. If I was able to discover an address, I
close
and re-open
the interface with the discovered IPMB-0 address as I found this was
necessary to make
sure that the open ipmi driver had the correct address of the target
IPMB-0. Then, if bridging is
specified with "-t" and/or "-T", I get the bridge target IPMB-0 address
and store that away to
determine when bridging is necessary for sensors identified in the SDR
repository accessed via
the bridging command line arguments.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your understanding is correct. Moreover, we already have a patch which
solves the issue (in our local IPMITool repo). We are going to submit
the patch for this issue shortly.
And to the topic raised.
The sensor owner ID in the SDR in my opinion shall match with the IPMC
slave address on the primary IPMB bus (channel #0).
Since there are cases when the IPMC accessed from other channels (than
channel #0), like LAN, the slave address of the IPMC on that
channel
may
not match with the primary IPMB address.
- introduced a BMC address which can be overridden by "-m" command-line
parameter (default valuse is 20h). This address is used to access the
IPMC on which a session to establish a session (for LAN).
- then using Get PICMG Properties to check whether the board is a
PICMG-based system.
- use either Get Address Info for FRU #0 or fetch the Management
Controller Locator Record to query the IPMC slave address on the primary
IPMB.
- store the fetched slave address. it then used to match the sensor
owner ID to decide if the bridging to sensor is required on not.
- for the case when bridging is used, the stored slave address is used
to compose the Send Message command is return address.
Regards,
Dmitry

Post by Jim Mankovich
All,
I've been digging into various issue associated with ipmitool
bridging
on a PICMG
system and I wouldappreciate some help with understanding what the
actual intended
use of the bridging command line arguments was. There are two
different bridging
argument specifications, -t target_address/-b target_channel (single
bridge), and
-T transit_address/-B transit_channel (dual bridge).
When only -t is specified, single level bridging will be used to read
the SDR repository
if the address specified by -t is not equivalent to the ipmitool
identified IPMB-0 address.
Note: The ipmitool identified IPMB-0 address is either the default of
0x20, or specified
on the command line via the -m address switch, or discovered via PICMG
get address
info.
In addition to -t, you may also specify a transit address via -T.If a
transit address is
specified, dual bridging will be used to read the SDR
repository(via the
transit address
to get to the target identified via -t). The specification of a
transit address without a
target address is meaningless as the transit address is not used unless
there is a target
address specification with -t.
Does my description agree with your understanding of these switches
and
their use?
Now, in addition to bridging to read the SDR repository, bridging will
also occur to access
an individual sensor if the sensor owner id identified in the SDR
repository does not match
the ipmitool identified IPMB-0 address. This bridging will override
the specified target address
identified via the -t switch, but will make use of the transit address
(and dual bridge) when
both -t and -T are specified.
This bridging implementation has issues on the PICMG system I have
been
using when
addressing sensors whose owner id and channel specification in the SDR
repository do
not identify the exact same addressing that was used to read the SDR
repository.
For example:If a sensor identified in an SDR repository resides on
IPMB-0 (channel 0),
but the SDR repository was accessed via bridging on IPMB-L
(channel
7),
the sensor can't
be accessed with the current code because the sensor will be addressed
via bridging using
channel 0 (from the SDR repository)instead of channel 7 (from the -b
channel specification).
The problem is that when using bridging to access an SDR
repository, the
bridged SDR
repository destination may actually identify another IPMB-0 at the
bridged destination.
If this is the case, then the sensor can simply be read using the same
bridging as was
used to read the SDR repository.
On PICMG compliant systems, this issue can be resolved by getting the
IPMB-0 address
of the target and compare this target IPMB-0 address with the sensor
owner id/channel
number from the SDR repository.If the sensor owner id is equal to the
target IPMB-0
address and the sensor channel is 0, then the sensor can be accessed
using the same
addressing as was used to address the SDR repository.
I have some ipmitool changes in the works which resolve the sensor
bridging issue
I've described, but I need some insight from someone more familiar
with
PICMG and
sensor bridging to make sure my analysis of the problem I'm
seeing is
correct.
Thanks in advance,
Jim
--
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Ipmitool-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Jim Mankovich

2013-04-25 20:56:25 UTC

Dmitry, Dan,

In doing some testing on my system, I've found that the value of
the IPMB address doesn't make any difference when you do bridged
requests over lanplus. I believe the same is true for lan as well since
Dan's testing showed that the value specified with -m address didn't
make any difference in success or failure when used in conjunction
with a target address (-t). This is not the case when not doing bridging.

Post by Dmitry Bazhenov
Hello, Jim,
I need to think it through.
Since double bridging is used to access AMC modules, then I guess, it maybe not worth to bother with the discovered PICMG address in LAN or other interfaces.
Regards,
Dmitry

Post by Jim Mankovich
Dmitry,
See below,

Post by Dmitry Bazhenov
Hello, Jim,
Unfortunately, we can not change my_addr after discovering that the
IPMC address on the primary IPMB is different from what was used to
connect the IPMC.
Consider an example. A board is accessed via LAN using 20h as a slave
addres while the slave address on the primary IPMB is 90h. If we set
my_addr to 90h, all subsequent RMCP packets will be incorrectly
composed and discarded by the board.
For this case we should set another address value, e.g. my_ipmb_addr,
which defaults to my_addr but then can be changed via PICMG discovery.

I agree that the scenario you present above will cause failures for lan
interfaces if it it were to occur, but I don't believe it
would ever make sense for PICMG discovery over lan to return anything
except 20h if the interface were opened using 20h.
Nothing I did should change the way in which the lan interfaces work
IPMB addressing and PICMG discovery.
With my changes, the only interface which supports re-setting my_addr to
the IPMB discovered address is OpenIPMI.

Post by Dmitry Bazhenov
Regarding to the BRIDGE_TO_SENSOR macro, I am now convinced that it
should work as needed.

Good

Post by Dmitry Bazhenov
There is one more thing. Please, add PICMG Extension 5.0 (05h) for
MicroTCA.0 base specification.

Is this another version like PICMG_AMC_MAJOR_VERSION. If so, should it be,
PICMG_MICROTCA_MAJOR_VERSION or is something else more appropriate?

Post by Dmitry Bazhenov
Regards,
Dmitry

Post by Jim Mankovich
Hi Dmitry,
I've attached an update patch which removes the need to close/re-open
the interface when
the PICMG discovered IPMB address is found to be different than the IPMB
address used to
open the interface. A new per interface function was added to enable
setting the IPMB
address (if the interface supports it), and the OpenIPMI interface was
modified to provide this
interface. See the patch for details.
In putting together the BRIDGE_TO_SENSOR macro, I was working under the
assumption that channel
0 was always used to identify the primary IPMB Channel (per the IPMI
specification). This
is why I first qualify that the SDR sensor record channel is equal to
zero before I compare the
target_ipmb_addr (which is only set on PICMG platforms), with the SDR
sensor record address.
This comparison is intended to be true when the sensor is on an IPMB and
the target IPMB (as returned
by PICMG Get Address Info) matches the sensor address. If this is the
case, then this sensor does
not require any extra bridging beyond what was used to address the SDR
repository (PICMG
platforms only). If you would like me to explicitly run time verify
in the macro that this condition is PICMG
only, I can qualify it with intf->picmg_avail in addition to the
target_ipmb_addr test.
The second condition in the BRIDGE_TO_SENSOR macro simply looks to see
if the sensor record
address and channel exactly match the argument specified target address
and channel (-t <address>
-b <channel>). If this is true, then the sensor does not require any
extra bridging beyond what
was used to address the SDR repository (any platform). This second
condition check doesn't change
the current logic from what exists today, it just clarifies the case in
which no extra bridging is
necessary beyond what was specified on the ipmitool command line. If
this test really confuses folks, it
could be removed.
NOTE: With the code that currently exists today in ipmitool, the address
of the sensor from the SDR repository
always overwrites the interface target address and target channel prior
to accessing the sensor
via the interface sendrecv routine. Then in the interface sendrecv
routines, bridging requests will be
built using the target address (target_addr) and channel
(target_channel) if the target_addr doesn't match the
interface address (my_addr).
I did not intend to change how sensors are addressed via bridging on non
PICMG platforms.
Thanks in Advance,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Please, see my comments mixed in.

Post by Jim Mankovich
Dmitry,
See my comments below.
Thanks,
Jim

Post by Dmitry Bazhenov
Hello, Jim,
Your approach has technical and logical flaws.
In technical part, all interface drivers shall be ensured to use
correct IPMB address when establishing or closing session/interface.
This especially regards to LAN and LAN+ drivers. Since some library
functionality may close and re-open the interface during its work (as
does HPM.1), this may cause problems. Also, a correct address must be
used for bridging (when composing a Send Message request).

I did not intended to do anything which would invalidate using "correct
IPMB when establishing or closing session/interface. But, I did need
to close/re-open to connect to the discovered IPMB address when I ran
across the issue with OpenIPMI. See my answer to your specific
question associated with OpenIPMI below.

Understood. But, still, there is an issue with the Send Message
request when performing bridging or double bridging using the LAN
interfaces. Though, it is a separate issue.

Post by Dmitry Bazhenov
In logical part, when bridging is used, we must perform the address
retrieval procedure not only on the IPMC on which the interface was
opened, but on the target IPMC as well. And the second acquired
address must be used in sensor owner ID comparison to decide if
bridging is required or not. It might be, if double bridging is used
to access the target IPMC, that sensor values are unreachable.

Using the second acquired address for sensor owner ID comparison for
bridging was my intent with the change I made. Did you see something
that indicated this was not what I was doing? Also, the channel
number has to be used in the comparison as well since it is part of
addressing identified in the sensor entries in the SDR repository.

You're right. I have missed it at the first time.
First: in my opinion, the channel comparison is wrong in the
BRIDGE_TO_SENSOR macro. The local channel number on the target IPMC
may not match with the channel number used to access the target IPMC
(intf->target_channel).
For example, for PICMG-defined Carrier IPMC, the channel for accessing
an AMC module is 7, while for the AMC module, the same channel is 0.
I understand that it is likely for PICMG systems that the first check
in the macro succeeds and the second check does not really matter.
But I am not sure that there will be no problem with other system types.
Second, the target address and channel substitution may be wrong too.
This works only if intf->target_channel can be used to access the
sensor owner, but it may not be the case. So, in some situation,
additional bridging step is needed. If a double bridging is already
used, such sensors may not be even reachable.
However, I can not imaging systems where such situation is possible.
So, this is rather theoretical issue.

Post by Dmitry Bazhenov
Also, since not all IPMCs are PICMG-based, it maybe not correct to use
the Get Address Info command for the target IPMC address
retrieval. It
is better to fetch the Management Controller Locator record instead
(implement this retrieval in ipmi_sdr.c or ipmi_sensor.c).

I could certainly do this on non PICMG-based systems, but isn't it
possible that there could be more than one Management Controller Locator
record in the target SDR repository? If there can be more than one,
how do you know which one to use?

There can be several MC locators for non-PICMG systems. PICMG-systems
contain only one MC locator and several FRU Device locators for
subsidiary FRUs.
I suggest fetching the target_ipmb_addr only for PICMG-based systems.

Post by Dmitry Bazhenov
And regarding to the OpenIPMI interface driver. Is it possible to set
another IPMC address without closing and re-opening interface? Other
interface drivers seem not require such procedure.

The OpenIPMI interface has the ability to set the address vial
IPMICTL_SET_MY_ADDRESS_CMD, and I believe this could be used to avoid
the close/re-open. Did your fix to resolve bridging issues work
correctly with OpenIPMI?

We do not actively use the OpenIPMI driver, so we are not aware of its issues.
My point is that no other interface drivers need this additional
close/open. So, it might be worth to do it only for the OpenIPMI interface.
No more comments.
Regards,
Dmitry