>Number:         35579
>Category:       kern
>Synopsis:       re(4) has problems with multicast. IPv6 doesn't work correctly.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 09 00:55:00 +0000 2007
>Originator:     Nino Dehne
>Release:        4.0_BETA2
>Organization:
>Environment:
NetBSD [...] 4.0_BETA2 NetBSD 4.0_BETA2 (CHARON.MPACPI-2007012502) #0: Thu Jan 25 16:03:25 CET 2007 root@[...]:/tmp/charon/x/s/n/netbsd-4/src/sys/arch/i386/compile/CHARON.MPACPI i386

>Description:
Server:
re0 at pci5 dev 0 function 0: RealTek 8168B/8111B PCIe Gigabit Ethernet
re0: interrupting at ioapic1 pin 12 (irq 10)
re0: eeprom autoload timed out
re0: Ethernet address [...]
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S 1000BASE-T media interface, rev. 2
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
[...]
        inet6 fe80::[...]%re0 prefixlen 64 scopeid 0x1
        inet6 <siteprefix1>:1::1:1 prefixlen 64
        inet6 <siteprefix1>:1::1:19 prefixlen 64 deprecated
        inet6 <siteprefix2>:1::1:1 prefixlen 64 deprecated
        inet6 <siteprefix2>:1::1:19 prefixlen 64 deprecated

Router:
vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        vlan: 1 parent: sip1
[...]
        inet6 fe80::[...]%vlan1 prefixlen 64 scopeid 0x7
        inet6 <siteprefix1>:1::ffff prefixlen 64
        inet6 <siteprefix2>:1::ffff prefixlen 64

The aliases on the server are very rarely used. They serve as listening
addresses and source addresses for outgoing Postfix connections and I
rarely receive mail from IPv6-aware senders. When trying to send mail
via IPv6 though, connections time out.

Trying to ping <siteprefix1>:1::1:19 from the router doesn't work
either because the server sees no neighbor solicitation request from
the router (with hindsight confirmed using tcpdump -p).

However, as soon as I run tcpdump in promiscuous mode on the server the
solicitation request is seen and everything magically works:

<router's mac address> > 33:33:[...], ethertype IPv6 (0x86dd), length 86: <siteprefix1>:1::ffff > ff02::1:ff01:19: icmp6: neighbor sol: who has <siteprefix1>:1::1:19

is@ hinted to a multicast-related problem with the re(4) driver. It
also looks like the OpenBSD guys already identified and fixed the
problem: http://archive.netbsd.se/?ml=openbsd-tech&a=2007-01&m=3037787

Regards,

ND
>How-To-Repeat:
see above
>Fix:
Yes, please.