Closed winkmichael closed 6 years ago
I'm surprised it was that easy. 512 is a magic number specified in the original TFTP standard. There's an extension (RFC 2347 and RFC 2348) for overriding it which involves the client requesting a new block size (which it does but my program currently ignores it) and the server acknowledging that. It sending a block less than what was negotiated marks the end of the transfer. In this case, the client should be assuming 512-byte blocks (as my server didn't include the option acknowledgement) and seems to be allowing oversized ones. If the file happened to end on a 512-byte boundary or something it probably wouldn't have gone as well; maybe it wouldn't have ever recognized the end of the file.
That's a long way of saying that I should implement the option negotiation, even though the one-line change worked for you this time.
We ran into the same issue with firmware for the HUHI-F4/N series of DVRs which have a firmware file just over 32MB.
I have a updated version of this server which will do block size negotiation in the works which I will open a PR for in the next little while once its cleaned up. Thanks for making this in the first place! Very helpful to have a tool that works in Linux.
Fixed by mempf's PR. Thanks!
Ran into this with the 5.5 firmware, seems to be a big file!
I was able to fix it by changing
BLOCK_SIZE = 1024