Hi,
I'm encountering a problem when tftp'ing a file of size 1747851 bytes with CONFIG_IP_DEFRAG defined and CONFIG_TFTP_BLOCKSIZE set to 4096. U-Boot's tftp times out on the last chunk. Undefining CONFIG_IP_DEFRAG/CONFIG_TFTP_BLOCKSIZE or downloading with a Linux tftp client are all well, so it does not look like a server problem.
In fact, a file size between 1747845 and 1747851 bytes (incl.) makes the tftp client to timeout. File sizes slightly below or higher than the before mentioned range are fine.
tcpdump trace of the last chunk yielding a timeout:
16:58:32.289427 IP 10.12.48.32.3285 > 10.12.48.10.33088: UDP, length 4 16:58:32.289449 IP 10.12.48.10.33088 > 10.12.48.32.3285: UDP, length 4100 16:58:32.289452 IP 10.12.48.10 > 10.12.48.32: udp 16:58:32.289454 IP 10.12.48.10 > 10.12.48.32: udp 16:58:32.290386 IP 10.12.48.32.3285 > 10.12.48.10.33088: UDP, length 4 16:58:32.290407 IP 10.12.48.10.33088 > 10.12.48.32.3285: UDP, length 2959 16:58:32.290410 IP 10.12.48.10 > 10.12.48.32: udp 16:58:32.290412 IP 10.12.48.10 > 10.12.48.32: udp
The patch below appears to solve my problem. WARNING: since I haven't rolled my mind yet around the NetDefragment IP/UDP stack, I don't know yet what are the side effects of my patch.
--- a/net/net.c 31 Mar 2010 21:54:39 +++ b/net/net.c 4 Jun 2010 15:09:08 @@ -1201,7 +1201,7 @@ static IP_t *__NetDefragment(IP_t *ip, i h = payload + h->next_hole; }
- if (offset8 + (len / 8) <= h - payload) { + if (offset8 + (len / 8) < h - payload) { /* no overlap with holes (dup fragment?) */ return NULL; }
The same problem should exist for NFS fragments. The arch is powerpc, U-Boot version 2010.03 (no fix seen in 2010.06-rc).
Best Regards