|
From: Daniel M. <dan...@er...> - 2011-11-02 13:11:15
|
Btw, I know that the BLOCK_SIZE option extension can be used to have up to 4.29GB of maximum file size. Nevertheless a 1024 bytes block size is used (limited by the server) and cannot be changed. Thanks BR Daniel ________________________________ From: Daniel Moral [mailto:dan...@er...] Sent: Wednesday, November 02, 2011 2:10 PM To: edk...@li...; efi...@li... Subject: Re: [edk2] MTFTP4 Protocol - Wrapping I will provide more information. I ran a test in which a TFTP client using the MTFTP4 protocol asks to read a file from a TFTP server. This is what happens: -> DATA(#65533) <- ACK(#65533) -> DATA(#65534) <- ACK(#65534) -> DATA(#65535) <- ACK(#0) -> DATA(#65535) -> DATA(#65535) -> DATA(#65535) The ->DATA(#BLOCK_NUMBER) is sent by the TFTP server. The <-ACK(#BLOCK_NUMBER) is sent by a TFTP application using the MTFTP4 driver. The behavior is clearly incorrect because ACK=0 should be only used by the TFTP server (according to TFTP's RFC number 1350). And it should be used only when the client asks for a write request, which is not the case. Any ideas? Thanks ________________________________ From: Daniel Moral [mailto:dan...@er...] Sent: Wednesday, November 02, 2011 1:48 PM To: edk...@li...; efi...@li... Subject: [edk2] MTFTP4 Protocol - Wrapping Hi all, This is a simple question in case you have worked with MTFTP4. This protocol has 2 bytes for the block sequence numbers. Therefore the maximum sequence number is 65535. Some servers, after the block 65535 has been sent, are able to wrap the numbers and start with the block number 0 again. Therefore, there would not be a file limit. My question is, the MTFTP4 protocol has this behavior? Or it does not wrap numbers? (i.e it finishes in seq number 65535 and does not continue) Thanks BR Daniel |