[Qemu-devel] qemu tun networking bug

[Qemu-devel] qemu tun networking bug

[Vitaly Belostotsky]

Dear QEMU developers!

This is my first post to this list so please don't be very angry
if I'm doing something wrong.

I've encountered some network related bug when using qemu with tun
and I'm willing to debug it but could you please provide some help.

The bug isn't new, I believe it's described in debian bug tracking system (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290569)
but I've found the conditions when it's easily reproducable.
It occurs when using tun (user mode networking is reportedly fine).

After sending packets for some time to the virtual host the network stalls.
This isn't fatal, the emulator remains responsive and even the network traffic 
can be resumed by sending some packets in the opposite direction,
for instance running tcpdump on the emulated host over ssh is enough.

How to reproduce the bug: boot the emulator with some low network usage system
(I use damnsmalllinux cd: qemu -boot -d -cdrom xxx),
open udp port 9 (for DSL: /etc/init.d/inetd start)
and start sending udp packets from outside (I use: tcpblast -d 100 vhost 9999).
It stalls usually in the very beginning of the first run.

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

I tried to debug it a bit and discovered that in such a situation
the poll() in vl.c/main_loop_wait() goes on being called
and usually returns with the value -1 (EINTR) or 0 less frequently but steadily.
The tun fd is included into the poll set (max_size > 0, several lines above poll()).
So to my mind tun fd keeps being polled but no data detected.
According to kernel source drivers/net/tun.c poll() uses
>    if (skb_queue_len(&tun->readq))
>	    mask |= POLLIN | POLLRDNORM;
and the buffer should be full due to udp sent, but I don't know for sure.

I also tried to run tcpdump on both sides of a link with more or less obvious results.

Could you please give me some clue for further debugging or confirm the bug presence
or any other help would be highly appreciated.

My configuration:
  qemu: I started from debian qemu-0.7.0-2 and then used pristine qemu-0.7.0 sources, i386-softmmu
  host: ubuntu hoary, linux kernel 2.6.10, i386
  target system: the same ubuntu or DSL-1.2.1 (kernels 2.6 and 2.4)

Re: [Qemu-devel] qemu tun networking bug

[Henrik Nordstrom]

On Tue, 12 Jul 2005, Vitaly Belostotsky wrote:

> I've encountered some network related bug when using qemu with tun
> and I'm willing to debug it but could you please provide some help.

you may want to try upgrading to the host kernel to 2.6.12. Had quite a 
bit of issues with tun devices "hanging" in earlier Linux-2.6 versions, 
but after I switched to a Fedora Core 4 host running Linux-2.6.12 things 
seems much more stable.

My diagnostics at the time indicated some flow control problem within the 
host kernle tun driver, making the driver stall and not deliver packets to 
the application (qemu). Your findings seems to indicate very similar 
result.

Regards
Henrik

Re: [Qemu-devel] qemu tun networking bug

[Vitaly Belostotsky]

Thank you very much, Henrik,

based on your reply I've found the relevant linux kernel TUN/TAP problem description
in http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.11-rc2
and was able to workaround the problem in my case with the small patch:

--- qemu-0.7.0/vl.c.orig        2005-04-28 00:52:05.000000000 +0400
+++ qemu-0.7.0/vl.c     2005-07-12 13:14:11.583204352 +0400
@@ -1622,7 +1622,7 @@
         return -1;
     }
     memset(&ifr, 0, sizeof(ifr));
-    ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
+    ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE;
     pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
     ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
     if (ret != 0) {

May be the problem deserves mentioning in some qemu docs?

Regards
Vitaly

On Tue, Jul 12, 2005 at 03:09:43AM +0200, Henrik Nordstrom wrote:
> On Tue, 12 Jul 2005, Vitaly Belostotsky wrote:
> 
> >I've encountered some network related bug when using qemu with tun
> >and I'm willing to debug it but could you please provide some help.
> 
> you may want to try upgrading to the host kernel to 2.6.12. Had quite a 
> bit of issues with tun devices "hanging" in earlier Linux-2.6 versions, 
> but after I switched to a Fedora Core 4 host running Linux-2.6.12 things 
> seems much more stable.
> 
> My diagnostics at the time indicated some flow control problem within the 
> host kernle tun driver, making the driver stall and not deliver packets to 
> the application (qemu). Your findings seems to indicate very similar 
> result.
> 
> Regards
> Henrik
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel