[Freeipmi-devel] [bug #38797] ipmi-dcmi 1.2.5 does not support the DCMI 1.5 definition of Mandatory Platform Attributes DCMI Capabilities Parameter

URL: http://savannah.gnu.org/bugs/?38797 Summary: ipmi-dcmi 1.2.5 does not support the DCMI 1.5 definition of Mandatory Platform Attributes DCMI Capabilities Parameter Project: GNU FreeIPMI Submitted by: rswindell Submitted on: Mon 22

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

URL: http://savannah.gnu.org/bugs/?38798 Summary: timestamps are interpretted as UTC rather than localtime, violating IPMI 2.0 section 37 Project: GNU FreeIPMI Submitted by: rswindell Submitted on: Mon 22 Apr 2013 04:33:14 AM GMT

[Freeipmi-devel] [bug #38790] Invalid Confidentiality Pad Length value in encrypted RMCP+ packets

Follow-up Comment #1, bug #38790 (project freeipmi): Here's the patch: Index: libfreeipmi/interface/ipmi-rmcpplus-interface.c === --- libfreeipmi/interface/ipmi-rmcpplus-interface.c (revision 9608) +++

[Freeipmi-devel] [bug #38781] Errant Legacy PAD byte added to IPMI 2.0 (RMCP+) packets

Follow-up Comment #4, bug #38781 (project freeipmi): Here's the patch (another one-liner): Index: libfreeipmi/api/ipmi-lan-session-common.c === --- libfreeipmi/api/ipmi-lan-session-common.c (revision 9608) +++

Re: [Freeipmi-devel] [bug #38790] Invalid Confidentiality Pad Length value in encrypted RMCP+ packets

-Original Message- From: Albert Chu [mailto:invalid.nore...@gnu.org] Sent: Thursday, April 25, 2013 11:27 AM To: Albert Chu; Rob Swindell; freeipmi-devel@gnu.org Subject: [bug #38790] Invalid Confidentiality Pad Length value in encrypted RMCP+ packets Update of bug #38790 (project freeipmi

[Freeipmi-devel] [bug #38799] IPMI 2.0 Special Timestamp values are not supported

Follow-up Comment #1, bug #38799 (project freeipmi): Here's a patch for one instance of this problem. A more generic IPMI timestamp display function should be created and used through-out the IPMI/DCMI code to address this problem globally: Index: bmc-device/bmc-device.c

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

Follow-up Comment #1, bug #38798 (project freeipmi): Here's a patch for one instance of this problem. Like I suggested for bug #38799, a generic IPMI timestamp function should be created and used everywhere so as to resolve these issues globally:

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

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? 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

[Freeipmi-devel] [bug #38866] buffer overrun in _output_date() from sel/ipmi-sel-string.c:675

URL: http://savannah.gnu.org/bugs/?38866 Summary: buffer overrun in _output_date() from sel/ipmi-sel-string.c:675 Project: GNU FreeIPMI Submitted by: rswindell Submitted on: Thu 02 May 2013 02:02:39 AM GMT Category:

Re: [Freeipmi-devel] [bug #38866] buffer overrun in _output_date() from sel/ipmi-sel-string.c:675

This code only exists in the current svn trunk (it's not in 1.2.6). No emergency. -Rob -Original Message- From: Albert Chu [mailto:invalid.nore...@gnu.org] Sent: Thursday, May 02, 2013 8:06 AM To: Albert Chu; Rob Swindell; freeipmi-devel@gnu.org Subject: [bug #38866] buffer overrun

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

: 05/09/2012 - 19:37:32 Looks good. -Rob -Original Message- From: Albert Chu [mailto:invalid.nore...@gnu.org] Sent: Thursday, May 09, 2013 10:10 AM To: Albert Chu; Rob Swindell; freeipmi-devel@gnu.org Subject: [bug #38798] timestamps are interpretted as UTC rather than localtime

Re: [Freeipmi-devel] [Freeipmi-users] FreeIPMI 1.2.6 Released

Just FYI, the web site (https://www.gnu.org/software/freeipmi/) hasn't been updated to include this release. -Rob -Original Message- From: freeipmi-users-bounces+swindell=broadcom@gnu.org [mailto:freeipmi-users-bounces+swindell=broadcom@gnu.org] On Behalf Of Albert Chu Sent:

[Freeipmi-devel] bmc-info now requires Device GUID support

The Free-IPMI 'bmc-info' command appears to now prematurely terminate with an error if the target BMC does not support the Get Device GUID command. This is new(ish) behavior. Previous behavior: # bmc-info -V bmc-info - 1.1.5 Copyright (C) 2003-2012 FreeIPMI Core Team This program is free

[Freeipmi-devel] [bug #40076] Does not differentiate between different OEM-SEL record types

URL: http://savannah.gnu.org/bugs/?40076 Summary: Does not differentiate between different OEM-SEL record types Project: GNU FreeIPMI Submitted by: rswindell Submitted on: Sat 21 Sep 2013 01:40:30 AM GMT Category:

Re: [Freeipmi-devel] ipmi_cmd_get_system_guid() ?

, 2013 11:02 AM To: Rob Swindell Cc: freeipmi-devel@gnu.org Subject: Re: [Freeipmi-devel] ipmi_cmd_get_system_guid() ? Hi Rob, It looks like none of the tools use it by default. Bmc-info uses the Get Device GUID command instead of Get System GUID. I suppose they can return different information, so

Re: [Freeipmi-devel] Retrieving BIOS information via IPMI

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

[Freeipmi-devel] segfault in ipmi-chassis

(gdb) set args -h nx-mgmt-fw-12 --set-boot-flags --force-progress-event-traps (gdb) run Starting program: /home/administrator/freeipmi/trunk/ipmi-chassis/.libs/lt-ipmi-chassis -h nx-mgmt-fw-12 --set-boot-flags --force-progress-event-traps [Thread debugging using libthread_db enabled] Using host