On Thu, 3 Jan 2002, Lennert Buytenhek wrote: > Having TCP/IP or not is probably not the problem. If W2K answers ARP > requests on this interface you're still fscked.
True. But I'd have thought disabling TCP/IP should disable ARP too. If the interface was configured, it'd also have a different IP > Can you try connecting to sandy for the first time from an external host > while having a tcpdump running on that external host (which has to be on > the same subnet)? Please try to find out: > > What MAC address sandy sends in ARP replies > What MAC address that ARP reply seems to be coming from. The ARP replies very frequently don't seem to get to the external ethernet at all, but when they do they come from 0:50:56:c0:0:1 (sandy's MAC address on the rocky-sandy internal link) and advertise that same MAC address. tcpdump on the rocky-sandy internal link also shows the same thing happening. I've come up with a possible theory for what could be happening, but my knowledge of precisely how ethernet works is a bit thin. Is it usual for ethernet cards to echo packets sent by the machine they are in back to that same machine? If the answer is no, then it could be caused by the VMWare "bridging" (I'll call it slaving from now on to avoid confusion). Recall that the external ethernet interface on rocky is actually slaved to sandy's external ethernet interface. Suppose the slaving decides which frames to send to rocky by looking at the source MAC address; if it's the MAC address of the slave device then it doesn't send them, and if it isn't it does. Then every packet that gets sent out by rocky onto the external interface which doesn't have its own MAC address will get echoed back to it; in particular this will confuse the bridge code into thinking that 0:50:56:c0:0:1 is on the wrong port. Does that sound plausible? Cheers, Ganesh _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
