From cf351d1806b2626ed18b5d132a33236ebdaa5eeb Mon Sep 17 00:00:00 2001 From: Jarrod Johnson Date: Wed, 21 Oct 2015 15:07:38 -0400 Subject: [PATCH] Stop spurious retry on incoming data When data came in from a BMC before acking a recent transmit, pyghmi would pessimistically take that as a cue that the data was missed in transit. However, if the data happens to be on the wire before an ack that is coming, this is a senseless retry. This retry happens typically within a few milliseconds of the original. Fix this by ignoring the non-ACK related data as a cue for doing a retransmit. Change-Id: I871377da0265a5e258baf922252ae86df6c578b0 --- pyghmi/ipmi/console.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/pyghmi/ipmi/console.py b/pyghmi/ipmi/console.py index a580c258..f5bdab24 100644 --- a/pyghmi/ipmi/console.py +++ b/pyghmi/ipmi/console.py @@ -351,9 +351,15 @@ class Console(object): self._sendpendingoutput() if len(self.pendingoutput) > 0: self._sendpendingoutput() - elif self.awaitingack: # session marked us as happy, but we are not - #this does mean that we will occasionally retry a packet - #sooner than retry suggests, but that's no big deal + elif ackseq != 0 and self.awaitingack: + # if an ack packet came in, but did not match what we + # expected, retry our payload now. + # the situation that was triggered was a senseless retry + # when data came in while we xmitted. In theory, a BMC + # should handle a retry correctly, but some do not, so + # try to mitigate by avoiding overeager retries + # occasional retry of a packet + # sooner than timeout suggests is evidently a big deal self.send_payload(payload=self.lastpayload) def main_loop(self):