When I enable 'blksize' and 'tsize' option below tftpd(!!!) tftp is not possible to send or download a file to a debian 5.0.4 system tftpd version 0.17-16. Errormessage: the blocksize is wrong. But even when I set it to 512 with -b, it is not working. When I compile it without this option it works.
I just tested it against the tftp server tftpd32 on windows and I got the same result: it is not working :(
When I check it with a network sniffer, it looks like that tftp receives the last acknowledge but does not terminate. After a timeout the tftpserver sends an additional ACK for packet 0. tftp answers with an error code. So the question is: why tftp did not finish after the last ACK?
Oh, not tftp answers with the errorcode, the tftpserver send this to the tftp program. Something else: I found always 2 write requests at beginning. Maybe the timeout for receiving the ACK is to short.
Hi, I have to say sorry !!! The tftp program works. But the errormessage "server only supports blocksize of 512" had confused me. I thought the transmission failed. But it was done correct. It would be better todo it like this: if(blksize != TFTP_BLKSIZE_DEFAULT) bb_error_msg("falling back to default blocksize"); Or something like that. So the message appears only when I used the -b option, and it sounds not that the transmission failed. Regarding to the 3rd and 4th reply: This happens only because that tftp sends to requests at start when connecting to a tftpd32 server. tftpd32 sends an error packet, because no further requests for thefirst request appears. To solve this I increased the constant TFTP_TIMEOUT_MS from 50 to 100. I read inside rfc1350 and there is not defined how long the timeout should be. So I think it is not a fault to increase it to 100. Best regards and again sorry for the trouble.
I am applying if (blksize != TFTP_BLKSIZE_DEFAULT) bb_error_msg("falling back to blocksize "TFTP_BLKSIZE_DEFAULT_STR); thing to git, thanks! Does TFTP_TIMEOUT_MS = 50 and resulting duplicate packets pose any practical problem?
Hi Denys, without a longer timeout, I got the following with tftpd32: Connection received from 192.168.18.202 on port 46297 [17/06 08:55:10.578] Read request for file <Interface>. Mode octet [17/06 08:55:10.578] Using local port 1352 [17/06 08:55:10.578] Warning : received duplicated request from 192.168.18.202:46297 [17/06 08:55:10.625] <Interface>: sent 7 blks, 3408 bytes in 0 s. 0 blk resent [17/06 08:55:10.640] Connection received from 192.168.18.202 on port 46297 [17/06 08:55:10.875] Read request for file <Interface>. Mode octet [17/06 08:55:10.875] Using local port 1353 [17/06 08:55:10.875] File <Interface> : error 10054 in system call recv Eine vorhandene Verbindung wurde vom Remotehost geschlossen. [17/06 08:55:10.937] The file is transmitted, so in general it works also with 50ms timeout. But since the timeout only occurs, when a 'fault' happens, an increase to 100ms doesn't influence the work with other tftp servers. They respond in the same time like before :) So why not 100ms?
Ok, bumped up to 100 ms. Closing