From owner-freebsd-net@FreeBSD.ORG Thu Nov 30 18:47:21 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id F14E716A407; Thu, 30 Nov 2006 18:47:21 +0000 (UTC) In-Reply-To: <20061129232331.8E55016A415@hub.freebsd.org> from Bill Paul at "Nov 29, 2006 11:23:31 pm" To: wpaul@FreeBSD.ORG (Bill Paul) Date: Thu, 30 Nov 2006 18:47:21 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM826140722-92783-0_ Content-Transfer-Encoding: 7bit Message-Id: <20061130184721.F14E716A407@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: pyunyh@gmail.com, stable@freebsd.org, ed@fxq.nl, net@freebsd.org Subject: Re: re(4) needs promisc to work properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 18:47:22 -0000 --ELM826140722-92783-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > On Tue, Nov 28, 2006 at 08:46:00PM +0100, Ed Schouten wrote: > > > Hello, > > > > > > I'm running FreeBSD 6.2-PRERELEASE on my new desktop. It has the > > > following hardware: > > > > > > - Intel Core 2 Duo 6400 > > > - Asus P5B motherboard > > > - On-board Realtek NIC (8168B/8111B) > > > > > > For some reason, it drops all incoming IPv6 packets. I can only SSH to > > > the machine using IPv6 when I run the following command: > > > > > > $ ifconfig re0 promisc > > > > > > Is this a known issue about these NICs? > > > > No, I'm not aware of the issue. > > > > The issue can happen on a NIC with incorrectly programmed ethernet > > address. Would you show me dmesg/tcpdump output of your system? > > Make sure to add -e option to tcpdump(1). > > It's more likely a problem with the multicast filter programming. > IPv6 is all about the multicasting (neighbord discovery depends on it > to work correctly). I can't explain why it's not working though. > I've tested the sample 8168B/8111B cards that RealTek sent me, and I > didn't have any multicast problems with them. > > -Bill I guess I wasn't diligent enough in my testing. Upon closer inspection of the documentation, it appears RealTek abitrarily decided to reverse the order of the multicast hash registers in the PCIe parts: you have to write the hash table out in reverse order. I have no idea why they did this. In any case, I'm attaching a patch which should fix the problem. -Bill --ELM826140722-92783-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=multicast_patch Content-Description: multicast_patch Content-Transfer-Encoding: 7bit *** if_re.c.orig Thu Nov 30 10:37:42 2006 --- if_re.c Thu Nov 30 10:37:05 2006 *************** *** 620,625 **** --- 620,626 ---- struct ifmultiaddr *ifma; u_int32_t rxfilt; int mcnt = 0; + u_int32_t hwrev; RL_LOCK_ASSERT(sc); *************** *** 660,667 **** rxfilt &= ~RL_RXCFG_RX_MULTI; CSR_WRITE_4(sc, RL_RXCFG, rxfilt); ! CSR_WRITE_4(sc, RL_MAR0, hashes[0]); ! CSR_WRITE_4(sc, RL_MAR4, hashes[1]); } static void --- 661,684 ---- rxfilt &= ~RL_RXCFG_RX_MULTI; CSR_WRITE_4(sc, RL_RXCFG, rxfilt); ! ! /* ! * For some unfathomable reason, RealTek decided to reverse ! * the order of the multicast hash registers in the PCI Express ! * parts. This means we have to write the hash pattern in reverse ! * order for those devices. ! */ ! ! hwrev = CSR_READ_4(sc, RL_TXCFG) & RL_TXCFG_HWREV; ! ! if (hwrev == RL_HWREV_8100E || hwrev == RL_HWREV_8101E || ! hwrev == RL_HWREV_8168_SPIN1 || hwrev == RL_HWREV_8168_SPIN2) { ! CSR_WRITE_4(sc, RL_MAR0, bswap32(hashes[1])); ! CSR_WRITE_4(sc, RL_MAR4, bswap32(hashes[0])); ! } else { ! CSR_WRITE_4(sc, RL_MAR0, hashes[0]); ! CSR_WRITE_4(sc, RL_MAR4, hashes[1]); ! } } static void --ELM826140722-92783-0_--