From: Alessandro Rubini <rubini-list@gnudd.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] net: defragment IP packets
Date: Fri, 31 Jul 2009 17:44:55 +0200 [thread overview]
Message-ID: <20090731154455.GA20564@mail.gnudd.com> (raw)
In-Reply-To: <200907311114.06294.rgetz@blackfin.uclinux.org>
> What I'm talking about is:
> - start a tftp file transfer.
> - CNTR-C it, causing a partial reassembly to done.
> - start a new transfer.
Yes, exactly the case I observed. But you are not guaranteed a partial
reassembly happens, as you should be ctrl-c-ing at the exact right
time.
> All I did was add this to the start of NetLoop() to ensure that
> things are OK.
>
> #ifdef CONFIG_IP_DEFRAG
> memset(pkt_buff, 0, IP_HDR_SIZE_NO_UDP);
> #endif
And the behaviour changed? It's strange, as the new fragments will most
likely (but 1/64k) have a different ID.
>> The old instance of the TFTP server resends the last packet of the
>> aborted xfer,
It sounded strange to me as well, but with atftpd it is what happens.
Earlier I had plain-old tftpd, which didn't even support blksize
option.
Here it is, from PC to PC:
17:28:49.166859 IP morgana.45177 > rudo.32854: UDP, length 516
17:28:49.167030 IP rudo.32854 > morgana.45177: UDP, length 4
17:28:49.167338 IP morgana.45177 > rudo.32854: UDP, length 516
17:28:54.173411 IP morgana.45177 > rudo.32854: UDP, length 516
17:28:59.178620 IP morgana.45177 > rudo.32854: UDP, length 516
17:29:04.183788 IP morgana.45177 > rudo.32854: UDP, length 516
17:29:09.188972 IP morgana.45177 > rudo.32854: UDP, length 516
17:29:14.194160 IP morgana.45177 > rudo.32854: UDP, length 516
atftpd repeats after 5, 10, 15, 20, 25 seconds, and nothing more.
I installed the hpa version just for trying (but I'm getting back to
atftpd, as i don't like the grub-like restriction "only absolute
pathnames").
It behaves similarly:
17:40:42.404539 IP morgana.54278 > rudo.32854: UDP, length 516
17:40:42.404717 IP rudo.32854 > morgana.54278: UDP, length 4
17:40:42.404972 IP morgana.54278 > rudo.32854: UDP, length 516
17:40:43.407340 IP morgana.54278 > rudo.32854: UDP, length 516
17:40:45.409766 IP morgana.54278 > rudo.32854: UDP, length 516
17:40:49.414101 IP morgana.54278 > rudo.32854: UDP, length 516
17:40:57.422814 IP morgana.54278 > rudo.32854: UDP, length 516
17:41:13.439200 IP morgana.54278 > rudo.32854: UDP, length 516
Here it's 1, 3, 7, 16, 31 seconds.
> As a minimal test - since we are only talking about tftp and nfs (so
> far) - if we did not attempt to assemble packets which are not
> coming from the serverip, that might be an OK thing to do...
>
> if (NetReadIP(&ip->ip_src) != NetServerIP)
Yes, I agree.
> All I'm asking for is something robust... :)
Great, thanks
/alessandro
next prev parent reply other threads:[~2009-07-31 15:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 9:02 [U-Boot] [PATCH 0/3] Defragment IP packets Alessandro Rubini
2009-07-30 9:02 ` [U-Boot] [PATCH 1/3] net: defragment " Alessandro Rubini
2009-07-30 9:03 ` [U-Boot] [PATCH 2/3] tftp: get the tftp block size from config file and from the environment Alessandro Rubini
2009-07-30 9:03 ` [U-Boot] [PATCH 3/3] arm nomadik: select defrag and 4k tftp block size Alessandro Rubini
[not found] ` <8124a390e4cbcfee291c7583a585c9d030aadf7a.1248943812.git.rubini @unipv.it>
2009-07-30 9:25 ` [U-Boot] [PATCH 2/3 V2] tftp: get tftpblocksize from cfg file and env Alessandro Rubini
[not found] ` <7b8035d1-8543-4b85-ba00-ac21ff1a60df@lists.denx.de>
2009-07-30 23:15 ` [U-Boot] [PATCH 1/3] net: defragment IP packets Robin Getz
2009-07-31 7:46 ` Alessandro Rubini
2009-07-31 11:50 ` Robin Getz
2009-07-31 12:16 ` Alessandro Rubini
2009-07-31 13:40 ` Robin Getz
2009-07-31 14:02 ` Alessandro Rubini
2009-07-31 15:14 ` Robin Getz
2009-07-31 15:44 ` Alessandro Rubini [this message]
2009-07-31 15:33 ` Robin Getz
2009-08-05 16:59 ` Robin Getz
2009-08-05 17:18 ` Alessandro Rubini
2009-08-05 17:24 ` Ben Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090731154455.GA20564@mail.gnudd.com \
--to=rubini-list@gnudd.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox