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

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

[Richard Neill]

> 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
>    root@localhost, 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 root@localhost
> 
>   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.


---------------


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?

2)Fix it...   :-)

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.

I suspect that I am not up to the task of (2), so I must defer to the 
experts...

Best wishes,

Richard

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

[Mark Jonckheere]

Richard Neill schreef:

>> 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
>>    root@localhost, 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 root@localhost
>> 
>>   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.
> 
> 
> ---------------
> 
> 
> 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?
> 
> 2)Fix it...   :-)
> 
> 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.

4)lookup the mailing list archive and find out that this problem
has already been detected, diagnosed, resolved and completely ignored
more than a year ago.

http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00188.html

I still patch every new download from CVS with my personal patchfile:

----8<----------------------------------------------------
diff -ur qemu/slirp/misc.c qemu-patched/slirp/misc.c
--- qemu/slirp/misc.c   Mon Sep  6 01:10:26 2004
+++ qemu-patched/slirp/misc.c   Wed Sep  8 16:12:14 2004
@@ -90,13 +90,12 @@
        char buff[256];
        struct hostent *he;

 
-       if (gethostname(buff,256) < 0)
-          return;
-
-       if ((he = gethostbyname(buff)) == NULL)
-          return;
-
-       our_addr = *(struct in_addr *)he->h_addr;
+       if (gethostname(buff,256) == 0)
+               if ((he = gethostbyname(buff)) != NULL)
+                       our_addr = *(struct in_addr *)he->h_addr;
+
+       if (our_addr.s_addr == 0 || our_addr.s_addr == loopback_addr.s_addr)
+               our_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
 }

 
 #if SIZEOF_CHAR_P == 8
diff -ur qemu/slirp/slirp.c qemu-patched/slirp/slirp.c
--- qemu/slirp/slirp.c  Mon Sep  6 01:10:26 2004
+++ qemu-patched/slirp/slirp.c  Wed Sep  8 16:13:00 2004
@@ -144,7 +144,6 @@
     m_init();

 
     /* set default addresses */
-    getouraddr();
     inet_aton("127.0.0.1", &loopback_addr);

 
     if (get_dns_addr(&dns_addr) < 0) {
@@ -153,6 +152,7 @@
     }

 
     inet_aton(CTL_SPECIAL, &special_addr);
+    getouraddr();
 }

 
 #define CONN_CANFSEND(so) (((so)->so_state & 
(SS_FCANTSENDMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
diff -ur qemu/slirp/udp.c qemu-patched/slirp/udp.c
--- qemu/slirp/udp.c    Tue Aug 24 23:57:12 2004
+++ qemu-patched/slirp/udp.c    Mon Sep  6 10:44:11 2004
@@ -314,6 +314,8 @@
     saddr = *addr;
     if ((so->so_faddr.s_addr & htonl(0xffffff00)) == special_addr.s_addr)
         saddr.sin_addr.s_addr = so->so_faddr.s_addr;
+    if ((so->so_faddr.s_addr & htonl(0x000000ff)) == htonl(0xff))
+        saddr.sin_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
     daddr.sin_addr = so->so_laddr;
     daddr.sin_port = so->so_lport;
     
----8<----------------------------------------------------

The patch in misc.c and slirp.c corrects your problem, the patch in udp.c
corrects the problem that UDP replies IP-broadcasts with the IP-broadcast
address instead of its own.

greetings,
Mark.

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

[Jim C. Brown]

On Wed, Nov 23, 2005 at 08:33:06AM +0000, Mark Jonckheere wrote:
> Richard Neill schreef:
> 
> 4)lookup the mailing list archive and find out that this problem
> has already been detected, diagnosed, resolved and completely ignored
> more than a year ago.
> 

And sadly, it seems it is being ignored once again. (I didn't actually get that
email back in Sept 2004. It is possible that it might have missed Fabrice as
well.)

Fabrice really should commit this to CVS.

--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Ben Taylor]

Richard Neill <rn214@hermes.cam.ac.uk> 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
> >    root@localhost, 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 root@localhost
> > 
> >   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