kern/122839: [multicast] FreeBSD 7 multicast routing problem

[Bruce M. Simpson]

The following reply was made to PR kern/122839; it has been noted by GNATS.

From: "Bruce M. Simpson" <bms at FreeBSD.org>
To: petunin1 at legis.krsn.ru
Cc: bug-followup at FreeBSD.org, 4pr at legis.krsn.ru
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Tue, 22 Apr 2008 16:39:01 +0100

 petunin1 at legis.krsn.ru wrote:
 > ...
 > So, as it seems to me, it is not a em driver problem. I fink, it is 
 > imposiible, what such different drivers, as xl, em and msk were was broken 
 > simultaneously and identically.
 >   
 
 Without seeing reproducible results, I couldn't comment either way.
 
 > As my colleague says, when we both take a brief look at the source codes 
 > of em driver, it seems some card have a hardware filter, and some do not 
 > have it. So, if the card's filter programmed correctly (by the driver), 
 > multicast working task working just fine, and if not, we have a problems.
 >   
 
 Yes. It's regrettable that not all devices support the IFF_ALLMULTI 
 feature, nor that it is supported correctly and consistently where it is 
 supported.
 
 For example, wi(4) has never supported IFF_ALLMULTI correctly. The 
 network stack has no notion that a card with IFF_MULTICAST capability 
 can't support IFF_ALLMULTI.
 
 The way to fix it is to add support for emulating it using IFF_PROMISC. 
 This was part of the motivation behind the M_PROMISC change to 
 ether_input() last year, which allows the input path to tell if it 
 received frames which it otherwise wouldn't. It was largely added to 
 avoid introducing layer 2 loops with vlan(4) and if_bridge(4).
 
 This use of IFF_PROMISC has to be reference counted however. What would 
 also help in tidying that piece of code up would be to get rid of the 
 special case of carp(4)'s emulated addresses by tying this into a common 
 API.
 
 Unfortunately I don't have free time to actually do this work at the 
 moment, but I am happy to review patches.
 
 > On latest intel's driver 6.8.7 we have commented a few string on the code, 
 > after what, multicast routing started to work correctly. But i fink, it's 
 > a wrong way, so i asking for help again, if someone can help me to 
 > investigate the source of the problem and fix it by the right way.
 >   
 
 Tony Ackerman (tackerman at FreeBSD.org) is still listed as em(4) 
 maintainer according to MAINTAINERS, last I heard Jack Vogel 
 (jfv at FreeBSD.org) was actually involved. The MAINTAINERS file should 
 probably be updated.
 
 It is probably best if you contact Jack about em(4) directly.
 
 Thanks.
 BMS