Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Nov 2006 18:47:21 +0000 (GMT)
From:      wpaul@FreeBSD.ORG (Bill Paul)
To:        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
Message-ID:  <20061130184721.F14E716A407@hub.freebsd.org>
In-Reply-To: <20061129232331.8E55016A415@hub.freebsd.org> from Bill Paul at "Nov 29, 2006 11:23:31 pm"

next in thread | previous in thread | raw e-mail | index | archive | help

--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_--



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