From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dmucf-0003Fn-IT for qemu-devel@nongnu.org; Mon, 27 Jun 2005 10:30:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DmucY-0003CT-ER for qemu-devel@nongnu.org; Mon, 27 Jun 2005 10:29:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DmucX-0003Bx-Om for qemu-devel@nongnu.org; Mon, 27 Jun 2005 10:29:57 -0400 Received: from [64.233.182.203] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DmucS-0002y4-3D for qemu-devel@nongnu.org; Mon, 27 Jun 2005 10:29:52 -0400 Received: by nproxy.gmail.com with SMTP id n15so185786nfc for ; Mon, 27 Jun 2005 07:25:29 -0700 (PDT) Message-ID: <46d6db6605062707256a4e600f@mail.gmail.com> Date: Mon, 27 Jun 2005 16:25:29 +0200 From: Christian MICHON Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [Qemu-devel] interesting tftp experiments Reply-To: Christian MICHON , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, since I was able on a windows host to connect (but no transfer) on a ftp server over slirp, I thought I could do the same: over slirp, connect to a true tftp server, not the layer provided in slirp/tftp.c In order to do so, I had to do minor patches to v0.7.0 - remove reference to tftp in vl.c - remove reference to tftp in slirp/udp.c - remove tftp.o linkage By doing so, I have a ~true~ tftp-over-slirp qemu. I tried it and yes I can READ & WRITE to a small tftp server I found for windows host (http://tftpd32.jounin.net). I still have some problems though. When the read or write command is sent, it apparently somehow jams the slirp channel. The read or write happens, but not immediately (around 2 sec delay).=20 The bad news is that so far, I've manage per session of qemu either one write, or one read. If someone has the knowledge of what could be wrong in this part of slirp, please correct the flaws of what I just found out. At least, we should be able to transfer back and forth files lesser than 32M. --=20 Christian