qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: user-net -redir working? [problem located]


From: Ben Taylor
Subject: Re: [Qemu-devel] Re: user-net -redir working? [problem located]
Date: Wed, 23 Nov 2005 11:10:19 -0500

Richard Neill <address@hidden> wrote:
> 
> > Re: User-net not working:
> > 
> > > Disabling the Nagle algorithm (i.e., enabling TCP_NODELAY) or typing a
> > > lot of garbage just to fill the buffer with enough data can help,
> > > also.
> > > 
> > > And IIRC, netcat has a UDP mode as well. I see no reason for this to
> > > happen, but is there any chance it's using UDP by default, and you're
> > > only redirecting TCP?
> > > 
> > > Good luck!
> > 
> > Thanks for your message.
> > 
> > I think that -redir really is broken: I've also been unsuccessful in 
> > trying to make it work using an FTP server on a Windows guest, and using 
> > the SSH server on a knoppix guest. Has anyone here ever had success with 
> > it? It also fails on hosts with 2 different versions of Mandrake.
> > 
> > Anyway, I've taken your suggestion, and run both ends with ethereal. 
> > Here's what I did:
> > 
> > 
> > HOST (Linux);
> >    qemu -cdrom /dev/cdrom -boot d -user-net -redir tcp:2200::22
> > 
> > GUEST (Knoppix):
> >    Boot up, then start sshd. Verify that I can indeed do ssh
> >    address@hidden, and that PermitRootLogin is yes in sshd_config.
> > 
> >     Then, start ethereal (on the "any" interface)
> > 
> > 
> > HOST:
> >    Start ethereal (on the "any" interface")
> >    ssh -p 2200 address@hidden
> > 
> >   At this point, ssh just stalls. It's obviously waiting for something,
> >   but not known what. I get no output at all from it.
> 
> 
> Can you try "ssh -p 2200 root@<my IP address not localhost>
> 
> I've run into this several times dealing with the -redir
> function, especially since localhost resolves as 127.0.0.1.
> On my Solaris host with a linux guest, the packet arriving
> showed up as 127.0.0.1, which ended up with the same
> behavior as you're describing.

on my solaris host, the problem was that the host name
was aliased to 127.0.0.1 as I use some software which 
automagically punts the interface to something like
hostname-<interface>.  So when it does a lookup for
the host name, and it gets 127.0.0.1, it then all falls
apart.  I'm not sure how you can code around this 
particular problem.  For those who say that the hostname
shouldn't point to 127.0.0.1, that's fine. However, for
my laptop, I'm constantly switching networks, and the 
software I use for that does it better than anything else
I've ever used. (Especially for Solaris)

> 
> ---------------
> 
> 
> Dear Ben,
> 
> Good guess! That's an ingenious bit of debugging, and it now works 
> perfectly. I suppose that now means 3 things need to be done:
> 
> 1)Figure out *why* it doesn't work. It's definitely QEMU-specific, since 
> if I run 2 separate netcat processes on the host, I have no problem. I'd 
> be interested to know why this occurs. In particular, is it a problem 
> with the user-net stuff on the host, or a problem with the guest?

Most likely there is some issue with the slirp code dealing
with the localhost construct.  I suspect that the slirp
code needs to be rewriting anything  that has a source
destination of 127.0.0.1 and map it some way.  

> 2)Fix it...   :-)

I haven't touched the code in a couple of months. Been
pretty distracted with other stuff these days.

> 
> 3)Document this on the website as a known bug, so Google can find it. 
> Currently, anyone using an earlier version will just think that qemu is 
> broken. It hasn't worked since at least 0.6.1, although I can't tell you 
> about earlier versions.

It should be google-able.  At least I remember posting to
the list about 8 months ago on this exact issue, and then
posted how I fixed it.  (IIRC).
 
> I suspect that I am not up to the task of (2), so I must defer to the 
> experts...

Yep. Probably need someone familiar with the slirp stack.

Ben





reply via email to

[Prev in Thread] Current Thread [Next in Thread]