<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5">
</HEAD>
<BODY>
On Thu, 2015-04-09 at 10:12 +0200, Michal Privoznik wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
I mildly recalls seeing a bug like this. The problem was in intel's
kernel driver. A NIC by defaul checks incoming packets whether they
match NIC's MAC. So if a TAP device was created over a NIC, it had to be
put into promisc mode (automatically done by the driver) to allow
different MACs and the check was done in kernel then. But since this
generates too much interrupts, NICs HW was extended and it can be
programmed with multiple MACs to let through. However, there was a bug
which I recall of, that intel driver was not always putting the TAP MAC
into the NIC HW correctly. Obviously, the bug was not visible if the NIC
was put into promisc mode. And this may be what you are seeing. Let me
see if I can find the bug.
</PRE>
</BLOCKQUOTE>
<BR>
FYI - enabling promiscious mode on eth0 does not help. I have to enable it on the macvtap0 which is on top of eth0.<BR>
<BR>
Stefan
</BODY>
</HTML>