-
Alessandro Rubini authored
The code is checking the sequence number of pdelay-rep and pdelay-rep-fup, but we may miss the reply and get the f-up. The result was something like this (first tuple is ok, next is wrong): diag-servo-2-wr1: servo:t3 = 1497279009:22584224:0 diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759 diag-servo-2-wr1: servo:t5 = 1497279009:23564032:0 diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547 diag-servo-2-wr1: ->mdelay = 0:684:306 diag-servo-2-wr1: servo:t3 = 1497279009:663586672:0 diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759 diag-servo-2-wr1: servo:t5 = 1497279009:683142000:0 diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547 diag-servo-2-wr1: ->mdelay = -1:-300579732:306 Here, t4 and t6 are old. The former is the receipt of the request, send back to the "slave" in the pdelay-reply payload; the latter is the receive time of such frame. We now invalidate t4 and t5 when using the tuple. They are the two "remote" times, one sent back in the response and the other sent back in the response-fup. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
223459dd