Re: Crypto backend in freeipmi

[Al Chu]

Hi pavel,

Great, gimme a little time to do that refactor.  I can ping you off-list 
when it's done.


Al

On 6/26/24 11:29, Pavel Cahyna wrote:

Hi Al,

thank you for your quick reply, yes, if you can do a refactor to make
this work easier, that would be great! My colelagues more experienced
with crypto recommend to not introduce wrappers ass they would make the
code much more complicated especially if there are only a few uses. Here
are two examples of code with configurable crypto backends:

https://urldefense.us/v3/__https://github.com/aide/aide/pull/164/files__;!!G2kpM7uM-TzIFchu!3MX84O25FdmuZ4MxTNfHV_dnmsLTtDRqo8Jbi9uJ9XAUDvO4m2fZLlXk2FT6LPsJ4nsLiGWNKFbIqVHu$

and
https://urldefense.us/v3/__https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/md_crypto.c__;!!G2kpM7uM-TzIFchu!3MX84O25FdmuZ4MxTNfHV_dnmsLTtDRqo8Jbi9uJ9XAUDvO4m2fZLlXk2FT6LPsJ4nsLiGWNKGeouan9$
https://urldefense.us/v3/__https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/md_gcrypt.c__;!!G2kpM7uM-TzIFchu!3MX84O25FdmuZ4MxTNfHV_dnmsLTtDRqo8Jbi9uJ9XAUDvO4m2fZLlXk2FT6LPsJ4nsLiGWNKBwu3d2e$

(my understanding is that the first one uses ifdefs, in the second one
there is one file for each implementation).

Best regards, Pavel

On Wed, Jun 26, 2024 at 11:10:41AM -0700, Al Chu wrote:

Hi Pavel,

You guessed correctly, linking with libgcrypt was specifically due to
licensing issues with openssl when I wrote all that code eons ago (e
2005-ish?).

Skimming the libfreeipmi code, I think the `libcommon/ipmi-crypt.c` file is
the only place that needs modification.  There's a lot of macros
WITH_ENCRYPTION macos lingering in there, so we probably need to refactor
out a "gcrypt" and "openssl" into their own files.

If you'd like I can do a mini-refactor to get the gcrypt code into it's own
file.  That way you can hopefully just pug in a openssl equivalent
implementation?

Al

On 6/26/24 10:39, Pavel Cahyna wrote:

Hello,

I would like to ask about the crypto backend used by freeipmi. Currently
it is using libgcrypt for AES cipher and digests. This library is less
used and less actively developed than other crypto libraries, which
makes one less confident using it. Other crypto libraries also have the
advantage of easier certification and better integration with system
crypto policies for users who care about this. I thus propose adding
support for another (better supported) crypto library. This would be
selected at compile time (no pluggable modules or anything runtime like
that).

Choices for the other library are GnuTLS or OpenSSL. For OpenSSL one
will find many more tutorials and examples as it is much more widely
used and many more people are more or less familiar with it, so I think
it should be the preferred choice. In the past its license used to be a
problem for GPL programs, but now it is relicensed to the Apache 2
License in part to make it directly compatible with GPLv3 programs, so
there is no problem there. But GnuTLS would be ok as well.

Have there been any plans for such a change? If not, what do you think
about it? If we reach an agreement on this, I can start working on the
change and send patches.

Best regards,
Pavel Cahyna
Red Hat



--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory



--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: Crypto backend in freeipmi

[Al Chu]

Hi Pavel,

You guessed correctly, linking with libgcrypt was specifically due to 
licensing issues with openssl when I wrote all that code eons ago (e 
2005-ish?).


Skimming the libfreeipmi code, I think the `libcommon/ipmi-crypt.c` file 
is the only place that needs modification.  There's a lot of macros 
WITH_ENCRYPTION macos lingering in there, so we probably need to 
refactor out a "gcrypt" and "openssl" into their own files.


If you'd like I can do a mini-refactor to get the gcrypt code into it's 
own file.  That way you can hopefully just pug in a openssl equivalent 
implementation?


Al

On 6/26/24 10:39, Pavel Cahyna wrote:

Hello,

I would like to ask about the crypto backend used by freeipmi. Currently
it is using libgcrypt for AES cipher and digests. This library is less
used and less actively developed than other crypto libraries, which
makes one less confident using it. Other crypto libraries also have the
advantage of easier certification and better integration with system
crypto policies for users who care about this. I thus propose adding
support for another (better supported) crypto library. This would be
selected at compile time (no pluggable modules or anything runtime like
that).

Choices for the other library are GnuTLS or OpenSSL. For OpenSSL one
will find many more tutorials and examples as it is much more widely
used and many more people are more or less familiar with it, so I think
it should be the preferred choice. In the past its license used to be a
problem for GPL programs, but now it is relicensed to the Apache 2
License in part to make it directly compatible with GPLv3 programs, so
there is no problem there. But GnuTLS would be ok as well.

Have there been any plans for such a change? If not, what do you think
about it? If we reach an agreement on this, I can start working on the
change and send patches.

Best regards,
Pavel Cahyna
Red Hat



--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: Possible uninitialized value since commit 478ffaa7 ipmi-config: correct IPv6 dynamic address checkout error

[Al Chu]

Hey Pavel,

That's awesome.  Thanks!

Al

On 2/21/24 13:09, Pavel Cahyna wrote:

On Wed, Feb 21, 2024 at 09:50:35AM -0800, Al Chu wrote:

Yeah, to verify you'd need a BMC that has the ability to configure a dynamic
IP address.

I found that I have such a system, actually, so I tried the old and new
(with yout patch below) build.

Old:
# ipmi-config --checkout -e Lan6_Conf:IPv6_Dynamic_Address_Source_Type
Section Lan6_Conf
 ## READ-ONLY
 ## IPv6_Dynamic_Address_Source_Type
EndSection

# valgrind ipmi-config --checkout -e Lan6_Conf:IPv6_Dynamic_Address_Source_Type
==26033== ERROR SUMMARY: 264 errors from 46 contexts (suppressed: 0 from 0)

New:
# ipmi-config --checkout -e Lan6_Conf:IPv6_Dynamic_Address_Source_Type
Section Lan6_Conf
 ## READ-ONLY
 ## IPv6_Dynamic_Address_Source_Type   SLAAC
EndSection
# valgrind ipmi-config --checkout -e Lan6_Conf:IPv6_Dynamic_Address_Source_Type
==25466== ERROR SUMMARY: 256 errors from 38 contexts (suppressed: 0 from 0)

Certainly looks like an improvement!

Thank you, Pavel


here's the patch i just commited upstream

https://urldefense.us/v3/__https://github.com/chu11/freeipmi-mirror/commit/41d0d70f09b4becfceef0517543cbf335c0e927a__;!!G2kpM7uM-TzIFchu!2HMNiudAcfaP44Pib4TZCpqSnrhLps0kj1vNwcboaXeZSNMQ9A_r50dIclZ2ssPfkCAuzKGS9UAX--Gj$

Thanks for the catch

Oh and I got an e-mail that said you subscribed to freeipmi-devel today?
I'm not sure what was up with gnu's mailman, but hopefully it's fixed now.

Al

On 2/21/24 09:25, Pavel Cahyna wrote:

On Wed, Feb 21, 2024 at 09:04:13AM -0800, Al Chu wrote:

On 2/21/24 03:37, Pavel Cahyna wrote:

[ please Cc: me in replies, I am not subscribed and my attempt to
subscribe hits "Bug in Mailman version 2.1.29" .]

Hello Al,


certain fields are only used for static vs dynamic addresses, so only specific 
ones need to be initialized as long as things are programmed correctly.

IIRC, the patch below fixed the mistake that I used "source" instead of 
"source_type" for dynamic addresses.

that's my point - the patch below initializes "source_type" and leaves
"source" uninitialized, but then it keeps using "ipv6_data.source". To
me, the patch seems incomplete and
 
get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
looks like it should be changed to
 
get_dynamic_address_source_type_string (ipv6_data.source_type)) < 0)

Ohhh, I get it now.  I misread the prior e-mail.  Yeah, I think you're
right, that doesn't look right at all.

Thanks for the catch.  I can get this fixed sometime today.

I assume you hit this bug?  Is it critical for a new release?

I have not hit the bug, I am not using ipmi-config myself, actually. The
bug was found by a static code scanner. Do you know how would one
reproduce it or in general test this code? I suppose this needs a BMC
with an IPv6 address configured?

It is not entirely critical, but I would prefer not to update to a
release which has a coding error added. If you have a patch, I will add
it to the CentOS Stream and Fedora packages.

Regards, Pavel


Al


What do you think? If not, I don't see where does ipv6_data.source get
initialized.

Regards, Pavel

On Tue, Feb 20, 2024 at 05:03:46PM +0100, Pavel Cahyna wrote:

Hello,

I have a question about this commit:

commit 478ffaa7d2ffe240a0afaf9d7d5189342c94bd4d
Author: Albert Chu 
Date:   Wed Jan 26 21:48:47 2022 -0800

   ipmi-config: correct IPv6 dynamic address checkout error


It contains this change:

-
@@ -1089,15 +1090,15 @@ _get_ipv6_dynamic_address (ipmi_config_state_data_t 
*state_data,
  goto cleanup;
}

