> Not a lot yet. I have a minimal ftp server that would be perfect to use
> with qemu, with much of the code rewritten. However, to make it interface
> with slirp a lot more work is needed (basicly the ftp server uses sockets
> while slirp works with tcp/ip packets directly. Thus I have to write a
On Tue, Jun 21, 2005 at 10:39:14PM +0100, Paul Brook wrote:
>
> > Not a lot yet. I have a minimal ftp server that would be perfect to use
> > with qemu, with much of the code rewritten. However, to make it interface
> > with slirp a lot more work is needed (basicly the ftp server uses sockets
> >
On Tue, Jun 21, 2005 at 04:17:08PM +0200, Jan Marten Simons wrote:
> Jim C. Brown wrote:
>
> >I've been convinced. I'll take a look at it and see what can be done for a
> >builtin ftp server.
> >
> Hi Jim,
>
>
> Are there any results, yet?
> I'd like to help with testing this feature, as I canno
Jim C. Brown wrote:
>I've been convinced. I'll take a look at it and see what can be done for a
>builtin ftp server.
>
Hi Jim,
Are there any results, yet?
I'd like to help with testing this feature, as I cannot really help with
coding.
Jan
___
Qemu
On Tue, 14 Jun 2005, Christian MICHON wrote:
how do i do this?
from the windows host or from the linux guest?
Both, and compare them.
any special sw to install/setup?
tcpdump -X on Linux, or ethereal.
On Windows there is a sniffer included in Windows 2000 and later.
Available as a downlo
On Tue, 14 Jun 2005, Jim C. Brown wrote:
Because in active mode, the ftp server attempts to connect to a port on the
ftp client, in the guest. Due to the limitations of slirp, this is not possible
(in theory one could use redir support to work around this, but this is not
an easy task).
slirp
On Mon, Jun 13, 2005 at 02:52:25PM +0200, Christian MICHON wrote:
> > Did you try passive mode?
>
> nice suggestion.
> passive mode off: "dir" lasts forever...
Because in active mode, the ftp server attempts to connect to a port on the
ftp client, in the guest. Due to the limitations of slirp, th
On Mon, 2005-06-13 at 14:52 +0200, Christian MICHON wrote:
> > Did you try passive mode?
>
> nice suggestion.
> passive mode off: "dir" lasts forever...
> passive mode on: "dir" give "connection refused".
>
> any idea?
>
> Christian
>
Suggest some packet sniffs to see who is getting stuck.
--
how do i do this?
from the windows host or from the linux guest?
any special sw to install/setup?
I tried to use a tftp server on the windows host. It's functional,
but the linux guest cannot reach it. I suspect the tftp over slirp
may interfere here.
Christian
On 6/14/05, John R. Hogerhuis <[EM
> Did you try passive mode?
nice suggestion.
passive mode off: "dir" lasts forever...
passive mode on: "dir" give "connection refused".
any idea?
Christian
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qem
On Monday, June 13, 2005, 10:59:40, Christian MICHON wrote:
> I can now connect from the ftp guest (linux inside qemu), but no file
> transfer is possible. Actually, even a "dir" does not work.
Did you try passive mode?
--
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
The bigger th
> 6) Run a FTP daemon on your host, and FTP to this from your guest.
I tried this one, since it looked the easiest.
I installed war-ftpd, which is working well inside the host.
I can now connect from the ftp guest (linux inside qemu), but no file
transfer is possible. Actually, even a "dir" does
On Monday 13 June 2005 01:02, Henrik Nordstrom wrote:
> > If the ftp server ran on its own ip
> > address, then qemu could simply set up new servers on new ports for the
> > new data connections and have the client connect to them.
>
> You already have the router virtual IP address under your (or
On Sat, 11 Jun 2005, Christian MICHON wrote:
I had a look at the code, and can't figure out where the original
tftp command like 'get' and 'put' are parsed inside the tftp.
Apparently, it's just a question of recognising the 'put' cmd,
then open/create a file on the host matching the tftp
argume
On Sat, 11 Jun 2005, Jim C. Brown wrote:
With the user-net port redirection the wrapper can automate the task,
dynamically assigning a port to the FTP server and map this on port 21 of
the router.
Ok this might be slightly useful. Still, any sane client should support using
a non-standard port
On 6/11/05, Jim C. Brown <[EMAIL PROTECTED]> wrote:
> I agree. While I believe this can be worked around (given a cooperative ftpd),
> having a child process for every data connection is really not worth the
> trouble. It's just too ugly. Besides, not every system will have an ftpd
> installed.
si
On Thu, Jun 09, 2005 at 01:56:09PM +0200, Henrik Nordstrom wrote:
> On Wed, 8 Jun 2005, Jim C. Brown wrote:
>
> >Next to impossible to do portably. I am not sure how user-net port
> >redirection
> >even enters the picture - once the FTP daemon is set up, the guest sees
> >the FTP server on the ho
Johannes Schindelin wrote:
>Yes, please! And just for me, could you add a microwave oven, and maybe a
>Ferrari to QEmu also?
>
>Ciao,
>Dscho
>
>
Ok, actually I wouldn't mind if qemu could be used for showing-off or
getting something heated, but to get things straight:
A very simple internal FT
Hi,
On Thu, 9 Jun 2005, Jan Marten Simons wrote:
> > Not quite, but TFTP by protocol design limits filesize to 2^16-1 blocks
> > of 512 bytes or 32 MB minus 512 bytes (33553920 bytes).
>
> Well, if this is the case FTP should realy be added as an alternative
> protocol.
Yes, please! And just for
Hi,
On Thu, 9 Jun 2005, Henrik Nordstrom wrote:
> What I tried to refer to here is that vvfat if supporting writes from the
> host side it must monitor the mapped directory and on each host side
> initiated change of any kind (write to file, addition/removal of file, new
> subdirectory, timestamp
On Wed, 8 Jun 2005, Jim C. Brown wrote:
Next to impossible to do portably. I am not sure how user-net port redirection
even enters the picture - once the FTP daemon is set up, the guest sees
the FTP server on the host (admittedly on a nonstandard port, but is that
such a big deal?).
With the u
On Wed, 8 Jun 2005, Johannes Schindelin wrote:
There is several big issues involved in providing write support
a) On guest writes, the emulation must have a very good understanding of
how the guest writes to the emulated filesystem to allow it to piece
together the block level writes and map th
On Thu, Jun 09, 2005 at 12:31:18AM +0200, Jan Marten Simons wrote:
> > Not quite, but TFTP by protocol design limits filesize to 2^16-1 blocks
> > of 512 bytes or 32 MB minus 512 bytes (33553920 bytes).
>
> Well, if this is the case FTP should realy be added as an alternative
> protocol.
>
> And
> Not quite, but TFTP by protocol design limits filesize to 2^16-1 blocks
> of 512 bytes or 32 MB minus 512 bytes (33553920 bytes).
Well, if this is the case FTP should realy be added as an alternative
protocol.
And the more I think about vvFAT, the more I think it's too complex to get
this worki
On Mon, Jun 06, 2005 at 04:54:25PM -0700, John R. Hogerhuis wrote:
> I can think of some reasons for a non-native file service that is
> instead built into QEMU:
>
>
> -- John.
>
I agree with you there, especially for non-networked OS support. A qemu-specific
guest program will take in a file
On Tue, Jun 07, 2005 at 01:38:14AM +0200, Jan Marten Simons wrote:
> > Like I said, modifying TFTP for R/W would be a good option. It's already
> there,
> > the "miminalists" can't complain about having it removed (e.g. it may
> one day
> > be used to support "virtual" netboots), and one can use ft
On Tue, Jun 07, 2005 at 11:45:40PM +0200, Henrik Nordstrom wrote:
> On Mon, 6 Jun 2005, Jim C. Brown wrote:
>
> >Hmm...what if you don't have root/administrator access? It could still
> >work if
> >you are determined enough, but thats not the sort of thing you want to
> >force
> >onto a beginner
On Wed, 8 Jun 2005, Christian MICHON wrote:
this is the location of my mistake: I did "get w" instead of "get /q/w"
now it works in "get" mode only.
Good.
Is there anywhere a patch to get rw
access to tftp
As already said the TFTP server is currently read-only, however
implementing write
I made some progress based on your suggestions :)
> I don't have any to test on, but the code is extremely simple and not OS
> dependeng in any manner except the small detail that UNIX style paths must
> be used.
>
> Where is the file on the host?
c:\q\w
>
> What tftp argument did you gave to
Hi,
On Wed, 8 Jun 2005, Henrik Nordstrom wrote:
> On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
>
> Updates in the other direction is harder however, unless vvfat is changed
> to emulate a floppy with floppy change notification and the guest has
> support for changing floppy "at random".
The supp
On Wed, 8 Jun 2005, Christian MICHON wrote:
I used 3 ways, either valid with msys or dos shell.
all fail :(
I can ping 10.0.2.2 perfectly, I even tried as administrator inside a dos
prompt.
Good.
the file I'm trying to get inside the guest is barely 58 bytes long
Anyone ever got tftp to wor
On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
For the kind of thing I'm referring to is not usually very time
critical. The resolution is on the order of 15 to 30 minutes to an
hour... some stores get polled for data, the accounting system imports
the data and generates some reports which feed in
I used 3 ways, either valid with msys or dos shell.
all fail :(
I can ping 10.0.2.2 perfectly, I even tried as administrator inside a dos
prompt.
the file I'm trying to get inside the guest is barely 58 bytes long
Anyone ever got tftp to work inside a XP host ?
Christian
> > Error code 2: Acces
On Wed, 2005-06-08 at 00:15 +0200, Henrik Nordstrom wrote:
> On Mon, 6 Jun 2005, John R. Hogerhuis wrote:
>
> > I can think of some reasons for a non-native file service that is
> > instead built into QEMU:
>
> vvfat?
>
> > e) Scripts to be used across farms of QEMU virtual machines will have
>
On Tue, 7 Jun 2005, Christian MICHON wrote:
all these discussions around tftp looked nice and sweet. So I told
myself, instead of using winimage (shareware), why not transferring
files "live".
Yet, when you try on a windows host to exchange files with a linux
guest (inside qemu and with -tftp o
On Mon, 6 Jun 2005, John R. Hogerhuis wrote:
I can think of some reasons for a non-native file service that is
instead built into QEMU:
vvfat?
e) Scripts to be used across farms of QEMU virtual machines will have
more commonalities even across different OSes. The event and content of
a file
On Mon, 6 Jun 2005, Jim C. Brown wrote:
Like I said, modifying TFTP for R/W would be a good option. It's already there,
the "miminalists" can't complain about having it removed (e.g. it may one day
be used to support "virtual" netboots), and one can use ftp clients for the
tftp server (I think).
On Tue, 7 Jun 2005, Jan Marten Simons wrote:
Well the TFTP-server should get r/w, too, but if I get it right you'd have
to access the data on the guest from the host, which might lead to
situation where users shutdown the guest and then try to get their
(then lost) data from it via TFTP, which h
On Mon, 6 Jun 2005, Jim C. Brown wrote:
Hmm...what if you don't have root/administrator access? It could still work if
you are determined enough, but thats not the sort of thing you want to force
onto a beginner.
Then write a suitable wrapper install package around a suitable small FTP
daemon
Hi,
On Tue, 7 Jun 2005, Jan Marten Simons wrote:
> >> - no ide-channel is blocked (unlike vvFat)
> >
> > I don't believe this is a major issue. Alias, vvFat is readonly and
> > anyways not
> > suitable for the purposes of every OS (e.g. copy from Linux guest to Linux
> > host, preserving ownershi
all these discussions around tftp looked nice and sweet. So I told
myself, instead of using winimage (shareware), why not transferring
files "live".
Yet, when you try on a windows host to exchange files with a linux
guest (inside qemu and with -tftp option), all you get is:
Error code 2: Access v
I can think of some reasons for a non-native file service that is
instead built into QEMU:
a) One interface to all clients outside of QEMU. Lowers the learning
curve for dealing with different enviroments; at least for some raw file
access they are all accessible in the same way. You can lower
con
>> - no ide-channel is blocked (unlike vvFat)
>
> I don't believe this is a major issue. Alias, vvFat is readonly and
> anyways not
> suitable for the purposes of every OS (e.g. copy from Linux guest to Linux
> host, preserving ownership).
Well for the current project I'm working on, I'm running s
On Mon, Jun 06, 2005 at 08:11:08PM +0200, [EMAIL PROTECTED] wrote:
> The advantages are:
> - no ide-channel is blocked (unlike vvFat)
I don't believe this is a major issue. Alias, vvFat is readonly and anyways not
suitable for the purposes of every OS (e.g. copy from Linux guest to Linux
host, pre
> On Fri, 3 Jun 2005, Jan Marten Simons wrote:
>
>> Ok, I talked about this issue in irc lately, but as this list will have
>> a larger audience I'll post this here as well. So here is the (cleaned)
>> log:
>>
>> What I want:
>>
>> some feature I'm really missing is: a v(S)FTP sever inside the
>>
On Sun, Jun 05, 2005 at 09:17:45PM +0200, Henrik Nordstrom wrote:
> On Fri, 3 Jun 2005, Jan Marten Simons wrote:
>
> >Ok, I talked about this issue in irc lately, but as this list will have
> >a larger audience I'll post this here as well. So here is the (cleaned)
> >log:
> >
> >What I want:
> >
On Fri, 3 Jun 2005, Jan Marten Simons wrote:
Ok, I talked about this issue in irc lately, but as this list will have
a larger audience I'll post this here as well. So here is the (cleaned) log:
What I want:
some feature I'm really missing is: a v(S)FTP sever inside the
emulated network offeri
Ok, I talked about this issue in irc lately, but as this list will have
a larger audience I'll post this here as well. So here is the (cleaned) log:
What I want:
some feature I'm really missing is: a v(S)FTP sever inside the
emulated network offering a local folder of the host for R/W-access.
48 matches
Mail list logo
