On Tue, Aug 25, 2015 at 4:58 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Pavel,
On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek pavel@denx.de wrote:
On Tue 2015-08-25 10:25:35, Bin Meng wrote:
Hi,
With latest u-boot/master, TFTP is seriously broken.
Sorry about that.
=> tftp 100000 bzImage Speed: 100, full duplex Using pch_gbe device TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending through gateway 10.10.0.1 Filename 'bzImage'. Load address: 0x100000 Loading: T TFTP error: 'Unsupported option(s) requested' (8) Starting again
git bisect shows the following commit broke the TFTP
I was not intentionally changing the packets being sent.
Could you try to capture tcpdump, including contents of packet, ideally in both working and broken sessions?
Yep, I will do that. I also tested a tftpd Windows server (http://tftpd32.jounin.net) and it looks that this Windows server is immune to this commit.
Could you try setting
-#define TIMEOUT 5000UL +#define TIMEOUT 100UL
in net/tftp.c to something like 1000UL?
Could you please elaborate more on what this commit is trying to fix, or improve? From the commit message, I don't quite understand "With 5 seconds timeout, 10 retries maximum, tftp is impossible even on local network with single full-speed TCP connection".
OK, I am now pretty sure this commit should be reverted. This commit is a spec violation to RFC 2349 in which it defines the timeout minimum value should be 1.
With this commit change, we set timeout to 100ms which creates a wrong option timeout value = 0, when sending tftp read request to the server. The Linux xinitd server strictly follows the RFC and reports 'Unsupported option(s) requested' (8) while the Windows server is quite forgiving.
Regards, Bin