You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The serveACK method in tftpserver.py handles this, but the implementation leaves room for improvement, in fact there is a # TODO comment that it is incomplete.
My quick fix was to edit __next_send in state.py to save the file position before the file is read:
if peer_state.packetnum == num:
# Got the ACK we expected, carry on
pass
elif peer_state.packetnum == num + 1:
# Got another ACK for the previous packet, send it again
peer_state.file.seek(peer_state.last_pos, os.SEEK_SET)
peer_state.packetnum = num
else:
# TODO: handle ACK recovery when operating in streaming mode.
peer_state.state = state.STATE_ERROR
peer_state.error = proto.ERROR_ILLEGAL_OP
l.error('Got ACK with incoherent data packet number. '
'Aborting transfer.',
extra=peer_state.extra(notify.TRANSFER_FAILED))
To understand this a bit better, num is the incoming ACK number and peer_state.packetnum is the last packet number we sent. We expect peer_state.packetnum to equal num in the normal case.
However if we receive the same ACK twice, we want to rewind the file back to the saved last_pos and do another read. The current code simply ignores it and carries on sending the next block even though the client never acknowledged receiving the last one.
I don't know how you are supposed to recover from a bad ACK when a windowsize option has been set, but thankfully my client doesn't set it, so this fix works for me. I also don't know if I handled the wraparound case properly.
@mpetazzoni Could you please consider whether this is a better solution than the current behavior?
I'm fixing up ethernet on a little embedded thing and I noticed this:
The server sends block 10. The client doesn't see it so it sends an ack for block 9 again expecting get block 10 resent
but gets 11 instead.
Packet dumps:
Server output:
The text was updated successfully, but these errors were encountered: