Duplicate Address Detection misfire?

[Kevin Day]

Sorry for the slow reply.

We run mainly ESXi (the bare metal version of VMware, not the desktop versions) but I do remember seeing something sort of similar on a desktop version ages ago. Basically we narrowed it down to a Windows driver bug on the host system's ethernet card. It was basically reflecting back everything it transmitted into the receive queue. This was before IPv6 was in use here, but I remember it breaking a file sharing protocol (SMB? AFP?) that also didn't like seeing its own multicasts/broadcasts echoed back to itself.

By any chance is this on a system using WiFi rather than wired ethernet? Many routers/access points/wifi adapters have problems with the idea of VMware's "bridged mode" networking - they expect only one MAC per station and do not do the right thing in some places.

I don't have an answer for you, but I'd look at the physical networking card/adapter on the host OS first if I were troubleshooting this. Updated driver/replace with something else/etc.

-- Kevin

On Jul 23, 2013, at 12:44 AM, Zaphod Beeblebrox <zbeeble at 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4877 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20130723/0a2e8ffd/attachment.bin>