-  if (FIID_OBJ_GET (obj_cmd_rs, "source", ) < 0)
+  if (FIID_OBJ_GET (obj_cmd_rs, "source_type", ) < 0)
{
  pstdout_fprintf (state_data->pstate,
   stderr,
-   "fiid_obj_get: 'source': %s\n",
+   "fiid_obj_get: 'source_type': %s\n",
   fiid_obj_errormsg (obj_cmd_rs));
  goto cleanup;
}
-  ipv6_data->source = val;
+  ipv6_data->source_type = val;

  if (fiid_obj_get_data (obj_cmd_rs,
 "address",
-


which, IIUC, leaves ipv6_data->source uninitialized.

It then contains this change:
-
@@ -1186,7 +1187,7 @@ ipv6_dynamic_address_source_checkout 
(ipmi_config_state_data_t *state_data,

  if (ipmi_config_section_update_keyvalue_output (state_data,
  kv,
-  
get_dynamic_address_source_string (ipv6_data.source)) < 0)
+  
get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
return (IPMI_CONFIG_ERR_FATAL_ERROR);

Re: Possible uninitialized value since commit 478ffaa7 ipmi-config: correct IPv6 dynamic address checkout error

[Al Chu]

Yeah, to verify you'd need a BMC that has the ability to configure a 
dynamic IP address.


here's the patch i just commited upstream

https://github.com/chu11/freeipmi-mirror/commit/41d0d70f09b4becfceef0517543cbf335c0e927a

Thanks for the catch

Oh and I got an e-mail that said you subscribed to freeipmi-devel 
today?  I'm not sure what was up with gnu's mailman, but hopefully it's 
fixed now.


Al

On 2/21/24 09:25, Pavel Cahyna wrote:

On Wed, Feb 21, 2024 at 09:04:13AM -0800, Al Chu wrote:

On 2/21/24 03:37, Pavel Cahyna wrote:

[ please Cc: me in replies, I am not subscribed and my attempt to
subscribe hits "Bug in Mailman version 2.1.29" .]

Hello Al,


certain fields are only used for static vs dynamic addresses, so only specific 
ones need to be initialized as long as things are programmed correctly.

IIRC, the patch below fixed the mistake that I used "source" instead of 
"source_type" for dynamic addresses.

that's my point - the patch below initializes "source_type" and leaves
"source" uninitialized, but then it keeps using "ipv6_data.source". To
me, the patch seems incomplete and

get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
looks like it should be changed to

get_dynamic_address_source_type_string (ipv6_data.source_type)) < 0)

Ohhh, I get it now.  I misread the prior e-mail.  Yeah, I think you're
right, that doesn't look right at all.

Thanks for the catch.  I can get this fixed sometime today.

I assume you hit this bug?  Is it critical for a new release?

I have not hit the bug, I am not using ipmi-config myself, actually. The
bug was found by a static code scanner. Do you know how would one
reproduce it or in general test this code? I suppose this needs a BMC
with an IPv6 address configured?

It is not entirely critical, but I would prefer not to update to a
release which has a coding error added. If you have a patch, I will add
it to the CentOS Stream and Fedora packages.

Regards, Pavel


Al


What do you think? If not, I don't see where does ipv6_data.source get
initialized.

Regards, Pavel

On Tue, Feb 20, 2024 at 05:03:46PM +0100, Pavel Cahyna wrote:

Hello,

I have a question about this commit:

commit 478ffaa7d2ffe240a0afaf9d7d5189342c94bd4d
Author: Albert Chu 
Date:   Wed Jan 26 21:48:47 2022 -0800

  ipmi-config: correct IPv6 dynamic address checkout error


It contains this change:

-
@@ -1089,15 +1090,15 @@ _get_ipv6_dynamic_address (ipmi_config_state_data_t 
*state_data,
 goto cleanup;
   }

-  if (FIID_OBJ_GET (obj_cmd_rs, "source", ) < 0)
+  if (FIID_OBJ_GET (obj_cmd_rs, "source_type", ) < 0)
   {
 pstdout_fprintf (state_data->pstate,
  stderr,
-   "fiid_obj_get: 'source': %s\n",
+   "fiid_obj_get: 'source_type': %s\n",
  fiid_obj_errormsg (obj_cmd_rs));
 goto cleanup;
   }
-  ipv6_data->source = val;
+  ipv6_data->source_type = val;

 if (fiid_obj_get_data (obj_cmd_rs,
"address",
-


which, IIUC, leaves ipv6_data->source uninitialized.

It then contains this change:
-
@@ -1186,7 +1187,7 @@ ipv6_dynamic_address_source_checkout 
(ipmi_config_state_data_t *state_data,

 if (ipmi_config_section_update_keyvalue_output (state_data,
 kv,
-  
get_dynamic_address_source_string (ipv6_data.source)) < 0)
+  
get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
   return (IPMI_CONFIG_ERR_FATAL_ERROR);

 rv = IPMI_CONFIG_ERR_SUCCESS;
-

which keeps using ipv6_data.source, which looks uninitialized. This looks 
suspect, but I admit I
don't really understand the code.

Best regards, Pavel

--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory


--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: Possible uninitialized value since commit 478ffaa7 ipmi-config: correct IPv6 dynamic address checkout error

[Al Chu]

On 2/21/24 03:37, Pavel Cahyna wrote:

[ please Cc: me in replies, I am not subscribed and my attempt to
subscribe hits "Bug in Mailman version 2.1.29" .]

Hello Al,


certain fields are only used for static vs dynamic addresses, so only specific 
ones need to be initialized as long as things are programmed correctly.

IIRC, the patch below fixed the mistake that I used "source" instead of 
"source_type" for dynamic addresses.

that's my point - the patch below initializes "source_type" and leaves
"source" uninitialized, but then it keeps using "ipv6_data.source". To
me, the patch seems incomplete and
   
get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
looks like it should be changed to
   
get_dynamic_address_source_type_string (ipv6_data.source_type)) < 0)


Ohhh, I get it now.  I misread the prior e-mail.  Yeah, I think you're 
right, that doesn't look right at all.


Thanks for the catch.  I can get this fixed sometime today.

I assume you hit this bug?  Is it critical for a new release?

Al


What do you think? If not, I don't see where does ipv6_data.source get
initialized.

Regards, Pavel

On Tue, Feb 20, 2024 at 05:03:46PM +0100, Pavel Cahyna wrote:

Hello,

I have a question about this commit:

commit 478ffaa7d2ffe240a0afaf9d7d5189342c94bd4d
Author: Albert Chu 
Date:   Wed Jan 26 21:48:47 2022 -0800

 ipmi-config: correct IPv6 dynamic address checkout error


It contains this change:

-
@@ -1089,15 +1090,15 @@ _get_ipv6_dynamic_address (ipmi_config_state_data_t 
*state_data,
goto cleanup;
  }

-  if (FIID_OBJ_GET (obj_cmd_rs, "source", ) < 0)
+  if (FIID_OBJ_GET (obj_cmd_rs, "source_type", ) < 0)
  {
pstdout_fprintf (state_data->pstate,
 stderr,
-   "fiid_obj_get: 'source': %s\n",
+   "fiid_obj_get: 'source_type': %s\n",
 fiid_obj_errormsg (obj_cmd_rs));
goto cleanup;
  }
-  ipv6_data->source = val;
+  ipv6_data->source_type = val;

if (fiid_obj_get_data (obj_cmd_rs,
   "address",
-


which, IIUC, leaves ipv6_data->source uninitialized.

It then contains this change:
-
@@ -1186,7 +1187,7 @@ ipv6_dynamic_address_source_checkout 
(ipmi_config_state_data_t *state_data,

if (ipmi_config_section_update_keyvalue_output (state_data,
kv,
-  
get_dynamic_address_source_string (ipv6_data.source)) < 0)
+  
get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
  return (IPMI_CONFIG_ERR_FATAL_ERROR);

rv = IPMI_CONFIG_ERR_SUCCESS;
-

which keeps using ipv6_data.source, which looks uninitialized. This looks 
suspect, but I admit I
don't really understand the code.

Best regards, Pavel


--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: Possible uninitialized value since commit 478ffaa7 ipmi-config: correct IPv6 dynamic address checkout error

[Al Chu]

Hi,

It's always possible that I messed up something, but it appears that

```
struct ipv6_address_data {
  uint8_t source;   /* static */
  uint8_t source_type;  /* dynamic */
  uint8_t enable;   /* static */
  uint8_t address[IPMI_IPV6_BYTES];
  uint8_t address_prefix_length;
  uint8_t address_status;
};

```

certain fields are only used for static vs dynamic addresses, so only 
specific ones need to be initialized as long as things are programmed 
correctly.


IIRC, the patch below fixed the mistake that I used "source" instead of 
"source_type" for dynamic addresses.


Al

On 2/20/24 08:03, Pavel Cahyna wrote:

Hello,

I have a question about this commit:

commit 478ffaa7d2ffe240a0afaf9d7d5189342c94bd4d
Author: Albert Chu 
Date:   Wed Jan 26 21:48:47 2022 -0800

 ipmi-config: correct IPv6 dynamic address checkout error


It contains this change:

-
@@ -1089,15 +1090,15 @@ _get_ipv6_dynamic_address (ipmi_config_state_data_t 
*state_data,
goto cleanup;
  }

-  if (FIID_OBJ_GET (obj_cmd_rs, "source", ) < 0)
+  if (FIID_OBJ_GET (obj_cmd_rs, "source_type", ) < 0)
  {
pstdout_fprintf (state_data->pstate,
 stderr,
-   "fiid_obj_get: 'source': %s\n",
+   "fiid_obj_get: 'source_type': %s\n",
 fiid_obj_errormsg (obj_cmd_rs));
goto cleanup;
  }
-  ipv6_data->source = val;
+  ipv6_data->source_type = val;

if (fiid_obj_get_data (obj_cmd_rs,
   "address",
-


which, IIUC, leaves ipv6_data->source uninitialized.

It then contains this change:
-
@@ -1186,7 +1187,7 @@ ipv6_dynamic_address_source_checkout 
(ipmi_config_state_data_t *state_data,

if (ipmi_config_section_update_keyvalue_output (state_data,
kv,
-  
get_dynamic_address_source_string (ipv6_data.source)) < 0)
+  
get_dynamic_address_source_type_string (ipv6_data.source)) < 0)
  return (IPMI_CONFIG_ERR_FATAL_ERROR);

rv = IPMI_CONFIG_ERR_SUCCESS;
-

which keeps using ipv6_data.source, which looks uninitialized. This looks 
suspect, but I admit I
don't really understand the code.

Best regards, Pavel



--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

FreeIPMI 1.6.14 Released

[Al Chu]

Oops!

FreeIPMI 1.6.14 - 01/27/24
--
o Fix build issue common to non-x86 systems.

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.14.tar.gz

Al

--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

FreeIPMI 1.6.12 & 1.6.13 Released

[Al Chu]

FreeIPMI 1.6.12 and 1.6.13 released

It's a special 2 for 1 release special.  Approximately two months ago I 
tagged for release, but forgot to upload/announce it.  So two tags 
released today :-)


FreeIPMI 1.6.12 - 11/19/23
--
o Use poll() over select() to avoid fd limit in openipmi driver.
o Fix potential portability problems on systems without cbrt().
o Minor documentation updates.

FreeIPMI 1.6.13 - 01/26/24
--
o Fix build issues on systems where inb/outb are declared with inline
  assembly.
o Add additional sensor/event interpretations.

Al

--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: Add supermicro PowerSupply to freeipmi please

[Al Chu]

A bunch of x9dr7 and sc-826TQ works only for FRU addresses.


Does

ipmi-oem supermicro get-power-supply-status 1|2|3

work for the older ones?

Al

On 9/4/23 21:46, Андрей Грехов wrote:

Hi.
Понедельник,  4 сентября 2023, 22:27 +07:00 от "Al Chu" :

Hi,

I believe this is already implemented via

ipmi-oem supermicro get-pmbus-power-supply-status 1|2|3

If you can confirm, I can document that it works on X9DRD too.

I confirm.
But it depends more on the type of case.
Works for me on cs-825TQ.
Which are connected by i1c connector "power 5 pin" and protocol PMBus
(or old FRU)

This should work from X8 to X11 "power 5 pin".
I have X7DBE-X, but it works very unstable.

A bunch of x9dr7 and sc-826TQ works only for FRU addresses.
ipmitool -H $host -U $user -P $pass raw 0x06 0x52 0x05 0x$address 0x01 0x$d3
$address = 70|72|74

PWS-720-R
$d3 :
0xA Temp, C
0xB Fan1, RPM=$izm*114,5
0xС Fan2, RPM *114,5
--
There is no desire to add support for reading modern power supplies over the 
PMBus (rev 1.0,1.1,1.2) ?


Al

On 9/4/23 05:23, Андрей Грехов wrote:

This working X9drd. PMBus rev.1.1-1.4

ipmitool -H $host -U $user -P $pass raw 0x06 0x52 0x07 0x78 0x01 0x88

InputVoltage

0x78 first PowerSupply
0x7a second PowerSupply
raw 0x06 0x52 0x07 0x78 0x01 0x90 Fan1
raw 0x06 0x52 0x07 0x78 0x01 0x91 Fan2

The's my old articl.

Андрей Грехов

--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory



Андрей Грехов


--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: Add supermicro PowerSupply to freeipmi please

[Al Chu]

Hi,

I believe this is already implemented via

ipmi-oem supermicro get-pmbus-power-supply-status 1|2|3

If you can confirm, I can document that it works on X9DRD too.

Al

On 9/4/23 05:23, Андрей Грехов wrote:

This working X9drd. PMBus rev.1.1-1.4

ipmitool -H $host -U $user -P $pass raw 0x06 0x52 0x07 0x78 0x01 0x88 
InputVoltage
0x78 first PowerSupply
0x7a second PowerSupply
raw 0x06 0x52 0x07 0x78 0x01 0x90 Fan1
raw 0x06 0x52 0x07 0x78 0x01 0x91 Fan2

The's my old articl.

Андрей Грехов


--
Al Chu
Livermore Computing
Lawrence Livermore National Laboratory

Re: [PATCH 3/3] configure.ac: Use AC_USE_SYSTEM_EXTENSIONS instead of appending -D_GNU_SOURCE

[Al Chu]

Thanks, these all look.  Applied all to master and will backport to 1.6.X 
stable branch.

Al

On 11/3/22 19:12, Sam James wrote:
> This achieves the same effect as it'll use -D_GNU_SOURCE when possible
> but it ensures we never forget it in an individual Makefile.am.
>
> AC_USE_SYSTEM_EXTENSIONS was introduced in autoconf 2.60, so we bump
> the requirement from 2.57->2.60. Given the comment mentions "modern
> autoconf and automake", we could really justify bumping this to 2.69
> which itself is not exactly brand new, if we want.
>
> Signed-off-by: Sam James 
> ---
>  bmc-device/Makefile.am | 1 -
>  bmc-info/Makefile.am   | 1 -
>  bmc-watchdog/Makefile.am   | 1 -
>  common/debugutil/Makefile.am   | 1 -
>  common/miscutil/Makefile.am| 1 -
>  common/parsecommon/Makefile.am | 1 -
>  common/pingtool/Makefile.am| 1 -
>  common/portability/Makefile.am | 1 -
>  common/toolcommon/Makefile.am  | 1 -
>  configure.ac   | 4 +++-
>  ipmi-chassis/Makefile.am   | 1 -
>  ipmi-config/Makefile.am| 1 -
>  ipmi-dcmi/Makefile.am  | 1 -
>  ipmi-fru/Makefile.am   | 1 -
>  ipmi-locate/Makefile.am| 1 -
>  ipmi-oem/Makefile.am   | 1 -
>  ipmi-pet/Makefile.am   | 1 -
>  ipmi-raw/Makefile.am   | 1 -
>  ipmi-sel/Makefile.am   | 1 -
>  ipmi-sensors/Makefile.am   | 1 -
>  ipmiconsole/Makefile.am| 1 -
>  ipmidetect/Makefile.am | 1 -
>  ipmidetectd/Makefile.am| 1 -
>  ipmiping/Makefile.am   | 3 +--
>  ipmipower/Makefile.am  | 1 -
>  ipmiseld/Makefile.am   | 1 -
>  libfreeipmi/Makefile.am| 1 -
>  libipmiconsole/Makefile.am | 1 -
>  libipmimonitoring/Makefile.am  | 1 -
>  rmcpping/Makefile.am   | 3 +--
>  30 files changed, 5 insertions(+), 32 deletions(-)
>
> diff --git a/bmc-device/Makefile.am b/bmc-device/Makefile.am
> index 6b1f05771..d229ab4f5 100644
> --- a/bmc-device/Makefile.am
> +++ b/bmc-device/Makefile.am
> @@ -7,7 +7,6 @@ bmc_device_CPPFLAGS = \
>   -I$(top_srcdir)/common/portability \
>   -I$(top_builddir)/libfreeipmi/include \
>   -I$(top_srcdir)/libfreeipmi/include \
> - -D_GNU_SOURCE \
>   -D_REENTRANT
>  
>  bmc_device_LDADD = \
> diff --git a/bmc-info/Makefile.am b/bmc-info/Makefile.am
> index fb043c343..8c263c113 100644
> --- a/bmc-info/Makefile.am
> +++ b/bmc-info/Makefile.am
> @@ -7,7 +7,6 @@ bmc_info_CPPFLAGS = \
>   -I$(top_srcdir)/common/portability \
>   -I$(top_builddir)/libfreeipmi/include \
>   -I$(top_srcdir)/libfreeipmi/include \
> - -D_GNU_SOURCE \
>   -D_REENTRANT
>  
>  bmc_info_LDADD = \
> diff --git a/bmc-watchdog/Makefile.am b/bmc-watchdog/Makefile.am
> index be392dd96..99d6655c2 100644
> --- a/bmc-watchdog/Makefile.am
> +++ b/bmc-watchdog/Makefile.am
> @@ -7,7 +7,6 @@ bmc_watchdog_CPPFLAGS = \
>   -I$(top_srcdir)/common/portability \
>   -I$(top_builddir)/libfreeipmi/include \
>   -I$(top_srcdir)/libfreeipmi/include \
> - -D_GNU_SOURCE \
>   -D_REENTRANT \
>   -DBMC_WATCHDOG_LOCALSTATEDIR='"$(localstatedir)"'
>  
> diff --git a/common/debugutil/Makefile.am b/common/debugutil/Makefile.am
> index 16ba9cba7..48595accf 100644
> --- a/common/debugutil/Makefile.am
> +++ b/common/debugutil/Makefile.am
> @@ -5,7 +5,6 @@ libdebugutil_la_CPPFLAGS = \
>   -I$(top_srcdir)/common/portability \
>   -I$(top_builddir)/libfreeipmi/include \
>   -I$(top_srcdir)/libfreeipmi/include \
> - -D_GNU_SOURCE \
>   -D_REENTRANT
>  
>  libdebugutil_la_SOURCES = \
> diff --git a/common/miscutil/Makefile.am b/common/miscutil/Makefile.am
> index 7bd0c7687..5da082e72 100644
> --- a/common/miscutil/Makefile.am
> +++ b/common/miscutil/Makefile.am
> @@ -2,7 +2,6 @@ noinst_LTLIBRARIES = \
>   libmiscutil.la
>  
>  libmiscutil_la_CPPFLAGS = \
> - -D_GNU_SOURCE \
>   -D_REENTRANT
>  
>  libmiscutil_la_SOURCES = \
> diff --git a/common/parsecommon/Makefile.am b/common/parsecommon/Makefile.am
> index 3b2f42992..d4665993d 100644
> --- a/common/parsecommon/Makefile.am
> +++ b/common/parsecommon/Makefile.am
> @@ -5,7 +5,6 @@ libparsecommon_la_CPPFLAGS = \
>   -I$(top_srcdir)/common/portability \
>   -I$(top_builddir)/libfreeipmi/include \
>   -I$(top_srcdir)/libfreeipmi/include \
> - -D_GNU_SOURCE \
>   -D_REENTRANT
>  
>  libparsecommon_la_SOURCES = \
> diff --git a/common/pingtool/Makefile.am b/common/pingtool/Makefile.am
> index c37e1a825..66080a6c7 100644
> --- a/common/pingtool/Makefile.am
> +++ b/common/pingtool/Makefile.am
> @@ -6,7 +6,6 @@ libpingtool_la_CPPFLAGS = \
>   -I$(top_srcdir)/common/toolcommon \
>   -I$(top_builddir)/libfreeipmi/include \
>   -I$(top_srcdir)/libfreeipmi/include \
> - -D_GNU_SOURCE \
>   -D_REENTRANT
>  
>  libpingtool_la_SOURCES = \
> diff --git a/common/portability/Makefile.am b/common/portability/Makefile.am
> index 020c39e26..d00428e9a 100644
> --- a/common/portability/Makefile.am
> +++ 

FreeIPMI 1.6.9 Released

[Al Chu]

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.9.tar.gz

o Support --with-systemconfigdir build option.
o Fix build issue on musl where putmsg/getmsg are not available.
o Fix build issue when inb/outb are not available on some systems.
o Fix static build issues with gcrypt.
o Add conserver documentation in faq.
o Minor documentation updates.

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Re: Reading a sensor (fan) in C

[Al Chu]

Hi Ian,

It will be a tad slow going unfortunately, as you're trying to do
multiple steps :-)  My recommendation:

- look at the code at bmc-info (which is far simpler), use that to get
an idea of how to setup an IPMI connection.

- once you get that, look at the code ipmi-sensors to see how to read
the current fan speed.  It'll involve the "sdr" library in libfreeipmi,
then the "sensor-read" library in libfreeipmi. 

- then via code in ipmi-raw, you can see how to write raw data.

Hope that atleast provides hints.  You're sort of doing multiple steps
that typically aren't done together.  But feel free to ping this list
as you're moving along.

Al

On Mon, 2021-03-15 at 18:55 -0500, Ian Pilcher wrote:
> I want to write a simple program to manage the fan speeds on my
> Super-
> Micro server.  (The fan management "modes" provided by the BMC simply
> aren't able to achieve a good balance of noise and temperature.)
> 
> The program will need to read fan speeds via IPMI and send "raw"
> commands to set the fan duty cycles[1].  (CPU temperatures can be
> read
> from sysfs, and HDD temperatures can be read with libatasmart.)
> 
> So I'm trying to figure out how to read a fan sensor by looking at
> the
> FreeIPMI source code (particularly ipmi-sensors), but it's slow
> going.
> 
> Can anyone provide an overview of the steps needed?
> 
> Thanks!
>   [1] 
> https://urldefense.us/v3/__https://forums.servethehome.com/index.php?resources*supermicro-x9-x10-x11-fan-speed-control.20*__;Ly8!!G2kpM7uM-TzIFchu!ikpXmktiCoxQwp2t5-l7gnU4fmOH2kdwp1q1O1459i3EZ3_j1c6dZsxNl9slmVvN$
>  
> 
> 

Re: Lower freeipmi.conf permission as it could contain sensitive informations

[Al Chu]

On Sun, 2021-02-07 at 19:34 +0100, Fabio Fantoni wrote:
> Il 07/02/2021 19:10, Al Chu ha scritto:
> > Hi Fabio,
> > 
> > Thanks, I've decreased it and other conf files to 640.  I never
> > caught
> > this b/c the permissions were overwritten to 0600 in the RPM spec
> > files.
> 
> thanks, decrease all conf files is not needed if not all them can
> contain sensitive informations (like username/password) FWIK, I did a
> fast look and seems:
> 
> - freeipmi.conf ipmiseld.conf libipmiconsole.conf can contain
> sensitive
> informations
> 
> - freeipmi_interpret_sel.conf freeipmi_interpret_sensor.conf
> ipmidetect.conf ipmidetectd.conf don't can contain sensitive
> informations
> 
> is it correct?

I decided to decrease all the conf files to 0640 except for the
"freeipmi_interpret_*.conf" files.  

Al


> 
> > 
> > Al
> > 
> > On Sun, 2021-02-07 at 13:17 +0100, Fabio Fantoni wrote:
> > > Hi, freeipmi.conf could contain sensitive informations, default
> > > permission setted to it by build (in etc/Makefile.am) is 644,
> > > debian
> > > decreased it in packaging after build very long time ago
> > > (
> > > https://salsa.debian.org/debian/freeipmi/-/blob/master/debian/rules
> > > )
> > > .
> > > 
> > > I think is good decrease it also upstream from 644 to 640
> > > (removing
> > > read
> > > permission to others).
> > > 
> > > Thanks for any reply and sorry for my bad english.
> > > 
> > > 
> 
> 

Re: ipmi-console doesn't need root and should be in /usr/bin

[Al Chu]

Hi Fabio,

> thanks for reply, I don't know if one or more freeipmi tools "really"
> need root and I don't have time to check/test all them shortly

Let me ask this question.  Do you intend to resolve the debian issue
below by moving it to /usr/bin in the debian distribution?

> it is better to ask someone else's opinion, especially someone more
> experienced than me

I will ask some power users at my company and ask their opinion.

Al

On Sun, 2021-02-07 at 18:43 +0100, Fabio Fantoni wrote:
> Il 06/02/2021 18:56, Al Chu ha scritto:
> > Hi Fabio,
> > 
> > Actually thinking about this more, could this argument be made for
> > all
> > FreeIPMI tools that do out of band communication?  On my local
> > redhat
> > system, I notice they put ipmitool in /usr/bin.
> > 
> > Just wanting to know your opinion on this.
> 
> thanks for reply, I don't know if one or more freeipmi tools "really"
> need root and I don't have time to check/test all them shortly
> 
> if none of them will need root  I think can be ok mv all to /usr/bin,
> about symlinks for rename I think is a "must", for this "move only"
> instead is needed to avoid issue only for cases where are used with
> full
> path "hardcoded" so the risk of problems is less but maybe the links
> would be better to have them.
> 
> it is better to ask someone else's opinion, especially someone more
> experienced than me
> 
> > 
> > Al
> > 
> > On Sat, 2021-02-06 at 09:50 -0800, Al Chu wrote:
> > > Hi Fabio,
> > > 
> > > I think that's a good point.  And the same argument can maybe be
> > > made
> > > for `ipmipower` since it has no "in-band" component.  Both are in
> > > /usr/sbin mostly b/c everything else there is.
> > > 
> > > My one concern is that it's been in /usr/sbin for so long, I'm
> > > not
> > > sure
> > > how many people may have hard coded "/usr/sbin/" into
> > > scripts.  This
> > > is
> > > far likely with "ipmipower", but perhaps with "ipmiconsole" too.
> > > 
> > > Perhaps a backwards compatibility symlink would be needed?
> > > 
> > > What would you imagine debian doing in this case?
> > > 
> > > Al
> > > 
> > > On Sat, 2021-02-06 at 18:03 +0100, Fabio Fantoni wrote:
> > > > Hi, as reported in debian: 
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977949
> > > > > The ipmi-console command can be executed by any normal user
> > > > > and
> > > > > doesn't
> > > > > require "system administrator" (aka "root") permission.,
> > > > > IMHO, it
> > > > > should
> > > > > hence be installed to /usr/bin, and not to /usr/sbin., The
> > > > > fact
> > > > > that you
> > > > > are accessing an IPMO SoL console of another machine, (of
> > > > > which
> > > > > you
> > > > > may
> > > > > be the system administrator) doesn't mean you have to be the
> > > > > system
> > > > > administrator of the client running ipmi-console.
> > > > 
> > > > is there a reason why it should be kept in sbin instead bin?
> > > > thanks for any reply and sorry for my bad english
> > > > 
> 
> 

Re: Minor errors like spelling and typo

[Al Chu]

Hi Fabio,

Thanks, will fixup in the master branch and merge down into the stable
1.6.X branch.

And yes, savannah hosts the official git repo.

Al

On Sun, 2021-02-07 at 13:55 +0100, Fabio Fantoni wrote:
> Lintian in debian packages (of freeipmi 1.6.6) spotted a list of
> minor
> errors like spelling and typo (listed above).
> 
> I don't have enought time recently to check any and do patches (where
> needed) but if someone want the list can be useful for fast find them
> with some grep commands.
> 
> Small offtopic question: 
> https://git.savannah.gnu.org/cgit/freeipmi.git/
> is the official git repository?
> 
> 
> > I: freeipmi-ipmiseld: spelling-error-in-binary usr/sbin/ipmiseld
> > accesing accessing
> > 
> > I: freeipmi-tools: spelling-error-in-binary usr/sbin/bmc-info
> > initilization initialization
> > I: freeipmi-tools: spelling-error-in-binary usr/sbin/ipmi-config
> > recommened recommended
> > I: freeipmi-tools: spelling-error-in-binary usr/sbin/ipmi-oem failt
> > fail
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Absolut Absolute
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Accet Accept
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 CENARIO SCENARIO
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Comit Commit
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Communcation Communication
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 DEVELOPPEMENT DEVELOPMENT
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Developement Development
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Develpment Development
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Embeded Embedded
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 ExPet Expect
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 FUNCION FUNCTION
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Folse False
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Gloabl Global
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Goverment Government
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Grammer Grammar
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 INFOMATION INFORMATION
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Immedate Immediate
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 InCASE In case
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Informations Information
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Internation International
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Mangement Management
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Millenium Millennium
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Nam Name
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Netowrks Networks
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Neworks Networks
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Occured Occurred
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Ontain Contain
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Optio Option
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Oriente Oriented
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 PRESENSE PRESENCE
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Performace Performance
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Prefered Preferred
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Ressources Resources
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Skelton Skeleton
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Softwares Software
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Sofware Software
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Structual Structural
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Sytems Systems
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Taylored Tailored
> > I: libfreeipmi17: spelling-error-in-binary
> > usr/lib/libfreeipmi.so.17.2.5 Transmittion Transmission
> > I: libfreeipmi17: 

Re: Lower freeipmi.conf permission as it could contain sensitive informations

[Al Chu]

Hi Fabio,

Thanks, I've decreased it and other conf files to 640.  I never caught
this b/c the permissions were overwritten to 0600 in the RPM spec
files.

Al

On Sun, 2021-02-07 at 13:17 +0100, Fabio Fantoni wrote:
> Hi, freeipmi.conf could contain sensitive informations, default
> permission setted to it by build (in etc/Makefile.am) is 644, debian
> decreased it in packaging after build very long time ago
> (https://salsa.debian.org/debian/freeipmi/-/blob/master/debian/rules)
> .
> 
> I think is good decrease it also upstream from 644 to 640 (removing
> read
> permission to others).
> 
> Thanks for any reply and sorry for my bad english.
> 
> 

Re: systemd service files should not be executable

[Al Chu]

Hi Fabio,

Thanks!  I suspect the 755 permissions were cut & paste from the old
init scripts.  Fix will be there in the next FreeIPMI release.

Al

On Sat, 2021-02-06 at 21:23 +0100, Fabio Fantoni wrote:
> Hi, until now debian packages used its service files instead the
> upstream ones, now for next build I removed the debian ones and used
> upstream ones (generated from build) instead.
> 
> From warning spotted by lintian I saw that service files are
> executable
> on install even they shouldn't be, did a fast patch that change them
> to
> 644 (same of other service files), added as attachment if you want
> use it.
> 
> Thanks for any reply and sorry for my bad english.
> 
> 

Re: ipmi-console doesn't need root and should be in /usr/bin

[Al Chu]

Hi Fabio,

Actually thinking about this more, could this argument be made for all
FreeIPMI tools that do out of band communication?  On my local redhat
system, I notice they put ipmitool in /usr/bin.

Just wanting to know your opinion on this.

Al

On Sat, 2021-02-06 at 09:50 -0800, Al Chu wrote:
> Hi Fabio,
> 
> I think that's a good point.  And the same argument can maybe be made
> for `ipmipower` since it has no "in-band" component.  Both are in
> /usr/sbin mostly b/c everything else there is.
> 
> My one concern is that it's been in /usr/sbin for so long, I'm not
> sure
> how many people may have hard coded "/usr/sbin/" into scripts.  This
> is
> far likely with "ipmipower", but perhaps with "ipmiconsole" too.
> 
> Perhaps a backwards compatibility symlink would be needed?
> 
> What would you imagine debian doing in this case?
> 
> Al
> 
> On Sat, 2021-02-06 at 18:03 +0100, Fabio Fantoni wrote:
> > Hi, as reported in debian: 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977949
> > > The ipmi-console command can be executed by any normal user and
> > > doesn't
> > > require "system administrator" (aka "root") permission., IMHO, it
> > > should
> > > hence be installed to /usr/bin, and not to /usr/sbin., The fact
> > > that you
> > > are accessing an IPMO SoL console of another machine, (of which
> > > you
> > > may
> > > be the system administrator) doesn't mean you have to be the
> > > system
> > > administrator of the client running ipmi-console.
> > 
> > is there a reason why it should be kept in sbin instead bin?
> > thanks for any reply and sorry for my bad english
> > 
> 
> 

Re: ipmi-console doesn't need root and should be in /usr/bin

[Al Chu]

Hi Fabio,

I think that's a good point.  And the same argument can maybe be made
for `ipmipower` since it has no "in-band" component.  Both are in
/usr/sbin mostly b/c everything else there is.

My one concern is that it's been in /usr/sbin for so long, I'm not sure
how many people may have hard coded "/usr/sbin/" into scripts.  This is
far likely with "ipmipower", but perhaps with "ipmiconsole" too.

Perhaps a backwards compatibility symlink would be needed?

What would you imagine debian doing in this case?

Al

On Sat, 2021-02-06 at 18:03 +0100, Fabio Fantoni wrote:
> Hi, as reported in debian: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977949
> > The ipmi-console command can be executed by any normal user and
> > doesn't
> > require "system administrator" (aka "root") permission., IMHO, it
> > should
> > hence be installed to /usr/bin, and not to /usr/sbin., The fact
> > that you
> > are accessing an IPMO SoL console of another machine, (of which you
> > may
> > be the system administrator) doesn't mean you have to be the system
> > administrator of the client running ipmi-console.
> 
> is there a reason why it should be kept in sbin instead bin?
> thanks for any reply and sorry for my bad english
> 

Re: Ipmi and ilo5 hp server

[Al Chu]

There is no guarantee that your ilo5 will export the same sensors as
ilo4.  I would contact your vendor to determine what sensors are
available / not available.  

You can also try see if some of the workarounds in ipmi-sensors help
display more sensors.

Al

On Tue, 2020-12-22 at 12:01 +0100, Robin Z wrote:
> Hi,
> I try to monitor hp server ilo5 with ipmi using ipmi prometheus
> exporter that uses freeimpi.
> But with ipmi and ilo5 I dont have any info about drive status . I
> have these info with ilo4.
> 
> Any idea plz ?
> 
> Thank you

FreeIPMI 1.6.6 Released

[Al Chu]

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.6.tar.gz

o In libfreeipmi, fix segfault in SPMI parsing leading to immediate
  failures on some hardware across all tools.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Re: [PATCH] libfreeipmi: fix segfault in SPMI parsing

[Al Chu]

Hey Bruce,

Thanks, just wanted to double check.  I'll do a release soon.

Al

On Thu, 2020-09-03 at 14:08 -0700, Bryce Harrington wrote:
> On Thu, Sep 03, 2020 at 10:58:20AM -0700, Al Chu wrote:
> > Hey Christian,
> > 
> > I've applied the patch, thanks!  Just wondering how bad this is and
> > if
> > it warrants a FreeIPMI release.  It sounds like on certain systems,
> > a
> > segfault was probably happening all the time?
> 
> Yes, that's what seems to be happening.  While we're only aware of
> this
> happening on the mentioned Dell HW, the bug itself isn't HW-specific
> and
> could well affect any systems that happen to fall through the early
> release paths.  However, we did not reproduce it on other hardware,
> and
> did not find other reports of people experiencing this problem in the
> wild.
> 
> For Ubuntu, we'll likely be providing this patch directly to users
> via
> our stable release update process, and so won't need an upstream
> release
> for that.  However, an upstream release likely would be quite helpful
> for other Linux distributions and users more generally.
> 
> Thanks!
> Bryce

Re: [PATCH] libfreeipmi: fix segfault in SPMI parsing

[Al Chu]

Hey Christian,

I've applied the patch, thanks!  Just wondering how bad this is and if
it warrants a FreeIPMI release.  It sounds like on certain systems, a
segfault was probably happening all the time?

Al

On Thu, 2020-09-03 at 02:50 -0700, Al Chu wrote:
> Hi Christian,
> 
> LGTM, thanks and thanks for the thorough description.  I'm not a
> computer that I can apply right now, but will do so later.
> 
> This seems like a critical enough bug to do a new release, i will try
> to do so by the end of the week.
> 
> Al
> 
> On Thu, 2020-09-03 at 09:14 +0200, Christian Ehrhardt wrote:
> > Since 68ed819 "acpi-spmi locate driver" the initialization of
> > acpi_table
> > was done as a direct assignment on a global variable.
> > Later on _ipmi_acpi_get_table was restructured and now expects
> > malloced
> > memory, but the old intialization was left in place now killing the
> > malloced
> > pointer.
> > 
> > It turns out that on systems without /sys/firmware/acpi/tables/SPMI
> > like
> > Dell iDRAC6/9 _ipmi_acpi_get_table then tries to assign
> > acpi_table_buf to it.
> > This leads to an access of 0x0 and a crash, for a backtrace see:
> > https://launchpadlibrarian.net/495892193/apport-retrace-ipmi-locate.txt
> > 
> > On other hardware (with SPMI file in sysfs) there are some early
> > exits before
> > this happens. Additionally Before 094cd5ce "Audit libfreeipmi,
> > remove
> > unnecessary memsets, fix +1 buffers, etc." which is in >1.6.0 there
> > was
> > another early exit in _ipmi_acpi_get_table_dev_mem as
> > _ipmi_acpi_get_rsdp
> > never returned non zero, but since that fix it can reach the bad
> > code.
> > 
> > The old style assignment of acpi_table is wrong (writes the pointer
> > instead
> > of the pointer target) and superfluous as it is done correct at the
> > beginning
> > of _ipmi_acpi_get_table_dev_mem and between this init and the usage
> > no more
> > touched. Therefore it is safe to just remove the bad
> > initialization.
> > 
> > Signed-off-by: Christian Ehrhardt  > >
> > Reported-by: jeffrey.l...@canonical.com
> > ---
> >  libfreeipmi/locate/ipmi-locate-acpi-spmi.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> > b/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> > index 710674e53..11c688524 100644
> > --- a/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> > +++ b/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> > @@ -1384,7 +1384,6 @@ _ipmi_acpi_get_table_dev_mem
> > (ipmi_locate_ctx_t
> > ctx,
> >else
> >  acpi_table_count = rsdt_xsdt_table_data_length / 8;
> >  
> > -  acpi_table = NULL;
> >acpi_table_length = 0;
> >for (i = 0, signature_table_count = 0; i < acpi_table_count;
> > i++)
> >  {
> 
> 

Re: [PATCH] libfreeipmi: fix segfault in SPMI parsing

[Al Chu]

Hi Christian,

LGTM, thanks and thanks for the thorough description.  I'm not a
computer that I can apply right now, but will do so later.

This seems like a critical enough bug to do a new release, i will try
to do so by the end of the week.

Al

On Thu, 2020-09-03 at 09:14 +0200, Christian Ehrhardt wrote:
> Since 68ed819 "acpi-spmi locate driver" the initialization of
> acpi_table
> was done as a direct assignment on a global variable.
> Later on _ipmi_acpi_get_table was restructured and now expects
> malloced
> memory, but the old intialization was left in place now killing the
> malloced
> pointer.
> 
> It turns out that on systems without /sys/firmware/acpi/tables/SPMI
> like
> Dell iDRAC6/9 _ipmi_acpi_get_table then tries to assign
> acpi_table_buf to it.
> This leads to an access of 0x0 and a crash, for a backtrace see:
> https://launchpadlibrarian.net/495892193/apport-retrace-ipmi-locate.txt
> 
> On other hardware (with SPMI file in sysfs) there are some early
> exits before
> this happens. Additionally Before 094cd5ce "Audit libfreeipmi, remove
> unnecessary memsets, fix +1 buffers, etc." which is in >1.6.0 there
> was
> another early exit in _ipmi_acpi_get_table_dev_mem as
> _ipmi_acpi_get_rsdp
> never returned non zero, but since that fix it can reach the bad
> code.
> 
> The old style assignment of acpi_table is wrong (writes the pointer
> instead
> of the pointer target) and superfluous as it is done correct at the
> beginning
> of _ipmi_acpi_get_table_dev_mem and between this init and the usage
> no more
> touched. Therefore it is safe to just remove the bad initialization.
> 
> Signed-off-by: Christian Ehrhardt 
> Reported-by: jeffrey.l...@canonical.com
> ---
>  libfreeipmi/locate/ipmi-locate-acpi-spmi.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> b/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> index 710674e53..11c688524 100644
> --- a/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> +++ b/libfreeipmi/locate/ipmi-locate-acpi-spmi.c
> @@ -1384,7 +1384,6 @@ _ipmi_acpi_get_table_dev_mem (ipmi_locate_ctx_t
> ctx,
>else
>  acpi_table_count = rsdt_xsdt_table_data_length / 8;
>  
> -  acpi_table = NULL;
>acpi_table_length = 0;
>for (i = 0, signature_table_count = 0; i < acpi_table_count; i++)
>  {

Re: ipmi-oem Supermicro get-power-supply-status issue

[Al Chu]

On Thu, 2020-08-27 at 16:18 -0400, Andrew Orme wrote:
> BIOS versions are up to date. Referring to the BMC firmware? 

Yeah, BMC firmware.  You can see version via bmc-info command.

Al

> 
> On Thu, Aug 27, 2020 at 4:00 PM Andy Cress 
> wrote:
> > Quite so.  SuperMicro is slow to give firmware fixes, but having
> > the latest available firmware helps.
> > 
> > On Thu, Aug 27, 2020 at 2:08 PM Al Chu  wrote:
> > > On Thu, 2020-08-27 at 14:04 -0400, Andrew Orme wrote:
> > > 
> > > 
> > > > Indeed. Seems to run fine on our other systems running the same
> > > exact
> > > 
> > > 
> > > > hardware. Agreed that it is specific to Supermicro and is
> > > perhaps a
> > > 
> > > 
> > > > manufacturing issue somewhere.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > You may want to double check the firmware version, that's
> > > sometimes an
> > > 
> > > 
> > > issue.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Al
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > On Wed, Aug 26, 2020 at 1:07 PM Al Chu  wrote:
> > > 
> > > 
> > > > > Hi Andrew,
> > > 
> > > 
> > > > > 
> > > 
> > > 
> > > > > Thanks for the report.  Since this is a OEM specific command,
> > > there
> > > 
> > > 
> > > > > is
> > > 
> > > 
> > > > > a good chance this just isn't supported on your motherboard. 
> > > There
> > > 
> > > 
> > > > > is
> > > 
> > > 
> > > > > no way to know what Supermicro may have meant with the 0x83
> > > error
> > > 
> > > 
> > > > > code.
> > > 
> > > 
> > > > > 
> > > 
> > > 
> > > > > Al
> > > 
> > > 
> > > > > 
> > > 
> > > 
> > > > > On Thu, 2020-08-20 at 18:28 -0400, Andrew Orme wrote:
> > > 
> > > 
> > > > > > admin@server:~# ipmi-oem --debug Supermicro get-power-
> > > supply-
> > > 
> > > 
> > > > > status 1
> > > 
> > > 
> > > > > > =
> > > 
> > > 
> > > > > > Master Write Read Request
> > > 
> > > 
> > > > > > =
> > > 
> > > 
> > > > > > KCS Header:
> > > 
> > > 
> > > > > > 
> > > 
> > > 
> > > > > > [   0h] = lun[ 2b]
> > > 
> > > 
> > > > > > [   6h] = net_fn[ 6b]
> > > 
> > > 
> > > > > > IPMI Command Data:
> > > 
> > > 
> > > > > > --
> > > 
> > > 
> > > > > > [  52h] = cmd[ 8b]
> > > 
> > > 
> > > > > > [  BYTE ARRAY ... ] = raw_data[ 4B]
> > > 
> > > 
> > > > > > [ 07h 70h 01h 0Ch ]
> > > 
> > > 
> > > > > > =
> > > 
> > > 
> > > > > > Master Write Read Response
> > > 
> > > 
> > > > > > =
> > > 
> > > 
> > > > > > KCS Header:
> > > 
> > > 
> > > > > > 
> > > 
> > > 
> > > > > > [   0h] = lun[ 2b]
> > > 
> > > 
> > > > > > [   7h] = net_fn[ 6b]
> > > 
> > > 
> > > > > > IPMI Command Data:
> > > 
> > > 
> > > > > > --
> > > 
> > > 
> > > > > > [  52h] = cmd[ 8b]
> > > 
> > > 
> > > > > > [  BYTE ARRAY ... ] = raw_data[ 1B]
> > > 
> > > 
> > > > > > [ 83h ]
> > > 
> > > 
> > > > > > Supermicro:get-power-supply-status failed: No error message
> > > found
> > > 
> > > 
> > > > > for
> > > 
> > > 
> &

Re: ipmi-oem Supermicro get-power-supply-status issue

[Al Chu]

On Thu, 2020-08-27 at 14:04 -0400, Andrew Orme wrote:
> Indeed. Seems to run fine on our other systems running the same exact
> hardware. Agreed that it is specific to Supermicro and is perhaps a
> manufacturing issue somewhere.

You may want to double check the firmware version, that's sometimes an
issue.

Al

> On Wed, Aug 26, 2020 at 1:07 PM Al Chu  wrote:
> > Hi Andrew,
> > 
> > Thanks for the report.  Since this is a OEM specific command, there
> > is
> > a good chance this just isn't supported on your motherboard.  There
> > is
> > no way to know what Supermicro may have meant with the 0x83 error
> > code.
> > 
> > Al
> > 
> > On Thu, 2020-08-20 at 18:28 -0400, Andrew Orme wrote:
> > > admin@server:~# ipmi-oem --debug Supermicro get-power-supply-
> > status 1
> > > =
> > > Master Write Read Request
> > > =
> > > KCS Header:
> > > 
> > > [   0h] = lun[ 2b]
> > > [   6h] = net_fn[ 6b]
> > > IPMI Command Data:
> > > --
> > > [  52h] = cmd[ 8b]
> > > [  BYTE ARRAY ... ] = raw_data[ 4B]
> > > [ 07h 70h 01h 0Ch ]
> > > =
> > > Master Write Read Response
> > > =
> > > KCS Header:
> > > 
> > > [   0h] = lun[ 2b]
> > > [   7h] = net_fn[ 6b]
> > > IPMI Command Data:
> > > --
> > > [  52h] = cmd[ 8b]
> > > [  BYTE ARRAY ... ] = raw_data[ 1B]
> > > [ 83h ]
> > > Supermicro:get-power-supply-status failed: No error message found
> > for
> > > command 52h, network function 06h, and completion code 83h. 
> > Please
> > > report to 
> > > 
> > > admin@server:~# dmidecode -t 39 | grep 'Name'
> > > Name: To Be Filled By O.E.M.
> > > Name: To Be Filled By O.E.M.
> > > 
> > > admin@server:~# dmidecode -t 39
> > > # dmidecode 2.12
> > > SMBIOS 2.8 present.
> > > 
> > > Handle 0x0018, DMI type 39, 22 bytes
> > > System Power Supply
> > > Power Unit Group: 1
> > > Location: PSU1
> > > Name: To Be Filled By O.E.M.
> > > Manufacturer: To Be Filled By O.E.M.
> > > Serial Number: To Be Filled By O.E.M.
> > > Asset Tag: To Be Filled By O.E.M.
> > > Model Part Number: To Be Filled By O.E.M.
> > > Revision: To Be Filled By O.E.M.
> > > Max Power Capacity: Unknown
> > > Status: Not Present
> > > Type: Switching
> > > Input Voltage Range Switching: Auto-switch
> > > Plugged: Yes
> > > Hot Replaceable: No
> > > 
> > > Handle 0x0019, DMI type 39, 22 bytes
> > > System Power Supply
> > > Power Unit Group: 2
> > > Location: PSU2
> > > Name: To Be Filled By O.E.M.
> > > Manufacturer: To Be Filled By O.E.M.
> > > Serial Number: To Be Filled By O.E.M.
> > > Asset Tag: To Be Filled By O.E.M.
> > > Model Part Number: To Be Filled By O.E.M.
> > > Revision: To Be Filled By O.E.M.
> > > Max Power Capacity: Unknown
> > > Status: Not Present
> > > Type: Switching
> > > Input Voltage Range Switching: Auto-switch
> > > Plugged: Yes
> > > Hot Replaceable: No
> > 

Re: ipmi-oem Supermicro get-power-supply-status issue

[Al Chu]

Hi Andrew,

Thanks for the report.  Since this is a OEM specific command, there is
a good chance this just isn't supported on your motherboard.  There is
no way to know what Supermicro may have meant with the 0x83 error code.

Al

On Thu, 2020-08-20 at 18:28 -0400, Andrew Orme wrote:
> admin@server:~# ipmi-oem --debug Supermicro get-power-supply-status 1
> =
> Master Write Read Request
> =
> KCS Header:
> 
> [   0h] = lun[ 2b]
> [   6h] = net_fn[ 6b]
> IPMI Command Data:
> --
> [  52h] = cmd[ 8b]
> [  BYTE ARRAY ... ] = raw_data[ 4B]
> [ 07h 70h 01h 0Ch ]
> =
> Master Write Read Response
> =
> KCS Header:
> 
> [   0h] = lun[ 2b]
> [   7h] = net_fn[ 6b]
> IPMI Command Data:
> --
> [  52h] = cmd[ 8b]
> [  BYTE ARRAY ... ] = raw_data[ 1B]
> [ 83h ]
> Supermicro:get-power-supply-status failed: No error message found for
> command 52h, network function 06h, and completion code 83h.  Please
> report to 
> 
> admin@server:~# dmidecode -t 39 | grep 'Name'
> Name: To Be Filled By O.E.M.
> Name: To Be Filled By O.E.M.
> 
> admin@server:~# dmidecode -t 39
> # dmidecode 2.12
> SMBIOS 2.8 present.
> 
> Handle 0x0018, DMI type 39, 22 bytes
> System Power Supply
> Power Unit Group: 1
> Location: PSU1
> Name: To Be Filled By O.E.M.
> Manufacturer: To Be Filled By O.E.M.
> Serial Number: To Be Filled By O.E.M.
> Asset Tag: To Be Filled By O.E.M.
> Model Part Number: To Be Filled By O.E.M.
> Revision: To Be Filled By O.E.M.
> Max Power Capacity: Unknown
> Status: Not Present
> Type: Switching
> Input Voltage Range Switching: Auto-switch
> Plugged: Yes
> Hot Replaceable: No
> 
> Handle 0x0019, DMI type 39, 22 bytes
> System Power Supply
> Power Unit Group: 2
> Location: PSU2
> Name: To Be Filled By O.E.M.
> Manufacturer: To Be Filled By O.E.M.
> Serial Number: To Be Filled By O.E.M.
> Asset Tag: To Be Filled By O.E.M.
> Model Part Number: To Be Filled By O.E.M.
> Revision: To Be Filled By O.E.M.
> Max Power Capacity: Unknown
> Status: Not Present
> Type: Switching
> Input Voltage Range Switching: Auto-switch
> Plugged: Yes
> Hot Replaceable: No

FreeIPMI 1.6.5 Released

[Al Chu]

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.5.tar.gz

Updates in 
o Add FRU parsing workaround for Fujitsu Primergy RX1330, in which a
  CEh is used to indicate that no FRU data is available.
o Misc minor fixes.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

Re: [Freeipmi-devel] Large number of hosts in ipmiseld

[Al Chu]

So looking things over, the reason it doesn't support multiple inputs is
due to a architectural decision, mostly lifting conf-file parsing from
many of the other FreeIPMI tools.

Perhaps not the prettiest, but I think the simplest fix is to increase
the max size listed below.  Could you give it a try?  If you need a
patch I can provide one for you.

Al

On Tue, 2016-02-02 at 13:22 -0800, Albert Chu wrote:
> On Tue, 2016-02-02 at 11:45 -0800, Kilian Cavalotti wrote:
> > Hi Albert,
> > 
> > Thanks for your lightning-fast reply.
> > 
> > On Tue, Feb 2, 2016 at 11:36 AM, Albert Chu  wrote:
> > > I'm a little surprised you got that error.  I'll see if I can reproduce
> > > on my end and see what I can come up with.  Specifying on multiple lines
> > > seems like something that can be done too.
> > 
> > That would be awesome.
> > 
> > > I assume you're listing a very large list of hosts with comma
> > > separation?  In your environment are you not able to list via range
> > > format?  i.e. node[0-21]?
> > 
> > I actually use the range format, like this:
> > hostname = 
> > ipmi-sh-22-[1-36],ipmi-sh-23-[1-36],ipmi-sh-24-[1-36],ipmi-sh-8-[1-37]
> > 
> > It looks like the limit may be at 512 characters.
> 
> Looking at the conf file parsing lib (common/miscutil/conffile.h)
> 
> /* LENGTHS
>   
>   
>  *
>   
>   
>  * The following are the maximum values and lengths throughout
>   
>   
>  * the conffile parser.   
>   
>   
>  */
> 
> #define CONFFILE_MAX_LINELEN  32778
> #define CONFFILE_MAX_OPTIONNAMELEN  256
> #define CONFFILE_MAX_ARGS64
> #define CONFFILE_MAX_ARGLEN 512
> #define CONFFILE_MAX_ERRMSGLEN 1024
> 
> A jump from 512 to 1024 would probably fix this.  You could try this as
> a quick fix and recompile.
> 
> Al
> 
> > Cheers,



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] FreeIPMI Patch Submission

[Al Chu]

Great.  It'll be in the next release of FreeIPMI (1.4.4)

Al

On Thu, 2014-05-29 at 23:32 +, Dande, Shashi wrote:
 Hi Al
 
 Here is the updated patch per our conversation today. 
 
 Thanks
 Shashi
 
 Index: ipmi-ssif-driver-api.c
 ===
 --- ipmi-ssif-driver-api.c(revision 10066)
 +++ ipmi-ssif-driver-api.c(working copy)
 @@ -319,7 +319,9 @@
uint8_t cmd = 0; /* used for debugging */
uint8_t group_extension = 0; /* used for debugging */
uint64_t val;
 -
 +  struct timespec request, remain;
 +  uint8_t retry = IPMI_SSIF_RETRY_DEFAULT;
 +  
assert (ctx
  ctx-magic == IPMI_CTX_MAGIC
  ctx-type == IPMI_DEVICE_SSIF
 @@ -350,9 +352,39 @@
if (_ssif_cmd_write (ctx, cmd, group_extension, obj_cmd_rq)  0)
  return (-1);
  
 +  
 /**
 +12.9 SMBus NACKs and Error Recovery:
 +
 +The BMC can NACK the SMBus host controller if it is not ready to accept 
 a new 
 +transaction. Typically, this will be exhibited by the BMC NACK'ing its 
 slave 
 +address. 
 +
 +If the BMC NACKs a single part transaction, software can simply retry 
 it. 
 +If a 'middle' or 'end' transaction is NACK'd, software should not retry 
 the 
 +particular but should restart the multi-part read or write from the 
 beginning
 +Start transaction for the transfer.
 +  
 ***/
if (_ssif_cmd_read (ctx, cmd, group_extension, obj_cmd_rs)  0)
 -return (-1);
 +{
 +  while (1)
 +{
 +  request.tv_sec = 0; 
 +  request.tv_nsec = IPMI_SSIF_TIMEOUT_DEFAULT;
 +  if (nanosleep (request, remain)  0 )
 +return (-1);
  
 +  if (_ssif_cmd_read (ctx, cmd, group_extension, obj_cmd_rs)  0)
 +{
 +  if (retry == 0)
 +return (-1);
 +
 +  retry--;
 +}
 +else
 +  break;
 +}
 +}
 +
return (0);
  }
  
 Index: ipmi-ssif-driver-api.h
 ===
 --- ipmi-ssif-driver-api.h(revision 10066)
 +++ ipmi-ssif-driver-api.h(working copy)
 @@ -23,6 +23,9 @@
  #include freeipmi/api/ipmi-api.h
  #include freeipmi/fiid/fiid.h
  
 +#define IPMI_SSIF_RETRY_DEFAULT   5
 +#define IPMI_SSIF_TIMEOUT_DEFAULT 2000 /* 20 ms */
 +
  int api_ssif_cmd (ipmi_ctx_t ctx,
 fiid_obj_t obj_cmd_rq,
 fiid_obj_t obj_cmd_rs);
 
 -Original Message-
 From: Albert Chu [mailto:ch...@llnl.gov] 
 Sent: Thursday, May 29, 2014 2:16 PM
 To: Dande, Shashi
 Subject: RE: FreeIPMI Patch Submission
 
 Hi Shashi,
 
 Just re-pinging in case you forgot about this thread.
 
 Thanks,
 
 Al
 
 On Fri, 2014-05-09 at 15:14 +, Dande, Shashi wrote:
  Hi Al
  
  Thanks for your feedback. I will refractor the code to include your 
  feedback and repost the patch. 
  
  Thanks
  Shashi
  
  -Original Message-
  From: Al Chu [mailto:ch...@llnl.gov]
  Sent: Friday, May 09, 2014 9:54 AM
  To: Dande, Shashi
  Cc: freeipmi-devel@gnu.org
  Subject: RE: FreeIPMI Patch Submission
  
  Hi Shashi,
  
  The patch as a whole looks fine, but how about a few tweaks.  Comments 
  inlined below.
  
  On Wed, 2014-05-07 at 21:34 +, Dande, Shashi wrote:
   Hi Albert
   
   I have attached the patch file to this e-mail per your advice.
   
   I have also copied the content below for your reference. 
   
   Thanks
   Shashi
   
   
   Index: ipmi-ssif-driver-api.c
   ===
   --- ipmi-ssif-driver-api.c(revision 10066)
   +++ ipmi-ssif-driver-api.c(working copy)
   @@ -30,6 +30,7 @@
#endif /* HAVE_UNISTD_H */
#include assert.h
#include errno.h
   +#include time.h
  
  Throughout FreeIPMI you'll see code chunks like this:
  
  #if TIME_WITH_SYS_TIME
  #include sys/time.h
  #include time.h
  #else /* !TIME_WITH_SYS_TIME */
  #if HAVE_SYS_TIME_H
  #include sys/time.h
  #else /* !HAVE_SYS_TIME_H */
  #include time.h
  #endif /* !HAVE_SYS_TIME_H */
  #endif  /* !TIME_WITH_SYS_TIME */
  
  It is more portable b/c of the weirdness/legacy of the time.h headers.
  
#include freeipmi/driver/ipmi-ssif-driver.h
#include freeipmi/debug/ipmi-debug.h
   @@ -319,7 +320,9 @@
  uint8_t cmd = 0; /* used for debugging */
  uint8_t group_extension = 0; /* used for debugging */
  uint64_t val;
   -
   +  struct timespec request, remain;
   +  uint8_t retry = 5;
  
  To avoid using magic values, could we have a #define in the code 
  that will set the 5 and also the default 2 ms below.  Something 
  like
  
  #define IPMI_SSIF_RETRY_DEFAULT
  #define IPMI_SSIF_TIMEOUT_DEFAULT
  
   +  
  assert (ctx

Re: [Freeipmi-devel] FreeIPMI Patch Submission

[Al Chu]

Hi Shashi,

The patch as a whole looks fine, but how about a few tweaks.  Comments
inlined below.

On Wed, 2014-05-07 at 21:34 +, Dande, Shashi wrote:
 Hi Albert
 
 I have attached the patch file to this e-mail per your advice.
 
 I have also copied the content below for your reference. 
 
 Thanks
 Shashi
 
 
 Index: ipmi-ssif-driver-api.c
 ===
 --- ipmi-ssif-driver-api.c(revision 10066)
 +++ ipmi-ssif-driver-api.c(working copy)
 @@ -30,6 +30,7 @@
  #endif /* HAVE_UNISTD_H */
  #include assert.h
  #include errno.h
 +#include time.h 

Throughout FreeIPMI you'll see code chunks like this:

#if TIME_WITH_SYS_TIME
#include sys/time.h
#include time.h
#else /* !TIME_WITH_SYS_TIME */
#if HAVE_SYS_TIME_H
#include sys/time.h
#else /* !HAVE_SYS_TIME_H */
#include time.h
#endif /* !HAVE_SYS_TIME_H */
#endif  /* !TIME_WITH_SYS_TIME */

It is more portable b/c of the weirdness/legacy of the time.h headers.

  #include freeipmi/driver/ipmi-ssif-driver.h
  #include freeipmi/debug/ipmi-debug.h
 @@ -319,7 +320,9 @@
uint8_t cmd = 0; /* used for debugging */
uint8_t group_extension = 0; /* used for debugging */
uint64_t val;
 -
 +  struct timespec request, remain;
 +  uint8_t retry = 5;

To avoid using magic values, could we have a #define in the code that
will set the 5 and also the default 2 ms below.  Something like

#define IPMI_SSIF_RETRY_DEFAULT
#define IPMI_SSIF_TIMEOUT_DEFAULT

 +  
assert (ctx
  ctx-magic == IPMI_CTX_MAGIC
  ctx-type == IPMI_DEVICE_SSIF
 @@ -350,9 +353,39 @@
if (_ssif_cmd_write (ctx, cmd, group_extension, obj_cmd_rq)  0)
  return (-1);
  
 +  
 /**
 +12.9 SMBus NACKs and Error Recovery:
 +
 +The BMC can NACK the SMBus host controller if it is not ready to accept 
 a new 
 +transaction. Typically, this will be exhibited by the BMC NACK'ing its 
 slave 
 +address. 
 +
 +If the BMC NACKs a single part transaction, software can simply retry 
 it. 
 +If a 'middle' or 'end' transaction is NACK'd, software should not retry 
 the 
 +particular but should restart the multi-part read or write from the 
 beginning
 +Start transaction for the transfer.
 +  
 ***/
if (_ssif_cmd_read (ctx, cmd, group_extension, obj_cmd_rs)  0)
 -return (-1);
 +{
 +  while (1)
 +{
 +  request.tv_sec = 0; 
 +  request.tv_nsec = 2000; /* 20 ms */
 +  if (nanosleep (request, remain)  0 )
 +return (-1);
  
 +  if (_ssif_cmd_read (ctx, cmd, group_extension, obj_cmd_rs)  0)
 +{
 +  if (retry == 0)
 +return (-1);
 +
 +  retry--;
 +}
 +else
 +  break;
 +}
 +}
 +
return (0);
  } 
 
 -Original Message-
 From: Albert Chu [mailto:ch...@llnl.gov] 
 Sent: Tuesday, May 06, 2014 5:29 PM
 To: Dande, Shashi
 Subject: RE: FreeIPMI Patch Submission
 
 The trunk would be best.
 
 Thanks,
 
 Al
 
 On Tue, 2014-05-06 at 22:26 +, Dande, Shashi wrote:
  Thanks for a quick reply. Should I submit the patch against the trunk or a 
  particular version of your source code. 
  
  Thanks
  Shashi
  
  -Original Message-
  From: Albert Chu [mailto:ch...@llnl.gov]
  Sent: Tuesday, May 06, 2014 5:23 PM
  To: Dande, Shashi
  Subject: Re: FreeIPMI Patch Submission
  
  Hi,
  
  I'd be happy to work with you to get the code integrated.  Why don't you 
  post the patch to the freeipmi-devel@gnu.org mailing list and we can 
  iterate on the patch there.
  
  Al
  
  On Tue, 2014-05-06 at 22:10 +, Shashi Dande wrote:
   Hi Albert
   
   I am a software architect from Hewlett Packard and recenlty  I have 
   updated the FreeIPMI code to make sure that it works on our next 
   genaration ARM platforms. Please let me know if I can work with you 
   to merge these changes into the FreeIPMI project.
   
   Thanks
   Shashi
   
   ___
 Message sent via/by Savannah
 http://savannah.gnu.org/
   
  --
  Albert Chu
  ch...@llnl.gov
  Computer Scientist
  High Performance Systems Division
  Lawrence Livermore National Laboratory
  
  
 --
 Albert Chu
 ch...@llnl.gov
 Computer Scientist
 High Performance Systems Division
 Lawrence Livermore National Laboratory
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] freeipmi : Request to spin up a new version of freeipmi with ppc64le support.

[Al Chu]

Hi Chandan,

I can do it for 1.3.4 and release a special tarball just for this newer
libtool, and perhaps on-demand as it is needed.  But I cannot update the
build process to use it everytime.

Al

On Wed, 2014-01-15 at 12:53 +0530, Chandan wrote:
 Hi Chu,
 
 we are looking at new release tarball for distro to pick up of freeipmi.
 We are looking at being able to point the pkg tarball to the distro such
 that the pkg build in the distro build( that will obvious Little Endian
 version of Power Linux) without further issues.
 
 Currently available source tarball (freeipmi-1.3.4) on upstream uses the
 libtool that does not have support for ppc64le arch and so the build
 failed to generate the shared library.
 So I am hoping you will use the alpha libtool and spin up a new version
 of release tarball of freeipmi on upstream.
 
 Thanks
 Chandan
 On Tue, 2014-01-14 at 09:20 -0800, Al Chu wrote:
  Hi Chandan,
  
  Are you looking for a one-time build w/ this new libtool so you can try
  it on ppc64le machines?  Or are you hoping I will use the newer libtool
  for future FreeIPMI releases?
  
  The latter is more difficult for me todo, but I could do a one-off for
  ppc64le people to try out.
  
  Is this related to any work going on at Redhat?  Within the last few
  months, several PPC related patches came from Redhat.
  
  Al
  
  On Tue, 2014-01-14 at 16:33 +0530, Chandan wrote:
   Hi Albert,
   
   We are adding support for new ppc64le (IBM powerPC Little Endian)
   architecture as part of which we are looking at all the packages that
   need update.
   
   I was looking at “freeipmi” (from repo: cvs -z3
   -d:pserver:anonym...@cvs.savannah.gnu.org:/web/freeipmi and
   freeipmi-1.3.4 as well ) and was failed to build “freeipmi” on ppc64le
   machine because of outdated libtool.
   
   We have worked with libtool maintainer to get alpha source release that
   has all the needed bits to support building on ppc64le. A stable release
   is expected soon.
   
   You can pick up the libtool alpha source release from either of the
   below :
   ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz   (1.6MB)
   ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz   (920KB)
   
   Would it be possible for you to spin up a newer version of
   freeipmi which would support ppc64le? by using alpha libtool
   release?
   
   I can help to validate the new release of the freeipmi works
   well by compiling on ppc64le machine.
   
   Appreciate your response.
   
   Thanks,
   Chandan
   
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] freeipmi : Request to spin up a new version of freeipmi with ppc64le support.

[Al Chu]

On Wed, 2014-01-15 at 08:17 -0800, Al Chu wrote:
 Hi Chandan,
 
 I can do it for 1.3.4 and release a special tarball just for this newer
 libtool, and perhaps on-demand as it is needed.  But I cannot update the
 build process to use it everytime.

I should say ... can't update the build process to use it everytime
until it is more upstream in major distros.

Al

 Al
 
 On Wed, 2014-01-15 at 12:53 +0530, Chandan wrote:
  Hi Chu,
  
  we are looking at new release tarball for distro to pick up of freeipmi.
  We are looking at being able to point the pkg tarball to the distro such
  that the pkg build in the distro build( that will obvious Little Endian
  version of Power Linux) without further issues.
  
  Currently available source tarball (freeipmi-1.3.4) on upstream uses the
  libtool that does not have support for ppc64le arch and so the build
  failed to generate the shared library.
  So I am hoping you will use the alpha libtool and spin up a new version
  of release tarball of freeipmi on upstream.
  
  Thanks
  Chandan
  On Tue, 2014-01-14 at 09:20 -0800, Al Chu wrote:
   Hi Chandan,
   
   Are you looking for a one-time build w/ this new libtool so you can try
   it on ppc64le machines?  Or are you hoping I will use the newer libtool
   for future FreeIPMI releases?
   
   The latter is more difficult for me todo, but I could do a one-off for
   ppc64le people to try out.
   
   Is this related to any work going on at Redhat?  Within the last few
   months, several PPC related patches came from Redhat.
   
   Al
   
   On Tue, 2014-01-14 at 16:33 +0530, Chandan wrote:
Hi Albert,

We are adding support for new ppc64le (IBM powerPC Little Endian)
architecture as part of which we are looking at all the packages that
need update.

I was looking at “freeipmi” (from repo: cvs -z3
-d:pserver:anonym...@cvs.savannah.gnu.org:/web/freeipmi and
freeipmi-1.3.4 as well ) and was failed to build “freeipmi” on ppc64le
machine because of outdated libtool.

We have worked with libtool maintainer to get alpha source release that
has all the needed bits to support building on ppc64le. A stable release
is expected soon.

You can pick up the libtool alpha source release from either of the
below :
ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz   (1.6MB)
ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz   (920KB)

Would it be possible for you to spin up a newer version of
freeipmi which would support ppc64le? by using alpha libtool
release?

I can help to validate the new release of the freeipmi works
well by compiling on ppc64le machine.

Appreciate your response.

Thanks,
Chandan

  
  
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] freeipmi : Request to spin up a new version of freeipmi with ppc64le support.

[Al Chu]

Hi Chandan,

Are you looking for a one-time build w/ this new libtool so you can try
it on ppc64le machines?  Or are you hoping I will use the newer libtool
for future FreeIPMI releases?

The latter is more difficult for me todo, but I could do a one-off for
ppc64le people to try out.

Is this related to any work going on at Redhat?  Within the last few
months, several PPC related patches came from Redhat.

Al

On Tue, 2014-01-14 at 16:33 +0530, Chandan wrote:
 Hi Albert,
 
 We are adding support for new ppc64le (IBM powerPC Little Endian)
 architecture as part of which we are looking at all the packages that
 need update.
 
 I was looking at “freeipmi” (from repo: cvs -z3
 -d:pserver:anonym...@cvs.savannah.gnu.org:/web/freeipmi and
 freeipmi-1.3.4 as well ) and was failed to build “freeipmi” on ppc64le
 machine because of outdated libtool.
 
 We have worked with libtool maintainer to get alpha source release that
 has all the needed bits to support building on ppc64le. A stable release
 is expected soon.
 
 You can pick up the libtool alpha source release from either of the
 below :
 ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz   (1.6MB)
 ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz   (920KB)
 
 Would it be possible for you to spin up a newer version of
 freeipmi which would support ppc64le? by using alpha libtool
 release?
 
 I can help to validate the new release of the freeipmi works
 well by compiling on ppc64le machine.
 
 Appreciate your response.
 
 Thanks,
 Chandan
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] [SPAM] - RE: Retrieving BIOS information via IPMI - Email found in subject

[Al Chu]

I've seen it on a few other motherboards, where the privilege level you
set is seemingly irrelevant.  So it may simply be an issue until the
vendor fixes it.

Al

On Wed, 2014-01-08 at 12:47 -0500, Vinny Vallarine wrote:
 Ah, figured that was it initially but tried it using the wrong window 
 (running a different tool) and -l was not recognized.   Sorry!
 
 In either case:
 
 ./bmc-info -l ADMIN -h 192.168.123.72 -u ADMIN -p ADMIN --get-system-info
 ./bmc-info -l OPERATOR -h 192.168.123.72 -u ADMIN -p ADMIN --get-system-info
 ./bmc-info -l USER  -h 192.168.123.72 -u ADMIN -p ADMIN --get-system-info
 
 all return 
 ipmi_cmd_get_system_info_parameters_system_firmware_version_first_set:  
 privilege level insufficient
 
 I've found this post:
 http://lists.gnu.org/archive/html/freeipmi-devel/2011-11/msg8.html
 
 does this ring any bells?  My IPMI firmware is 2.34 and freeipmi package is 
 at rev 1.3.4 so much latter then the rev mentioned in the article.
 
 
 Thanks,
 
 Vinny
 
 -Original Message-
 From: Al Chu [mailto:ch...@llnl.gov] 
 Sent: Wednesday, January 08, 2014 12:05 PM
 To: Vinny Vallarine
 Cc: Rob Swindell; freeipmi-devel@gnu.org
 Subject: RE: [SPAM] - RE: [Freeipmi-devel] Retrieving BIOS information via 
 IPMI - Email found in subject
 
 Try them as command line parameters.
 
 bmc-info -l admin ...
 
 Al
 
 On Wed, 2014-01-08 at 07:59 -0500, Vinny Vallarine wrote:
  Not entirely sure what you mean by this.  Could you clarify?  
  
  -Original Message-
  From: Al Chu [mailto:ch...@llnl.gov]
  Sent: Tuesday, January 07, 2014 5:25 PM
  To: Vinny Vallarine
  Cc: Rob Swindell; freeipmi-devel@gnu.org
  Subject: RE: [SPAM] - RE: [Freeipmi-devel] Retrieving BIOS information 
  via IPMI - Email found in subject
  
  On Tue, 2014-01-07 at 17:13 -0500, Vinny Vallarine wrote:
   Sorry, totally left that out.  Now,
   
   ./bmc-info -h 192.168.123.72 -u ADMIN -p ADMIN --get-system-info
  
  Try adjusting the privilege level of the tool. e.g.
  
  -l operator
  -l admin
  
  Al
  
   Returns:
   
   ipmi_cmd_get_system_info_parameters_system_firmware_version_first_set: 
   privilege level insufficient
   
   I assumed ADMIN (default) should be all I would need but does not seem 
   so. 
   
   
   
   -Original Message-
   From: Rob Swindell [mailto:swind...@broadcom.com]
   Sent: Tuesday, January 07, 2014 5:02 PM
   To: Vinny Vallarine; Al Chu
   Cc: freeipmi-devel@gnu.org
   Subject: RE: [SPAM] - RE: [Freeipmi-devel] Retrieving BIOS 
   information via IPMI - Email found in subject
   
   Did you try with the  --get-system-info option? The value you're 
   looking for is System Firmware Version, not Firmware Revision.
   
   -Rob
   
   -Original Message-
   From: Vinny Vallarine [mailto:vvallar...@idtus.com]
   Sent: Tuesday, January 07, 2014 11:41 AM
   To: Rob Swindell; Al Chu
   Cc: freeipmi-devel@gnu.org
   Subject: RE: [SPAM] - RE: [Freeipmi-devel] Retrieving BIOS 
   information via IPMI - Email found in subject
   
   Rob, thanks for the info.  I've been able to verify that running:
   
   ./bmc-info -h 192.168.123.72 -u ADMIN -p ADMIN returns:
   
   
   Device ID : 32
   Device Revision   : 1
   Device SDRs   : unsupported
   Firmware Revision : 2.34
   Device Available  : yes (normal operation)
   IPMI Version  : 2.0
   Sensor Device : supported
   SDR Repository Device : supported
   SEL Device: supported
   FRU Inventory Device  : supported
   IPMB Event Receiver   : supported
   IPMB Event Generator  : supported
   Bridge: unsupported
   Chassis Device: supported
   Manufacturer ID   : Super Micro Computer Inc. (10876)
   Product ID: 1591
   ~~~
   
   Unfortunately, Firmware Revision : 2.34 is the firmware of the 
   BMC.  I've confirmed this logging into the BIOS directly and looking 
   through the screens. 
   
   Any additional ideas would be appreciated.  I'll continue to look through 
   things...
   
   
   Thanks,
   
   Vinny
   
   -Original Message-
   From: Rob Swindell [mailto:swind...@broadcom.com]
   Sent: Monday, January 06, 2014 7:31 PM
   To: Al Chu; Vinny Vallarine
   Cc: freeipmi-devel@gnu.org
   Subject: [SPAM] - RE: [Freeipmi-devel] Retrieving BIOS information 
   via IPMI - Email found in subject
   
   The IPMI Get System Info Parameters command  (IPMI 2.0, section 22.14b) 
   allows a remote management console/utility/library to query the System 
   Firmware version. This version information would be the primary BIOS 
   version (legacy or UEFI) on a server.
   
   The Free-IPMI bmc-info command used with the --get-system-info option 
   can be used to query the BMC and display this detail if it's available.  
   While this command is not vendor-specific, not all BMC vendors may 
   implement support for this IPMI command or this specific System Info 
   Parameter (1).
   
   Of course

Re: [Freeipmi-devel] ipmi-sensors crash

[Al Chu]

Ping me after the new year and we can look at it more.  I'd like to see
the debug output of a --bridge-sensors with one of those ambient
sensors.

That's the one I expected to work.  Not what's going on.  Could be some
subtle bug ... or possibly an internal timeout or something.

Al

On Fri, 2013-12-20 at 14:33 +, Dave Love wrote:
 Albert Chu ch...@llnl.gov writes:
 
  On Thu, 2013-12-19 at 11:56 +, Dave Love wrote:
  I realized that the system that caused the crash has 601 sensors; really.
  Patch attached.
 
  Well how about that :-)
 
 I should have apologized for not looking properly to start with, as the
 stack had been smashed.
 
  Could you try running w/ --bridge-sensors
 
 That's _very_ slow, and still gives N/A.
 
  or the 'assumebmcowner'
  workaround.  The sensor isn't owned by the BMC, leading to the N/A.
 
 The workaround doesn't make any difference.
 
 I don't know how it's done on the system, and I'm not sure we have
 useful technical docs, but the individual BMCs in the component boxes
 all report the sensors in all four boxes as far as I can tell.
 
 This is a bit of an annoyance for our monitoring, but not a big deal,
 but I can look again in the new year if you would like to address it.
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ipmi-sensors crash

[Al Chu]

Hi Dave,

Huh ... I'm sorta at a loss.  The state_data-prog_data data structure
is pretty core.  It's set once near the beginning in main and never
written to again once the main code is executed, which may include
 threads if you're doing hostranges.  Dunno if the threading could be
part of the problem for your unique system.

For kicks, another fellow on the mailing recently had a segv problem and
it appeared it was related to this.  Possible for you too?

http://www.gnu.org/software/freeipmi/freeipmi-faq.html#Why-am-I-seeing-so-many-_0027internal-IPMI-error_0027-or-_0027driver-busy_0027-messages_003f

Al

On Wed, 2013-12-18 at 15:02 +, Dave Love wrote:
 I got a segv trying to run ipmi-sensors (1.3.4).  It may be relevant
 that the system is somewhat unusual -- four (Bull) servers glued
 together to make a large SMP box.
 
 I don't have time to debug it properly, but here's a backtrace, although
 it may be junk, given the top of the stack.  I can send specific info
 that might be useful.  The --debug output is 120k compressed, so I
 haven't attached it.
 
 (gdb) bt
 #0  0x004050be in _calculate_record_ids (state_data=0x7fff4e10)
 at ipmi-sensors.c:485
 #1  _display_sensors (state_data=0x7fff4e10) at ipmi-sensors.c:1162
 #2  0x80048003 in ?? ()
 #3  0x7fff8005 in ?? ()
 #4  0x006371b0 in ?? ()
 #5  0x7fff5100 in ?? ()
 #6  0x in ?? ()
 (gdb) l
 480  ipmi_sdr_parse_record_id_and_type: 
 %s\n,
 481  ipmi_sdr_ctx_errormsg 
 (state_data-sdr_ctx));
 482 return (-1);
 483   }
 484   
 485 if (state_data-prog_data-args-exclude_record_ids_length)
 486   {
 487 int found_exclude = 0;
 488 
 489 for (j = 0; j  
 state_data-prog_data-args-exclude_record_ids_length; j++)
 (gdb) p *state_data-prog_data-args
 Cannot access memory at address 0x7fff800d
 (gdb) p *state_data-prog_data
 Cannot access memory at address 0x7fff8005
 (gdb) p *state_data
 $1 = {prog_data = 0x7fff8005, ipmi_ctx = 0x6371b0, 
   pstate = 0x7fff5100, hostname = 0x0, sdr_ctx = 0x637bd0, 
   sensor_read_ctx = 0x648050, interpret_ctx = 0x0, output_headers = 0, 
   column_width = {record_id = 5, sensor_name = 15, sensor_type = 23, 
 sensor_units = 5}, oem_data = {manufacturer_id = 0, product_id = 0, 
 ipmi_version_major = 0 '\000', ipmi_version_minor = 0 '\000'}, 
   intel_node_manager = {node_manager_data_found = 0, 
 nm_health_event_sensor_number = 0 '\000', 
 nm_exception_event_sensor_number = 0 '\000', 
 nm_operational_capabilities_sensor_number = 0 '\000', 
 nm_alert_threshold_exceeded_sensor_number = 0 '\000'}}
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] [bug #38798] timestamps are interpretted as UT rather than localtime, violating IPMI 2.0 section 37

[Al Chu]

On Thu, 2013-05-02 at 16:34 +0200, Liebig, Holger wrote:
  
  I for one think that's a great idea. Do you happen to know of BMCs which
  actually support the Get SEL Time UTC Offset command?
 [Liebig, Holger] 
 I know at least one BMC base firmware provider which supports these 2
 optional IPMI cmds in current firmware versions. But (unfortunately)
 logs by default into the SEL with local time timestamps and in
 addition provides the UTC offset of the running embedded O/S with the
 Get SEL Time UTC cmd - which in my opinion is not correct. A BMC
 should log either in local time or in UTC and provide information
 about the current UTC offset of the SEL in the latter case, but not
 both at the same time.
 
 My understanding is: 
 Get SEL Time UTC Offset not supported or returning unspecified
 (0x7FFF) the SEL is operating in local time. Any other value within
 the valid range of -1440 ... 1400 is indicating the SEL running in UTC
 mode. Adding the offset to the SEL timestamps results in calendar
 time, quote from the man page: When interpreted as an absolute time
 value, it represents the number of seconds elapsed since the Epoch,
 1970-01-01 00:00:00 + (UTC). Both localtime_r() and gmtime_r()
 take calendar time as input, which would represents your usage model
 of converting #1 into #2 or #3 below. 

I don't think that's the case?  localtime_r() and gmtime_r() assume
input is UTC time.  gmtime_r() only converts the inputted timestamp into
the broken down time (struct tm)?

I've been actually trying to figure out the best/most portable/thread
safe way to convert from a localtime to UTC time and haven't quite
figured it out.  One developer in my group said I may need to muck w/
the timezone fields within 'struct tm', which seems scary.  Mucking w/
the TZ environment variable is (AFAIK) not thread safe.  I'm thinking
manual calculation is probably the most safe/portable (i.e. calculate
the difference between the gmtime  localtime results and adjust
appropriately).

  
  One point of frequent confusion is that there are actually 3 potential
  interpretations of a time-stamp:
  1. Local time for the managed system/BMC 2. Local time for the management
  console 3. UTC
 [Liebig, Holger] 
 It can be even more complicated, depending if the BMC has its own
 RTC/time source (better), or is using the systems RTC (bad). If the
 BMC is using the system RTC and depending on the O/S and the
 configuration of the system, the system RTC can reflect local time
 (Windows default) or UTC (Linux default). This can be changed for both
 of them to match each other, but the default is vice versa and dual
 booting is fun. See also
 http://mikebeach.org/2011/04/10/windows-linux-dual-boot-system-time-issues/ . 
 Additional problems arise, when the O/S is operating the system RTC in UTC 
 mode, but the BMC is interpreting the RTC as local time without a standard 
 way of knowledge of the RTC mode of the running O/S. So we might end up with 
 multiple command line options:
 
 --interpret-sel-time-as-localtime: 
 If Get SEL UTC offset returns unspecified or is not supported pass the 
 timestamp unmodified into gmtime_r()

This was what I was going to have output as default.

 If Get SEL UTC offset valid pass the timestamp + offset into localtime_r()

 --interpret-sel-time-as-utc
 If Get SEL UTC offset returns unspecified or is not supported pass the 
 timestamp unmodified into localtime_r()

Yup, this was going to be my --assume-time-utc like option.

 If Get SEL UTC offset valid pass the timestamp + offset into gmtime_r()
 
 --ignore-sel-time-utc-offset
 Workaround for the case mentioned above when the BMC is logging with
 local time timestamps and is also returning a valid SEL Time UTC
 offset. -- pass the timestamp unmodified into gmtime_r()
 
 And the combinations:
 --interpret-sel-time-as-utc --ignore-sel-time-utc-offset
 ??? use UTC offset from management console?
 
 --interpret-sel-time-as-localtime --ignore-sel-time-utc-offset
 pass the timestamp unmodified into gmtime_r()

I need to look on my systems and see how many support the get/set SEL
UTC time commands.  If very few do, I think that implementing something
that tries to use it is perhaps fruitless.

Or perhaps there would be option for the user to tell FreeIPMI to use
them at their risk?

One colleague made a great suggestion of that FreeIPMI should always
offer a --utc-offset=XXX option so that users can also just explicitly
list whatever they want.

Al

  
  The IPMI specification defines time-stamps sent from the management
  controller as format #1. If the management console can get the managed
  system's UTC offset (e.g. using Get SEL Time UTC Offset), then it could
  convert the timestamps from format #1 to either #2 or #3 (for display,
  storage or comparison purposes).
 
 [Liebig, Holger] 
 As I stated above, my understanding is that this command is for solely for 
 the SEL Time UTC offset and **not** a generic Get BMC Time UTC offset. 
 
 
 Let me know if 

Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds for ruby implementation

[Al Chu]

On Mon, 2012-07-30 at 06:16 -0700, Jim Mankovich wrote:
 Al, Corey,
 
 FYI, The  DL380 G5 only supports IPMI 2.0.

Well that's an IPMI compliance issue as well.

 Could one of you summarize which IPMI command or commands that
 you are having issues with?  Maybe I can help out.

The issue is the Get System Boot Options IPMI command and the boot
flags parameter selector.  See Corey's previous link:

http://pastebin.com/6E9R9VNG

which shows a packet trace.

Al

 -- Jim Mankovich | jm...@hp.com --
 
 On 7/29/2012 1:18 PM, Al Chu wrote:
  On Sun, 2012-07-29 at 11:48 -0700, Corey Osman wrote:
 
 
 
  On Jul 29, 2012, at 11:05 AM, Al Chu ch...@llnl.gov wrote:
 
  Hey Corey,
 
  For some reason, on your system, HP motherboard sends extra data for
  this particular IPMI payload.
 
  192.168.1.22: Payload Unexpected Data:
  192.168.1.22: 
  192.168.1.22: [  BYTE ARRAY ... ] = unexpected_data[12B]
  192.168.1.22: [ 00h 00h 00h 00h 00h 00h 00h 00h ]
  192.168.1.22: [ 00h 00h 00h F5h ]
 
  FreeIPMI reasonably determines this payload is bogus and throws it
  out.
  I'm not really sure how to work around this.  Can you do a
  --checkout
  with IPMI 1.5?  i.e. --driver-type=LAN
 
  I can't because of the following error which is fixed by specifying
  LAN_2_0
 
 
authentication type unavailable for attempted privilege level
  Your system simply may not be configured to allow the currently used
  authentication level.  You can experiment with different ones using the
  '-a' option.
 
 
 
  Additionally,
 
 
  I just tried the ipmitool method to set the boot device and it
  worked.  However the difference is that it sets the boot device
  instead of retrieving the information
 
  I am going to try and just set the boot device instead of performing a
  checkout.  I would assume it freeipmi is better sending data than
  querying.
  The issue is that FreeIPMI will send the data in the format it knows of,
  which may not work with whatever data format the HP motherboard is
  working with.
 
  I suppose it's also worth trying inband communication on the motherboard
  to see if reading the chassis config works that way.
 
  At the minimum, please send this information to HP.  They should
  definitely fix their board.
 
  Al
 
  Corey
 
 
 
  Al
 
  On Sun, 2012-07-29 at 10:20 -0700, Corey Osman wrote:
  Please ignore my previous post as I forgot to plugin my ipmi
  device.
 
 
  Here is the corrected output:
 
 
  ipmi-chassis-config --username=admin
  --password=password--hostname=192.168.1.22 --driver-type=LAN_2_0
  --debug --section=Chassis_Boot_Flags --checkout
 
 
  http://pastebin.com/6E9R9VNG
 
  Note: this is an HP DL380 G5 with ilo 2 - version 2.0 firmware
 
 
  Thanks,
 
 
  Corey Osman
  co...@logicminds.biz
 
 
  Green IT and Data Center Automation Specialist
 
 
 
 
 
 
 
 
 
 
  On Jul 29, 2012, at 9:57 AM, Corey Osman co...@logicminds.biz
  wrote:
 
  Here is the out of running the following command (There were 9
  total
  attempts with the output below):
 
 
  ipmi-chassis-config --username=admin
  --password=password--hostname=192.168.1.22 --driver-type=LAN_2_0
  --debug --section=Chassis_Boot_Flags --checkout
 
 
  192.168.1.22:
  =
  192.168.1.22: IPMI 1.5 Get Channel Authentication Capabilities
  Request
  192.168.1.22:
  =
  192.168.1.22: RMCP Header:
  192.168.1.22: 
  192.168.1.22: [   6h] = version[ 8b]
  192.168.1.22: [   0h] = reserved[ 8b]
  192.168.1.22: [  FFh] = sequence_number[ 8b]
  192.168.1.22: [   7h] = message_class.class[ 5b]
  192.168.1.22: [   0h] = message_class.reserved[ 2b]
  192.168.1.22: [   0h] = message_class.ack[ 1b]
  192.168.1.22: IPMI Session Header:
  192.168.1.22: 
  192.168.1.22: [   0h] = authentication_type[ 8b]
  192.168.1.22: [   0h] = session_sequence_number[32b]
  192.168.1.22: [   0h] = session_id[32b]
  192.168.1.22: [   9h] = ipmi_msg_len[ 8b]
  192.168.1.22: IPMI Message Header:
  192.168.1.22: 
  192.168.1.22: [  20h] = rs_addr[ 8b]
  192.168.1.22: [   0h] = rs_lun[ 2b]
  192.168.1.22: [   6h] = net_fn[ 6b]
  192.168.1.22: [  C8h] = checksum1[ 8b]
  192.168.1.22: [  81h] = rq_addr[ 8b]
  192.168.1.22: [   0h] = rq_lun[ 2b]
  192.168.1.22: [  1Eh] = rq_seq[ 6b]
  192.168.1.22: IPMI Command Data:
  192.168.1.22: --
  192.168.1.22: [  38h] = cmd[ 8b]
  192.168.1.22: [   Eh] = channel_number[ 4b]
  192.168.1.22: [   0h] = reserved1[ 3b]
  192.168.1.22: [   1h] =
  get_ipmi_v2.0_extended_data[ 1b]
  192.168.1.22: [   4h] = maximum_privilege_level[ 4b]
  192.168.1.22: [   0h] = reserved2[ 4b

Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds for ruby implementation

[Al Chu]

Hey Corey,

For some reason, on your system, HP motherboard sends extra data for
this particular IPMI payload.

192.168.1.22: Payload Unexpected Data:
192.168.1.22: 
192.168.1.22: [  BYTE ARRAY ... ] = unexpected_data[12B]
192.168.1.22: [ 00h 00h 00h 00h 00h 00h 00h 00h ]
192.168.1.22: [ 00h 00h 00h F5h ]

FreeIPMI reasonably determines this payload is bogus and throws it out.
I'm not really sure how to work around this.  Can you do a --checkout
with IPMI 1.5?  i.e. --driver-type=LAN

Al

On Sun, 2012-07-29 at 10:20 -0700, Corey Osman wrote:
 Please ignore my previous post as I forgot to plugin my ipmi device.
 
 
 Here is the corrected output:
 
 
 ipmi-chassis-config --username=admin
 --password=password--hostname=192.168.1.22 --driver-type=LAN_2_0
 --debug --section=Chassis_Boot_Flags --checkout
 
 
 http://pastebin.com/6E9R9VNG
 
 Note: this is an HP DL380 G5 with ilo 2 - version 2.0 firmware 
 
 
 Thanks,
 
 
 Corey Osman
 co...@logicminds.biz
 
 
 Green IT and Data Center Automation Specialist
 
 
 
 
 
 
 
 
 
 
 On Jul 29, 2012, at 9:57 AM, Corey Osman co...@logicminds.biz wrote:
 
  Here is the out of running the following command (There were 9 total
  attempts with the output below):
  
  
  ipmi-chassis-config --username=admin
  --password=password--hostname=192.168.1.22 --driver-type=LAN_2_0
  --debug --section=Chassis_Boot_Flags --checkout
  
  
  192.168.1.22: =
  192.168.1.22: IPMI 1.5 Get Channel Authentication Capabilities
  Request
  192.168.1.22: =
  192.168.1.22: RMCP Header:
  192.168.1.22: 
  192.168.1.22: [   6h] = version[ 8b]
  192.168.1.22: [   0h] = reserved[ 8b]
  192.168.1.22: [  FFh] = sequence_number[ 8b]
  192.168.1.22: [   7h] = message_class.class[ 5b]
  192.168.1.22: [   0h] = message_class.reserved[ 2b]
  192.168.1.22: [   0h] = message_class.ack[ 1b]
  192.168.1.22: IPMI Session Header:
  192.168.1.22: 
  192.168.1.22: [   0h] = authentication_type[ 8b]
  192.168.1.22: [   0h] = session_sequence_number[32b]
  192.168.1.22: [   0h] = session_id[32b]
  192.168.1.22: [   9h] = ipmi_msg_len[ 8b]
  192.168.1.22: IPMI Message Header:
  192.168.1.22: 
  192.168.1.22: [  20h] = rs_addr[ 8b]
  192.168.1.22: [   0h] = rs_lun[ 2b]
  192.168.1.22: [   6h] = net_fn[ 6b]
  192.168.1.22: [  C8h] = checksum1[ 8b]
  192.168.1.22: [  81h] = rq_addr[ 8b]
  192.168.1.22: [   0h] = rq_lun[ 2b]
  192.168.1.22: [  1Eh] = rq_seq[ 6b]
  192.168.1.22: IPMI Command Data:
  192.168.1.22: --
  192.168.1.22: [  38h] = cmd[ 8b]
  192.168.1.22: [   Eh] = channel_number[ 4b]
  192.168.1.22: [   0h] = reserved1[ 3b]
  192.168.1.22: [   1h] = get_ipmi_v2.0_extended_data[ 1b]
  192.168.1.22: [   4h] = maximum_privilege_level[ 4b]
  192.168.1.22: [   0h] = reserved2[ 4b]
  192.168.1.22: IPMI Trailer:
  192.168.1.22: --
  192.168.1.22: [  3Dh] = checksum2[ 8b]
  ipmi-chassis-config: connection timeout
  
  
  
  Thanks,
  
  
  Corey Osman
  co...@logicminds.biz
  
  
  Green IT and Data Center Automation Specialist
  
  
  
  
  
  
  
  
  
  
  On Jul 22, 2012, at 10:57 PM, Al Chu ch...@llnl.gov wrote:
  
   Hi Corey,
   
   On Sun, 2012-07-22 at 13:20 -0700, Corey Osman wrote:
Hi,

My ruby implementation is off to a great start but I had a few
questions with regards to driver types and inband configuration.

Since I will have no idea as to what kind of IPMI device needs
to be
controlled I need to make sure that everything appears automatic
with
regards to driver types and any kind of workarounds.

My goal is to automatically detect driver type and workarounds
to ease
the pain for folks who use the ruby-freeipmi library.  
   
   I admit I'm not sure of the best way to handle this and make sure
   the
   code is super-portable.  It's sort of an unfortunate
   side-effect/consequence of IPMI being implemented by so many
   vendors.
   ipmitool is no different, as you select an interface if the
   default
   doesn't work.
   
My current test device is an HP DL380 G5.  I was hoping to have
this
device automatically detected but it appears I need to supply
the
--driver-type=LAN_2_0.

Although this is not really a problem as I am planning on doing
some
testing up front as to which driver to explicitly assign.

However, I have noticed that when I call ipmi-chassis-config
--checkout  the command appears to stall and doesn't provide all
the
information.  Output below
   
   Could you provide the --debug output from

Re: [Freeipmi-devel] Thresholds in CSV output

[Al Chu]

Hi Diego,

It wouldn't be too hard to add the threshold output as new columns in
the ipmi-sensors output (it'll be a bit of work, but not an insane
amount).  I'd have to make it an option to maintain the default output.
Is something like this what you are thinking of

1, Proc 1 Temp, Processor, 88.4, C, N/A, 3.0, 8.0, 42.0, 48.0, N/A, 'OK'

the above would be for something from this:

Lower Critical Threshold: 3.00 C
Upper Critical Threshold: 47.00 C
Lower Non-Critical Threshold: 8.00 C
Upper Non-Critical Threshold: 42.00 C
Lower Non-Recoverable Threshold: N/A
Upper Non-Recoverable Threshold: N/A
Normal Min.: 11.00 C
Normal Max.: 69.00 C

should I output the normal min/max too??

As for power consumption, many boards do not do it within an IPMI
sensor, there is usually an OEM extension for it.  I wrote an answer on
serverfault.com awhile back that has all the examples I personally have
seen.

http://serverfault.com/questions/389224/power-usage-via-ipmi-or-bios-or

Al

On Thu, 2012-07-26 at 19:47 -0700, Diego Elio Pettenò wrote:
 Hi all,
 
 Today I had to fight with the (very bad) ipmi plugin for Munin, which is
 based off ipmitool. Since then I wrote a plugin that outputs the same
 thing but with freeipmi's ipmi-sensors.
 
 The main issue is that ipmitool does output on its (not-so-clear)
 listing the thresholds by default, which Munin can use. ipmi-sensors
 doesn't, as it is, it only outputs them in verbose mode, which is simply
 very bad to write scripts for.
 
 Would it be possible to have it at the end of the CSV?
 
 And another thing, has anybody a sample output of an IPMI board that
 reports power consumption? That's the second feature my freeipmi-based
 plugin is missing, and if I can get those two in, Munin 2.1 will use it
 by default.
 
 Thanks for the help,
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Questions regarding auto discovery and workarounds for ruby implementation

[Al Chu]

Hi Corey,

On Sun, 2012-07-22 at 13:20 -0700, Corey Osman wrote:
 Hi,
 
 My ruby implementation is off to a great start but I had a few
 questions with regards to driver types and inband configuration.
 
 Since I will have no idea as to what kind of IPMI device needs to be
 controlled I need to make sure that everything appears automatic with
 regards to driver types and any kind of workarounds.
 
 My goal is to automatically detect driver type and workarounds to ease
 the pain for folks who use the ruby-freeipmi library.  

I admit I'm not sure of the best way to handle this and make sure the
code is super-portable.  It's sort of an unfortunate
side-effect/consequence of IPMI being implemented by so many vendors.
ipmitool is no different, as you select an interface if the default
doesn't work.

 My current test device is an HP DL380 G5.  I was hoping to have this
 device automatically detected but it appears I need to supply the
 --driver-type=LAN_2_0.

 Although this is not really a problem as I am planning on doing some
 testing up front as to which driver to explicitly assign.
 
 However, I have noticed that when I call ipmi-chassis-config
 --checkout  the command appears to stall and doesn't provide all the
 information.  Output below

Could you provide the --debug output from the below?  Use the
--section=Chassis_Boot_Flags so we can isolate the debug output to just
he bad section below.

 How do I set the bios to boot from cdrom, usb and network?  Also do I
 have a choice of which network device I can boot from?

Once we get this section working, you'll see the full list of options.

## Possible values: NO-OVERRIDE/PXE/HARD-DRIVE/HARD-DRIVE-SAFE-MODE/
##  DIAGNOSTIC_PARTITION/CD-DVD/BIOS-SETUP/REMOTE-FLOPPY
##  
PRIMARY-REMOTE-MEDIA/REMOTE-CD-DVD/REMOTE-HARD-DRIVE/FLOPPY
Boot_Device   NO-OVERRIDE

 Can someone supply or document the commands I would use to set the
 boot device?  What boot options do I have available, as only Floppy is
 in the output?
 Additionally,  is this a one time boot setting or will it boot from
 the device after every reboot.

It should be configurable via

## Possible values: Yes/No (Yes = All Future Boots; No = Next Boot Only)
Boot_Flags_Persistent No

once we get it to output.

 Also, do I need to supply an inband option here?

Inband communication is usually auto-discovered, but every simple is
different and its certainly possible a auto-discovery can fail in some
systems.  Some HP motherboards have a known inband defect, which may
require use of a workaround (see manpage).

Hope this helps get things going for you,

Al

 Please feel free to have a look at my code and provide any suggestions.  I 
 have written a README file to explain how things will work.
 
 https://github.com/logicminds/ruby-freeipmi
 
 Command line examples would be great as I can easily convert them to ruby 
 calls.
 
 
 
 #
 # Section Chassis_Front_Panel_Buttons Comments 
 #
 # The following configuration options are for enabling or disabling button 
 # functionality on the chassis. Button may refer to a pushbutton, switch, or 
 # other front panel control built into the system chassis. 
 #
 # The value of the below may not be able to be checked out. Therefore we 
 # recommend the user configure all four fields rather than a subset of them, 
 # otherwise some assumptions on configure may be made. 
 #
 Section Chassis_Front_Panel_Buttons
   ## Possible values: Yes/No
   Enable_Standby_Button_For_Entering_StandbyYes
   ## Possible values: Yes/No
   Enable_Diagnostic_Interrupt_ButtonYes
   ## Possible values: Yes/No
   Enable_Reset_Button   Yes
   ## Possible values: Yes/No
   Enable_Power_Off_Button_For_Power_Off_OnlyYes
 EndSection
 #
 # Section Chassis_Power_Conf Comments 
 #
 # The following configuration options are for configuring chassis power 
 # behavior. 
 #
 # The Power_Restore_Policy determines the behavior of the machine when AC 
 # power returns after a power loss. The behavior can be set to always power 
 on 
 # the machine (On_State_AC_Apply), power off the machine 
 # (Off_State_AC_Apply), or return the power to the state that existed 
 before 
 # the power loss (Restore_State_AC_Apply). 
 #
 # The Power_Cycle_Interval determines the time the system will be powered 
 down 
 # following a power cycle command. 
 #
 Section Chassis_Power_Conf
   ## Possible values: 
 Off_State_AC_Apply/Restore_State_AC_Apply/On_State_AC_Apply
   Power_Restore_Policy  Restore_State_AC_Apply
   ## Give value in seconds
   ## Power_Cycle_Interval   
 EndSection
 #
 # Section Chassis_Boot_Flags Comments 
 #
 # The following configuration options are for configuring chassis boot 
 behavior. 
 # Please note that some fields may apply to all 

Re: [Freeipmi-devel] [PATCH] Add support for Supermicro H8DGU-F to ipmi-sensors.

[Al Chu]

Hi Diego,

Applied, thanks.  I also added the support for ipmi-sel and the
--output-sensor-state/--output-event-state options.

However, proper --output-sensor-state support, I need to know what the
motherboard manufactuer ID is from bmc-info.  Normally I don't need to
ask, but too many Supermicro motherboards come with invalid IDs.  I
simply guessed it was the 47488 ID.

Al

On Sat, 2012-05-05 at 10:44 -0700, Diego Elio Pettenò wrote:
 Signed-off-by: Diego Elio Pettenò flamee...@flameeyes.eu
 ---
  .../include/freeipmi/spec/ipmi-product-id-spec.h   |1 +
  .../util/ipmi-sensor-and-event-code-tables-util.c  |3 ++-
  2 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/libfreeipmi/include/freeipmi/spec/ipmi-product-id-spec.h 
 b/libfreeipmi/include/freeipmi/spec/ipmi-product-id-spec.h
 index 516c5f9..5c5a0df 100644
 --- a/libfreeipmi/include/freeipmi/spec/ipmi-product-id-spec.h
 +++ b/libfreeipmi/include/freeipmi/spec/ipmi-product-id-spec.h
 @@ -219,6 +219,7 @@ extern C {
  #define IPMI_SUPERMICRO_PRODUCT_ID_X8DTNPLUS_F 1551
  #define IPMI_SUPERMICRO_PRODUCT_ID_X8SIE   1037
  #define IPMI_SUPERMICRO_PRODUCT_ID_X9SCA_F_O   1585
 +#define IPMI_SUPERMICRO_PRODUCT_ID_H8DGU_F 43025
  
  /* Seen in the wild w/ proper IANA number 10876 */
  /* defined above: IPMI_SUPERMICRO_PRODUCT_ID_X9SCM */
 diff --git a/libfreeipmi/util/ipmi-sensor-and-event-code-tables-util.c 
 b/libfreeipmi/util/ipmi-sensor-and-event-code-tables-util.c
 index 0e9c475..68d2718 100644
 --- a/libfreeipmi/util/ipmi-sensor-and-event-code-tables-util.c
 +++ b/libfreeipmi/util/ipmi-sensor-and-event-code-tables-util.c
 @@ -2153,7 +2153,8 @@ _supermicro_oem_temp_level_sensor_supported (uint32_t 
 manufacturer_id, uint16_t
 || product_id == IPMI_SUPERMICRO_PRODUCT_ID_X9SCM
 || product_id == IPMI_SUPERMICRO_PRODUCT_ID_X8DTNPLUS_F
 || product_id == IPMI_SUPERMICRO_PRODUCT_ID_X8SIE
 -   || product_id == IPMI_SUPERMICRO_PRODUCT_ID_X9SCA_F_O))
 +   || product_id == IPMI_SUPERMICRO_PRODUCT_ID_X9SCA_F_O
 +   || product_id == IPMI_SUPERMICRO_PRODUCT_ID_H8DGU_F))
|| (manufacturer_id == IPMI_IANA_ENTERPRISE_ID_MAGNUM_TECHNOLOGIES
  product_id == IPMI_SUPERMICRO_PRODUCT_ID_X8DTL))
  return (1);
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] [PATCH 1/2] Check against password length of IPMI 2 intead of 1.5.

