[U-Boot] u-boot tftp problem

Joe Hershberger
2015-02-23T23:02:44Z

On Fri, Feb 20, 2015 at 10:51 AM, PF4Public <PF4Public@mail.ru> wrote:
>
> Hello, Nikolay
>
> Now I see, what you mean.
>
> From every dump the requests made by U-Boot are the same. They're as
follows:
> 00:00:00.000310 IP (tos 0x0, ttl 255, id 11267, offset 0, flags [DF],
proto UDP (17), length 66)
> 192.168.100.88.3821 > 192.168.100.254.69: 38 RRQ "uImage" octet
timeout 5 blksize 1468
>
> However the answers from servers are different.
> Linux host answers with 516 byte packets for example:
> 00:00:00.004169 IP (tos 0x0, ttl 64, id 29290, offset 0, flags [DF],
proto UDP (17), length 544)
> 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1
> Whereas Windows host answers conforming to requested block size somewhat:
> 00:00:00.000136 IP (tos 0x0, ttl 128, id 20143, offset 0, flags [none],
proto UDP (17), length 1500)
> 192.168.100.86.63959 > 192.168.100.88.3811: 1472 DATA block 1
>
> Also those configs, which contain "#define CONFIG_TFTP_BLOCKSIZE 4096",
are from completely different boards. As well as neither did I nor it was
by default defined for mine board.
> So I believe that there must be something different with my set up. I
have not yet tried debugging network at U-Boot side, but it is the last
thing, that left to check.

I actually just tested this on sandbox against atftpd server 0.7 in Ubuntu
Linux. Even with IP Fragmentation and 4k block size, u-boot acked every
packet correctly.

Can you provide more exact details on the servers you are trying including
versions? Perhaps also provide pcap files (not text dumps) so the exact
packet contents can be observed?

-Joe