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
___
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 cannot really
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
while
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, 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
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
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.
-- John.
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, this is
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
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 me,
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: Access
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
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
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 support
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 qemu
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 ftp clients
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
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 the more
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
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
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 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 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
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:
jamasi some
- 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 short
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
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:
jamasi some feature I'm really missing is: a v(S)FTP sever inside the
emulated network
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:
jamasi some feature I'm really missing is: a v(S)FTP sever inside the
emulated network offering a local folder of the host for
28 matches
Mail list logo