[Al Chu]

Hey Diego,

Good catch.  To be consistent to some other code in FreeIPMI, I fixed it
a slightly different way.

Index: ipmiconsole/ipmiconsole-argp.c
===
--- ipmiconsole/ipmiconsole-argp.c  (revision 8805)
+++ ipmiconsole/ipmiconsole-argp.c  (working copy)
@@ -237,6 +237,11 @@
 
   init_common_cmd_args_admin ((cmd_args-common));
 
+  /* ipmiconsole differences */
+  cmd_args-common.driver_type = IPMI_DEVICE_LAN_2_0;
+  cmd_args-common.session_timeout = 6;
+  cmd_args-common.retransmission_timeout = 500;
+
   cmd_args-escape_char = '';
   cmd_args-dont_steal = 0;
   cmd_args-deactivate = 0;
@@ -248,10 +253,6 @@
   cmd_args-noraw = 0;
 #endif /* NDEBUG */
 
-  /* special case to ipmiconsole, different timeout defaults */
-  cmd_args-common.session_timeout = 6;
-  cmd_args-common.retransmission_timeout = 500;
-
   argp_parse (cmdline_config_file_argp,
   argc,
   argv,


Al

On Fri, 2012-05-04 at 23:33 -0700, Diego Elio Pettenò wrote:
 For some commands, such as ipmi-console, there is no way to define the
 driver to use, and if this is not used, longer passwords are refused.
 
 When parsing command lines, passwords are always checked against IPMI
 2 and not 1.5, so keep this consistent.
 
 Signed-off-by: Diego Elio Pettenò flamee...@flameeyes.eu
 ---
  common/toolcommon/tool-cmdline-common.c |8 +++-
  1 files changed, 3 insertions(+), 5 deletions(-)
 
 diff --git a/common/toolcommon/tool-cmdline-common.c 
 b/common/toolcommon/tool-cmdline-common.c
 index 5a796c2..0827b16 100644
 --- a/common/toolcommon/tool-cmdline-common.c
 +++ b/common/toolcommon/tool-cmdline-common.c
 @@ -544,18 +544,16 @@ verify_common_cmd_args_outofband (struct 
 common_cmd_args *cmd_args, int check_ho
exit (1);
  }
  
 -  /* We default to IPMI 1.5 if the user doesn't specify LAN vs. LAN_2_0 */
 -
if (((cmd_args-hostname
   cmd_args-driver_type == IPMI_DEVICE_UNKNOWN)
 -   || cmd_args-driver_type == IPMI_DEVICE_LAN)
 +   || cmd_args-driver_type == IPMI_DEVICE_LAN
 +   || cmd_args-driver_type == IPMI_DEVICE_LAN_2_0)
 cmd_args-password
 -   strlen (cmd_args-password)  IPMI_1_5_MAX_PASSWORD_LENGTH)
 +   strlen (cmd_args-password)  IPMI_2_0_MAX_PASSWORD_LENGTH)
  {
fprintf (stderr, password too long\n);
exit (1);
  }
 -  /* else, 2_0 password length was checked in argp_parse() previously */
  
