[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 libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. 0x77086415 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x77086415 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00404c14 in boot_flag_parse (state=optimized out, arg=0x0, key=optimized out) at ipmi-chassis-argp.c:285 #2 cmdline_parse (key=optimized out, arg=0x0, state=optimized out) at ipmi-chassis-argp.c:467 #3 0x77052d03 in argp_parse () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00405527 in ipmi_chassis_argp_parse (argc=5, argv=0x7fffe5b8, cmd_args=0x7fffe340) at ipmi-chassis-argp.c:594 #5 0x0040295b in main (argc=5, argv=0x7fffe5b8) at ipmi-chassis.c:1687 On an unrelated note, I'm having a hard time finding the correct usage of 'ipmi-chassis --set-boot-flags' in any of the help output or man pages. Experimentation found this segfault. -Rob ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
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 --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 there are underlying Free-IPMI library functions available to exercise this command and return the data to an application. -Rob -Original Message- From: freeipmi-devel-bounces+swindell=broadcom@gnu.org [mailto:freeipmi-devel-bounces+swindell=broadcom@gnu.org] On Behalf Of Al Chu Sent: Monday, January 06, 2014 11:38 AM To: Vinny Vallarine Cc: freeipmi-devel@gnu.org Subject: Re: [Freeipmi-devel] Retrieving BIOS information via IPMI Yes, if you look at the tool bmc-info, you'll see it output various firmware/system information. Underneath the covers, these are calls to various IPMI device queries. Al On Mon, 2014-01-06 at 14:20 -0500, Vinny Vallarine wrote: Ah, interesting. So if the Vendor(s) we're interfacing with use the same rev number for all their device firmware, I may be able to simply query for the IPMI firmware version number, correct? Assuming this is part of the IPMI spec? -Original Message- From: Al Chu [mailto:ch...@llnl.gov] Sent: Monday, January 06, 2014 12:50 PM To: Vinny Vallarine Cc: freeipmi-devel@gnu.org Subject: RE: [Freeipmi-devel] Retrieving BIOS information via IPMI On Mon, 2014-01-06 at 12:41 -0500, Vinny Vallarine wrote: Thanks Al. I'd be content at the moment to be able to retrieve the BIOS version number. Sounds like something as simple as that would be Vendor specific, correct? Yes no. My recollection is that nothing in the IPMI spec allows you to specifically retrieve the BIOS version. However, many vendors flash all of their device firmware (BIOS + IPMI firmware, etc.) with the same image. So many of the device/system versions retrieved via IPMI may in fact be identical to the BIOS version. We're interfacing with SuperMicro main boards. I know they have specific tools to do exactly what I need to do so I'm assuming they've added the needed extensions. You may be in luck. There is an extensions for Supermicro firmware versions in ipmi-oem. However, again, it's not necessarily the BIOS version. Al I'll check out your suggestions to see what is configurable and what the vendors have added. Thanks, Vinny -Original Message- From: Al Chu [mailto:ch...@llnl.gov] Sent: Monday, January 06, 2014 12:24 PM To: Vinny Vallarine Cc: freeipmi-devel@gnu.org Subject: Re: [Freeipmi-devel] Retrieving BIOS information via IPMI Hi Vinny, The IPMI specification does not support the ability to retrieve/modify BIOS options per se. The IPMI specification does allow modification of various motherboard parameters, many of which may happen to be readable/modifiable/managed by the BIOS. So if you are looking to use IPMI for querying the BIOS, it really depends on what you would like to query. Not everything in the BIOS will be queryable. For example, the chassis subsection of IPMI allows the configuration of a number of boot options. Many of these configuration options are likely in the BIOS (see ipmi-chassis-config tool to get an idea of what is configurable). General device information is available through various device queries and that may also be in the BIOS (see bmc-info tool for examples of info that is available). I believe some vendors support reading of the SEL in the BIOS for hardware analysis (see tool ipmi-sel for example). As an aside, various vendors have added extensions to IPMI to retrieve/set BIOS settings, but these are on a vendor by vendor (many times motherboard by motherboard) basis. If you look through the tool ipmi-oem, you can see what some vendors have supported. If one of the tools supports what you would like to do, then we can perhaps dig into the API from that point. Al On Mon, 2014-01-06 at 10:20 -0500, Vinny Vallarine wrote: My company is looking for an IPMI package that we can interface with. I’ve just downloaded your freeIPMI package. What we need to do is query multiple machines and retrieve their BIOS revision numbers as well as specific BIOS settings. I’ve looked through your documentation but don’t see an API that would allow me to do that via your libraries. Could you let me know how this can be done through your
Re: [Freeipmi-devel] ipmi_cmd_get_system_guid() ?
Yes, we are interested. The Device (BMC) GUID and the system GUID *should* be different from my understanding. Some implementations may support one command/GUID but not the other. Thanks! -Rob -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Thursday, December 12, 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 perhaps bmc-info should do both. I can add it if you're interested in it. Al On Thu, 2013-12-12 at 02:47 +, Rob Swindell wrote: I was looking for a way to test the ipmi_cmd_get_system_guid() function in Free-IPMI. Is there an included command utility which uses this function (and displays the returned system GUID)? Thanks, -Rob ___ 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
[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: ipmi-sel Severity: 3 - Normal Priority: 5 - Normal Item Group: Improper Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Operating System: None ___ Details: OEM-SEL entries may have types from 0xC0 through 0xFF, but the ipmi-sel program just output OEM defined, not differentiating between the different potential OEM-defined record types. This patch displays the actual 'record type' value for OEM-defined SEL entries. This allows parsers to differentiate between OEM type 0xE0 and 0xE1 for example and interpet the OEM-defined entry data accordingly. Example ipmi-sel output from before the patch: 3 | N/A | N/A | N/A | N/A | OEM defined = DEh CEh 3Ch 52h 01h 00h 00h 39h 00h 00h 04h 05h 00h Example ipmi-sel output from after the patch: 3 | N/A | N/A | N/A | N/A | OEM E4h defined = DEh CEh 3Ch 52h 01h 00h 00h 39h 00h 00h 04h 05h 00h If you prefer to put the record-type in parenthesis or after the word defined, that would be fine too, but tools which parse OEM-defined entries the output of ipmi-sel will need to know the exact record type value. ___ File Attachments: --- Date: Sat 21 Sep 2013 01:40:30 AM GMT Name: oem_sel_type.patch Size: 571B By: rswindell Patch created with quot;svn diffquot; which addresses the issue described. http://savannah.gnu.org/bugs/download.php?file_id=29188 ___ Reply to this item at: http://savannah.gnu.org/bugs/?40076 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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 software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. # bmc-info - Device ID : 1 Device Revision : 0 Device SDRs : unsupported Firmware Revision : 3.00 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : unsupported IPMB Event Receiver : unsupported IPMB Event Generator : unsupported Bridge: unsupported Chassis Device: unsupported Manufacturer ID : Broadcom Corporation (4413) Product ID: 5725 Auxiliary Firmware Revision Information : 0E00h System Firmware Version : V0.29 System Name : x 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 : 1 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 2 Medium Type : System Interface (KCS, SMIC, or BT) Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 3 Medium Type : System Interface (KCS, SMIC, or BT) Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Current behavior: # bmc-info -V bmc-info - 1.4.0 Copyright (C) 2003-2013 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. # bmc-info Device ID : 1 Device Revision : 0 Device SDRs : unsupported Firmware Revision : 3.00 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : unsupported IPMB Event Receiver : unsupported IPMB Event Generator : unsupported Bridge: unsupported Chassis Device: unsupported Manufacturer ID : Broadcom Corporation (4413) Product ID: 5725 Auxiliary Firmware Revision Information : 0E00h ipmi_cmd_get_device_guid: command invalid or unsupported The Get Device GUID command is optional (Table 20-1 in IPMI v2.0) and not supported in all BMCs. -Rob ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
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: Monday, April 29, 2013 1:16 PM To: freeipmi-annou...@gnu.org; freeipmi-us...@gnu.org; freeipmi-devel@gnu.org Subject: [Freeipmi-users] FreeIPMI 1.2.6 Released http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.2.6.tar.gz FreeIPMI 1.2.6 - 04/29/13 - o Support HP Proliant DL160 G8 OEM sensors. o Support Supermicro X9SCM-iiF OEM sensors and events. o Support output of temperature sampling period to ipmi-dcmi. o Clarify error message when SOL session cannot be stolen in ipmiconsole/libipmiconsole. o Fix dcmi rolling average time period output error o Fix ipmi-dcmi output errors with --get-dcmi-sensor-info. o Fix corner case in calculation of confidentiality pad length with AES-CBC-128 encryption. Incorrect pad effects some vendor firmware implementations. o Send IPMI 2.0 packets differently than IPMI 1.5 packets, as the former does not require legacy pad data to be appended to payloads. o Fix Intel OEM SEL buffer overflow. o Fix out of trunk source build. Libraries - o Support new ipmi_rmcpplus_sendto() and ipmi_rmcpplus_recvfrom() functions. o Support new HP Proliant DL160 G8 OEM sensor events. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list freeipmi-us...@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users ___ 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 UTC rather than localtime, violating IPMI 2.0 section 37
I can confirm that the SDR, SEL, and DCMI timestamps are now being interpreted as local time (corresponding to IPMI 2.0 section 37). For example, executed with both managed system and management console at May-9, 7:3x PM: SDR Repository Time : 05/09/2012 - 19:31:26 SEL Time : 05/09/2012 - 19:31:39 978 | May-09-2012 | 19:33:19 | PSU_REDUNDANCY | Power Unit | Non-redundant:Sufficient Resources from Redundant ; Event Data2 = F0h 979 | May-09-2012 | 19:33:19 | System Restart | System Boot Initiated | System Restart ; Chassis Control command 980 | May-09-2012 | 19:33:20 | SYS0_FAN_TACH | Fan | Lower Critical - going low ; Sensor Reading = 1280.00 RPM ; Threshold = 1792.00 RPM Power Statistics for Rolling Average Time Period 0 Seconds Current Power: 252 Watts Minimum Power over sampling duration : 22 watts Maximum Power over sampling duration : 264 watts Average Power over sampling duration : 181 watts Time Stamp : 05/09/2012 - 19:35:00 Statistics reporting time period : 0 milliseconds Power Measurement: Active Recent addition timestamp : 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, violating IPMI 2.0 section 37 Update of bug #38798 (project freeipmi): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?38798 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
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 in _output_date() from sel/ipmi-sel-string.c:675 Follow-up Comment #1, bug #38866 (project freeipmi): Thanks for the catch. Is this occurring regularly for you w/ 1.2.6? Or has it always been around? Just wondering if I need to do an emergency 1.2.7 release. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38866 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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: ipmi-sel Severity: 3 - Normal Priority: 5 - Normal Item Group: Crash Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux ___ Details: call-stack trace: #0 0x7f16d3e18425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f16d3e1bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7f16d3e5639e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x7f16d3eec807 in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x7f16d3eeb700 in __chk_fail () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x7f16d43a52c2 in memset (__len=257, __ch=0, __dest=0x7fff37f97ce0) at /usr/include/x86_64-linux-gnu/bits/string3.h:85 #6 _output_date (wlen=0x7fff37f97cd0, flags=22, buflen=4096, buf=0x7fff37f97eb0 , sel_record_type=optimized out, sel_entry=0x7fff37f97df0, ctx=0x139b1d0) at sel/ipmi-sel-string.c:675 #7 sel_format_record_string (ctx=0x139b1d0, fmt=0x42797e d, sel_record=optimized out, sel_record_len=optimized out, buf=0x7fff37f97eb0 , buflen=4096, flags=22) at sel/ipmi-sel-string.c:3443 #8 0x7f16d439d5cf in ipmi_sel_parse_read_record_string (ctx=0x139b1d0, fmt=0x42797d %d, sel_record=optimized out, sel_record_len=optimized out, buf=optimized out, buflen=optimized out, flags=22) at sel/ipmi-sel.c:2059 #9 0x004057be in _normal_output_date (state_data=0x7fff37f9c0c0, flags=optimized out) at ipmi-sel.c:771 #10 0x00406824 in _normal_output (state_data=0x7fff37f9c0c0, record_type=optimized out) at ipmi-sel.c:1260 #11 0x004072b5 in _sel_parse_callback (ctx=optimized out, callback_data=0x7fff37f9c0c0) at ipmi-sel.c:1622 #12 0x7f16d439ec35 in ipmi_sel_parse (ctx=0x139b1d0, record_id_start=0, record_id_last=65535, callback=0x406f80 _sel_parse_callback, callback_data=0x7fff37f9c0c0) at sel/ipmi-sel.c:1099 #13 0x00405379 in _display_sel_records (state_data=0x7fff37f9c0c0) at ipmi-sel.c:2100 You can't memset (tmpbuf, '\0', SEL_BUFFER_LENGTH + 1) when tmpbuf is only SEL_BUFFER_LENGTH bytes in length. -Rob ___ Reply to this item at: http://savannah.gnu.org/bugs/?38866 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ 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
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 management console 3. UTC 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). -Rob -Original Message- From: freeipmi-devel-bounces+swindell=broadcom@gnu.org [mailto:freeipmi-devel-bounces+swindell=broadcom@gnu.org] On Behalf Of Liebig, Holger Sent: Thursday, April 25, 2013 10:51 PM To: freeipmi-devel@gnu.org Subject: Re: [Freeipmi-devel] [bug #38798] timestamps are interpretted as UT rather than localtime, violating IPMI 2.0 section 37 Al, If this gets fixed (and if possible) could you please include handling of the optional Get SEL Time UTC offset command introduced in Errata 4? This can be used to convert non localtime timestamps back to calendar time and come in handy when a BMC is configured to use a NTP server. From calendar time you can then convert it to localtime or UTC using the appropriate libc functions (localtime_r() and gmtime_r()). And as generic improvement: customers with BMC's around the world might appreciate a command line option to display SEL timestamps in GMT in addition to localtime in order to correlate events to each other. Thanks, Holger 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 Category: ipmi-sel Severity: 3 - Normal Priority: 5 - Normal Item Group: Improper Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Operating System: None ___ Details: IPMI 2.0 section 37 (Timestamp Format) states that all timestamps (e.g. for SDR repository and SEL) are representing local time ... does not include GMT offset., yet ipmi-sel and bmc-device interpret timestamps as though they are based on GMT/UTC and apply the local timezone bias before printing in human-readable form. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38798 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] [bug #38790] Invalid Confidentiality Pad Length value in encrypted RMCP+ packets
I can confirm your patch fixes the problem.
I was able to reproduce the original problem with *any* payload that happened
to be evenly divisible by 16 and was greater than 16 (the AES-128 block size).
This included sending specific lengths of SOL payload data, DCMI asset tag,
DCMI management controller ID string or any *sent* encrypted packet which
happened to result in these special payload sizes.
I was able to reproduce it with your example (DCMI asset tag of 5 characters)
as well as my example (DCMI asset tag of 21 characters) - both work now with
your patch.
Thanks,
-Rob
-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):
Assigned to:None = chu11
___
Follow-up Comment #2:
I was able to reproduce with --set-asset-tag=12313 (not sure why it did not
with your example). I'm surprised this bug lingered so long. I guess most
vendors do not check the pad.
I did a different patch though, and found another location in the code that
needed to be changed. Here's the patch I commited for 1.2.6. I've of course
given credit to you Broadcom in the ChangeLog for finding the bug and the
fix location.
===
--- libfreeipmi/interface/ipmi-rmcpplus-interface.c (revision 9608)
+++ libfreeipmi/interface/ipmi-rmcpplus-interface.c (working copy)
@@ -739,7 +739,7 @@
uint8_t iv[IPMI_CRYPT_AES_CBC_128_IV_LENGTH];
int iv_len;
uint8_t payload_buf[IPMI_MAX_PAYLOAD_LENGTH];
- uint8_t pad_len;
+ uint8_t pad_len, pad_tmp;
int payload_len, cipher_keylen, cipher_blocklen, encrypt_len;
/* Note: Confidentiality Key for AES_CBS_128 is K2 */
@@ -808,7 +808,11 @@
/* Pad the data appropriately */
/* +1 is for the pad length field */
- pad_len = IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH - ((payload_len + 1) %
IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH);
+ pad_tmp = ((payload_len + 1) % IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH);
+ if (pad_tmp)
+pad_len = IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH - pad_tmp;
+ else
+pad_len = 0;
if ((payload_len + pad_len + 1) IPMI_MAX_PAYLOAD_LENGTH)
{
@@ -821,8 +825,8 @@
unsigned int i;
for (i = 0; i pad_len; i++)
payload_buf[payload_len + i] = i + 1;
- payload_buf[payload_len + pad_len] = pad_len;
}
+ payload_buf[payload_len + pad_len] = pad_len;
/* +1 for pad length field */
if ((encrypt_len = crypt_cipher_encrypt (IPMI_CRYPT_CIPHER_AES,
___
Reply to this item at:
http://savannah.gnu.org/bugs/?38790
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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
===
--- bmc-device/bmc-device.c (revision 9608)
+++ bmc-device/bmc-device.c (working copy)
@@ -1274,15 +1274,26 @@
goto cleanup;
}
- /* Posix says individual calls need not clear/set all portions of
- * 'struct tm', thus passing 'struct tm' between functions could
- * have issues. So we need to memset.
- */
- memset (tm, ' ', sizeof(struct tm));
+/* Per IPMI 2.0 section 37.1: */
+#define IPMI_TIMESTAMP_UNSPECIFIED 0x
+#define IPMI_TIMESTAMP_POST_INIT0x2000
+ if (val == IPMI_TIMESTAMP_UNSPECIFIED)
+snprintf (timestr, sizeof (timestr), Unspecified);
+ else if (val = IPMI_TIMESTAMP_POST_INIT)
+snprintf (timestr, sizeof (timestr), %u seconds since initialization,
(unsigned)val);
+ else
+{
+ /* Posix says individual calls need not clear/set all portions of
+ * 'struct tm', thus passing 'struct tm' between functions could
+ * have issues. So we need to memset.
+ */
+ memset (tm, ' ', sizeof(struct tm));
- t = val;
- localtime_r (t, tm);
- strftime (timestr, sizeof (timestr), %m/%d/%Y - %H:%M:%S, tm);
+ t = val;
+ localtime_r (t, tm);
+ strftime (timestr, sizeof (timestr), %m/%d/%Y - %H:%M:%S, tm);
+}
+
pstdout_printf (state_data-pstate,
SEL Time : %sn,
timestr);
___
Reply to this item at:
http://savannah.gnu.org/bugs/?38799
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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: === --- bmc-device.c(revision 9608) +++ bmc-device.c(working copy) @@ -1281,7 +1281,7 @@ memset (tm, ' ', sizeof(struct tm)); t = val; - localtime_r (t, tm); + gmtime_r (t, tm); strftime (timestr, sizeof (timestr), %m/%d/%Y - %H:%M:%S, tm); pstdout_printf (state_data-pstate, SEL Time : %sn, ___ Reply to this item at: http://savannah.gnu.org/bugs/?38798 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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)
+++ libfreeipmi/interface/ipmi-rmcpplus-interface.c (working copy)
@@ -808,7 +808,7 @@
/* Pad the data appropriately */
/* +1 is for the pad length field */
- pad_len = IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH - ((payload_len + 1) %
IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH);
+ pad_len = (IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH - ((payload_len + 1) %
IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH))
(IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH-1);
if ((payload_len + pad_len + 1) IPMI_MAX_PAYLOAD_LENGTH)
{
___
Reply to this item at:
http://savannah.gnu.org/bugs/?38790
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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)
+++ libfreeipmi/api/ipmi-lan-session-common.c (working copy)
@@ -2304,7 +2304,10 @@
do
{
- ret = ipmi_lan_sendto (ctx-io.outofband.sockfd,
+ /* bug #38781 fix:
+ Do not use ipmi_lan_sendto() for RMCP+ packets as the Legacy Pad
byte added by that function
+ is not needed or allowed with IPMI 2.0/RMCP+ */
+ ret = sendto (ctx-io.outofband.sockfd,
pkt,
send_len,
0,
___
Reply to this item at:
http://savannah.gnu.org/bugs/?38781
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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 Apr 2013 04:23:31 AM GMT Category: libfreeipmi Severity: 3 - Normal Priority: 5 - Normal Item Group: Improper Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Operating System: None ___ Details: ipmi-dcmi (v1.2.5) goes into a long request loop (before eventual timeout) when the --get-dcmi-capability-info response for the mandatory platform attributes parameter returns 5 bytes (per Table 6-3 of the DCMI 1.5 spec) and eventually returns the error message: ipmi_cmd_dcmi_get_dcmi_capability_info_mandatory_platform_attributes: session timeout Solution: Update tmpl_cmd_dcmi_get_dcmi_capability_info_mandatory_platform_attributes_rs definition in ipmi-dcmi-cmds-templates.h to include full DCMI 1.5 compliant 5-byte parameter. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38797 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
[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 Category: ipmi-sel Severity: 3 - Normal Priority: 5 - Normal Item Group: Improper Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Operating System: None ___ Details: IPMI 2.0 section 37 (Timestamp Format) states that all timestamps (e.g. for SDR repository and SEL) are representing local time ... does not include GMT offset., yet ipmi-sel and bmc-device interpret timestamps as though they are based on GMT/UTC and apply the local timezone bias before printing in human-readable form. ___ Reply to this item at: http://savannah.gnu.org/bugs/?38798 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
