Date:        Sun, 20 Jul 2003 22:11:31 +0200
    From:        Ignatios Souvatzis <ignatios@theory.cs.uni-bonn.de>
    Message-ID:  <20030720201131.GB4369@cs.uni-bonn.de>

  | Uhm... I've seen occurences of "IPv6 doesn't work" that pointed me at
  | a bug in multicast address handling on a specific hardware driver.

Yes, I'd heard about that kind of thing too, which is why I noted that
(normally anyway) multicast was working - that is, it appeared as if,
most of the time anyway, multicast works fine in this driver (both systems
are using the ex driver).

  | In my case it was something like "last multicast address configured doesn't
  | work" or "first multicast address configured doesn't work"

But I never tested it that thoroughly.

  | (The interesting difference about multicast vs. IPv6 is, that non-broadcast
  | multicasts are part of the infrastructure, while in IPv4, to the end user
  | they're only part of experimental protocols that are somehow expected to
  | mysteriously fail, such formerly, driver bugs in handling of the multicast
  | address list sometimes weren't detected for a long time.)

Yes - another advantage of IPv6!


itojun@iijlab.net in <20030721033446.2005D13@coconut.itojun.org> said:

  | DAD code actually works. 

OK, fine - now I know where to start hunting (wanted to check this wasn't
just something "not yet implemented as in practice it never happens anyway"
before wasting time looking in the wrong area).

  | 	try running tcpdump on "b4" machine (so that "b4" would receive all
  | 	packets) and perform the same test again, then you'll see
  | 	fe80::dead:beef marked as "duplicated". 

I will do some more testing along those lines later today.

kre

ps: in my earlier message I said "kernels were 1.6U from late May", which
was obvious nonsense, as 1.6U didn't appear till June 15.   That was a
brain fade ... the kernels were really 1.6T (I have 1.6U versions waiting
to be installed on the relevant systems, but haven't done it yet)