Make code better readable by replacing `if (rsp->ccode > 0)`
and 'if (rsp->ccode != 0)' with just `if (rsp->ccode)` as
rsp->ccode is anyway an unsigned byte and can't be negative.
Also replace 'if (rsp->ccode == 0)' with 'if (!rsp->ccode)'.
All these changes make lines shorter and easier to read as
a non-zero ccode is an indication of some failure, and so !ccode
naturally reads as 'no error'.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Get rid of lanplus-specific yet very generic in nature
lanplus_swap() function that unconditionally swaps bytes
in an arbitrary byte array. Move it to helper module and
add two conditionally working interfaces to it:
- array_ntoh() for network (BE) to host conversion, and
- array_letoh() for ipmi (LE) to host conversion.
The added functions will only perform byte swapping if
the target architecture differs in endianness from the
data source. array_ntoh() will only do swap on LE machines,
while array_letoh() will only do it on BE ones.
These functions are introduced for future use in other
places of ipmitool.
Partially resolvesipmitool/ipmitool#26
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
There are lots of feature test macros like _POSIX_SOURCE,
_BSD_SOURCE, etc. chaotically placed at the beginning of
multiple files without apparent reason, sometime purely
erroneously.
This commit removes them all for the sake of cleaner code.
No new warnings are added due to that at least for gcc 5.4
on Linux with glibc 2.23.
c&p from the ticket:
~~~
When I try to use CVS-ipmitool on Ubuntu 8.04 x86_64 to talk to a SuperMicros
SIMSO-HTC (Rev. 2.5, IPMI 2.0) chip on a X7SBi-Board via SOL I often get doubled
characters when typing fast, making the SOL interface basically unusable for
anyone accustomed to using a keyboard for longer than a month ;)
At first I thought this was an issue with SuperMicros implementation of the
protocol and/or the flow control
setup on the machine, but their own app works fine (but not the Linux CLI, which
is maybe
based on ipmitool?). But after reading the IPMI 2.0 SOL specs and watching the
debug output for a bit, it seems that is really an issue with lanplus-SOL
protocol implentation of ipmitool in general.
Specifically, in lanplus.c:ipmi_lanplus_send_payload, when waiting for a SOL
response the case that a non SOL packet is returned is not being
checked. Also the "if (is_sol_packet(rsp) && rsp->data_len)" branch does
terminate with a break, but instead goes for a send try, that seems
counterintuitive, Both these things cause doubled characters for me.
The attached patch seems to solve these issues in my case, but I don't claim to
fully understand your protocol code and/or the protocol, so maybe it will cause
problems elsewhere, especially under packet loss conditions.
~~~
Commit adds support for cipher suites 6/7/8 (HMAC-MD5) and cipher
suites 15/16/17 (HMAC_SHA256).
This also fixes:
* ID:442 - IPMI_AUTH_RAKP_HMAC_MD5 support in lanplus
* ID:141 - RMCP+ Cipher-suite 17 not supported
Original author Liebig Holger(Fujitsu).
Code cleanup done by Florian Breu and Zdenek Styblik.
Move the logic that checks the session ID from read_session_data_v2x
function to the ipmi_lan_poll_single function in order to avoid calling
assert in this case. We can continue with the next packet if we detect
a session ID mismatch.
Signed-off-by: Boris Ranto <branto@redhat.com>
Boards equipped with 'dumb' Intel MAC can do only SOL. IPMITool performs
several autodetection requests before initiating SOL, which are not
recognized by the boards. With each request retried 5 times it takes
about 30 seconds to establish SOL. This patch resolves the problem.
Request/response matching for bridged and double-bridged requests is broken.
This patch reworks the sending and command construction code, and fixes the
response matching problems.
Since the polling code is retried several times, it was moved into a separate
function in order to make the code more readable.
Commit for: Dmitry Bazhenov
When closing, LAN and LAN+ interfaces do not do proper cleaning of request
entries. Some pointers remain non NULL. This may cause bad memory references.
Commit for: Dmitry Bazhenov
Currently, interface-management code in the ipmitool does not allow safe
interface re-opening (i.e. closing and opening again). It is because the session
is allocated in the interface setup callback while is freed in the close
callback. So, normal re-opening of the interface, which can be required for
example durng the HPM.1 upgrade, leads to segmentation fault. That's why in the
ipmi_hpmfwupg.c instead of normal closing interface, directly access the
interface data for subsequent re-opening.
Commit for Dmitry Bazhenov
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.
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.
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
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
``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
