[Ipmitool-cvs] [SCM] ipmitool branch, master, updated. 51198a17490e5c81f675fee9a4bb042de65a7a96

[Zdenek S. <st...@us...>]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "ipmitool".

The branch, master has been updated
       via  51198a17490e5c81f675fee9a4bb042de65a7a96 (commit)
      from  cc9a6b3964629fef0c3b4a03c4eaed8730fa1550 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 51198a17490e5c81f675fee9a4bb042de65a7a96
Author: Zdenek Styblik <st...@tu...>
Date:   Sun Aug 21 13:16:16 2016 +0200

    ID: 38 - Protocol violating SOL retries when talking to SIMSO-HTC
    
    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.
    ~~~

diff --git a/src/plugins/lanplus/lanplus.c b/src/plugins/lanplus/lanplus.c
index a9ff926..a0e388c 100644
--- a/src/plugins/lanplus/lanplus.c
+++ b/src/plugins/lanplus/lanplus.c
@@ -2369,6 +2369,10 @@ ipmi_lanplus_send_payload(
 
 			rsp = ipmi_lanplus_recv_sol(intf); /* Grab the next packet */
 
+			if (!is_sol_packet(rsp)) {
+				break;
+			}
+
 			if (sol_response_acks_packet(rsp, payload))
 				break;
 
@@ -2381,6 +2385,7 @@ ipmi_lanplus_send_payload(
 				intf->session->sol_data.sol_input_handler(rsp);
 				/* In order to avoid duplicate output, just set data_len to 0 */
 				rsp->data_len = 0;
+				break;
 			}
 		}
 

-----------------------------------------------------------------------

Summary of changes:
 src/plugins/lanplus/lanplus.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)


hooks/post-receive
-- 
ipmitool