All of lore.kernel.org
 help / color / mirror / Atom feed
From: Magnus Damm <magnus.damm@gmail.com>
To: qemu-devel@nongnu.org
Cc: Cedric.Roux@eurecom.fr
Subject: Re: [Qemu-devel] one bug and one suggestion
Date: Tue, 12 Apr 2005 11:40:13 +0200	[thread overview]
Message-ID: <aec7e5c305041202404b5e7679@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0504111624360.22286-100000@perignan.eurecom.fr>

Cedric, All,

On 4/11/05, Cedric Roux <Cedric.Roux@eurecom.fr> wrote:
> Dear Qemu people,
> 
> there is a bug in slirp/udp.c for tftp handling.
> You do:
>         if (ntohs(uh->uh_dport) == TFTP_SERVER) {
>             tftp_input(m);
>             goto bad;
>         }
> You don't test if the destination is the emulator
> or the outside world. So, if I want to connect to another
> computer running a tftp server, qemu will instead take
> the hand.
> This bug exists while using -user-net. Don't know for
> tun/tap, I am not root here.

Yes, you are correct what I can tell. I thought that only data for the
emulated server went through that path so I copied the BOOTP code, but
I now realize that the BOOTP case handles broadcast data. Care to make
a patch?

> Now, for a suggestion.
> There is the -tftp option. It would be a good idea
> to add some option like -tftp-relative-names or something
> like that so that the client can ask for a file /foo/bar.dummy
> and get access to this file under the tftp directory.
> 
> To be clear: you run qemu -tftp /tftp/directory/something
> and the client inside qemu asks for /foo/bar.dummy, but
> effectively accesses /tftp/directory/something/foo/bar.dummy.
> The client does not have to ask for
> /tftp/directory/something/foo/bar.dummy
> Get the point?
> It seems more natural to me. What do you think?

I agree it is more natural. But I was lazy and I wanted to keep it
simple. And there are several limitations that comes with TFTP such as
limited file size, no directory listing and so on so I would like to
keep the TFTP server as simple as possible, ie read only. I hope that
someone will hack together a webdav or FTP server that makes it easy
to transfer files for normal users too.

Thanks,

/ magnus

      reply	other threads:[~2005-04-12  9:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-11 14:33 [Qemu-devel] one bug and one suggestion Cedric Roux
2005-04-12  9:40 ` Magnus Damm [this message]

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=aec7e5c305041202404b5e7679@mail.gmail.com \
    --to=magnus.damm@gmail.com \
    --cc=Cedric.Roux@eurecom.fr \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.