From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbnHH-0008Ma-Fd for qemu-devel@nongnu.org; Fri, 23 Nov 2012 02:02:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbnHD-0004U0-3K for qemu-devel@nongnu.org; Fri, 23 Nov 2012 02:02:19 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:42739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbnHC-0004Tj-EZ for qemu-devel@nongnu.org; Fri, 23 Nov 2012 02:02:15 -0500 Received: by mail-bk0-f45.google.com with SMTP id jk13so2588332bkc.4 for ; Thu, 22 Nov 2012 23:02:13 -0800 (PST) Date: Fri, 23 Nov 2012 08:02:11 +0100 From: Stefan Hajnoczi Message-ID: <20121123070211.GC22787@stefanha-thinkpad.hitronhub.home> References: <50AE36E0.8000307@dlhnet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AE36E0.8000307@dlhnet.de> Subject: Re: [Qemu-devel] tap devices not receiving packets from a bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: netdev@vger.kernel.org, "qemu-devel@nongnu.org" On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote: > is anyone aware of a problem with the linux network bridge that in very rare circumstances stops > a bridge from sending pakets to a tap device? > > My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu Kernel 3.2.0-34.53 > which is based on Linux 3.2.33. > > I was not yet able to reproduce the issue, it happens in really rare cases. The symptom is that > the tap does not have any TX packets. RX is working fine. I see the packets coming in at > the physical interface on the host, but they are not forwarded to the tap interface. > The bridge itself has learnt the mac address of the vServer that is connected to the tap interface. > It does not help to toggle the bridge link status, the tap interface status or the interface in the vServer. > It seems that problem occurs if a tap interface that has previously been used, but set to nonpersistent > is set persistent again and then is by chance assigned to the same vServer (=same mac address on same > bridge) again. Unfortunately it seems not to be reproducible. Not sure but this patch from Michael Tsirkin may help - it solves an issue with persistent tap devices: http://patchwork.ozlabs.org/patch/198598/ Stefan