On Sun, Nov 12, 2000 at 11:21:30PM +0900, itojun@iijlab.net wrote:
> >But, when the IP-address I try to steal is from a machine that is
> >configured as an IPv6 router, the host does send out a neighbour
> >solicitation for that address (to the solicited-nodes multicast
> >address; i.e. :: > ff02::1:ff00:2: icmp6: neighbor sol: who has...),
> >but the router never replies that it actually uses that address. This
> >results in (semi-)successful theft of the address, in that the thief 
> >configures the address to its interface (without the duplicated tag).
> >`semi' because normally the neighbour discovery cache still has the
> >entry for the real owner (the router), whcih does not get overwritten.
> 
> 	the last part of the above is separate story, i believe.  first
> 	let us concentrate to DAD issues.
Yes, and not overwriting it doesn't seem very inappropriate in this
case anyway.

> >It looks to me that this is because the router doesn't listen to the
> >Solicited-Node Multicast, however it does reply to pings to that
> >address.
> 
> 	we do have tested DAD tons of times, including during TAHI
> 	conformance tests, and I'm convinced it works fine.
I know that, and therefor was rather suprised and tried to doublecheck
and tested it at mutliple machines. I ran tests against fairly similar
machines; both laptops (although different model), same ethernet
driver (ep driver, although slightly different card model; etherlink
III and 3com MegaHertz respectively. both PCMCIA 10Mbs UTP), both
running NetBSD-1.5_Beta. One laptop is configured as router and one as
host. As said before, the host replies fine in the DAD round, the
router does not.

The thief machines in either case are also fairly similar; same type
of PC, same type of Ethernet card (ex driver), running both
NetBSD-more-or-less current.

The second router I tested uses different hardware and the thief is
quite different to. Router is PC running NetBSD-1.5_ALPHA, using ex
driver for its ethernet cards. The thief is a (much faster than the
other two) laptop using a Xircom 100Mbs ethernet cardbus card with the
tlp driver.
 
> 	first of all, what kind of ethernet card are you using?  some of the
> 	ethernet card comes with broken multicast packet filter (or broken
> 	driver).
But I think the drivers I use are pretty mature and in wide use, also
pings to varying multicast addresses work just fine.

> 	next, a little bit of spec issue.  we run DAD right after interface
> 	initialization.  some of the ethernet cards need more than seconds to
> 	finish its initialization.  as IPv6 layer has no way to know if the
> 	interface initialization is really done, DAD can be invoked before
> 	interface gets ready, and sometimes DAD packet will not go out,
> 	or thief cannot receive DAD response from victim.
Do not think this is relevant in my case, unless I misunderstand what
you mean, as the interfaces are already completely up and running. I
*add* a manually configured address (the one to steal) with ifconfig
inet6 ... alias. The interface is at that point already happily up and
running with its auto-configured address.
 
> 	also, could you please make sure to diagnose the following:
> 	- during the test, DO NOT run tcpdump on victim nor the thief.
> 	  by running tcpdump the interface behavior will be changed (due to
> 	  promiscuous mode).  run tcpdump on other node.
Whether I run tcpdump or not, the final result (duplicated tag to
ifconfig-ed address or not) is the same. But sofar I only used tcpdump
on the thief. I ran tcpdump on the router too now, and on a third
machine (not thief, not router). See below for mroe confusion.

> 	- are you sure that the router is not listening to the solicited
> 	  node multicast address? (if it is really true, your router will
> 	  have problem runing ND) see the result of ifmcstat(8).  also,
> 	  check if you see number increase in IPv6 counters (netstat -sn)
> 	  during DAD session.
Ah! didn't know ifmcstat. quite useful, thanks. It shows it is
listening to the solicited node multicast (also indicated by pinging
to it). I've never seen problems with any of these machines with
`normal' neighbour discovery or router discovery. Just this special
case of a host trying to steal a router's address.

> 	this was fixed in KAME tree already (with newer interface address
> 	removal handling in sys/netinet6/in6.c), this is not integrated
> 	into netbsd 1.5 nor netbsd-current yet.  the new code changes some of
> 	reference counting code, and i (or we) would like to be very sure that
> 	the new code works fine for all cases.
Ok, fine. Whould be nice to have in 1.5 though. Hope that's not too
late (it's nice for my laptop wandering between three nets on a
regular basis, and doesn't use mobile-IP (not in NetBSD yet).

****
New tcpdump results are as follows:

The tcpdump on the thief sees the DAD neighbour discovery icmp message
to the sollicited multicase address going out, but neither the router
nor the third machine see this. This would indicate a driver problem
on the thief. However a ping6 to the sollicited multicast address
*does* show at the router *and* the third machine and the router
replies to it. In my case:

drifter# ping6 -I tlp0 -n ff02::1:ff00:2
PING6(56=40+8+8 bytes) fe80::210:a4ff:fead:43c0%tlp0 --> ff02::1:ff00:2
16 bytes from fe80::250:4ff:feec:b149%tlp0, icmp_seq=0 hlim=64 time=0.391 ms
...

I haven't been able to test this yet for the laptop router case, which is
on my homenetwork. But this thief exhibits same behaviour when trying
to steal the address of another host (instead of the router), so that
is not a determining factor.

This indicates I think that the problem is slightly more subtle than
`multicast in this driver doesn't work'. However I have no clue what
it might be. 

Feico.








Feico.