qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] socket,mcast looping back frames -> IPv6 broken


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] socket,mcast looping back frames -> IPv6 broken
Date: Wed, 6 Mar 2013 13:29:37 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Mar 05, 2013 at 05:35:10PM +0100, Samuel Thibault wrote:
> The reason why IPv6 does not work when using -net socket,mcast=foo is
> that since qemu explicitly sets IP_MULTICAST_LOOP to 1, it receives its
> own frames.  When the IPv6 stack performs duplicate addresse detection
> (DAD) through a multicasted announce, it receives its own announcement,
> and thus believes another machine has the same address.

The reason for IP_MULTICAST_LOOP is to allow QEMU processes running on
the same host to communicate with each other.

> AIUI, on a real physical network network boards do not receive the
> multicasts they send, so the issue does not happen. Perhaps some boards
> even filter out any frame with its own MAC as source, eliminating the
> issue altogether.
> 
> As a result, we should probably perform this kind of dropping, I'm just
> wondering at which level that would be preferable.
> 
> - We could do that in qemu_send_packet_async_with_flags, thus fixing the
> issue for all kinds of frame transporters.
> 
> - Or we could do that for the only case that matters, mcast, in
> net_socket_send_dgram (which will thus do it for the unicast udp case
> too).
> 
> What do people think about it?

We should fix the layer that introduces the problem.  Therefore I think
the fix needs to be net/socket.c.

Unfortunately net/socket.c does not have the concept of a link-layer
address, so we cannot easily filter out multicast packets coming from
our NIC's address.

Are you aware of a way to filter out just the packets sent by *this*
process?

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]