| Summary: | tftp is not working with tftpd 0.17-16 on debian 5.04 with size protocoll enabled | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | busybox.user |
| Component: | Networking | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.16.x | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
busybox.user
2010-06-10 10:50:56 UTC
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 |