When "putting" a file, the atftp 0.7-r1 client fails to correctly handle the block number wrapping from 65536 to 0. Instead of either handling it correctly or aborting, the client just keeps sending data blocks forever (or until an error is returned by the server). The upstream "Homepage" link <ftp://ftp.mamalinux.com/pub/atftp/> in the package database is broken, so one presumes atftp no longer has an "upstream"?
Created attachment 233163 [details, diff] Patch to fix bug that occurs in atftp 0.7-r1 when block number wraps I've tested this using the client for both get and put. Haven't tested server or multicast operation.
Oh, my patch also fixes a compiler warning about ignoring return value of fwrite().
*** Bug 320417 has been marked as a duplicate of this bug. ***
While both of the bugs involve large files, I don't believe that these two bugs are duplicates. The patch submitted for 320417 will not fix the problem reported in this bug. Likewise, the patch I submitted for this bug will not will not fix the problem reported in 320417. The patch for bug 320417 fixes problems with support for large block sizes. This bugs patch fixes problem when block numbers wrapping. The two are orthogonal.
Agreed with Comment #4 From Grant Edwards. I guess that the issue in my case (https://bugs.gentoo.org/show_bug.cgi?id=320417) was driven by following: "If the server is willing to accept the blocksize option, it sends an Option Acknowledgment (OACK) to the client. The specified value must be less than or equal to the value specified by the client. The client must then either use the size specified in the OACK, or send an ERROR packet, with error code 8, to terminate the transfer." Read more: http://www.faqs.org/rfcs/rfc2348.html#ixzz0qp7Y4v31 Also combining these two patches will help me for sure in my case where path MTU is 1500 I believe that tftp client and server should consider proper path MTU in their exchange because: "... if the blocksize exceeds the path MTU, IP fragmentation and reassembly will begin to add more overhead. This will be more noticable the greater the number of gateways in the path." Read more: http://www.faqs.org/rfcs/rfc2348.html#ixzz0qp7tMHvo So it would be great to incorporate path mtu discovery mechanism in atftpd. Or at least use interface MTU less the TFTP, UDP and IP header lengths as blksize hoping that fragmentation and reassembly won't take place.
The fix has been integrated into net-ftp/atftp-0.7-r2. MTU discovery would definitely be a nice thing to have. I think however that it should be solved upstream.
