[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.