On 23 Aug, Bill Paul wrote:
> > IPv6 autoconfiguration with -STABLE and Dlink DFE-550TX network adapters is
> > not working as it should.
>
> I need you do "pciconf -l | grep ste"
All cards have the same behavior. Here you go:
ste0@pci0:15:0: class=0x020000 card=0x10021186 chip=0x10021186 rev=0x00 hdr=0x00
ste0@pci0:9:0: class=0x020000 card=0x10021186 chip=0x10021186 rev=0x00 hdr=0x00
ste0@pci0:8:0: class=0x020000 card=0x10021186 chip=0x10021186 rev=0x00 hdr=0x00
> so that I can see which revision
> of the Sundance Technologies "alta" chip you have on your card. I have
> samples of these cards (which I used to write the driver) but they're
> old. I want to be sure this problem isn't due to behavioral differences
> between your chip rev and mine.
[...]
> but the
> real issue is that the multicast filter isn't being programmed
> correctly.
Yes. I have patched your driver to force the card to listen to all multicast
datagrams and not use the filter. It works perfectly.
> I'm going to stick one of my sample DFE-550TX cards in a test box
> in the lab and see if I can duplicate this problem, but it would help
> if you could run tcpdump -n -e -i ste0 so that we can see just what
> multicast address the NIC should be receiving.
tcpdump -n -e -i ste0 ip6 on the client:
20:59:09.335613 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded >
ff02::2: icmp6: router solicitation
20:59:09.460728 0:50:ba:15:69:fc 33:33:0:0:0:1 86dd 142: fe80::250:baff:fe15:69fc >
ff02::1: icmp6: router advertisement
20:59:09.461028 0:50:ba:71:bd:ed 33:33:ff:71:bd:ed 86dd 78: :: > ff02::1:ff71:bded:
icmp6: neighbor sol: who has 2002:c1fc:3606:0:250:baff:fe71:bded
and on the router:
21:00:43.207059 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded >
ff02::2: icmp6: router solicitation
21:00:43.332052 0:50:ba:15:69:fc 33:33:0:0:0:1 86dd 142: fe80::250:baff:fe15:69fc >
ff02::1: icmp6: router advertisement
21:00:43.332464 0:50:ba:71:bd:ed 33:33:ff:71:bd:ed 86dd 78: :: > ff02::1:ff71:bded:
icmp6: neighbor sol: who has 2002:c1fc:3606:0:250:baff:fe71:bded
> > Is this a known problem with the ste driver ?
>
> Ok, you know, I'm getting tired of people asking this question. It
> makes it sound like I leave bugs lying around just for people to
> trip on. If I knew about this problem, I would have fixed it.
Hey, relax. I didn't imply you write buggy drivers. It just seemed strange
nobody else had seen this problem before...
> > How can I be sure the client does not receive the advertisement without
> > running tcpdump ?
>
> You can also run tcpdump -n -e -p -i ste0. The -p flag means "don't
> put the interface into promisc mode."
If I do that, I get the following results :
20:47:24.524999 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded >
ff02::2: icmp6: router solicitation
20:47:28.545067 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded >
ff02::2: icmp6: router solicitation
20:47:32.565102 0:50:ba:71:bd:ed 33:33:0:0:0:2 86dd 70: fe80::250:baff:fe71:bded >
ff02::2: icmp6: router solicitation
Other machines (in promiscuous mode, or with a patched driver) show the router
advertisements.
Francois
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
