Re: recent MFC code to 6-STABLE kills ipv6

On Mon, 2005-11-07 at 18:23 +0000, Bill Paul wrote: 
> > On Sun, 2005-11-06 at 18:06 +0900, SUZUKI Shinsuke wrote:
> > > Hello Sean,
> > > 
> > > >>>>> On Sat, 5 Nov 2005 14:39:13 -0800
> > > >>>>> sean_at_mcneil.com(Sean McNeil)  said:
> > > 
> > > > > sean> ping6 does NOT work for
> > > > > sean> fe80::203:6dff:fe1a:b19b%dc0
> > > > > sean> 2002:18c7:2d36:0:203:6dff:fe1a:b19b
> > > > > sean> 2002:18c7:2d36::
> > > > >
> > > > > It seems an IPv6 operation for dc0 is disabled entirely.  Don't you
> > > > > see an error message from your kernel like following?
> > > > > 	dc0: possible hardware address duplication detected, disable IPv6
> > > > No, nothing like that in any logs.  I can't see how there could  
> > > > suddenly be a duplication of hardware addresses.  I agree, though,  
> > > > that IPv6 is disabled for dc0.  Some change in the kernel has caused  
> > > > this.
> > > 
> > > I tried the same configuration (with the different interface card)
> > > using the latest RELENG-6 in my environment, but I couldn't reproduce
> > > your problem.
> 
> In order to really duplicate his configuration, you would need to use
> the same network card. But of course you can't do that, because he
> never mentioned just what card he has.
> 
> The dc(4) driver supports a whole bunch of different chips. It really
> really really matters that you tell us exactly which one you have.

How could this possibly matter?  There were no changes to the dc0 driver
from Nov 1st to present.  There were numerous ones to the IPv6 layer,
though, that were MFCd recently.  I can ping6 www.kame.net which goes
through this nic, so IPv6 works through the stf pathway. Also, internal
pings are completely dropped only on the nic tied to stf.  I think it is
more likely an amd64 vs i386 issue.  Perhaps a long instead of an int
somewhere.  I would start with testing it on an amd64 machine first
before looking for differences in the nics.

> It would also really really help if you could run a packet dump on
> dc0 while trying to ping6 it from another host. You should do
> tcpdump -n -e -p -i dc0 so as not to force it into promisc mode.

I did that and I get for each packet sent with the new kernel:

10:42:34.093463 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56:
        0x0000:  0000 0203 6dff fe1a b19b 2002 18c7 2d36  ....m.........-6
        0x0010:  0000 0203 6dff fe1a b19b 8000 1e51 0567  ....m........Q.g
        0x0020:  0000 436f a01a 0001 6d01                 ..Co....m.
10:42:35.093983 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56:
        0x0000:  0000 0203 6dff fe1a b19b 2002 18c7 2d36  ....m.........-6
        0x0010:  0000 0203 6dff fe1a b19b 8000 1c56 0567  ....m........V.g
        0x0020:  0001 436f a01b 0001 6efa                 ..Co....n.
10:42:36.093883 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56:
        0x0000:  0000 0203 6dff fe1a b19b 2002 18c7 2d36  ....m.........-6
        0x0010:  0000 0203 6dff fe1a b19b 8000 1cb6 0567  ....m..........g
        0x0020:  0002 436f a01c 0001 6e98                 ..Co....n.
10:42:37.093795 3a:40:20:02:18:c7 > 60:00:00:00:00:10, ethertype Unknown (0x2d36), length 56:
        0x0000:  0000 0203 6dff fe1a b19b 2002 18c7 2d36  ....m.........-6
        0x0010:  0000 0203 6dff fe1a b19b 8000 1d0d 0567  ....m..........g
        0x0020:  0003 436f a01d 0001 6e3f                 ..Co....n?

The packets are going in, but nothing is coming out.  The dump looks
very peculiar for both the sk0 and the dc0 nic.  None of the ethertypes
are known.  In contrast, the Nov 1 kernel that works shows me things
like:

11:11:12.363832 00:03:6d:1a:b1:9b > 33:33:00:00:00:09, ethertype IPv6 (0x86dd), length 86: fe80::203:6dff:fe1a:b19b.521 > ff02::9.521:  ripng-resp 1: 2002:18c7:2d36:1::/64 (1)

Cheers,
Sean