Re: [PATCH] TFTP client's bad behaviour when unexpected blockisreceived and not optimal timeouts
Date: Fri, 07 Oct 2011 12:32:27 +0200
On Wed, 5 Oct 2011, Daniel Stenberg <daniel_at_haxx.se> wrote:
> I'd suggest something similar to what we've done several times for other
> protocols: we add commands within the <servercmd> tag (see tests/FILEFORMAT)
> and then we make the tftpd server read those for each test. We then introduce
> commands that will cause the server to behave as we want.
> The tests/server/tftpd.c:validate_access() function already reads the <reply>
> tag so it would be easy to make it read another tag for these custom commands.
> See for example the tests 271 283 284 285 and 286 for existing TFTP tests.
I'll do my best to prepare test case, but at the minute I don't have time for this.
Anyway my colleague pointed that my suggestion was not 100% compliant with RFC:
> I suggest following solution. If we are waiting for block X and receive block Y:
> - Y < X we should send ACK and not increase retry counter
> - Y > X we should not increase retry counter
> - Y == X we should send ACK and increase X (which is already implemented)
He pointed that we can send/retransmit ACK only for the last expected block that we received. So I can rewrite suggestion in following way.
If we are waiting for block X and receive block Y that is the expected one, we should send ACK and increase X (which is already implemented). Otherwise drop the packet and don't increase retry counter.
According to this, I am attaching a new version of patch. Hopefully last one :)
- unknown/unknown attachment: tftp.patch.3