Date: Tue, 22 Apr 2008 16:00:04 GMT From: "Bruce M. Simpson" <bms@FreeBSD.org> To: freebsd-net@FreeBSD.org Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200804221600.m3MG04Ym049135@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/122839; it has been noted by GNATS. From: "Bruce M. Simpson" <bms@FreeBSD.org> To: petunin1@legis.krsn.ru Cc: bug-followup@FreeBSD.org, 4pr@legis.krsn.ru Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Tue, 22 Apr 2008 16:39:01 +0100 petunin1@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@FreeBSD.org) is still listed as em(4) maintainer according to MAINTAINERS, last I heard Jack Vogel (jfv@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804221600.m3MG04Ym049135>