netdev - Re: [Qemu-devel] tap devices not receiving packets from a bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 May 2013 15:21:24 +0100
From:	Nicholas Thomas <nick@...emark.co.uk>
To:	Peter Lieven <pl@...net.de>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	Stefan Hajnoczi <stefanha@...il.com>, qemu-devel@...gnu.org,
	netdev@...r.kernel.org
Subject: Re: [Qemu-devel] tap devices not receiving packets from a bridge

Hi all,

On Tue, 2013-02-12 at 08:06 +0100, Peter Lieven wrote:
> On 23.01.2013 11:03, Michael S. Tsirkin wrote:
> > For future, we can try to set TUN_ONE_QUEUE flag on the interface,
> > or try applying this patch
> > 5d097109257c03a71845729f8db6b5770c4bbedc
> > in kernel see if this helps.
> >
> 
> If have set this option for 2 weeks now and not seen this problem again.
> How does this flag work with the recently added tap multiqueue support?
> 
> Peter

( Host systems are Linux kernel 3.2, from debian squeeze-backports, in
all cases. The guests use virtio-net, the hosts use netxen_nic )

We run QEMU like: 

qemu-system-x86_64 -enable-kvm -[...] \
  -net user,vlan=50,name=user,restrict=y
  -net nic,macaddr=fe:ff:00:00:00:00,name=t100,model=virtio,vlan=748
  -net tap,downscript=no,name=t100,script=no,vlan=748,ifname=t100 [...]

The TAP devices are created by us, by calling the appropriate ioctls,
more or less like:
fd = open("/dev/net/tun", "a+")
ioctl(fd, TUNSETIFF, "t100", IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE )
ioctl(fd, TUNSETOWNER, "t100", 20000)
ioctl(fd, TUNSETGROUP, "t100", 108)
ioctl(fd, SIOCSIFHWADDR, "t100", ARPHRD_ETHER, "fe:ff:00:00:00:00")
ioctl(fd, TUNSETPERSIST, "t100", 1)

(I'm translating ruby code here, but that's the gist of it)

We used to run QEMU 0.15.0, and didn't set IFF_ONE_QUEUE on the tap
devices we created. We never saw this bug. Last week, we began upgrading
to QEMU 1.4.1; our imager setup (netboot, download a large disc image
over HTTP, run a script in it) immediately began triggering this bug,
quite reliably. 

We changed our code to set IFF_ONE_QUEUE on the tap devices we created,
and this has reduced the frequency with which the bug is triggered, but
we still experience it from time to time. Over 5 trials, I triggered the
bug three times.

Interestingly, while the guest fails to receive packets, no TX overruns
to the tap device are initially reported on the host (by ifconfig). The
overrun counter ticks to 1 after I ping the guest a few times, like so:

Before:

t100      Link encap:Ethernet  HWaddr ae:17:96:7d:32:3f  
          inet6 addr: fe80::ac17:96ff:fe7d:323f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:58006 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57992 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:3825467 (3.6 MiB)  TX bytes:87661451 (83.6 MiB)

After:

t100      Link encap:Ethernet  HWaddr ae:17:96:7d:32:3f  
          inet6 addr: fe80::ac17:96ff:fe7d:323f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:58006 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57992 errors:0 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:3825467 (3.6 MiB)  TX bytes:87661451 (83.6 MiB)

The packets are still visible coming in on the bridge interface, and the
bridge knows the MAC address of the guest. I'm afraid I'm at a bit of a
loss on how to track this down; can anyone advise? 

/Nick

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html