tftp client does not ack if server re-sends same block

[hetul]

Hello,

Has anyone encountered a situation where trying to use tftp client to get a file results in "Unknown transfer ID" after it receives few blocks?  In my scenario, after debugging it came down to server re-sending a block (possible ack timeout due to delay) which resulted in tftp_recv_data function returning bad TID error.

I found a work around to this by adding additional else if statement in tftp_recv_data function(screenshot attached).

Is this a possible bug or am I doing something wrong?

[Carlos_Musich]

Hi Hetul,

TFTP is implemented on the top of UDP/IP protocol. UDP is a non-connection oriented transport protocol, therefore it not acknowledge whether data it is lost or not. This is the normal behavior of the protocol and if you dont get the file you are waiting for you must ask for it again.

If this happens very often you may consider your network settings.

- If network is too fast and the MCU is not able to process all packets it may loss data.

- If there is too much traffic in the network it is possible to have collisions and data would be lost.

As I told before, as TFTP is implemented over UDP there is no acknowledge when data is received or not.

I hope this helps.

Regards,

Carlos

[hetul]

Hello Carlos,

Looking at the RFC, i understand that client has to ack before server would send the next block.  And if timeout occurs on server side before client has ack receive of block, then server re-sends the block. In this case, client has to ack that re-transmitted block to receive next block.  This last part was not done in the tftp client in RTCS.

RFC 1350 - The TFTP Protocol (Revision 2)  Section 2, talks about this.

Best Regards,

Hetul

[Carlos_Musich]

Hi Hetul,

this is now being handled by MQX development team.

Regards,

Carlos