On 03/05/2012 11:14 AM, Eric Blake wrote:
On 03/05/2012 09:05 AM, Laine Stump wrote:
> This patch is in response to:
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=798467
>
> If a guest's tap device is created using the same MAC address the
> guest uses for its own network card (which connects to the tap
> device), the Linux kernel will log the following message and traffic
> will not pass:
>
> kernel: vnet9: received packet with own address as source address
>
> This patch disallows MAC addresses with a first byte of 0xFE, but only in
> the case that the MAC address is used for a guest interface that's
> connected by way of a standard tap device. (In other words, the
> validation is done at runtime at the same place the MAC address is
> modified for the tap device, rather than when mac address is parsed,
> the idea being that it is then we know for sure the address will be
> problematic.)
> ---
> src/util/virnetdevtap.c | 22 ++++++++++++++++++++--
> 1 files changed, 20 insertions(+), 2 deletions(-)
ACK.
Thanks. I recieved the additional info that this was discovered not by
someone manually setting the mac address to fe:xx:xx:xx:xx:xx in some
ill-informed attempt to match what they saw in the tap device's ifconfig
output, but because a management application automatically chose an
address that started with 0xFE. I'm waiting to push until I hear back
whether or not that management application can be configured to *not* do
that.