Re: re(4) needs promisc to work properly

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
*** 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
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: re(4) needs promisc to work properly
    ... it drops all incoming IPv6 packets. ... It's more likely a problem with the multicast filter programming. ... reverse the order of the multicast hash registers in the PCIe parts: ...
    (freebsd-net)
  • Re: RFC 1918 addresses
    ... > in any case, but 224/4, being multicast, can be very useful to allow ... usually given to the loopback interface. ... I hope that IPv6 will be widely used soon. ... for running unmanaged test networks too. ...
    (comp.unix.bsd.openbsd.misc)
  • Re: re(4) needs promisc to work properly
    ... it drops all incoming IPv6 packets. ... The issue can happen on a NIC with incorrectly programmed ethernet ... It's more likely a problem with the multicast filter programming. ... didn't have any multicast problems with them. ...
    (freebsd-net)
  • Re: re(4) needs promisc to work properly
    ... it drops all incoming IPv6 packets. ... The issue can happen on a NIC with incorrectly programmed ethernet ... It's more likely a problem with the multicast filter programming. ... didn't have any multicast problems with them. ...
    (freebsd-stable)
  • Re: re(4) needs promisc to work properly
    ... didn't have any multicast problems with them. ... reverse the order of the multicast hash registers in the PCIe parts: ... you have to write the hash table out in reverse order. ... In any case, I'm attaching a patch ...
    (freebsd-net)