public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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