On Tue, Aug 25, 2015 at 4:58 PM, Bin Meng <bmeng...@gmail.com> wrote: > Hi Pavel, > > On Tue, Aug 25, 2015 at 3:12 PM, Pavel Machek <pa...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
