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