Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Jul 2009 09:14:29 +0100
From:      Bruce Simpson <bms@incunabulum.net>
To:        iprebeg@freebsd.org
Cc:        jfv@FreeBSD.org, freebsd-net@freebsd.org
Subject:   Re: em driver doesn't set multicast ethernet address
Message-ID:  <4A5849E5.90909@incunabulum.net>
In-Reply-To: <20090711073647.GA1824@valeria.zesoi.fer.hr>
References:  <20090711073647.GA1824@valeria.zesoi.fer.hr>

next in thread | previous in thread | raw e-mail | index | archive | help
iprebeg@freebsd.org wrote:
> While testing -CURRENT in VMWare environment, I discovered that em
> driver doesn't properly set destination address in Ethernet header. In
> the other words, when I start listening multicast session with mcastread
> (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is
> 224.0.0.22, but its destionation Ethernet address doesn't look like
> 01:00:5e:... Other machines that I run in same environment (like
> FreeBSD-7) behave in good manner.
>   

It seems that the introduction of IGMPv3 may have exposed some 
driver/hardware issues, where certain network interfaces are not able to 
transmit on groups which haven't been joined for receive. This is a bug, 
and would likely break production use of IPv6, which makes heavier use 
of link-scope groups than IPv4 does.

Can you provide the following information please, so that someone can 
better help you:
 1) the date of the -CURRENT code you are using;
 2) tcpdump or wireshark capture output, containing the actual output 
generated by em(4).

Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 
inside the guest? The kernel will *not* listen to 224.0.0.22, unless 
you're running a multicast routing daemon -- as it doesn't have to; that 
link-scope group is for reports only.

This issue doesn't appear with IGMPv2, because it only ever transmits 
its reports on the group thus joined. This has the disadvantage that 
multicast routers have to have functioning promiscuous multicast 
receive, just to proxy or forward traffic.

Can you force the use of IGMPv2 using the sysctls as defined in the 
igmp(4) man page as a workaround?

thanks,
BMS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A5849E5.90909>