if (cmd_args-retransmission_timeout  cmd_args-session_timeout)
  {
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.1.3 Released

[Al Chu]

http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.1.3.tar.gz

FreeIPMI 1.1.3 - 03/06/12
-
Tools
--
o Support Supermicro CPU temperature SEL events.
o In ipmi-oem, fix corner case with Dell C410x power control
  calculation.
o In all tools, fix error messages to differentiate between invalid
  and unsupported cipher suite IDs.
o In bmc-config, fix a Cipher Suite Privilege configuration
  corner case in the workaround for an HP DL145 workaround.
o In bmc-config, add workaround for Cipher Suite Privilege
  configuration on Intel S2600JF/Appro 512X.
o Various documentation updates.

Libraries
--
o In libfreeipmi, fix incorrect packet layout for the Get Lan
  Configuration Parameters RMCPplus Messaging Cipher Suite Entry Support
  response.
o In libipmimonitoring, properly return connection timeout error on
  connection timeout.

Misc

o Fix build when using --docdir. 
o Various documentation updates.

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Recreating SDR cache before reading sensors information

[Al Chu]

You can pick specific sensors via the record-ID associated with the SDR
entry.

I'm not 100% sure what you're trying to program, but you may want to
consider looking at the libipmimonitoring library, which is a wrapper
that hides a lot of the sensor details.  There is an example on the
FreeIPMI webpage too.

Al

On Mon, 2012-02-27 at 01:50 -0800, Dinh Khac Thanh wrote:
 Hi,
 
 BTW, this is unlikely, but is there any more efficient way to get
 sensor data for one particular sensor rather than getting all sensors'
 data?
 I just need confirmation. Thanks in advance.
 
 Best regards
 Thanh
 
 On Mon, Feb 27, 2012 at 1:49 PM, Dinh Khac Thanh than...@gmail.com
 wrote:
 Hi,
 
 Yes, I am using libfreeipmi instead of ipmi-sensors
 executable.
 
 Best regards,
 Thanh
 
 
 On Mon, Feb 27, 2012 at 1:31 PM, Kaiwang Chen
 kaiwang.c...@gmail.com wrote:
 Thanh, are you using libfreeipmi instead of the
 ipmi-sensors
 executable? I am not quite sure about your senario,
 anyway good news
 is it works as you expect.
 
 Thanks,
 Kaiwang
 
 2012/2/27 Dinh Khac Thanh than...@gmail.com:
  Hi Kaiwang,
 
  I found out that It works if I reopen the cache
 before getting the sensor
  data. Thanks anyway.
 
  Best regards
  Thanh
 
 
  On Mon, Feb 27, 2012 at 12:04 PM, Dinh Khac Thanh
 than...@gmail.com wrote:
 
  Hi Kaiwang,
 
  Thanks for your reply. I tested with/without
 recreating the cache before
  getting the sensor data. It works fine when the
 cache is recreated, e.g:
  CPU1 Temp 46 C nominal
  CPU2 Temp N/A unavailable
  ...
  Fan11 N/A unavailable
  Intrusion N/A unavailable
  PS Status N/A unavailable
 
  but not when the cache is reused:
 
  PS Status N/A unavailable
  PS Status N/A unavailable
  PS Status N/A unavailable
  ...
  PS Status N/A unavailable
 
  The number of records in both cases are 30.
  The code is based on ipmi-sensors.c
 
  Best regards
  Thanh
 
 
  On Fri, Feb 24, 2012 at 9:12 PM, Kaiwang Chen
 kaiwang.c...@gmail.com
  wrote:
 
  2012/2/24 Dinh Khac Thanh than...@gmail.com:
   Hi,
  
   I am working on a monitoring application that
 needs to get sensor
   information via IPMI every 10 seconds. I have
 skimmed through the
   source
   code for ipmi-sensors to learn how to use
 freeipmi.
  
   My question is: If I am using the same IPMI
 session to get sensor data,
   do I
   need to recreate the SDR cache every time before
 reading the data?
 
  I believe not. The cache is checked before real
 ipmi traffic, and it's
  a noop when the cache exists and is up to date.
 There is one sdr cache
  per ipmi node, which defaults  to
 
 ~/.freeipmi/sdr-cache/sdr-cache-localhost.ipminode
 
  The logic resides in common code path defined in
 
 
 common/toolsdr/tool-sdr-cache-common.c:sdr_cache_create_and_load(),
  which is called by run_cmd_args(), which in turn
 called by
  _ipmi_sensors(). You can find _ipmi_sensors as
 callback in main
  function. All of them are in
 ipmi-sensors/ipmi-sensors.c, in the
  trunk(revision 8603).
 
 
  
   Best regards
   Thanh
  
   ___
   Freeipmi-devel mailing list
   Freeipmi-devel@gnu.org
  
 https://lists.gnu.org/mailman/listinfo/freeipmi-devel
  
 
  Thanks,
  Kaiwang
 
  

[Freeipmi-devel] FreeIPMI 1.1.2 Released

[Al Chu]

http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.1.2.tar.gz

FreeIPMI 1.1.2 - 02/06/12
-
Tools
--
o In ipmi-oem, support new Dell C410x OEM extensions
  slot-power-toggle, slot-power-control, get-port-map, set-port-map.
o Fix daemon setup race condition in ipmidetectd and bmc-watchdog that
  can affect systemd.
o In ipmiconsole, support new --serial-keepalive-empty option.
o In bmc-device, support new --rearm-sensor option.
o In ipmi-oem, add additional Dell get-system-info options
  - slot-number
  - system-revision
  - embedded-video-status
  - idrac-info
  - idrac-ipv4-url
  - idrac-gui-webserver-control
  - cmc-ipv4-url,
  - cmc-ipv6-info
  - cmc-ipv6-url
o In ipmi-oem, support Dell 12G mac addresses under get-system-info.   
o In ipmi-sensors, some sensors that reported Unknown may now report
  N/A due to an interpretation change of several IPMI error codes.
o In ipmi-sensors, workaround sensor reading issue on Sun Blade x6250
  and Sun Blade 6000M2.
o Fix several freeipmi.conf config file parsing bugs.

Libraries
--
o In libipmiconsole, fix serial keepalive timeout calculation bug that
  can lead to excessive packets retransmitted.
o In libipmiconsole, support new SERIAL_KEEPALIVE_EMPTY engine flag.
o In libipmiconsole, do not deactivate a SOL payload if it appears the
  SOL payload has been stolen, but we did not receive a SOL deactivating
  flag.
o In libipmiconsole, fix corner case in which session not closed
  cleanly when DEACTIVATE_ONLY flag specified.
o In libipmiconsole, workaround bug in Dell Poweredge M605, M610, and
  M915 where instance count of SOL is always returned as 0.
o In libfreeipmi, add functions for re-arm sensor events IPMI payload. 
o In libfreeipmi/sensor-read, under some error conditions return error
  of unavailable instead of cannot be obtained error code.
o In libfreeipmi/sensor-read, add workarounds to handle issues on Sun
  Blade x6250 and Sun Blade 6000M2.

Misc

o Various documentation updates.
o Redo formattig of include/freeipmi/templates/ documents.

Special thanks to Ryan Cox for a lot of his Dell extension reverse
engineering, testing, and documentation.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Supermicro X8DTG-QF System Event Log

[Al Chu]

Hey Gotz,

I got a branch that should have the SEL support for the Supermicro
motherboards:

svn co http://svn.savannah.gnu.org/svn/freeipmi/branches/supermicrosel 
freeipmi-supermicro
cd freeipmi-supermicro
./autogen.sh
./configure
make

then

cd ipmi-sel
./ipmi-sel --interpret-oem-data
(or if you were doing it out of band, use whatever additional options
you did before)

PLMK if that works for you.

BTW, the build will require things like libgcrypt-devel and maybe some
other libraries to be installed.  If you can't get them, LMK and I'll
e-mail you a tar.gz.

Al

On Tue, 2012-02-07 at 08:28 -0800, Al Chu wrote:
 Hey Gotz,
 
 Well, I'm going to guess that OVERHEAT is the only SEL event that can
 occur then.  I'll work on a patch.
 
 Al
 
 On Tue, 2012-02-07 at 07:56 -0800, Götz Waschk wrote:
  On Tue, Feb 7, 2012 at 4:44 PM, Al Chu ch...@llnl.gov wrote:
   Could you try a few more 0x04-0x0F
  
   0x04 0xFF 0xFF
   0x05 0xFF 0xFF
   ...
   0x0E 0xFF 0xFF
   0x0F 0xFF 0xFF
  OK:
  
  13 | Feb-07-2012 | 17:51:53 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 04h
  14 | Feb-07-2012 | 17:51:56 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 05h
  15 | Feb-07-2012 | 17:52:00 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 06h
  16 | Feb-07-2012 | 17:52:04 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 07h
  17 | Feb-07-2012 | 17:52:07 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 08h
  18 | Feb-07-2012 | 17:52:11 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 09h
  19 | Feb-07-2012 | 17:52:15 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 0Ah
  20 | Feb-07-2012 | 17:52:18 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 0Bh
  21 | Feb-07-2012 | 17:52:21 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 0Ch
  22 | Feb-07-2012 | 17:52:24 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 0Dh
  23 | Feb-07-2012 | 17:52:29 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 0Eh
  24 | Feb-07-2012 | 17:52:32 | Sensor #2  | OEM Reserved  | OEM
  Event Offset = 0Fh
  
  RID:[0D][00] RT:[02] TS:[A9][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [04] ED2: [FF] ED3: [FF]
  RID:[0E][00] RT:[02] TS:[AC][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [05] ED2: [FF] ED3: [FF]
  RID:[0F][00] RT:[02] TS:[B0][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [06] ED2: [FF] ED3: [FF]
  RID:[10][00] RT:[02] TS:[B4][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [07] ED2: [FF] ED3: [FF]
  RID:[11][00] RT:[02] TS:[B7][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [08] ED2: [FF] ED3: [FF]
  RID:[12][00] RT:[02] TS:[BB][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [09] ED2: [FF] ED3: [FF]
  RID:[13][00] RT:[02] TS:[BF][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [0A] ED2: [FF] ED3: [FF]
  RID:[14][00] RT:[02] TS:[C2][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [0B] ED2: [FF] ED3: [FF]
  RID:[15][00] RT:[02] TS:[C5][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [0C] ED2: [FF] ED3: [FF]
  RID:[16][00] RT:[02] TS:[C8][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [0D] ED2: [FF] ED3: [FF]
  RID:[17][00] RT:[02] TS:[CD][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [0E] ED2: [FF] ED3: [FF]
  RID:[18][00] RT:[02] TS:[D0][56][31][4F] GID:[21][00] ER:[04] ST:[C0]
  SN:[02] EDIR:[F0] ED1: [0F] ED2: [FF] ED3: [FF]
  
  
  Event:13 Time:02/07/2012 16:51:53 Type:OEM
  CPU2 Temp  De-assertion: OEM| Event = CPU Temp Overheat
  --
  Event:14 Time:02/07/2012 16:51:56 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:15 Time:02/07/2012 16:52:00 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:16 Time:02/07/2012 16:52:04 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:17 Time:02/07/2012 16:52:07 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:18 Time:02/07/2012 16:52:11 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:19 Time:02/07/2012 16:52:15 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:20 Time:02/07/2012 16:52:18 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:21 Time:02/07/2012 16:52:21 Type:OEM
  CPU2 Temp  De-assertion: undefined
  --
  Event:22 Time:02/07

Re: [Freeipmi-devel] Supermicro X8DTG-QF System Event Log

[Al Chu]

On Mon, 2012-02-06 at 12:27 -0800, Götz Waschk wrote:
 On Mon, Feb 6, 2012 at 7:06 PM, Albert Chu achu.de...@gmail.com wrote:
  To create SEL events, we can use bmc-device and the --platform-event
  option.  I think the following would be the equivalent to what you've
  seen before:
 
  bmc-device --platform-event=0x20 0x04 0xC0 0x02 0x70 deassertion 0x02
  0xFF 0xFF
 
  of what has been generated so far.
 Hi,
 
 that's not exactly what I had before. Instead it has generated this event:
 
 9  | Feb-06-2012 | 22:23:51 | Sensor #2  | OEM Reserved  | OEM
 Event Offset = 02h
 
 RID:[09][00] RT:[02] TS:[E7][44][30][4F] GID:[21][00] ER:[04] ST:[C0]
 SN:[02] EDIR:[F0] ED1: [02] ED2: [FF] ED3: [FF]

Argh!  B/c this was generated by software, the generator ID is not
correct, leading to the alternate output. (the [21] above is normally
[20] if generated by hardware)

Did you try the Supermicro software?  It's certainly possible they'll
ignore the generator ID.  Their software might be hard-coded to handle
their hardware and so they may not do all the same checks that I do in
FreeIPMI.

Al

 Regards, Götz
 
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] clean exit of external process when conmand shuts down

[Al Chu]

.  PLMK how it works for you.
 
  BTW, for documentation purchases, what motherboard are you seeing this
  issue on.
 
  Al
 
  On Wed, 2012-01-11 at 10:54 -0800, Albert Chu wrote:
  Hey Brian,
 
  On Tue, 2012-01-10 at 20:14 -0800, Brian Lambert wrote:
  I did another test, and have attached debug output.
 
  First, I rebooted the BMC (Dell iDRAC6) to make sure there were no
  sessions active.
 
  I then established an initial SOL session, using the following command:
 ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize 
  --serial-keepalive
 
  So far, so good.
 
  Instead of killing the first session, I left it active and tried to 
  start
  a second session using the same command.  That failed as expected, with 
  a
  BMC Error message.  Debug output from that first reconnect attempt is
  attached in ipmiconsole-reconnect1.txt.
 
  Ok, I see the problem.
 
  n003-bmc: =
  n003-bmc: IPMI 2.0 Get Payload Activation Status Response
  n003-bmc: =
  snip
  n003-bmc: IPMI Command Data:
  n003-bmc: --
  n003-bmc: [  4Ah] = cmd[ 8b]
  n003-bmc: [   0h] = comp_code[ 8b]
  n003-bmc: [   0h] = instance_capacity[ 4b]
  n003-bmc: [   1h] = reserved[ 4b]
  n003-bmc: [   1h] = instance_1[ 1b]
  n003-bmc: [   0h] = instance_2[ 1b]
  n003-bmc: [   0h] = instance_3[ 1b]
  n003-bmc: [   0h] = instance_4[ 1b]
 
  the bug in Dell's implementation is the 0h = instance_capacity.  This
  indicates the number of SOL instances that can be done at the same time.
  The fact that I ignore that it's 0 is a bug on my part (it should be  0
  always if SOL can be done).
 
  This is then used iterate on instance_1, instance_2, etc. to determine
  if SOL is currently activated.  The 1h = instance_1 indicates that SOL
  is active.  But because instance_capacity is 0, I never look at it, so
  the calculation is that no SOL is currently active.  ipmiconsole
  attempts to activate a SOL session as always, but b/c an SOL session is
  already active, the activation fails, so it trys again (assuming someone
  else raced with libipmiconsole and took SOL before it could).  It checks
  again to see if SOL is active, notices it's not, tries to activate
  again, fails, and now we have a loop.  Eventually there are too many
  failed activation attempts and libipmiconsole errors out.
 
  I then tried to deactivate the existing session using the command:
 ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize  
  --serial-keepalive --deactivate
 
  That command completed without error, but the original session was still
  active and responding to keystrokes.  Debug output from that attempt is
  attached in ipmiconsole-deactivate1.txt.
 
  Now this one makes sense.  Given the above knowledge, libipmiconsole
  calculates that the SOL session is already deactivated, so it never
  attempts an actual SOL deactivation.
 
  I think this is very workaroundable, although I need to think about how
  to do it (via workaround option?  without?) and how I can be
  careful/safe with it and not break other systems.  I'll let ya know when
  I have something you can try and tell ya the branch it's on.
 
  Al
 
  I then tried to activate a new session a second time.  It failed with 
  the
  same error message as the first reconnect attempt.  Debug output from 
  the
  second attempt is in ipmiconsole-reconnect2.txt.
 
  Thanks for your help.  Let me know if you need further details or want 
  me
  to try anything else.
 
  thanks,
  Brian
 
 
  On Sun, 8 Jan 2012, Al Chu wrote:
 
  Hi Brian,
 
  I've moved the IPMI portion of this thread to freeipmi-devel, since 
  it's
  a bit more appropriate for this mailing list.
 
  To start a session, I can use the following FreeIPMI command:
  ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize 
  --serial-
  keepalive
 
  I can quit out of that session using the . escape sequence, and
  reconnect right away.  But if I 'kill -9' that process, I get a
  [error received]: BMC Error message when I try to connect with
  another ipmiconsole command.
 
  This indicates an unexpected error code along the way.  ipmiconsole
  probably noticed that the previous SOL session was activated and tried
  to deactivate it, with some error occurring at some point.  Could you
  send the --debug output of ipmiconsole when you try to reconnnect?
 
  This is the same error message I get
  when trying the connect when another session is already active.  If I
  then issue the command:
  ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize 
  --serial-
  keepalive --deactivate
  This completes without error, but I still can't reconnect to the
  serial console.
 
  Can you give me the --debug output of the later connect attempt?  I'd
  like to see why it can't connect again.
 
  I get similar results

Re: [Freeipmi-devel] clean exit of external process when conmand shuts down

[Al Chu]

Hi Brian,

I've moved the IPMI portion of this thread to freeipmi-devel, since it's
a bit more appropriate for this mailing list.

 To start a session, I can use the following FreeIPMI command:
 ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize --serial-
 keepalive
 
 I can quit out of that session using the . escape sequence, and
 reconnect right away.  But if I 'kill -9' that process, I get a
 [error received]: BMC Error message when I try to connect with
 another ipmiconsole command.  

This indicates an unexpected error code along the way.  ipmiconsole
probably noticed that the previous SOL session was activated and tried
to deactivate it, with some error occurring at some point.  Could you
send the --debug output of ipmiconsole when you try to reconnnect?

 This is the same error message I get
 when trying the connect when another session is already active.  If I
 then issue the command:
 ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize --serial-
 keepalive --deactivate
 This completes without error, but I still can't reconnect to the
 serial console.

Can you give me the --debug output of the later connect attempt?  I'd
like to see why it can't connect again.

 I get similar results when using ipmitool.  In that case, when I try
 to reconnect, I get:
 #ipmitool -U root -P calvin -H n003-bmc -I lanplus sol activate
 Info: SOL payload already active on another session
 
 If I try to deactivate the existing session, I get:
 # ipmitool -U root -P calvin -H n003-bmc -I lanplus sol deactivate
 Info: SOL payload already de-activated

I don't know the exact test situation you're trying, but you could be
racing a bit in some of these scenarios.  When you kill the previous
session with kill -9, the server/BMC does not immediately end the
IPMI/SOL session.  It lasts for awhile longer until the server/BMC
eventually times out.  So that can explain why your first activate
attempt indicates the session is already activated, but it's deactivated
by the time your try to deactivate.

 Once it's in this state, the only thing I've been able to do to regain
 access to the serial console is reboot the BMC or wait for the session
 to time out.
 
 I have the same experience when connecting to Dell iDRAC5 and iDRAC6,
 both running the latest firmware.  Al, if you'd like more information
 or debug output from the freeipmi tools I'd be happy to provide it.

Would like to get to the bottom of this.

Al


On Sun, 2012-01-08 at 20:13 -0800, lambert wrote:
 After some additional experimentation, it looks like a direct ssh to
 the Dell blade iDRAC (BMC) followed by a command to activate the
 serial connection may be the way to go with these.  I found that a
 SIGKILL to the ssh session was sufficient to close the serial console
 session, such that I could start another session with out needing to
 wait several minutes for the old session to time out.
 
 I still need to do some more testing, but Chris you may want to wait
 before you spend too much time implementing the external process
 cleanup coding.  If I get this approach working robustly, a clean
 shutdown of the external process will be less important.
 
 
 As for the IPMI SOL issues:
 
 To start a session, I can use the following FreeIPMI command:
 ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize --serial-
 keepalive
 
 I can quit out of that session using the . escape sequence, and
 reconnect right away.  But if I 'kill -9' that process, I get a
 [error received]: BMC Error message when I try to connect with
 another ipmiconsole command.  This is the same error message I get
 when trying the connect when another session is already active.  If I
 then issue the command:
 ./ipmiconsole -h n003-bmc -u root -p calvin -W solpayloadsize --serial-
 keepalive --deactivate
 This completes without error, but I still can't reconnect to the
 serial console.
 
 I get similar results when using ipmitool.  In that case, when I try
 to reconnect, I get:
 #ipmitool -U root -P calvin -H n003-bmc -I lanplus sol activate
 Info: SOL payload already active on another session
 
 If I try to deactivate the existing session, I get:
 # ipmitool -U root -P calvin -H n003-bmc -I lanplus sol deactivate
 Info: SOL payload already de-activated
 
 Once it's in this state, the only thing I've been able to do to regain
 access to the serial console is reboot the BMC or wait for the session
 to time out.
 
 I have the same experience when connecting to Dell iDRAC5 and iDRAC6,
 both running the latest firmware.  Al, if you'd like more information
 or debug output from the freeipmi tools I'd be happy to provide it.
 
 thanks,
 Brian
 
 On Jan 7, 6:06 pm, Al Chu ch...@llnl.gov wrote:
   Thanks also for the FreeIPMI link.  That list confirms the the issue
   I've been seeing with the Dell iDRACs not responding to the sol
   deactivate.  I've made Dell aware of the issue, but don't know if they
   have any plans to fix it.
 
  When you do a sol deactivate does the original

Re: [Freeipmi-devel] Unknown sensors ibm-servers

[Al Chu]

Hi Hendrik,

This beta

http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.7.beta0.tar.gz

Includes 5 new sensor interpretations for your motherboards that weren't
there before.  I'll need the --verbose output for the sensors below to
include the rest.

Thanks,
Al

On Mon, 2011-09-12 at 10:16 -0700, Albert Chu wrote:
 Hi Hendrik,
 
 I can definitely add the interpretations necessary for the sensors you
 have on these motherboards.  There are a few that I need a bit more
 information on b/c there's not enough information in the output you've
 provided.  If you get the verbose output (-v option) that'd be great.
 If you could limit the output to specific sensors by using -r, that'd
 help too.  I assume the interpretations are the same across all your
 machines (and the across similar sensors), so lets go with just the
 information you list in ibm_x3550_m2.txt.  If we need more later, we can
 iterate.
 
 48  | Sys Board Fault  | Chip Set | N/A  | N/A| 
 N/A   | 'OK'
 
 53  | VT Fault | Power Supply | N/A  | N/A| 
 N/A   | 'OK'
 54  | Pwr Rail A Fault | Current  | N/A  | N/A| 
 N/A   | 'OK'
 
 97  | DIMM 1 Temp  | Temperature  | N/A  | N/A| 
 N/A   | 'OK'
 
 190 | Backup Memory| Memory   | N/A  | N/A| 
 N/A   | 'OK'
 
 210 | OS RealTime Mod  | System Event | N/A  | N/A| 
 N/A   | 'OK'
 
 Al
 
 On Thu, 2011-09-08 at 05:40 -0700, Strohschein, Hendrik wrote:
  Hi Folks,
  
   
  
   
  
  I had several issues while setting up hardware monitoring with the
  IPMI Sensor Monitoring Plugin at a bunch of IBM Servers. Luckily
  Werner Fischer of thomas-krenn helped me out, so with excluding a few
  sensors everything works fine.
  
   
  
  Could you please take a look at the  attached files. I think the
  hardware
  
   
  
  ibm_x3550_m2
  
  ibm_x3650_m3
  
  ibm_x3250
  
   
  
  is worth to get into the ipmi standard. If you need further
  information please let me know.
  
   
  
  Thank you in advance!
  
   
  
   
  
  Hendrik
  
   
  
   
  
  
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] can't read tempeature info

[Al Chu]

Great!  Yes, it'll be in the next release of FreeIPMI.  I'll probably
release early next week.

Al

On Fri, 2011-08-26 at 09:53 -0700, Franco Brasolin wrote:
 Hi Albert,
 yes, it works 
 thank you very much for your help!
 
 just to know: will  be also on next freeipmi official release ?
 
 ciao
 Franco
 
 Il 25/08/2011 21:02, Albert Chu ha scritto:
  Hi Franco,
 
  I've just put up this beta.
 
  http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.6.beta1.tar.gz
 
  I added a workaround called 'ignorescanningdisabled', which you can use
  via -W ignorescanningdisabled'.
 
  So you don't have to type it on the command line all the time, it can
  also be configured in /etc/freeipmi.conf.
 
  PLMK if it works for you.
 
  Al
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Can't read CPU OEM Sensor Supermicro X8SIL-F

[Al Chu]

Hi David,

It seems to be like all the other Supermicro CPU OEM sensors, so I can
just add the interpretation support in for you.  I'll get a beta tar.gz
to you to try.

BTW,

 1143 | PS Status | Power Supply  | N/A  | N/A| N/A
| 'Presence detected' 'Unrecognized Event = 0100h' 'Unrecognized Event =
0200h' 'Unrecognized Event = 0400h' 'Unrecognized Event = 0800h'
'Unrecognized Event = 1000h' 'Unrecognized Event = 2000h' 'Unrecognized
Event = 4000h'

You can cleanup this messy output w/ the --ignore-unrecognized-events option.

(I reported this issue to Supermicro awhile back).

Al 

On Mon, 2011-07-11 at 01:45 -0700, vitamin.b wrote:
 Hello,
 
 i need some help on reading the cpu sensor from this hardware:
 Mainboard: Supermicro X8SIL-F Rev. 1.02
 CPU: Intel Xeon L3406 
 
 
 uname -a
 bmc-info
 ipmi-sensors -V
 ipmi-sensors --flush-cache
 ipmi-sensors --interpret-oem-data --output-sensor-state
 ipmi-sensors --interpret-oem-data --output-sensor-state 
 --ignore-not-available-sensors
 ipmi-sensors --interpret-oem-data --output-sensor-state -v --record-ids=71
 
 
 $ uname -a
 Linux vidar 2.6.38-bpo.2-amd64 #1 SMP Mon Jun 6 15:24:02 UTC 2011 x86_64 
 GNU/Linux
 
 
 $ bmc-info
 Device ID : 32
 Device Revision   : 1
 Device SDRs   : unsupported
 Firmware Revision : 2.50
 Device Available  : yes (normal operation)
 IPMI Version  : 2.0
 Sensor Device : supported
 SDR Repository Device : supported
 SEL Device: supported
 FRU Inventory Device  : supported
 IPMB Event Receiver   : supported
 IPMB Event Generator  : supported
 Bridge: unsupported
 Chassis Device: supported
 Manufacturer ID   : Super Micro Computer Inc. (47488)
 Product ID: 1541
 
 GUID : ----
 
 Channel Information
 
 Channel Number   : 0
 Medium Type  : IPMB (I2C)
 Protocol Type: IPMB-1.0
 Active Session Count : 0
 Session Support  : session-less
 Vendor ID: Intelligent Platform Management Interface forum (7154)
 
 Channel Number   : 1
 Medium Type  : 802.3 LAN
 Protocol Type: IPMB-1.0
 Active Session Count : 0
 Session Support  : multi-session
 Vendor ID: Intelligent Platform Management Interface forum (7154)
 
 Channel Number   : 3
 Medium Type  : Asynch. Serial/Modem (RS-232)
 Protocol Type: IPMB-1.0
 Active Session Count : 0
 Session Support  : single-session
 Vendor ID: Intelligent Platform Management Interface forum (7154)
 
 Channel Number   : 5
 Medium Type  : IPMB (I2C)
 Protocol Type: IPMB-1.0
 Active Session Count : 0
 Session Support  : session-less
 Vendor ID: Intelligent Platform Management Interface forum (7154)
 
   
 $ ipmi-sensors -V
 ipmi-sensors - 1.0.5
 Copyright (C) 2003-2010 FreeIPMI Core Team
 This program is free software; you may redistribute it under the terms of
 the GNU General Public License.  This program has absolutely no warranty.
 
 
 $ ipmi-sensors --flush-cache
 Flushing cache: /root/.freeipmi/sdr-cache/sdr-cache-vidar.localhost
 
 
 $ ipmi-sensors --interpret-oem-data --output-sensor-state 
 Caching SDR repository information: 
 /root/.freeipmi/sdr-cache/sdr-cache-vidar.localhost
 Caching SDR record 25 of 25 (current record ID 1612)
 ID   | Name  | Type  | State| Reading| Units | 
 Event
 4| System Temp   | Temperature   | Nominal  | 55.00  | C | 
 'OK'
 71   | CPU Temp  | OEM Reserved  | N/A  | N/A| N/A   | 
 'OEM Event = h'
 138  | FAN 1 | Fan   | Nominal  | 1325.00| RPM   | 
 'OK'
 205  | FAN 2 | Fan   | N/A  | N/A| RPM   | N/A
 272  | FAN 3 | Fan   | Nominal  | 1140.00| RPM   | 
 'OK'
 339  | FAN 4 | Fan   | Nominal  | 1140.00| RPM   | 
 'OK'
 406  | FAN 5 | Fan   | Nominal  | 1325.00| RPM   | 
 'OK'
 473  | CPU Vcore | Voltage   | Nominal  | 0.90   | V | 
 'OK'
 540  | +3.3VCC   | Voltage   | Nominal  | 3.26   | V | 
 'OK'
 607  | +12 V | Voltage   | Nominal  | 12.14  | V | 
 'OK'
 674  | CPU DIMM  | Voltage   | Nominal  | 1.52   | V | 
 'OK'
 741  | +5 V  | Voltage   | Nominal  | 5.09   | V | 
 'OK'
 808  | -12 V | Voltage   | Nominal  | -12.48 | V | 
 'OK'
 875  | VBAT  | Voltage   | Nominal  | 3.14   | V | 
 'OK'
 942  | +3.3VSB   | Voltage   | Nominal  | 3.25   | V | 
 'OK'
 1009 | AVCC  | Voltage   | Nominal  | 3.26   | V | 
 'OK'
 1076 | Chassis Intru | Physical Security | Nominal  | N/A| N/A   | 
 'OK'
 1143 | PS Status | Power Supply  | N/A  | N/A| N/A   | 
 'Presence detected' 

Re: [Freeipmi-devel] in need of guidance...

[Al Chu]

Hi Arnaud,

On Sat, 2011-06-25 at 15:46 -0700, Arnaud Quette wrote:
 IPMI fellows,
 
 first, congrats for the FreeIPMI project. it's a cool piece of
 software ;-)

Thanks.

 I'm currently having a look at IPMI to implement a PSU monitor driver
 for the NUT project:
 https://wiki.ubuntu.com/ServerOneiricInfraPower#NUT_PSU_.2BAC8_native_IPMI_driver
 
 I've had a look at the various IPMI implementations out there, and
 FreeIPMI seems the most suitable.
 I've then had a look at FreeIPMI docs, code, svn, examples, contrib,
 and there I got lost!
 the code is very complex and hidden in many abstraction layers. And
 docs and examples are not very helpful.
 I also don't see pkg-config supports files (.pc).
 Have I missed something? or isn't it developer friendly :(

It depends on what you're trying to develop.  A few libs, like
libipmimonitoring and libipmiconsole are very suitable for high level
views of IPMI.  It's what a number of other developers use to do IPMI
stuff for monitoring and console access.

However, most of what's in libfreeipmi is at an abstraction level where
you need to know details from the IPMI specification to know what you're
doing.

 I've got the attached output from ipmi-fru and ipmi-sensors
 I'd like to do the exact same thing (ie identify and get all PSU
 information and events), but looking at the code and docs, I still
 don't see the light.

So what I gather is that you're looking to be able to program access to
the FRU and sensors, rather than do it via scripts from the tools?

With the current library everything you need is there.  But it's not at
an abstraction level that will probably give you a very easy interface.
I can describe in more detail the steps you'd have to take if you're
interested.

Al

 Could you please provide me some help and guidance?
 
 thanks,
 Arnaud
 -- 
 Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
 Network UPS Tools (NUT) Project Leader -
 http://www.networkupstools.org/
 Debian Developer - http://www.debian.org
 Free Software Developer - http://arnaud.quette.free.fr/
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] hardcoded path to ipmi-sensors in ipmimonitoring script caused problems in Gentoo

[Al Chu]

Sorry, you need to look at ipmimonitoring.in.  When you run ./configure,
it'll replace @IPMIMONITORINGSBINDIR@ and create ipmimonitoring.

Al

On Sat, 2011-06-18 at 09:35 -0700, Werner Fischer wrote:
 Hi Al,
 
 I have extracted the freeipmi-1.0.4.tar.gz tarball and the last line of
 the file ./ipmi-sensors/src/ipmimonitoring contains:
 wfischer@werner-t410:~/freeipmi-1.0.4$ tail -1 
 ./ipmi-sensors/src/ipmimonitoring
 exec /usr/local/sbin/ipmi-sensors $options
 
 You mentioned that this should be:
 exec @IPMIMONITORINGSBINDIR@/ipmi-sensors $options
 
 Am I looking at a wrong file or is the script in the tarball maybe wrong?
 
 Best regards,
 Werner
 
 On Fri, 2011-06-10 at 08:57 -0700, Al Chu wrote:
  Hi Werner,
  
  This is normally something that is handled within the build system.  I'm
  not familiar with debian/gentoo, so I can't really comment on how the
  build systems work (perhaps Yaroslav is watching and can comment).
  
  If you look at the code, you'll see that the script line is:
  
  exec @IPMIMONITORINGSBINDIR@/ipmi-sensors $options
  
  and the appropriate path is put in via configure.
  
  Al
  
  On Fri, 2011-06-10 at 07:27 -0700, Werner Fischer wrote:
   Hi Al,
   
   our Nagios/Icinga IPMI is meanwhile available in Gentoo as an ebuild,
   just like FreeIPMI is, too:
   http://packages.gentoo.org/package/net-analyzer/nagios-check_ipmi_sensor
   http://packages.gentoo.org/package/sys-libs/freeipmi
   
   In a bug report for the plugin Rolf Eike Beer mentions that the
   hardcoded path to ipmi-sensors in the ipmimonitoring script of FreeIPMI
   1.0.4 caused troubles in Gentoo:
   Additionally the file /usr/sbin/ipmimonitoring in 1.0.4 has a
   hardcoded path to /usr/local/sbin/ipmi-sensors which is
   in /usr/sbin instead.
   See: http://bugs.gentoo.org/show_bug.cgi?id=367357#c1
   
   The ipmimonitoring script has the following last line:
   exec /usr/local/sbin/ipmi-sensors $options
   
   With the plugin I had the same issue regarding setting the location of
   ipmimonitoring. I resolved it there with the following part (but the
   plugin requires /bin/bash, I'm not sure whether this works also with
   other shells in this way...)
   if [ -x /usr/sbin/ipmimonitoring ]; then 
   IPMICOMMAND=/usr/sbin/ipmimonitoring
   elif [ -x /usr/bin/ipmimonitoring ]; then 
   IPMICOMMAND=/usr/bin/ipmimonitoring
   elif [ -x /usr/local/sbin/ipmimonitoring ]; then 
   IPMICOMMAND=/usr/local/sbin/ipmimonitoring
   fi
   
   Do you see an option how you could modify the ipmimonitoring script so
   that it also works when ipmi-sensors is not in /usr/local/sbin/ but
   in /usr/sbin instead?
   
   Best regards,
   Werner
   
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] hardcoded path to ipmi-sensors in ipmimonitoring script caused problems in Gentoo

[Al Chu]

Hi Werner,

This is normally something that is handled within the build system.  I'm
not familiar with debian/gentoo, so I can't really comment on how the
build systems work (perhaps Yaroslav is watching and can comment).

If you look at the code, you'll see that the script line is:

exec @IPMIMONITORINGSBINDIR@/ipmi-sensors $options

and the appropriate path is put in via configure.

Al

On Fri, 2011-06-10 at 07:27 -0700, Werner Fischer wrote:
 Hi Al,
 
 our Nagios/Icinga IPMI is meanwhile available in Gentoo as an ebuild,
 just like FreeIPMI is, too:
 http://packages.gentoo.org/package/net-analyzer/nagios-check_ipmi_sensor
 http://packages.gentoo.org/package/sys-libs/freeipmi
 
 In a bug report for the plugin Rolf Eike Beer mentions that the
 hardcoded path to ipmi-sensors in the ipmimonitoring script of FreeIPMI
 1.0.4 caused troubles in Gentoo:
 Additionally the file /usr/sbin/ipmimonitoring in 1.0.4 has a
 hardcoded path to /usr/local/sbin/ipmi-sensors which is
 in /usr/sbin instead.
 See: http://bugs.gentoo.org/show_bug.cgi?id=367357#c1
 
 The ipmimonitoring script has the following last line:
 exec /usr/local/sbin/ipmi-sensors $options
 
 With the plugin I had the same issue regarding setting the location of
 ipmimonitoring. I resolved it there with the following part (but the
 plugin requires /bin/bash, I'm not sure whether this works also with
 other shells in this way...)
 if [ -x /usr/sbin/ipmimonitoring ]; then 
 IPMICOMMAND=/usr/sbin/ipmimonitoring
 elif [ -x /usr/bin/ipmimonitoring ]; then 
 IPMICOMMAND=/usr/bin/ipmimonitoring
 elif [ -x /usr/local/sbin/ipmimonitoring ]; then 
 IPMICOMMAND=/usr/local/sbin/ipmimonitoring
 fi
 
 Do you see an option how you could modify the ipmimonitoring script so
 that it also works when ipmi-sensors is not in /usr/local/sbin/ but
 in /usr/sbin instead?
 
 Best regards,
 Werner
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ganglia_ipmimonitoring.pl parse issue?

[Al Chu]

I think you're right.  Normally fan sensors always give RPMs, not a
state.  With FreeIPMI 1.0.0 impending, I'll fix this in the scripts for
that.

As for the 0.8.X line.  Does the following hack fix things for your for
the time being? (P.S. I didn't test this.)

--- ganglia_ipmimonitoring.pl   (revision 7523)
+++ ganglia_ipmimonitoring.pl   (working copy)
@@ -335,7 +335,7 @@
 
 if ($group eq Temperature
 || $group eq Voltage
-|| $group eq Fan)
+|| ($group eq Fan  $unit eq RPM))
 {

Al

On Sat, 2011-01-01 at 20:06 -0800, Christopher Maestas wrote:
 Here's what I see ... I don't know what should normally show there,
 but I suspect a string is now what the script is expecting eh?
 
 
 ---
 # ipmimonitoring -h mp-cn5
 ID | Name| Type | State| Reading| Units |
 Event
 0  | UID Light   | N/A  | N/A  | N/A| N/A   |
 N/A
 1  | Sys. Health LED | N/A  | N/A  | N/A| N/A   |
 N/A
 2  | Power Supply 1  | Power Supply | Nominal  | N/A| N/A   |
 'Presence detected'
 3  | Power Supply 2  | Power Supply | Nominal  | N/A| N/A   |
 'Presence detected'
 4  | Power Supply 3  | Power Supply | N/A  | N/A| N/A   |
 N/A
 5  | Power Supply 4  | Power Supply | N/A  | N/A| N/A   |
 N/A
 6  | Power Supplies  | Power Supply | Nominal  | N/A| N/A   |
 'Fully Redundant'
 8  | Fan 1   | Fan  | Nominal  | N/A| N/A   |
 'transition to Running'
 9  | Fan 2   | Fan  | Nominal  | N/A| N/A   |
 'transition to Running'
 10 | Fan 3   | Fan  | Nominal  | N/A| N/A   |
 'transition to Running'
 11 | Fan 4   | Fan  | Nominal  | N/A| N/A   |
 'transition to Running'
 12 | Fans| Fan  | Nominal  | N/A| N/A   |
 'Fully Redundant'
 14 | Temp 1  | Temperature  | Nominal  | 11.00  | C |
 'OK'
 15 | Temp 2  | Temperature  | Nominal  | 16.00  | C |
 'OK'
 16 | Temp 3  | Temperature  | Nominal  | 20.00  | C |
 'OK'
 17 | Temp 4  | Temperature  | Nominal  | 18.00  | C |
 'OK'
 18 | Temp 5  | Temperature  | Nominal  | 17.00  | C |
 'OK'
 19 | Temp 6  | Temperature  | Nominal  | 35.00  | C |
 'OK'
 20 | Temp 7  | Temperature  | Nominal  | 16.00  | C |
 'OK'
 21 | Temp 8  | Temperature  | Nominal  | 17.00  | C |
 'OK'
 22 | Temp 9  | Temperature  | Nominal  | 17.00  | C |
 'OK'
 23 | Temp 10 | Temperature  | Nominal  | 17.00  | C |
 'OK'
 24 | Temp 11 | Temperature  | Nominal  | 16.00  | C |
 'OK'
 25 | Temp 12 | Temperature  | Nominal  | 16.00  | C |
 'OK'
 26 | Temp 13 | Temperature  | Nominal  | 15.00  | C |
 'OK'
 27 | Temp 14 | Temperature  | Nominal  | 15.00  | C |
 'OK'
 28 | Temp 15 | Temperature  | Nominal  | 18.00  | C |
 'OK'
 29 | Temp 16 | Temperature  | Nominal  | 20.00  | C |
 'OK'
 30 | Temp 17 | Temperature  | Nominal  | 18.00  | C |
 'OK'
 31 | Temp 18 | Temperature  | Nominal  | 19.00  | C |
 'OK'
 32 | Temp 19 | Temperature  | Nominal  | 17.00  | C |
 'OK'
 33 | Temp 20 | Temperature  | Nominal  | 18.00  | C |
 'OK'
 34 | Temp 21 | Temperature  | Nominal  | 18.00  | C |
 'OK'
 35 | Temp 22 | Temperature  | Nominal  | 20.00  | C |
 'OK'
 36 | Temp 23 | Temperature  | Nominal  | 24.00  | C |
 'OK'
 37 | Temp 24 | Temperature  | Nominal  | 20.00  | C |
 'OK'
 38 | Temp 25 | Temperature  | Nominal  | 28.00  | C |
 'OK'
 39 | Temp 26 | Temperature  | Nominal  | 31.00  | C |
 'OK'
 40 | Temp 27 | Temperature  | Nominal  | 39.00  | C |
 'OK'
 41 | Temp 28 | Temperature  | Nominal  | 53.00  | C |
 'OK'
 42 | Temp 29 | Temperature  | Nominal  | 41.00  | C |
 'OK'
 43 | Temp 30 | Temperature  | Nominal  | 25.00  | C |
 'OK'
 44 | Temp 31 | Temperature  | Nominal  | 27.00  | C |
 'OK'
 45 | Temp 32 | Temperature  | Nominal  | 19.00  | C |
 'OK'
 46 | Temp 33 | Temperature  | N/A  | N/A| N/A   |
 N/A
 47 | Temp 34 | Temperature  | N/A  | N/A| N/A   |
 N/A
 48 | Temp 35 | Temperature  | N/A  | N/A| N/A   |
 N/A
 49 | Temp 36 | Temperature  | N/A  | N/A| N/A   |
 N/A
 50 | Memory  | Memory   | Nominal  | N/A| N/A   |
 'Presence detected'
 51 | Power Meter | Current  | N/A  | N/A| N/A   |
 'Device Enabled'
 ---
 
 
 On Mon, Dec 27, 2010 at 11:01 AM, Al Chu ch...@llnl.gov wrote:
 Hey Chris,
 
 It appears there's some parsing bug.  What does your

Re: [Freeipmi-devel] ganglia_ipmimonitoring.pl

[Al Chu]

Hey Chris,

Patch for the most part looks fine.  With the FreeIPMI 1.0.0 beta
already out, why don't we aim this patch for the new Ganglia ipmi
sensors perl script that will be released along with it.
(ipmimonitoring has been deprecated for a new --output-event-state
option in ipmi-sensors).

Would you like to do the forward port, or should I?

Al

On Tue, 2010-12-21 at 21:35 -0800, Christopher Maestas wrote:
 Here's a stab at adding a -e flag that lets you run a perl regex
 against the hostname.  Then you can run:
 
 
 ./ganglia_ipmimonitoring.pl -e 's/^mp-//g' -h mp-cn[1-4] -D -d
 
 
 I'm sure it could be cleaned up further or restricted to only
 doing/checking for search and replace expressions.
 
 
 -cdm
 
 On Tue, Dec 21, 2010 at 2:20 PM, Al Chu ch...@llnl.gov wrote:
 Hi Chris,
 
 Hmmm.  I'm not really sure how we could/should do that.
  Perhaps some
 other option would tell the script to create/remove the prefix
 before
 passing it up to ganglia?
 
 Al
 
 
 On Tue, 2010-12-21 at 10:52 -0800, Christopher Maestas wrote:
  Any thought given to translating the hostlist from the
 management
  processor name to a real device name?  For example:
* device name is mp-cn[1-2] and hostname is cn[1-2]
 
 
  ./ganglia_ipmimonitoring.pl -D -d -h mp-cn[1-2] | sed -e
 's/mp-//g'
 
 
  but I don't think that will do what I want ...
 
 --
 Albert Chu
 ch...@llnl.gov
 Computer Scientist
 High Performance Systems Division
 Lawrence Livermore National Laboratory
 
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] Re: FreeIPMI beta w/ BMC watchdog workaround for Sun machines

[Al Chu]

Hi Frank,

On Thu, 2010-12-23 at 06:53 -0800, Frank Steiner wrote:
 Dave Love wrote
 
  says ps, where I need the -D on x4100 or x4200m2 to avoid 
  
bmc-watchdog:  Get Watchdog Timer Error: BMC Busy
  
 Just ran into this (and -D openipmi didn't work for me) and figured out
 that the /etc/init.d/lm_sensors script loads the ipmi_si and ipmi_msghandler
 modules on our Sun machines. I didn't realize figure out the problem for 
 some time because the ipmi service itself was disabled in the runlevels
 and so I didn't even think of the kernel modules :-)

 Maybe a little warning from the bmc-watchdog binary when ipmi kernel modules
 are loaded when running on a Sun machine could help others to avoid this?

I'm not really sure what kind of error message could be portable and/or
reasonable.  From the perspective of most FreeIPMI software, any
driver/mechanism to reach the BMC card is ok.  If the OpenIPMI driver is
available, it can use it.

I'm not sure why (in this case) using the OpenIPMI kernel driver didn't
work.  Did you get any other error messages?  The predominant issue that
all IPMI software should try to avoid is using different drivers (e.g.
one tool uses /dev/ipmi0 and another uses memory mapped I/O from
userspace).  That can lead to issues.

Also, just to make sure, did you use the ignorestateflag workaround
when running bmc-watchdog?

Al

 cu,
 Frank
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ganglia_ipmimonitoring.pl

[Al Chu]

Hi Chris,

Hmmm.  I'm not really sure how we could/should do that.  Perhaps some
other option would tell the script to create/remove the prefix before
passing it up to ganglia?

Al

On Tue, 2010-12-21 at 10:52 -0800, Christopher Maestas wrote:
 Any thought given to translating the hostlist from the management
 processor name to a real device name?  For example:
   * device name is mp-cn[1-2] and hostname is cn[1-2]
 
 
 ./ganglia_ipmimonitoring.pl -D -d -h mp-cn[1-2] | sed -e 's/mp-//g'
 
 
 but I don't think that will do what I want ...
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.0.0.beta0 Released

[Al Chu]

The following is the beta release for FreeIPMI 1.0.

http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.0.beta0.tar.gz

Here are the major highlights of the additions since 0.8.12.  I'd
appreciate any testing or sanity checks of portability to other OSes.
Please let me know if anyone finds anything.

Major Changes, Additions, and Features
--
o Remove ipmimonitoring tool.  Tool is now superseded by ipmi-sensors
  and the new --output-sensor-state option.
o Support --output-event-state option for ipmi-sel to support SEL event
  interpretation.
o All config-tools now support multi-channel configuration under
  verbose mode.
o Re-architect libipmimonitoring to support all defined IPMI sensor
  types, OEM bitmasks, and OEM interpretations.
o Add SEL monitoring support to libipmimonitoring.
o Support new 'interpret' sub-library in libfreeipmi.
o Support interpretation rules for sensors when no states/events occur.
o Support interpretation rules for out of spec sensor states/events.
o Support interpretation rules for OEM sensors and events.
o Move all config files to /etc/freeipmi/.  Support legacy config
  files for backwards compatibility.
o Support serial keepalive in ipmiconsole to check if serial
  connection has remained alive across system reboots.
o Create symlinks and manpage pointers for 'ipmi-power', 'ipmi-ping',
  'rmcp-ping', 'ipmi-console', and 'ipmi-detect' to give some
  additional consistency to the tool naming.
o Various documentation updates.
o Update to support DCMI 1.1.
o Update all licensing information to GPLv3.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.12 Released

[Al Chu]

http://download.gluster.com/pub/freeipmi/0.8.12/

FreeIPMI 0.8.12 - 12/06/10
--
o In bmc-config, workaround RMCP+ Privilege Level configuration
  compliance bugs on HP DL145 servers.
o In ipmi-chassis-config, after configuring boot flags, set valid bits
  appropriately.
o Fix N/A output corner case in ipmi-sel.
o Support Supermicro X8DTU-6+ motherboard OEM sensors.
o Fix FRU date/time calculation bug that did not account for leap
  years.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

[Al Chu]

Hey Peter,

On Wed, 2010-11-17 at 20:56 -0800, Peter Selby wrote:
 Hi Al,
 
 Huh, weird...
 
 Now I get this:
 
 $ ./bmc-config --commit --filename=/tmp/bmc.config
 --section=Rmcpplus_Conf_Privilege
 fiid_obj_get: 'maximum_privilege_for_cipher_suite_5': data not available
 
 I tried checking out a config, but got:
 
 $ ./bmc-config checkout
 ...
 ...
 Section Rmcpplus_Conf_Privilege
 fiid_obj_get: 'maximum_privilege_for_cipher_suite_5': data not available
 
 Don't know where that #5 came from, it was never mentioned before...

Doh!  I screwed up my previous patch. Here's the newest beta.

http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta4.tar.gz

 Sorry, this has got to be frustrating, I get the impression this BIOS
 is horribly buggy?

Most of the issues I've been dealing with in beta1-4 are actually bugs
in my workaround code.  It's just a little hard to deal with because of
a lot of subtleties in this area and your particular issue.

Thanks for taking the time to iterate.  I *hope* it can fix your
problem, but we still don't quite know.

Al

 Thanks,
 
 Peter
 
 On Wed, Nov 17, 2010 at 4:14 PM, Al Chu ch...@llnl.gov wrote:
  Hi Peter,
 
  Ok, try #4 :P
 
  http://BLOCKEDdownload.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta3.tar.gz
 
  I think it was assuming you had to input ALL cipher suite ids, instead
  of just the ones that were supported on your motherboard.  Hopefully
  it'll work, but there's still the potential there's an additional IPMI
  problem on the motherboard when we do the actual write (thus far, the
  bugs have been setting things up for the write).
 
  Al
 
  On Wed, 2010-11-17 at 15:16 -0800, Peter Selby wrote:
  Hi Al,
 
  Still getting the same problem:
 
  $ ./bmc-config --commit --filename=/tmp/bmc.config
  --section=Rmcpplus_Conf_Privilege
  ERROR: Failed to commit `Lan_Conf:MAC_Address': Read Only Field
  ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
  Field Required
  ERROR: Failed to commit
  `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0'
  ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
  Field Required
  ERROR: Failed to commit
  `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_1'
  ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
  Field Required
  ERROR: Failed to commit
  `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_2'
  ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
  Field Required
  ERROR: Failed to commit
  `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_3'
 
  The config looks like:
 
  Section Rmcpplus_Conf_Privilege
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  Maximum_Privilege_Cipher_Suite_Id_0   OEM_Proprietary
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  Maximum_Privilege_Cipher_Suite_Id_1   OEM_Proprietary
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  Maximum_Privilege_Cipher_Suite_Id_2   Administrator
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  Maximum_Privilege_Cipher_Suite_Id_3   Administrator
  EndSection
 
  On Wed, Nov 17, 2010 at 2:46 PM, Al Chu ch...@llnl.gov wrote:
   Hey Peter,
  
   I put up a new release that hopefully outputs better/right error
   messages.
  
   http://BLOCKEDdownload.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta2.tar.gz
  
   Thanks,
  
   Al
  
   On Wed, 2010-11-17 at 14:15 -0800, Al Chu wrote:
   Hey Peter,
  
   On Wed, 2010-11-17 at 14:05 -0800, Peter Selby wrote:
That works!
   
Checking out the config, I get:
   
Section Rmcpplus_Conf_Privilege
## Possible values: 
Unused/User/Operator/Administrator/OEM_Proprietary
Maximum_Privilege_Cipher_Suite_Id_0   OEM_Proprietary
## Possible values: 
Unused/User/Operator/Administrator/OEM_Proprietary
Maximum_Privilege_Cipher_Suite_Id_1   OEM_Proprietary
## Possible values: 
Unused/User/Operator/Administrator/OEM_Proprietary
## Maximum_Privilege_Cipher_Suite_Id_2
## Possible values: 
Unused/User/Operator/Administrator/OEM_Proprietary
## Maximum_Privilege_Cipher_Suite_Id_3
EndSection
  
   This is good, exactly what I hoped would happen.
  
When committing, any uncommented line gives:
   
ERROR: Failed to commit
`Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0': Field
Required
   
...Regardless of setting.  Is that an error, or is the field just 
read-only?
  
   Doh!  I need to fix the error message text, but the basic behavior is
   correct.  The other two fields:
  
   Maximum_Privilege_Cipher_Suite_Id_2
   and
   Maximum_Privilege_Cipher_Suite_Id_2
  
   need to be populated with a value (and the line

Re: [Freeipmi-devel] Set Boot Device Parameter in ipmi-chassis-config

[Al Chu]

Hey Holger,

By SVN Version, I assume you mean the head trunk, not the 0-8-0 stable
branch?

The primary differences between 0.8.10 and trunk is my call to BMC boot
flag valid bit clearing (param 3 as you describe below).  My
recollection about this section is a little hazy, but I believe you want
to call this command so that boot parameters are permanently stored
(rather than being cleared after a reboot).  Is this the side affect
you're witnessing?

Since this was a semi-big change, I decided not to backport it.
However, if you guys need it, I can go ahead and backport it into the
stable branch and release with the next version.

Al

On Wed, 2010-11-17 at 04:26 -0800, Liebig, Holger wrote:
 Hi Al,
 do you have any background info or remember what has caused the
 current change in the SVN version of ipmi-chassis-config versus the
 0.8.10 in sending the Set Boot Device Parameter? It is working fine
 with the SVN version on our system, but the older version seems to
 have some side effects.
  
 Background is: A customer is trying to temporary set the Boot Option
 for booting into PXE for installation on a System under Solaris with 
 
 ./ipmi-chassis-config  --commit -e Chassis_Boot_Flags:Boot_Device=PXE
 
 As far as I can see from the trace, the SVN version sends 
 Param 5 / Param 3 / Param 4
 
 While the slightly older version is sending
 Param 5 / Param 4
 
 In our Web Interface of the BMC we are sending (only disabling the 60 seconds 
 timer with param 3):
 Param 3 / Param 5
 
 The customer wants to perform some unattended/scripted installation,
 so we recommended freeipmi to him but he currently only has the
 official release.
 
 Thanks,
 Holger Liebig
 
 
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 http://BLOCKEDlists.gnu.org/mailman/listinfo/freeipmi-devel
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

[Al Chu]

Hey Peter,

I put up a new release that hopefully outputs better/right error
messages.

http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta2.tar.gz

Thanks,

Al

On Wed, 2010-11-17 at 14:15 -0800, Al Chu wrote:
 Hey Peter,
 
 On Wed, 2010-11-17 at 14:05 -0800, Peter Selby wrote:
  That works!
  
  Checking out the config, I get:
  
  Section Rmcpplus_Conf_Privilege
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  Maximum_Privilege_Cipher_Suite_Id_0   OEM_Proprietary
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  Maximum_Privilege_Cipher_Suite_Id_1   OEM_Proprietary
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  ## Maximum_Privilege_Cipher_Suite_Id_2
  ## Possible values: 
  Unused/User/Operator/Administrator/OEM_Proprietary
  ## Maximum_Privilege_Cipher_Suite_Id_3
  EndSection
 
 This is good, exactly what I hoped would happen.
 
  When committing, any uncommented line gives:
  
  ERROR: Failed to commit
  `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0': Field
  Required
  
  ...Regardless of setting.  Is that an error, or is the field just read-only?
 
 Doh!  I need to fix the error message text, but the basic behavior is
 correct.  The other two fields:
 
 Maximum_Privilege_Cipher_Suite_Id_2
 and
 Maximum_Privilege_Cipher_Suite_Id_2
 
 need to be populated with a value (and the line uncommented).  Hopefully
 that will be enough to get around the HP problem (if there's a further
 HP mobo problem, we'll have to deal with it when we find it).
 
 Al
 
  Thanks again!
  
  Peter
  
  On Wed, Nov 17, 2010 at 11:26 AM, Al Chu ch...@llnl.gov wrote:
   Hi Peter,
  
   http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta1.tar.gz
  
   I realized the workaround in beta0 fixed the --checkout part for this
   issue on your motherboard, but I had a bug in the --commit portion of
   the workaround.  Could you check out the above instead?  Thanks.
  
   Al
  
   On Tue, 2010-11-16 at 17:23 -0800, Al Chu wrote:
   Hi Peter,
  
   I believe I have something that should workaround your problem, can you
   try out this test tar.gz to see?  Without a motherboard to try this on,
   I don't know if it works for sure, but I'm confident it will.  The
   tar.gz is here;
  
   http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta0.tar.gz
  
   It is quite newer than what you were running before, hope that's ok.
  
   Normal ./configure ; make ; make install to install, or you can run
   bmc-config out of the local build bmc-config/src/.
  
   If it doesn't work, please send the --debug output like before.
  
   Thanks,
   Al
  
   On Mon, 2010-11-15 at 21:34 -0800, Peter Selby wrote:
Thanks!  Let me know if you need any more info...
   
On Mon, Nov 15, 2010 at 4:10 PM, Al Chu ch...@llnl.gov wrote:
 Hi Peter,

 It's as I suspected:

 =
 Get LAN Configuration Parameters Response
 =
 [   2h] = cmd[ 8b]
 [   0h] = comp_code[ 8b]
 [   1h] = present_revision[ 4b]
 [   1h] = oldest_revision_parameter[ 4b]
 [   4h] = cipher_suite_entry_count[ 4b]
 [   0h] = reserved[ 4b]

 This says there are 4 cipher suites to read.

 =
 Get LAN Configuration Parameters Response
 =
 [   2h] = cmd[ 8b]
 [   0h] = comp_code[ 8b]
 [   1h] = present_revision[ 4b]
 [   1h] = oldest_revision_parameter[ 4b]
 [   0h] = reserved[ 8b]
 [   0h] = cipher_suite_id_entry_A[ 8b]
 [   1h] = cipher_suite_id_entry_B[ 8b]
 [   2h] = cipher_suite_id_entry_C[ 8b]
 [   3h] = cipher_suite_id_entry_D[ 8b]

 This shows which ones are supported, and it properly shows 4 of them.

 =
 Get LAN Configuration Parameters Response
 =
 [   2h] = cmd[ 8b]
 [   0h] = comp_code[ 8b]
 [   1h] = present_revision[ 4b]
 [   1h] = oldest_revision_parameter[ 4b]
 [  55h] = reserved[ 8b]
 [   5h] = maximum_privilege_for_cipher_suite_1[ 4b]
 [   5h] = maximum_privilege_for_cipher_suite_2[ 4b]
 fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

 This is supposed to tell us what the maximum privilege level for 
 those 4
 cipher suites are, but the command only returns 2.  Uh oh

Re: [Freeipmi-devel] fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

[Al Chu]

Hi Peter,

Ok, try #4 :P

http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta3.tar.gz

I think it was assuming you had to input ALL cipher suite ids, instead
of just the ones that were supported on your motherboard.  Hopefully
it'll work, but there's still the potential there's an additional IPMI
problem on the motherboard when we do the actual write (thus far, the
bugs have been setting things up for the write).

Al

On Wed, 2010-11-17 at 15:16 -0800, Peter Selby wrote:
 Hi Al,
 
 Still getting the same problem:
 
 $ ./bmc-config --commit --filename=/tmp/bmc.config
 --section=Rmcpplus_Conf_Privilege
 ERROR: Failed to commit `Lan_Conf:MAC_Address': Read Only Field
 ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
 Field Required
 ERROR: Failed to commit
 `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0'
 ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
 Field Required
 ERROR: Failed to commit
 `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_1'
 ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
 Field Required
 ERROR: Failed to commit
 `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_2'
 ERROR: 'Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_4'
 Field Required
 ERROR: Failed to commit
 `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_3'
 
 The config looks like:
 
 Section Rmcpplus_Conf_Privilege
 ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary
 Maximum_Privilege_Cipher_Suite_Id_0   OEM_Proprietary
 ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary
 Maximum_Privilege_Cipher_Suite_Id_1   OEM_Proprietary
 ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary
 Maximum_Privilege_Cipher_Suite_Id_2   Administrator
 ## Possible values: Unused/User/Operator/Administrator/OEM_Proprietary
 Maximum_Privilege_Cipher_Suite_Id_3   Administrator
 EndSection
 
 On Wed, Nov 17, 2010 at 2:46 PM, Al Chu ch...@llnl.gov wrote:
  Hey Peter,
 
  I put up a new release that hopefully outputs better/right error
  messages.
 
  http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta2.tar.gz
 
  Thanks,
 
  Al
 
  On Wed, 2010-11-17 at 14:15 -0800, Al Chu wrote:
  Hey Peter,
 
  On Wed, 2010-11-17 at 14:05 -0800, Peter Selby wrote:
   That works!
  
   Checking out the config, I get:
  
   Section Rmcpplus_Conf_Privilege
   ## Possible values: 
   Unused/User/Operator/Administrator/OEM_Proprietary
   Maximum_Privilege_Cipher_Suite_Id_0   OEM_Proprietary
   ## Possible values: 
   Unused/User/Operator/Administrator/OEM_Proprietary
   Maximum_Privilege_Cipher_Suite_Id_1   OEM_Proprietary
   ## Possible values: 
   Unused/User/Operator/Administrator/OEM_Proprietary
   ## Maximum_Privilege_Cipher_Suite_Id_2
   ## Possible values: 
   Unused/User/Operator/Administrator/OEM_Proprietary
   ## Maximum_Privilege_Cipher_Suite_Id_3
   EndSection
 
  This is good, exactly what I hoped would happen.
 
   When committing, any uncommented line gives:
  
   ERROR: Failed to commit
   `Rmcpplus_Conf_Privilege:Maximum_Privilege_Cipher_Suite_Id_0': Field
   Required
  
   ...Regardless of setting.  Is that an error, or is the field just 
   read-only?
 
  Doh!  I need to fix the error message text, but the basic behavior is
  correct.  The other two fields:
 
  Maximum_Privilege_Cipher_Suite_Id_2
  and
  Maximum_Privilege_Cipher_Suite_Id_2
 
  need to be populated with a value (and the line uncommented).  Hopefully
  that will be enough to get around the HP problem (if there's a further
  HP mobo problem, we'll have to deal with it when we find it).
 
  Al
 
   Thanks again!
  
   Peter
  
   On Wed, Nov 17, 2010 at 11:26 AM, Al Chu ch...@llnl.gov wrote:
Hi Peter,
   
http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta1.tar.gz
   
I realized the workaround in beta0 fixed the --checkout part for this
issue on your motherboard, but I had a bug in the --commit portion of
the workaround.  Could you check out the above instead?  Thanks.
   
Al
   
On Tue, 2010-11-16 at 17:23 -0800, Al Chu wrote:
Hi Peter,
   
I believe I have something that should workaround your problem, can 
you
try out this test tar.gz to see?  Without a motherboard to try this 
on,
I don't know if it works for sure, but I'm confident it will.  The
tar.gz is here;
   
http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta0.tar.gz
   
It is quite newer than what you were running before, hope that's ok.
   
Normal ./configure ; make ; make install to install, or you can run
bmc-config out of the local build bmc-config/src/.
   
If it doesn't work, please send the --debug output like before

Re: [Freeipmi-devel] fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

[Al Chu]

Hey Peter,

Hopefully I can get a patch out to you later this afternoon.  Just as a
follow up (this is more for IPMI developers on this mailing list).

 =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [  55h] = reserved[ 8b]
  [   5h] = maximum_privilege_for_cipher_suite_1[ 4b]
  [   5h] = maximum_privilege_for_cipher_suite_2[ 4b]
  fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set
 
  This is supposed to tell us what the maximum privilege level for those 4
  cipher suites are, but the command only returns 2.  Uh oh ...

What I spoke of above was incorrect.  According to the IPMI spec, the
motherboard should always return all 16 entries, not just the number it
supports.  So the bug is slightly different than what I said before.

Al


On Mon, 2010-11-15 at 21:34 -0800, Peter Selby wrote:
 Thanks!  Let me know if you need any more info...
 
 On Mon, Nov 15, 2010 at 4:10 PM, Al Chu ch...@llnl.gov wrote:
  Hi Peter,
 
  It's as I suspected:
 
  =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [   4h] = cipher_suite_entry_count[ 4b]
  [   0h] = reserved[ 4b]
 
  This says there are 4 cipher suites to read.
 
  =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [   0h] = reserved[ 8b]
  [   0h] = cipher_suite_id_entry_A[ 8b]
  [   1h] = cipher_suite_id_entry_B[ 8b]
  [   2h] = cipher_suite_id_entry_C[ 8b]
  [   3h] = cipher_suite_id_entry_D[ 8b]
 
  This shows which ones are supported, and it properly shows 4 of them.
 
  =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [  55h] = reserved[ 8b]
  [   5h] = maximum_privilege_for_cipher_suite_1[ 4b]
  [   5h] = maximum_privilege_for_cipher_suite_2[ 4b]
  fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set
 
  This is supposed to tell us what the maximum privilege level for those 4
  cipher suites are, but the command only returns 2.  Uh oh ...
 
  I'll need to think about how to work around this.  Maybe if this
  happens, I could have bmc-config output Unknown or something, and it's
  up to the user to force the configuration of something.  Let me think
  about this and get back to you with a patch ...
 
  Al
 
  On Mon, 2010-11-15 at 16:00 -0800, Peter Selby wrote:
  Thanks for the quick response!
 
  ipmiping doesn't work, either from the host or from a neighbour.  I'm
  pretty sure it's not a network issue, but I'll double-check, and try a
  hard-reset.
 
  Here's the output of debug:
 
  bmc-config --checkout --section=Rmcpplus_Conf_Privilege --debug
  =
  Get Device ID Request
  =
  [   1h] = cmd[ 8b]
  =
  Get Device ID Response
  =
  [   1h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   0h] = device_id[ 8b]
  [   3h] = device_revision.revision[ 4b]
  [   0h] = device_revision.reserved1[ 3b]
  [   0h] = device_revision.sdr_support[ 1b]
  [   1h] = firmware_revision1.major_revision[ 7b]
  [   0h] = firmware_revision1.device_available[ 1b]
  [  22h] = firmware_revision2.minor_revision[ 8b]
  [   2h] = ipmi_version_major[ 4b]
  [   0h] = ipmi_version_minor[ 4b]
  [   1h] = additional_device_support.sensor_device[ 1b]
  [   1h] = additional_device_support.sdr_repository_device[ 1b]
  [   1h] = additional_device_support.sel_device[ 1b]
  [   1h] = additional_device_support.fru_inventory_device[ 1b]
  [   1h] = additional_device_support.ipmb_event_receiver[ 1b]
  [   0h

Re: [Freeipmi-devel] fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

[Al Chu]

Hi Peter,

I believe I have something that should workaround your problem, can you
try out this test tar.gz to see?  Without a motherboard to try this on,
I don't know if it works for sure, but I'm confident it will.  The
tar.gz is here;

http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.12.beta0.tar.gz

It is quite newer than what you were running before, hope that's ok.  

Normal ./configure ; make ; make install to install, or you can run
bmc-config out of the local build bmc-config/src/.

If it doesn't work, please send the --debug output like before.

Thanks,
Al

On Mon, 2010-11-15 at 21:34 -0800, Peter Selby wrote:
 Thanks!  Let me know if you need any more info...
 
 On Mon, Nov 15, 2010 at 4:10 PM, Al Chu ch...@llnl.gov wrote:
  Hi Peter,
 
  It's as I suspected:
 
  =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [   4h] = cipher_suite_entry_count[ 4b]
  [   0h] = reserved[ 4b]
 
  This says there are 4 cipher suites to read.
 
  =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [   0h] = reserved[ 8b]
  [   0h] = cipher_suite_id_entry_A[ 8b]
  [   1h] = cipher_suite_id_entry_B[ 8b]
  [   2h] = cipher_suite_id_entry_C[ 8b]
  [   3h] = cipher_suite_id_entry_D[ 8b]
 
  This shows which ones are supported, and it properly shows 4 of them.
 
  =
  Get LAN Configuration Parameters Response
  =
  [   2h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   1h] = present_revision[ 4b]
  [   1h] = oldest_revision_parameter[ 4b]
  [  55h] = reserved[ 8b]
  [   5h] = maximum_privilege_for_cipher_suite_1[ 4b]
  [   5h] = maximum_privilege_for_cipher_suite_2[ 4b]
  fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set
 
  This is supposed to tell us what the maximum privilege level for those 4
  cipher suites are, but the command only returns 2.  Uh oh ...
 
  I'll need to think about how to work around this.  Maybe if this
  happens, I could have bmc-config output Unknown or something, and it's
  up to the user to force the configuration of something.  Let me think
  about this and get back to you with a patch ...
 
  Al
 
  On Mon, 2010-11-15 at 16:00 -0800, Peter Selby wrote:
  Thanks for the quick response!
 
  ipmiping doesn't work, either from the host or from a neighbour.  I'm
  pretty sure it's not a network issue, but I'll double-check, and try a
  hard-reset.
 
  Here's the output of debug:
 
  bmc-config --checkout --section=Rmcpplus_Conf_Privilege --debug
  =
  Get Device ID Request
  =
  [   1h] = cmd[ 8b]
  =
  Get Device ID Response
  =
  [   1h] = cmd[ 8b]
  [   0h] = comp_code[ 8b]
  [   0h] = device_id[ 8b]
  [   3h] = device_revision.revision[ 4b]
  [   0h] = device_revision.reserved1[ 3b]
  [   0h] = device_revision.sdr_support[ 1b]
  [   1h] = firmware_revision1.major_revision[ 7b]
  [   0h] = firmware_revision1.device_available[ 1b]
  [  22h] = firmware_revision2.minor_revision[ 8b]
  [   2h] = ipmi_version_major[ 4b]
  [   0h] = ipmi_version_minor[ 4b]
  [   1h] = additional_device_support.sensor_device[ 1b]
  [   1h] = additional_device_support.sdr_repository_device[ 1b]
  [   1h] = additional_device_support.sel_device[ 1b]
  [   1h] = additional_device_support.fru_inventory_device[ 1b]
  [   1h] = additional_device_support.ipmb_event_receiver[ 1b]
  [   0h] = additional_device_support.ipmb_event_generator[ 1b]
  [   1h] = additional_device_support.bridge[ 1b]
  [   1h] = additional_device_support.chassis_device[ 1b]
  [ F85h] = manufacturer_id.id[20b]
  [   0h] = manufacturer_id.reserved1[ 4b]
  [   0h] = product_id[16b]
  =
  Get Channel Info Command Request

Re: [Freeipmi-devel] fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set

[Al Chu]

 Configuration Parameters Response
 =
 [   2h] = cmd[ 8b]
 [   0h] = comp_code[ 8b]
 [   1h] = present_revision[ 4b]
 [   1h] = oldest_revision_parameter[ 4b]
 [   0h] = reserved[ 8b]
 [   0h] = cipher_suite_id_entry_A[ 8b]
 [   1h] = cipher_suite_id_entry_B[ 8b]
 [   2h] = cipher_suite_id_entry_C[ 8b]
 [   3h] = cipher_suite_id_entry_D[ 8b]
 =
 Get LAN Configuration Parameters Request
 =
 [   2h] = cmd[ 8b]
 [   2h] = channel_number[ 4b]
 [   0h] = reserved1[ 3b]
 [   0h] = get_parameter[ 1b]
 [  18h] = parameter_selector[ 8b]
 [   0h] = set_selector[ 8b]
 [   0h] = block_selector[ 8b]
 =
 Get LAN Configuration Parameters Response
 =
 [   2h] = cmd[ 8b]
 [   0h] = comp_code[ 8b]
 [   1h] = present_revision[ 4b]
 [   1h] = oldest_revision_parameter[ 4b]
 [  55h] = reserved[ 8b]
 [   5h] = maximum_privilege_for_cipher_suite_1[ 4b]
 [   5h] = maximum_privilege_for_cipher_suite_2[ 4b]
 fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set
 
 On Mon, Nov 15, 2010 at 3:55 PM, Al Chu ch...@llnl.gov wrote:
  Hi Peter,
 
  Assuming you're using a recent version of FreeIPMI, there's probably
  some IPMI non-compliance going on on your motherboard.  The short guess
  is that the motherboard isn't properly reporting things to bmc-config
  correctly, and bmc-config gets confused and gives up.  There's been a
  few IPMI issues for the HP DL145 already reported to me. Lets see if we
  can figure out what's going on.  Can you send me the --debug output.
  Since the problem appears just in that section, how about running this
  to shorten the output
 
  bmc-config --checkout --section=Rmcpplus_Conf_Privilege --debug
 
  Any idea what could be wrong, or how to fix it?  And could this be the
  reason the network won't come up?
 
  Although it's always possible, it's unlikely this is the cause of IPMI
  over LAN not working.  Can you get an ipmiping (/usr/sbin/ipmiping) to
  work?  If yes that would point to it being an authentication problem
  (e.g. username/password/privilege, etc.), if no, possibly a more basic
  networking issue (subnetting, routing, etc.).
 
  I haven't played with this motherboard specifically, but a few recent
  ones I've encountered require you to hard-reset (e.g. power button push)
  the motherboard for configuration changes to stick.  It certainly
  can't hurt to try.
 
  Al
 
  On Mon, 2010-11-15 at 15:29 -0800, Peter Selby wrote:
  Hi guys,
 
  I'm trying to configure the BMC on an HP ProLiant DL145 G2 using
  bmc-config.  IPMI over LAN is not working; it should have a fixed IP,
  but it won't respond to anything.
 
  When I try to dump the BMC config, I get:
 
  $ bmc-config --checkout
  ...
  Section Rmcpplus_Conf_Privilege
  fiid_obj_get: maximum_privilege_for_cipher_suite_3: no data set
  $
 
  Everything prior to that dumps okay.  Adding the section (and
  subsequent SOL_Conf section) manually, I get two possible results:
 
   * Empty Rmcpplus_Conf_Privilege:  Config commits successfully, but a
  checkout results in the same problem
   * Rmcpplus_Conf_Privilege filled in based on the bmc-config.conf
  manpage (with Maximum_Privilege_Cipher_Suite_Id_0-through-4 or 12):  I
  get the same error, fiid_obj_get:
  maximum_privilege_for_cipher_suite_3: no data set
 
  Any idea what could be wrong, or how to fix it?  And could this be the
  reason the network won't come up?
 
  Thanks,
 
  Peter
 
  ___
  Freeipmi-devel mailing list
  Freeipmi-devel@gnu.org
  http://BLOCKEDBLOCKEDlists.gnu.org/mailman/listinfo/freeipmi-devel
 
  --
  Albert Chu
  ch...@llnl.gov
  Computer Scientist
  High Performance Systems Division
  Lawrence Livermore National Laboratory
 
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.11 Released

[Al Chu]

Thanks to Holger Liebig, FreeIPMI now has support for all Fujitsu iRMC
S1 and S2 systems.

http://download.gluster.com/pub/freeipmi/0.8.11/

FreeIPMI 0.8.11 - 10/28/10
--
o Support Fujitsu iRMC S1 and iRMC S2 OEM extensions in ipmi-sensors
  and ipmi-sel.
o Support --output-oem-event-string in ipmi-sel.
o Other minor documentation/bug fixes.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ipmi support with HP iLO2 servers initial success!

[Al Chu]

Hi Chris,

On Sun, 2010-08-29 at 20:12 -0700, Christopher Maestas wrote:
 I guess another question I would ask, is when will ipmi 1.5 be
 deprecated and the default be 2.0?  I was just curious when defaults
 should move away.

The short answer is not anytime soon.  The IPMI 2.0 spec states all IPMI
2.0 systems shall support IPMI 1.5.  Given a number of older systems
support IPMI 1.5 but not IPMI 2.0, it makes sense to keep the default
IPMI 1.5.

I believe ipmitool and ipmiutil have this policy as well.

Al

 
 This server is a proliant dl385g5 server (amd barcelona quad core).  I
 have also tested on a bl460g6 (proliant blade Intel 6 core).
 
 On Wed, Aug 25, 2010 at 11:07 AM, Albert Chu ch...@llnl.gov wrote:
 Hey Chris,
 
 (Moving this to freeipmi-devel, since this is more of a devel
 discussion)
 
  I'm sorry I should have tagged that first case of using
 ipmipower as
  an error.
 
 
 Does HP believe this to be a bug in their firmware?  Many of
 the tests
 in the freeipmi-testing document use IPMI 1.5 specifically
 (instead of
 IPMI 2.0), so we'll want to get this bug fixed so you can pass
 those
 tests too.
 
 Also, as an FYI, what motherboard are you testing on?  So that
 I can
 document this stuff.
 
 Al
 
 
 On Tue, 2010-08-24 at 19:38 -0700, Christopher Maestas wrote:
  Al,
 
 
  I'm sorry I should have tagged that first case of using
 ipmipower as
  an error.  Once I added -D LAN_2_0  things worked great.
  I think I
  also figured out the freeipmi.conf parameter (driver-type
 LAN_2_0) to
  change to make it work by default and still talk to lo100
 and iLO
  devices without any issue at first glance
 
 
  Things are running fine now.  I will continue to do some
 more testing
  tomorrow with SOL, sensor gatherings.  In addition I will
 try and
  report back on conman/powerman using their ipmi drivers work
 against
  the iLO server as well.
 
 
  Finally I will try and take a look at some tests specified
 here:
 
 
 
 http://**www.**gnu.org/software/freeipmi/freeipmi-testing.txt
 
 
  and report back.
 
  -cdm
 
 
  On Tue, Aug 24, 2010 at 5:11 PM, Albert Chu ch...@llnl.gov
 wrote:
  Hi Chris,
 
   For freeipmi (ipmipower) I found the following
 combination
  worked:
   ---
   # ipmipower -h cut0iogw1-ilo -s
   cut0iogw1-ilo: authentication type unavailable for
 attempted
  privilege level
 
 
  This isn't good.  It suggests that the HP firmware
 might be
  returning
  bad/poor information in the Get Authentication
 Capabilities
  phase of
  IPMI.  Does ipmipower work if you also specify the
 authcap
  workaround?
  (-W authcap).
 
  If it does work, then there is a bug.  Perhaps you
 can send me
  a --debug
  output and we can take a look to figure out what the
 bug is.
 
  Al
 
 
  On Tue, 2010-08-24 at 15:29 -0700, Christopher
 Maestas wrote:
   Hello,
  
   With the recent update of the 2.00 iLO2 firmware,
 we can now
  support:
  
  
  - IPMI over LAN functionality. The IPMI 2.0
 RMCP+ (or
  Linux ipmitool
  lanplus) protocol is supported with this
 release.
  - IPMI Serial Over LAN (SOL)
  - Data Center Manageability Interface (DCMI)
 v1.0
  specification
  - Enhanced the in band Intelligent Platform
 Management
  Interface (IPMI)
  to comply with the IPMI specification version
 2.0
  
   I've been able to use ipmitool to test this
 successfully
  (power, SOL and
   sensor gathering).  Here's what I do with
 ipmitool:
   ---
   # rpm -q ipmitool
   ipmitool-1.8.11-1
   # ipmitool -I lanplus -H cut0iogw1-ilo -U USER -P
 PASS power
  status
   Chassis Power is off
   # 

[Freeipmi-devel] Re: Patch for Fujitsu OEM Sensor Types and SEL decoding

[Al Chu]

Hey Holger,

Thanks for the patch.  Just skimming it casually, it looks good.  1 or 2
nits here and there and I'm sure I'll notice 1 or 2 things on closer
inspection.  On this particular comment:

+/*
+ * HLiebig: TODO:
+ * This should take a sensor_type  event_reading_code combination
+ * It is currently called for sensor specific (0x6F) only.
+ */
 int
 ipmi_get_oem_sensor_type_message (uint32_t manufacturer_id,
   uint16_t product_id,

I think I know the problem you're describing.  Up until now, all OEM
messages were generic (e.g. event reading type code = a string
mapping) or specific (e.g. event reading type code == 0x6F 
sensor_type is OEM).  So it was just like the IPMI spec.

However, I just hit an intel motherboard where every OEM event reading
type code and sensor type together match some specific string mapping.
So I created a new ipmi_get_oem_specific_message() (that's the current
name atleast) where you pass in an event-reading-type-code and
sensor-type. Is this the type of function you needed?  I can't quite
tell in the code, b/c you may have programmed around the lack of that
function.

If you do need that function, how about I finish my intel motherboard
patch and then we can iterate a bit.

Al

On Fri, 2010-08-27 at 04:35 -0700, Liebig, Holger wrote:
 Hi all,
 The attached patch against freeipmi-0.8.9 adds Fujitsu iRMC S1 / iRMC S2 OEM 
 specific Sensor type decoding to ipmi-sensors and integrates the Fujitsu OEM 
 command 'Get SEL Entry Long Text' into ipmi-sel. The use of this OEM IPMI 
 command has been reviewed and slightly adapted to older iRMC S1 systems in 
 ipmi-oem (partial read and smaller text). The OEM decoding is activated with 
 --interpret-oem-data. There is still room for improvement, but it's a 
 starting point.
 
 Some notes regarding ipmi-sel:
 The OEM command currently hooks into the OEM Record and event (%e) decoding 
 only. If the command is successful completed, further event decoding should 
 not really be required, but is currently executed by the generic decoding 
 routines from freeipmi. As a result, some information might be redundant in 
 the final output for threshold based sensors (e.g trigger).
 
 Reading of the SEL normally does not require any elevated privilege, but the 
 used OEM IPMI command requires Admin privilege, so a hint is added to the 
 output. Dependend from the command line arguments you will get the following 
 outputs:
 
 No additional arguments:
 20   | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers 
 (2880h) | OEM defined = 10h 02h C0h A8h 33h 6Ah
 
 --interpret-oem-data
 20   | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers 
 (2880h) | (admin privilege required for full OEM decoding) OEM defined = 10h 
 02h C0h A8h 33h 6Ah  
 
 --interpret-oem-data -l admin
 20   | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers 
 (2880h) | INFORMATIONAL: iRMC Browser user 'admin' AVR Session started from 
 192.168.51.106
 
 
 And for ipmi-sensors:
 No additional arguments
 2000 | DIMM-1A  | OEM Reserved| N/A| N/A   | 
 'Unrecognized State'
 
 --interpret-oem-data
 2000 | DIMM-1A  | OEM Memory Status   | N/A| N/A   | 'OK'
 
 Holger
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

RE: [Freeipmi-devel] Patch for SHA256 Support

[Al Chu]

Hey Holger,

On Thu, 2010-07-29 at 23:25 -0700, Liebig, Holger wrote:
  
  Hi Holger,
  
  Thanks for the patch.  This was on my todo, but w/o a motherboard to
  test on, I just let it linger.  
 
 Freeipmi was a good counterpart for testing the BMC implementation, if
 only the turnaround times for a make cycle would be shorter ;)

LOL.  Yeah ... the build time has definitely grown in length :P

  I think you forgot to add the
  appropriate permutation of cipher suite/SHA256 into
  libfreeipmi/src/debug/ and the manpages in common/man/, but no worries,
  I can add that myself.
  
  Only one question, are cipher suites 15-17 defined in the upcoming DCMI
  1.1?  ASAIK it hasn't been released publicly.  I have a tiny concern
  about committing something that is not yet finalized.  Or is DCMI 1.1
  finalized and going to be released publicly soon??
 
 As far as I know, it is supposed to be published end of this month if
 there are no major objections from others. There is no need to commit
 the patch before, I just wanted to let you know that most of the work
 is done and if there is any other feedback it's more than welcome.

Ok.  I'll just hold off for the time being until it's published.  That
way it's sort of official.

 Only Cipher Suite 17 in the mentioned combination (3/4/1) is mentioned
 in the latest review copy of DCMI 1.1, that's why I skipped the other
 combinations. There seem to be (strong) requests from DCMI customers
 to add a stronger authentication algorithm than HMAC_SHA1, who knows
 why. 
 
 Too bad Intel forgot to add the Cipher Suite Numbers into the IPMI 2.0
 errata 4. 

That is interesting.  I just assumed there would be a cipher suite 15
and 16.  Given the length of time between erratas, it may take time to
find out.

Thanks,
Al

 Holger
 
  On Thu, 2010-07-29 at 06:07 -0700, Liebig, Holger wrote:
   Hi all,
   please find attached the required modification for SHA256 and Cipher
   Suite 17 support in freeipmi. SHA256 has been added in IPMI 2.0 Errata
   4 and is also one of the recommended Cipher Suites of the upcoming
   DCMI 1.1 Specification (where the Cipher Suite number is taken from).
   The modifications itself are straight forward, I just had to find all
   the places.
  
   Comments or feedback is more than welcome, especially if it works with
   other vendor implementations.
  
   Thanks,
   Holger
  
  
  
  
  
  --
  Albert Chu
  ch...@llnl.gov
  Computer Scientist
  High Performance Systems Division
  Lawrence Livermore National Laboratory
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] Re: FreeIPMI beta w/ BMC watchdog workaround for Sun machines

[Al Chu]

 says ps, where I need the -D on x4100 or x4200m2 to avoid 
 
   bmc-watchdog:  Get Watchdog Timer Error: BMC Busy

Yeah, I'm certainly unsure of that one.  Have you tried running w/o the
IPMI kernel driver?  I'm wondering if they don't together for you (don't
work together for me on some mobos there).

Al

On Thu, 2010-06-17 at 05:30 -0700, Dave Love wrote:
 Al Chu ch...@llnl.gov writes:
 
  (Naturally, I added confirmed to work around based on the assumption
  you guys can confirm it for me :-)
 
 I can't confirm it on either x4100 -- not x4100m2 -- (RedHat 5) or x4500
 (Solaris).  In each case, the daemon reports:
 
   timer stopped by another process
   stopping bmc-watchdog daemon
 
 Under Solaris, SMF restarts the daemon anyway, so it kind-of works, but
 not under RedHat.
 
 I'm running it as
 
   /usr/sbin/bmc-watchdog -d -u 4 -p 0 -a 1 -F -P -L -S -O -i 900 -e 60 -D 
 openipmi -W ignorestateflag
 
 says ps, where I need the -D on x4100 or x4200m2 to avoid 
 
   bmc-watchdog:  Get Watchdog Timer Error: BMC Busy
 
 Ii think I have the latest firmware in each case -- some version of
 2.0.2.5.
 
 I wonder what's different between me and Frank.  I don't have time to
 investigate immediately, but I'll try to later.
 
 By the way, I know I'm running the right version as it accepts
 ignorestateflag.  However, bmc-watchdog doesn't accept --version, though
 it's in the --help output.
 
 By the way 2, I noticed that it's still using GPLv2, not v3.  Is that an
 oversight, or because the copyrights don't allow it?
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] Re: FreeIPMI beta w/ BMC watchdog workaround for Sun machines

[Al Chu]

Hey Dave,

Doh!  The --version bug was due to me not understanding a subtlety in
the argp library.  Thanks for the catch.  I've put up a new QA release
with a fix in it.

http://ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.8.beta0.tar.gz

Hmm.  I don't know much about the openipmi kernel driver, but I know it
can have it's own bmc-watchdog running.  Are you sure it's not running
it's own watchdog out of the kernel?

I do have one other guess as to how you're seeing timer stopped by
another process.  It's possible there is an early race, where the timer
has not yet quite started.  In bmc-watchdog/src/bmc-watchdog.c, perhaps
you can try this tiny test.

--- bmc-watchdog.c  16 Jun 2010 17:52:38 -  1.131
+++ bmc-watchdog.c  17 Jun 2010 23:18:57 -
@@ -1920,6 +1920,8 @@ _daemon_cmd (void)
 reset_period  (retry_wait_time * retry_attempt))
 retry_attempt = reset_period/retry_wait_time;
 
+  sleep (5);
+
   while (shutdown_flag)
 {
   struct timeval start_tv, end_tv;

 By the way 2, I noticed that it's still using GPLv2, not v3.  Is that 
 an oversight, or because the copyrights don't allow it?

Nope, it'll be GPLv3 when I release the next major release of FreeIPMI.
Was just too lazy to back update all the headers and documents in the
current release line :P

Al

On Thu, 2010-06-17 at 05:30 -0700, Dave Love wrote:
 Al Chu ch...@llnl.gov writes:
 
  (Naturally, I added confirmed to work around based on the assumption
  you guys can confirm it for me :-)
 
 I can't confirm it on either x4100 -- not x4100m2 -- (RedHat 5) or x4500
 (Solaris).  In each case, the daemon reports:
 
   timer stopped by another process
   stopping bmc-watchdog daemon
 
 Under Solaris, SMF restarts the daemon anyway, so it kind-of works, but
 not under RedHat.
 
 I'm running it as
 
   /usr/sbin/bmc-watchdog -d -u 4 -p 0 -a 1 -F -P -L -S -O -i 900 -e 60 -D 
 openipmi -W ignorestateflag
 
 says ps, where I need the -D on x4100 or x4200m2 to avoid 
 
   bmc-watchdog:  Get Watchdog Timer Error: BMC Busy
 
 Ii think I have the latest firmware in each case -- some version of
 2.0.2.5.
 
 I wonder what's different between me and Frank.  I don't have time to
 investigate immediately, but I'll try to later.
 
 By the way, I know I'm running the right version as it accepts
 ignorestateflag.  However, bmc-watchdog doesn't accept --version, though
 it's in the --help output.
 
 By the way 2, I noticed that it's still using GPLv2, not v3.  Is that an
 oversight, or because the copyrights don't allow it?
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] Re: FreeIPMI beta w/ BMC watchdog workaround for Sun machines

[Al Chu]

Hey Frank,

Great.  I'll make sure this'll get into the FreeIPMI 0.8.7 release.

Al

On Wed, 2010-06-16 at 01:32 -0700, Frank Steiner wrote:
 Al Chu wrote
 
  Hi Frank, Dave,
  
  I finally got around to trying to develop that workaround into BMC
  watchdog to get around the issue on the Sun motherboards you have.  Do
  you think you guys could try it out and make sure it works for you?
  
  http://*ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.7.ignorestateflag.tar.gz
  
  You have to add the '-W ignorestateflag' option to turn on the
  workaround.  You'll have to edit /etc/sysconfig/bmc-watchdog to add the
  workaround for Linux.  Not sure how you would do this on Solaris.
 
 Seems to work fine on my X4100 M2 machines :-) Starts up, reports status
 correctly, resets etc. 
 
 Btw., Sun has confirmed it's a bug that the state flag does not change.
 The 2nd level support has requested a firmware update for the ILOM, but it's
 not yet clear if it will be granted.
 
 Thanks a lot for the patch, now I can safely deploy the watchdog on all
 our servers :-)
 
 cu,
 Frank
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.7 Released

[Al Chu]

http://ftp.gluster.com/pub/freeipmi/0.8.7/

FreeIPMI 0.8.7 - 06/17/10
-
o Support Supermicro X8DTG OEM sensors.
o Support Supermicro X8DTG workarounds with 'integritycheckvalue'
workaround flag.
o Document workarounds for Intel S5500WBV/Penguin Relion 700
motherboard.
o Map IPMI 2.0 invalid role error code to privilege level cannot be
  obtained for better usability.
o Fix bmc-config Security Keys commit by making some required fields
optional.
o Fix bmc-watchdog init script return codes on Suse.
o Support 'ignorestateflag' workaround in bmc-watchdog.
o Fix ipmi-sensors corner case for sensors with percentage units.
o Support 'slowcommit' workaround for config tools to work around slower
BMCs.
o Update documentation w/ Supermicro X8DTG issues.
o Update documentation w/ inband troubleshooting.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] watchdog problems on Sun X4100M2

[Al Chu]

On Tue, 2010-06-01 at 13:12 -0700, Frank Steiner wrote:
 Al Chu wrote
 
  Hi Frank,
  
  This sounded familiar.  There is this thread for not too long ago.
  
  http://*lists.gnu.org/archive/html/freeipmi-users/2010-05/msg00017.html
 
 Doh, I searched for the wrong keywords in the archive :-)

It happens to all of us :-)

 Yes, that's the same bug and if I get Dave's mail right he is seeing
 the bug on the X4500 and X4200. If it's a X4200M2, it has the same
 firmware as the X4100M2, and for this one the bug is not fixed in
 the recent update.
 
  Same applies.  I can give a patch a shot, and you can try it out??  It
 
 Of course I could, but I agree with you that it wouldn't be a good thing.

Ok, when I get a chance, I'll try to come up with something.

 I can work without the daemon of course and use cron and a endless 
 while-loop to reset the timer, and I guess that's better than patching
 around such an obvious bug. 
 I succeeded in triggering the bug without the bmc-watchdog by just 
 accessing the watchdog remotely via ipmi machine ...  mc watchdog 
 get/reset. 
 Thus, Sun has no chance argueing it is some Linux problem with freeipmi etc.
 And since we still have support for the X4100M2 I will demand a firmware 
 upgrade. Let's see what they do.
 
 I just wanted to make sure there was an obvious workaround that I missed :-)
 Thanks! And I will let you know what comes out of the Sun support request!

Thanks.  PLMK what comes about the request, so I can update my
documentation.

Al

 cu,
 Frank
 
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] watchdog problems on Sun X4100M2

[Al Chu]

Hi Frank,

This sounded familiar.  There is this thread for not too long ago.

http://lists.gnu.org/archive/html/freeipmi-users/2010-05/msg00017.html

Not sure if it's the same ILOM, but they are both Sun machines, so I bet
the firmware is broken in similar ways.  As I said in the previous post:

 I think ignoring the flag is a bad idea (it would get around it).
 But it would probably solve the problem.
 
 Perhaps I can edit the code to do some workaround check to see if the
 countdown is changing.  If it is, assume the timer is running regardless
 of what the flag says??  I'm willing to give it a shot if you're
 interested.

Same applies.  I can give a patch a shot, and you can try it out??  It
definitely is a bug.  Unlike other workarounds, I'm just a little scared
of implementing this one.  Afterall, it's a daemon that, if implemented
incorrectly, can lead to a machine rebooting :-)

Al

On Tue, 2010-06-01 at 05:15 -0700, Frank Steiner wrote:
 Hi,
 
 I'm successfully running the bmc-watchdog on our Sun x2200M2 machines.
 But on the X4100M2 I see a strange problem: The timer starts counting, but
 claims to be stopped:
 
 
 sunserver2 /root# bmc-watchdog -g
 Timer Use:   SMS/OS
 Timer:   Stopped
 Logging: Enabled
 Timeout Action:  Power Cycle
 Pre-Timeout Interrupt:   None
 Pre-Timeout Interval:0 seconds
 Timer Use BIOS FRB2 Flag:Set
 Timer Use BIOS POST Flag:Set
 Timer Use BIOS OS Load Flag: Set
 Timer Use BIOS SMS/OS Flag:  Set
 Timer Use BIOS OEM Flag: Set
 Initial Countdown:   900 seconds
 Current Countdown:   900 seconds
 
 
 sunserver2 /root# /usr/sbin/bmc-watchdog -d -u 4 -p 0 -a 3 -F -P -L -S -O -i 
 900 -e 540
 sunserver2 /root# bmc-watchdog -g
 Timer Use:   SMS/OS
 Timer:   Stopped
 Logging: Enabled
 Timeout Action:  Power Cycle
 Pre-Timeout Interrupt:   None
 Pre-Timeout Interval:0 seconds
 Timer Use BIOS FRB2 Flag:Set
 Timer Use BIOS POST Flag:Set
 Timer Use BIOS OS Load Flag: Set
 Timer Use BIOS SMS/OS Flag:  Set
 Timer Use BIOS OEM Flag: Set
 Initial Countdown:   900 seconds
 Current Countdown:   896 seconds
 
 And it continues to countdown.
 
 The problem is that I cannot use the watchdog as daemon because according
 to strace it exits when it sees the timer field is still stopped.
 
 Is anything known about this? I didn't find a hint in the workarounds.
 The watchdog daemon is disabled in the bios to avoid it resetting when
 e.g. a file system check takes some time. But so it is on the x2200M2,
 and those correctly set the field to Running after the above call.
 
 The ILOM on the 4100M2 is up-to-date (just flashed today).
 
 cu,
 Frank
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.6 Released

[Al Chu]

http://ftp.gluster.com/pub/freeipmi/0.8.6/

FreeIPMI 0.8.6 - 05/24/10
-
o Support Quanta S99Q/Dell FS12-TY OEM SEL events.
o In ipmi-oem, support Quanta S99Q/Dell FS12-TY OEM commands.
o Fix --key-pair parsing bug in all config tools.
o Locally support sunbmc driver if bmc_intf.h header not found.
o If Sunbmc driver is not supported, report Device Not Supported
  instead of Internal Error.
o Fix error output messages.
o Fix Solaris install issue.
o Other minor fixes.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] fix for installation failure on Solaris

[Al Chu]

On Wed, 2010-05-05 at 06:15 -0700, Dave Love wrote:
 Al Chu ch...@llnl.gov writes:
 
  Hey Dave,
 
  Actually, the patch broke things on Linux.
 
 Sorry, I don't know what I was thinking that the two things were
 equivalent.  I'm obviously displaying a lack of sleep.
 
  After looking around, a
  suggestion on line was made to only create the link on install time
  rather than build time (which makes sense to me).  Does the attached
  patch work for you?
 
 Yes.
 
 In case you're about to release a new version, I'm trying to get
 bmc-watchdog running on Solaris (which is why I was building there) and
 failing so far.  The daemon just dies around startup with no indication
 why.  It's probably not worth worrying about too much while I try to
 figure out what's going on, but just FYI.

I didn't intend to release for a bit, so there's time.  Are you checking
out the log file and turning on debugging?  It's always possible your HW
has some subtle non-compliance that needs to be worked around.  Feel
free to send a --debug output.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] bmc-watchdog.8 minor fix

[Al Chu]

Thanks.

Al

On Wed, 2010-05-05 at 07:29 -0700, Dave Love wrote:
 There's some runaway emboldening.
 
 --- bmc-watchdog.82010/05/05 14:20:49 1.1
 +++ bmc-watchdog.82010/05/05 14:21:07
 @@ -93,7 +93,7 @@
  .TP
  \fB\-t\fR, \fB\-\-start\fR
  Start BMC Watchdog Timer. Does nothing if the timer is currently
 -running. Identical to \fB\-\-reset command when the timer is stopped with
 +running. Identical to \fB\-\-reset\fR command when the timer is stopped with
  the exception of the start command options listed below under START
  OPTIONS.
  .TP
 
 
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] fix for installation failure on Solaris

[Al Chu]

Hey Dave,

Thanks, it'll be in the next release (wish I had waited 1 more day to
release 0.8.5).

Al

On Fri, 2010-04-30 at 07:51 -0700, Dave Love wrote:
 Solaris 10's cp doesn't have -d.  This is against 0.8.4 source.
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.5 Released

[Al Chu]

http://ftp.gluster.com/pub/freeipmi/0.8.5/

FreeIPMI 0.8.5 - 04/29/10
-
o Support Inventec 5442/Dell Xanadu III OEM events.
o Workaround Quanta S99Q/Dell FS12-TY Node Busy errors.
o Fix some library error checks limiting bmc-config Bad Password
  Threshold configuration.
o Fix some library macro names based on actual OEM names.
o Fix documentation typos.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Reg Cipher Suites

[Al Chu]

Hi John,

(Sorry for the late reply, your message got mixed in with a bunch of
kruft).

As mentioned in the FreeIPMI manpages, the following cipher suite IDs
are supported.


  0 - Authentication Algorithm = None; Integrity Algorithm =
None; Confidentiality Algorithm = None

  1 - Authentication Algorithm = HMAC-SHA1; Integrity
Algorithm = None; Confidentiality Algorithm = None

  2 - Authentication Algorithm = HMAC-SHA1; Integrity
Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = None

  3 - Authentication Algorithm = HMAC-SHA1; Integrity
Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128

  6 - Authentication Algorithm = HMAC-MD5; Integrity
Algorithm = None; Confidentiality Algorithm = None

  7 - Authentication Algorithm = HMAC-MD5; Integrity
Algorithm = HMAC-MD5-128; Confidentiality Algorithm = None

  8 - Authentication Algorithm = HMAC-MD5; Integrity
Algorithm = HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128

  11 - Authentication Algorithm = HMAC-MD5; Integrity
Algorithm = MD5-128; Confidentiality Algorithm = None

  12 - Authentication Algorithm = HMAC-MD5; Integrity
Algorithm = MD5-128; Confidentiality Algorithm = AES-CBC-128


It seems you're particularly interested in the Cipher Suite IDs that use
xRC4.  Do you have a motherboard that supports it?  Part of the reason
it was never supported in FreeIPMI is b/c no motherboard I ever saw
supported it.

Al

On Mon, 2010-04-12 at 03:37 -0700, Winston John wrote:
 Hi All,
 
  I would like to know the cipher suite ID's supported by free
 ipmi.  Is Cipher suite 4,6,9,10,13,14 supported in free ipmi ? Please
 let me know your comments.
 
 Thanks,
 Winston
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.4 Released

[Al Chu]

http://ftp.gluster.com/pub/freeipmi/0.8.4/

FreeIPMI 0.8.4 - 03/05/10
-
o Fix IPMI 2.0 sequence number wrap around corner case.
o Fix ipmi-sensors --comma-separated-output corner case.
o In ipmi-sensors, output multiple event strings w/ space delimiter in
  simple output.
o In ipmi-oem, support Dell get-active-lom-status.
o In ipmi-oem, support IBM get-led.
o In ipmi-sel, fix possible --assume-system-event-records corner case.
o Fix Posix portability issue w/ time functions.
o Minor documentation updates.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

[Al Chu]

Hey Matt,

Looks pretty good.  A few comments:

+int
+ipmi_kcs_wait (ipmi_kcs_ctx_t ctx)
+{
+  /* Sit in loop waiting for the SMS_ATN register to be set.
+ This can also exit by invoking ipmi_kcs_wait_cancel */
+  ctx-event_exit = 0;
+  while (ctx-event_exit == 0)
+{
+  if (_ipmi_kcs_get_status (ctx)  IPMI_KCS_STATUS_REG_SMS_ATN)
+return(0);
+  sleep(1);
+}
+   
+   KCS_SET_ERRNUM(ctx, IPMI_KCS_ERR_DRIVER_TIMEOUT);
+   return (-1);
+}

A sleep of 1 second is probably too big for most people.  Perhaps we can
pass in a parameter to determine the usleep time??

Looking through the spec, I think not locking the inband sempahore is
probably safe.  Although there's a tiny part of me that says maybe we
should lock it just to be on the safe side.  A.B., what do you think?

+int
+ipmi_kcs_clear_wait (ipmi_kcs_ctx_t ctx)
+{
+  /* Allow the event thread to exit the wait loop */
+  ctx-event_exit = 1;
+}

This isn't thread safe.  Perhaps we can add back that extra semaphore
(like in your first patch) as the flag to break out of the loop?

BTW, a few commenting nits for when I integrate the patch, you don't
follow GNU coding style.  The biggest thing you're missing is a space
between a function call and the parentheses.  So for example:

 KCS_SET_ERRNUM(ctx, IPMI_KCS_ERR_DRIVER_TIMEOUT);

should be

 KCS_SET_ERRNUM (ctx, IPMI_KCS_ERR_DRIVER_TIMEOUT);

and

+  if (ctx-type == IPMI_DEVICE_KCS)
+{
+  return(ipmi_kcs_cmd_wait_event(ctx));
+}

there shouldn't be any braces with one line after the if.

 but I didn't run it on hardware yet because my customer has not yet 
 sent me the KCS hardware.

No problem.  Once we settle on a patch, we'll wait for you to test.
Once it's good to go, we can add it into FreeIPMI.

Al

On Mon, 2010-03-01 at 06:34 -0800, Matt Jerdonek wrote:
 
 Al,
 
 Thanks for the clarification.  I see your point and I updated the
 patch to address it.  As with the previous patch, this compiles, but I
 didn't run it on hardware yet because my customer has not yet sent me
 the KCS hardware.
 
 Thanks again,
 -Matt
 
 
 --- On Thu, 2/25/10, Al Chu ch...@llnl.gov wrote:
 
 From: Al Chu ch...@llnl.gov
 Subject: Re: [Freeipmi-devel] KCS Driver  SMS_ATN Register
 To: Matt Jerdonek maj1...@yahoo.com
 Cc: Anand Babu Periasamy a...@gnu.org.in,
 freeipmi-devel@gnu.org
 Date: Thursday, February 25, 2010, 10:33 AM
 
 Hi Matt,
 
 I don't see it that way.  I could see someone programming a
 single
 thread and only wanting to poll the SMS_ATN bit, and process
 events as
 they occur.  Not doing any other KCS. e.g.
 
 main()
 {
setup_kcs();
 
while (1) {
   kcs_wait_for_sms()
   get_message_flags()
   process_event()
}
 }
 
 Maybe I didn't describe it well.  The concern I have with your
 patch (if
 I'm reading it correctly, correct me if I'm wrong) is that the
 only time
 the SMS ATN bit is checked is in _ipmi_kcs_get_status().
 _ipmi_kcs_get_status() will only be called through other KCS
 functions
 like ipmi_kcs_read() and ipmi_kcs_write().
 
 So in order for the SMS ATN bit to be checked, ipmi_kcs_read()
 and
 ipmi_kcs_write() have to be called, either by your application
 or other
 IPMI going on in the system, otherwise the SMS_ATN bit will
 never be
 checked.  Correct?  Under your patch, in the above code
 snippet,
 kcs_wait_for_sms() will never return, b/c no other KCS calls
 are going
 on (unless they are other KCS IPMI going on in the system
 elsewhere). 
 
 Perhaps within your patch, you assumed other IPMI going on in
 other
 parts of the system?
 
 Al
 
 -- 
 Albert Chu
 ch...@llnl.gov
 Computer Scientist
 High Performance Systems Division
 Lawrence Livermore National Laboratory
 
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

[Al Chu]

Hey Matt,

I noticed one or two minor nits, but I can fix em.  I guess I am only
perplexed by this design choice.  It seems you want to have two threads.
One thread does normal IPMI regularly, and the other thread will wait
for the SMS_ATN bit.  It appears that _ipmi_kcs_get_status() is the only
place that the SMS_ATN bit is checked, so you need to be doing some type
of other KCS in order to ever check for it?

Perhaps it'd be better to just have a function that regularly polls the
SMS_ATN bit, and if it is true, return to the user??  Perhaps something
like:

poll_sms_atn(unsigned int poll_interval, unsigned int max_iterations)
{
  while (count = max_iterations)
  {
  lock_kcs_semaphore();
  if (sms_atn bit set)
  break;
  unlock_kcs_sempahore();   
  sleep (poll_interval);
  }
  unlock_kcs_sempahore();  
}




Al

On Tue, 2010-02-23 at 08:27 -0800, Matt Jerdonek wrote:
 
 
 Please give the attached patch a look.  Since you two didn't like the
 idea of a callback, I created an API to wait for an event and a second
 API to cancel the wait.  Basically the application will be responsible
 for creating a thread which invokes the API.  The API will block the
 application's thread until an event occurs.  The application will be
 responsible for issuing a GET MESSAGE FLAGS command once the thread
 unblocks.
 
 I had to use a semaphore to block the thread, so I made some small
 changes to ipmi-semaphores.c as well.
 
 Note: this compiles, but I didn't try to run it yet.  My customer has
 not yet sent me the hardware with the KCS interface, so I don't have
 hardware to exercise the code.  
 
 Thanks again for your consideration,
 -Matt
 
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

[Al Chu]

Hey A.B.,

On Mon, 2010-02-22 at 01:16 -0800, Anand Babu Periasamy wrote:
 On Sun, Feb 21, 2010 at 8:38 AM, Al Chu ch...@llnl.gov wrote:
  Hey A.B,
 
  Al, Unfortunately SMS_ATN is KCS specific. So we can't create an
  abstracted API.
 
  There's no reason other drivers won't have interrupt callbacks in the
  future.  We can abstract it by calling the API function something like
  interrupt_callback.  The only driver supported with it would be KCS in
  the beginning.
 
  Al
 
 Then lets create an API and return ENOTSUP erno for system interfaces
 other than KCS (for now). It makes sense for higher level abstracted
 API to call get-message-flags in addition. This function is already
 asynchronous.  Application developers would prefer an async API over
 callback framework.

We'd probably return IPMI_ERR_DEVICE_NOT_SUPPORTED  or make a new error
code, but yeah, that's the basic idea.

Al

 --
 Anand Babu Periasamy
 GPG Key ID: 0x62E15A31
 Blog [http://*www.*unlocksmith.org]
 GlusterFS [http://*www.*gluster.org]
 GNU Operating System [http://*www.*gnu.org]
 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

[Al Chu]

Hi Matt,

Definitely open to patches.  Looking over the IPMI spec, I agree w/
A.B., it seems to be more useful for a higher level monitoring, w/ the
Get Message Flags and similar commands.  I can think of several patch
ideas:

1) add a KCS driver flag for checking for SMS_ATN in addition to OBF (or
instead of??).  Flags may be propogated up into higher level APIs too.

2) an additional function that checks for SMS_ATN in addition/or instead
of OBF that users can call instead.

It would be useful to understand your use case too.  Are you using the
KCS driver and IPMI bridging commands to bridge from one BMC to another
BMC?

Thanks,

Al

On Wed, 2010-02-17 at 18:51 -0800, Matt Jerdonek wrote:
 Hello,
 
 The KCS driver appears to not use the SMS_ATN register.  This register
 is useful for BMC-to-BMC communication to know when the remote BMC has
 responded.  Are there any plans to monitor this register in future
 releases?  If not, are the maintainers open to including a patch?
 
 Thanks,
 -Matt
 
 
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] KCS Driver SMS_ATN Register

[Al Chu]

Hi Matt,

Anand wrote the KCS driver, so he'll respond too.

Re-reading the spec again and reading your comments, I think I
understand your situation.  You're looking to read the SMS_ATN register
so that you'll know whether a receive queue, event buffer, or whatever
other thing has occurred, then you'll do something appropriate given the
situation.  This is in contrast to the relative request-reply model of
the current driver. e.g. for IPMB, I poll the recieve queue. Correct?

Based on what you said below, here's my idea of how to implement what
you're thinking.

We'll add a function like ipmi_kcs_sms_atn_callback_register(), where
you register a function that will be called if SMS_ATN is set to 1.

Add another function, something like ipmi_kcs_sms_atn_spin(), that just
spins and checks SMS_ATN once in awhile.  It'll call the callback
whenever appropriate.  This is going to be like our sleep or wait
equivalent when your app is waiting to do something.  

Within the KCS driver, check the SMS_ATN bit before any KCS read or
write operation done within the KCS driver.  If the SMS_ATN bit is 1,
call the callback.

So the net affect is an event can be generated whenever you are doing
KCS or you sleep w/ the spin function.  You're right, that the
downside is is that the user shouldn't use ipmi_kcs_cmd_api_ipmb() in
this situation (worst that happens is you get timeouts if you take a
message off the receive queue instead of libfreeipmi).  But I figure
this is a bit of advanced use, so they'll have to know that you
shouldn't use ipmi_kcs_cmd_api_ipmb().

Is this what you're looking for??

Al

On Thu, 2010-02-18 at 13:24 -0800, Matt Jerdonek wrote:
 Al  Anand,
 
 Thanks for the quick response.  I'm planning on using libfreeipmi to
 create a custom application that, among other things, will have to
 read event flags from the local event log and query sensors on local
 and remote BMCs.
 
 I looked at the spec, and I think I have a slightly different
 understanding (I'm not saying I'm right -- I may be misunderstanding
 the spec).  I don't think SMS_ATN and OBF can be used interchangeably.
 Here's my understanding:
 1) If the SMS_ATN bit is set the local BMC requires some attention.
 2) A GET MESSAGE FLAGS command should be sent to query the BMC.
 3) If bit 0 is set in the response, that indicates a receive message
 is available.  From looking at the ipmi_kcs_cmd_api_ipmb code, it
 appears as if that code polls the local BMC with GET MESSAGE cmds
 instead of using this bit to indicate when the response from the
 remote BMC is ready.  While polling may not be ideal, it's certainly
 ok for my application.
 4) If bit 1 is set in the response, that indicates an event is
 available.
 5) I'll ignore the pre-watchdog timeout and OEM bits for now ...
 
 I don't understand how libfreeipmi notifies the application that an
 event is available without monitoring the SMS_ATN bit.  I think I want
 to create a patch that does the following:
 1) Creates a callback from libfreeapi to the application when an event
 occurs.
 2) Monitors the SMS_ATN bit.
 3) If set, invokes the callback.
 
 
 The application would be responsible for issuing the GET MESSAGE FLAGS
 command and handling the response.  One downside of this approach is
 that it prevents you from ever making ipmi_kcs_cmd_api_ipmb
 event-driven.  What do you two think?
 
 Thanks,
 -Matt
 
 __
 From: Al Chu ch...@llnl.gov
 To: Matt Jerdonek maj1...@yahoo.com
 Cc: freeipmi-devel@gnu.org
 Sent: Thu, February 18, 2010 10:58:06 AM
 Subject: Re: [Freeipmi-devel] KCS Driver  SMS_ATN Register
 
 Hi Matt,
 
 Definitely open to patches.  Looking over the IPMI spec, I agree w/
 A.B., it seems to be more useful for a higher level monitoring, w/ the
 Get Message Flags and similar commands.  I can think of several patch
 ideas:
 
 1) add a KCS driver flag for checking for SMS_ATN in addition to OBF
 (or
 instead of??).  Flags may be propogated up into higher level APIs too.
 
 2) an additional function that checks for SMS_ATN in addition/or
 instead
 of OBF that users can call instead.
 
 It would be useful to understand your use case too.  Are you using the
 KCS driver and IPMI bridging commands to bridge from one BMC to
 another
 BMC?
 
 Thanks,
 
 Al
 
 On Wed, 2010-02-17 at 18:51 -0800, Matt Jerdonek wrote:
  Hello,
  
  The KCS driver appears to not use the SMS_ATN register.  This
 register
  is useful for BMC-to-BMC communication to know when the remote BMC
 has
  responded.  Are there any plans to monitor this register in future
  releases?  If not, are the maintainers open to including a patch?
  
  Thanks,
  -Matt
  
  
  ___
  Freeipmi-devel mailing list
  Freeipmi-devel@gnu.org
  http://**lists.gnu.org/mailman/listinfo/freeipmi-devel
 -- 
 Albert Chu
 ch...@llnl.gov
 Computer Scientist
 High Performance Systems Division
 Lawrence Livermore National Laboratory

[Freeipmi-devel] Replacing ipmimonitoring tool w/ ipmi-sensors tool

[Al Chu]

Hi everyone,

With some recent architectural changes, I am contemplating removing the
ipmimonitoring tool (don't worry, I'm leaving the libipmimonitoring
library).  Before I do this, I figure I'll ask the community if they
would have any problems.

The reasons for doing this are:

A) For FreeIPMI 0.9.X there will be a new --output-sensor-state option
in ipmi-sensors that accomplishes the sensor state interpretation that
ipmimonitoring/libipmimonitoring was once only capable of doing.

B) The default output of ipmimonitoring since 0.8.1 is now identical to
ipmi-sensors w/ the --output-sensor-state option.

If I remove ipmimonitoring, I would have a symlink pointing
ipmimonitoring to ipmi-sensors w/ the right options.

The primary negative to doing this is that the ipmimonitoring
--legacy-output option would effectively disappear (you would get the
--legacy-output of ipmi-sensors).

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 0.8.3 Released

[Al Chu]

http://ftp.gluster.com/pub/freeipmi/0.8.3/

FreeIPMI 0.8.3 - 02/02/10
-
o Support Sun Microsystems OEM SEL events.
o Fix Solaris 64 bit portability bugs.
o In ipmi-oem, fix some Dell options and output given Dell docs 
  (backwards compatability maintained on options).
  - Rename 'get-power-headroom-info' to 'get-power-head-room'.
o Minor bug fixes.
o Minor documentation updates.
o Minor documentation fixes.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] 0.8.2 Solaris patch

[Al Chu]

Hey Andrew,

On Mon, 2010-01-25 at 16:15 +1100, Andrew Wansink wrote:
 On Mon, Jan 18, 2010 at 11:07:23PM -0500, Al Chu wrote:
  Hi Andrew,
  
  Thanks for the catch.  I wrote the attached patch, to try and load
  headers (and subsequently MAXHOSTNAMELEN) more correctly and
  consistently globally.  I consider that the more core problem (e.g. in
  some places I didn't even try and load limits.h for Linux).  Can you
  give it a shot and LMK if it works for you.
 
 It looks good but doesn't apply cleanly to 0.8.2.  I guess you're
 patching against CVS.

Wouldn't have anticipated a hiccup against 0.8.2, but yeah, it was
against the codebase.

  
   Also it fixes a little Solaris problem finding
   the m4 files during auto(re)conf.
  
  Is this what:
  
  +ACLOCAL_AMFLAGS = -Iconfig
  
  solves?  I'm a little confused, b/c this should be automatic.
 
 Precisely.  No matter what I did I couldn't get autoconf to
 find the macros in 'config' until I found that option.  Maybe
 it's an ancient version of autoconf shipped with OpenSolaris,
 `autoconf -V` reports 2.61.

Doh!  I realize what's going on.  I run w/ the autogen.sh script that
is in the code repo, it has 

aclocal -I config

I guess you were running aclocal/autoconf/etc. by hand b/c autogen.sh
isn't released with the tar.gz.  Perhaps I should dist out the script
for those that are going to hack on the code a bit.

Al

 Perhaps I'm doing something else wrong.
 
 Andrew Wansink
 
 snip
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] freeipmi-0.8.2: possible buffer overflow -- patch attached

[Al Chu]

Hey Klaus,

Yup, definitely a cut  paste mistake.  Thanks for the catch.

Al

On Thu, 2010-01-14 at 16:54 +0100, Klaus Kaempf wrote:
 Hi,
 
 compiling freeipmi-0.8.2, GNU-C 4.4 gives a warning about a buffer
 overflow in libfreeipmi/src/cmds/ipmi-messaging-support-cmds.c at line
 1487.
 
 Looking more closely, there are a couple of duplicate lines due to a
 copy-and-paste error.
 
 Patch attached.
 
 Enjoy,
 
 Klaus
 ---
 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
 
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] make install issue in freeipmi-0.8.2.beta3

[Al Chu]

Hey Andy,

If I'm not mistaken, the in-band in ipmiutil is via normal Windows,
not Cygwin?

Al

On Thu, 2009-12-24 at 07:29 -0800, Andy Cress wrote:
 There is a closed-source port of ipmitool from Sun that apparently has
 some in-band Windows support with a special Sun driver, but the only
 open-source IPMI support for Windows in-band is via ipmiutil
 (http://*ipmiutil.sf.net), which supports both the Intel driver and
 the Microsoft driver.  
 
  
 
 Andy
 
  
 
 From:freeipmi-devel-bounces+arcress=users.sourceforge@gnu.org
 [mailto:freeipmi-devel-bounces+arcress=users.sourceforge@gnu.org]
 On Behalf Of sandeep patra
 Sent: Wednesday, December 23, 2009 1:07 AM
 To: ch...@llnl.gov
 Cc: freeipmi-devel@gnu.org
 Subject:  Re: [Freeipmi-devel] make install issue in
 freeipmi-0.8.2.beta3 
 
 
  
 
 Hi Albert,
 I have used the default --prefix option. (i.e. ./configure without any
 --prefix option)
 
 I did modifications in two Makefiles to complete the make install
 step
 those file were
 bmc-watchdog/Makefile 
 ipmi-pef-config/src/Makefile 
 
 the changes that i did was (in the ipmi-pef-config/src/Makefile )
 previous:
 $(install_sh) -d -m 755 $(DESTDIR)/$(sbindir)
 cp -d ./pef-config $(DESTDIR)/$(sbindir)
 
 modified to:
 $(install_sh) -d -m 755 $(DESTDIR)$(sbindir)
 cp -d ./pef-config $(DESTDIR)$(sbindir)
 
 I did this steps manually [as these Makefiles were generated
 automatically after ./configure].
 
 After doing above two steps all the exe's were installed to the
 location /usr/local/sbin/. 
 when i run commands likes ipmimonitoring or ipmi-sensors, it is giving
 me error like permission denied
 
 Thanks and  Regards,
 Sandeep Kumar Patra
 
  
 
 On Tue, Dec 22, 2009 at 7:53 PM, Al Chu ch...@llnl.gov wrote:
 
 Hi Sandeep,
 
 From the README.build file
 
 
 By default files will typically be installed in /usr/local (binaries
 in /usr/local/bin, libraries in /usr/local/lib, configuration files in
 /usr/local/etc/, etc.).  To install into the more common locations
 such as /usr/bin, /usr/lib/, /etc, etc. the options passed into
 `./configure' must be adjusted.
 
 The following set of options and settings are suitable for most Linux
 systems.
 
 --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc
 --localstatedir=/var --mandir=/usr/share/man
 
 Your mileage may vary depending on your system.
 
 
 Al
 
 
 On Tue, 2009-12-22 at 12:31 +0530, sandeep patra wrote:
  Hi,
  I am trying to install freeipmi-0.8.2.beta3 on cygwin
 (CYGWIN_NT-5.1),
  but failed to do so.
  ./configure  and make commands work fine
  but when i run make install, it gives me following error
 
 
  make[3]: Nothing to be done for `install-exec-am'.
  /usr/bin/install -c -m 755 -d /usr/local/etc/init.d
  /usr/bin/install -c -m
  755 ./bmc-watchdog.init /usr/local/etc/init.d/bmc-watchdo
  g
  /usr/bin/install -c -m 755 -d //usr/local/etc/sysconfig
  /usr/bin/install: cannot create directory `//usr': No such file or
  directory
  make[3]: *** [install-init-scripts] Error 1
  make[3]: Leaving directory
  `/home/Administrator/freeipmi_issue/fresh_freeipmi/fr
  eeipmi-0.8.2.beta3/bmc-watchdog'
  make[2]: *** [install-am] Error 2
  make[2]: Leaving directory
  `/home/Administrator/freeipmi_issue/fresh_freeipmi/fr
  eeipmi-0.8.2.beta3/bmc-watchdog'
  make[1]: *** [install-recursive] Error 1
  make[1]: Leaving directory
  `/home/Administrator/freeipmi_issue/fresh_freeipmi/fr
  eeipmi-0.8.2.beta3/bmc-watchdog'
  make: *** [install-recursive] Error 1
 
 
  No idea, why the path for sysconfig file
  is //usr/local/etc/sysconfig 
 
 
 
 
  Thanks and Regards,
  Sandeep Kumar Patra
 
 
 
 
 
 
 
 
  ___
  Freeipmi-devel mailing list
  Freeipmi-devel@gnu.org
  http://**lists.gnu.org/mailman/listinfo/freeipmi-devel
 --
 Albert Chu
 ch...@llnl.gov
 Computer Scientist
 High Performance Systems Division
 Lawrence Livermore National Laboratory
 
 
  
 
 
 The information contained in this document is CONFIDENTIAL and
 property of Kontron. Any unauthorized review, use, disclosure or
 distribution is prohibited without express written consent of Kontron.
 If you are not the intended recipient, please contact the sender and
 destroy all copies of the original message and enclosed attachments.
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] make install issue in freeipmi-0.8.2.beta3

[Al Chu]

Hi Sandeep,

From the README.build file


By default files will typically be installed in /usr/local (binaries
in /usr/local/bin, libraries in /usr/local/lib, configuration files in
/usr/local/etc/, etc.).  To install into the more common locations
such as /usr/bin, /usr/lib/, /etc, etc. the options passed into
`./configure' must be adjusted.

The following set of options and settings are suitable for most Linux
systems.

--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc
--localstatedir=/var --mandir=/usr/share/man

Your mileage may vary depending on your system.


Al

On Tue, 2009-12-22 at 12:31 +0530, sandeep patra wrote:
 Hi,
 I am trying to install freeipmi-0.8.2.beta3 on cygwin (CYGWIN_NT-5.1),
 but failed to do so.
 ./configure  and make commands work fine
 but when i run make install, it gives me following error
 
 
 make[3]: Nothing to be done for `install-exec-am'.
 /usr/bin/install -c -m 755 -d /usr/local/etc/init.d
 /usr/bin/install -c -m
 755 ./bmc-watchdog.init /usr/local/etc/init.d/bmc-watchdo
 g
 /usr/bin/install -c -m 755 -d //usr/local/etc/sysconfig
 /usr/bin/install: cannot create directory `//usr': No such file or
 directory
 make[3]: *** [install-init-scripts] Error 1
 make[3]: Leaving directory
 `/home/Administrator/freeipmi_issue/fresh_freeipmi/fr
 eeipmi-0.8.2.beta3/bmc-watchdog'
 make[2]: *** [install-am] Error 2
 make[2]: Leaving directory
 `/home/Administrator/freeipmi_issue/fresh_freeipmi/fr
 eeipmi-0.8.2.beta3/bmc-watchdog'
 make[1]: *** [install-recursive] Error 1
 make[1]: Leaving directory
 `/home/Administrator/freeipmi_issue/fresh_freeipmi/fr
 eeipmi-0.8.2.beta3/bmc-watchdog'
 make: *** [install-recursive] Error 1
 
 
 No idea, why the path for sysconfig file
 is //usr/local/etc/sysconfig 
 
 
 
 
 Thanks and Regards,
 Sandeep Kumar Patra
 
 
 
 
 
 
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Regarding Serial Interface Support

[Al Chu]

Hi Winston,

In terms of a direct interface, currently no.  Looking through the IPMI
spec, I suppose adding this support via an extra interface to FreeIPMI
(i.e. -I serial or something like that) wouldn't be too hard, but it
would definitely take time to add.  I don't know enough of the details
to do it quickly and easily (not to mention setup a machine w/ a serial
connection so I can try code out).

Al

On Tue, 2009-12-22 at 05:19 -0800, Winston John wrote:
 Hi All,
 
 
   I would like to test Serial Interface support for IPMI firmware.
 It would be more helpful if you let me know whether free-ipmi supports
 communication to BMC via Serial Interface.
 
 
 Thanks,
 Winston
 ___
 Freeipmi-devel mailing list
 Freeipmi-devel@gnu.org
 http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel