Does that mean, then, that the only fix open to some people is to turn off DAD? I have another idea:
Require DAD to inspect the sending MAC address. If the sending MAC address is _our_ MAC address, then the packet is not an indication of a duplicate address? On Tue, Jul 23, 2013 at 2:15 AM, Kimmo Paasiala <kpaas...@gmail.com> wrote: > On Tue, Jul 23, 2013 at 8:44 AM, Zaphod Beeblebrox <zbee...@gmail.com> > wrote: > > What to do when you don't trust the interface? VMWare is obviously > > emulating the hardware and their interpretation of what the hardware "is" > > is possibly different from ours. > > > > If I boot single-user and tcpdump the interface, I see two transmitted > > solicitations. The kernel claims to have sent one. > > > > My concern: is the vmware interface reflecting the solicitation packet > > because it is a broadcast packet? > > > > To determine this, I've gone over the tcpdump and pcap-filter man pages > to > > look for a way to only dump packets leaving from or arriving at an > > interface. Can this be done? > > > > If VMWare is reflecting the packet back, I'm curious as to how we can fix > > this. > > > > > > That sounds exactly like my experience with DAD misbehaving on my > Zyxel WAP3205 access point. It is reflecting the multicasts (I hope > that's the right term) so that any IPv6 equipment on the wireless > network will think that its address is already in use. For the record, > the client machines in my case are all OS X. Nice to know I'm not the > only one with such problems. > > -Kimmo > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
