ID: 355 - Fix compiler warnings for Dummy Interface

Commit fixes compiler warnings for Dummy Interface:
* fix variable name
* remove unused variables

Fix file descriptor leak in ipmi_exec_main() - CID#1149040

ID:355 - Fix ``ISO C forbids omitting the middle term of a ?: expression''

Commit fixes omitted middle terms of ternary expressions.

ID:355 - Fix ``obsolete use of designated initializer with ‘:’'' warning

Commit fixes compiler warning ``obsolete use of designated initializer with
‘:’''. Use of ``fieldname: value'' has been obsol

ID:355 - Fix ``obsolete use of designated initializer with ‘:’'' warning

Commit fixes compiler warning ``obsolete use of designated initializer with
‘:’''. Use of ``fieldname: value'' has been obsolete since GCC 2.5.

show more ...

ID:354 - forcefully switch to C99 and more strict CFLAGS

Commit changes CFLAGS which include C99 and more strict flags. Watch out for
falling rocks.

ID:354 - replace/drop caddr_t in IMB

Commit replaces caddr_t in IMB driver with char *. This is a wild guess
replacement, because caddr_t doesn't have to be char *. However, it shouldn't be
used and

ID:354 - replace/drop caddr_t in IMB

Commit replaces caddr_t in IMB driver with char *. This is a wild guess
replacement, because caddr_t doesn't have to be char *. However, it shouldn't be
used and so shouldn't mmap(). So we'll have to see how things work out.

http://computer-programming-forum.com/47-c-language/556a90938d01f023.htm

show more ...

ID:354 - Replace obsolete u_int[0-9]+_t with standardized types in Free iface

Fix of previous commit - memset() expects pointer

Commit fixes replacement of bzero() with memset(). memset() expects pointer and
pointer should be given to it.

Replace deprecated bzero() with memset()

Commit replaces deprecated bzero() with memset().

ID: 307 - Intel I82751 super pass through mode fixup

The patch adds missing check for the Intel i82751 MAC being in the super
pass-through mode, which has known deviations in RMCP+ from the IPMI
spe

ID: 307 - Intel I82751 super pass through mode fixup

The patch adds missing check for the Intel i82751 MAC being in the super
pass-through mode, which has known deviations in RMCP+ from the IPMI
specification.

show more ...

ID#277 - support for hostnames longer than 64 chars

ID#313 ipmitool doesn't support hostname long than 64 symbols
ID#277 Minor issue with ipmi_intf_session_set_hostname()

Commit adds support pretty

ID#277 - support for hostnames longer than 64 chars

ID#313 ipmitool doesn't support hostname long than 64 symbols
ID#277 Minor issue with ipmi_intf_session_set_hostname()

Commit adds support pretty much for FQDN not just up to the length of one label.
This is achieved by change in in struct ipmi_session; and strdup() of user
input. Of course, we have to free() this once we're done.

show more ...

print message header and data in verbose print

Change-Id: I613e35e180c815279d2a50f44956a5ed5bf5461b
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.xx.bhuvaragan@ericsson.com>

fix incorrect data validation

Change-Id: I6c277b4716445e8ae9a6851cca48e1ad95df49b4
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.xx.bhuvaragan@ericsson.com>

ID: 310 - lanplus retry regression

The lanplus driver for has a bug in ipmi_lanplus_open_session(). There is
an extra and undesired check for a null response (timeout). As a result, it
returns 1 to

ID: 310 - lanplus retry regression

The lanplus driver for has a bug in ipmi_lanplus_open_session(). There is
an extra and undesired check for a null response (timeout). As a result, it
returns 1 to the caller. The result of this is an occasional assertion. Commit
mends this.

Commit for Pat Donlin

show more ...

ID:302 - HPM.2 long message support

This patch adds basic long message support for PICMG-based systems according to
the HPM.2 specification.
It also introduces APIs for setting inbound and outbound

ID:302 - HPM.2 long message support

This patch adds basic long message support for PICMG-based systems according to
the HPM.2 specification.
It also introduces APIs for setting inbound and outbound messages sizes per
selected interface.
This APIs are used in LAN and LAN+ interfaces to set autonomously detected
inbound and outbound message sizes.
The newly introduced APIs also replace the existing message size detection code
in several ipmitool commands in order to leverage the advantages of long message
support (HPM.1 upgrade, SDR acquring, FRU inventory read and write).
The Kontron-specific long message support is moved under a OEM option.

Commit for Dmitry Bazhenov

show more ...

ID: 299 - openipmi plugin writes zero to wrong byte

The intent is to zero the byte that no longer contains valid data (because the
data was shifted one byte to the left). However, the wrong byte is

ID: 299 - openipmi plugin writes zero to wrong byte

The intent is to zero the byte that no longer contains valid data (because the
data was shifted one byte to the left). However, the wrong byte is being zeroed.
One way this shows up is when displaying the descriptions with hpm compprop.

show more ...

ID: 298 - fix LANplus retry

``I had submitted a patch back on Nov 19, 2013 regarding a fix to lanplus retry.
This had resolved a problem whereby a retry of a payload type of
IPMI_PAYLOAD_TYPE_IPMI f

ID: 298 - fix LANplus retry

``I had submitted a patch back on Nov 19, 2013 regarding a fix to lanplus retry.
This had resolved a problem whereby a retry of a payload type of
IPMI_PAYLOAD_TYPE_IPMI first removed the request from the queue before going
back for a retry of the message. I have been able to determine why this fix
works correctly. More importantly I have been able to resolve other retry
problems in lanplus where assertion panics were hitting on certain retry
operations. A new, replacement patch for resolving both of these types of retry
bugs follows.

The first bug,where the ipmi_lanplus_send_payload() is sending a payload type of
IPMI_PAYLOAD_TYPE_IPMI is retryable, however I found in testing that it did not
remove the previous request entry from the list of requests chain. If the
original message had timed out, a second message sent, the second reply would
not match up to the right entry on the list as the req command and sequence
numbers are the same. By first removing the first request from the chain this
resolves it. The consequence of not removing the stale entry was random errors.

The second bug is when waiting for a message response times out during the
ipmi_lanplus_send_payload types IPMI_PAYLOAD_TYPE(s) RCMP_OPEN_REQUEST, RAKP1,
RAKP_3. In various testing where the message timed out on either of these three
payload types, ipmitool would assertion panic upon retry as the session_state
was wrong. The timeout could be due to the message never getting to the BMC, the
BMC never acting/responding to the message, or the reply message packet dropped
(it is UDP after all). If the BMC had acted on the message but the reply was not
received, the BMC state would had advanced, and a retry of any of these three
commands would error. It is not knowable at retry time if the BMC had acted on
the message or not. The solution is upon message timeout failure, retry all
three commands in the sequence. This has shown to be reliable and does not
result in assertions or any unexpected BMC behaviors. Should the original
message response eventually arrive very late, it is just discarded.

The testing for these problems was elusive until we found a moderately slow BMC
and had separate sessions direct a fusillade of nmap operations on the BMC, then
run simple ipmitool commands. This caused sufficient loading of the network and
BMC to cause lengthy delays and outright packet drops. The general approach on
the second fix is to return a timeout error code back through ipmi_lanplus_open
where the sequence can be retried.''

Patch-by: Pat Donlin

show more ...

Move all files one level up in the file hierarcy, to avoid the useless ipmitool directory.