Bugzilla – Bug 569
tap bridge USE_LOCAL not working with virtual machines
Last modified: 2009-06-24 01:20:35 EDT
You need to log in before you can comment on or make changes to this bug.
TapBridge is designed to bridge a tap device to an ns-3 device. However, in USE_BRIDGE mode, the underlying ns-3 device needs to support bridging (support the function call NetDevice::SendFrom()). Some devices may want to be used in emulation, but they are not bridging devices (e.g. wifi adhoc), so TapBridge needs to compensate for this and use Send() instead. see the closed bug 510 for more details.
changed subject; this needs a test case and debugging.
Created an attachment (id=471) [details] start of a patch to fix This patch starts to fix this bug. There are a few problems that need to be resolved to allow container-based VMs to hook to ns-3 devices that do not support bridging (the TapDevice::USE_LOCAL mode). 1) Node::RegisterProtocolHandler should not associate SupportsSendFrom() with setting promiscuous receive hooks 2) We should have a base class NetDevice::SetAddress() method so that the TapBridge can overwrite the ns-3-assigned Mac address at runtime 3) The TapBridge should unregister protocol handlers on the underlying device before registering itself as a handler. This prevents duplicate Arp replies. This is not implemented in the patch (see an XXX there) Once these three things are fixed, I think it will work
Created an attachment (id=473) [details] Fully Implemented Patch Completes Tom's patch. Untested on VM testcase.
(In reply to comment #3) > Created an attachment (id=473) [details] [details] > Fully Implemented Patch > > Completes Tom's patch. Untested on VM testcase. > I tested this patch yesterday and it seems to resolve the problem. My testing was limited to only a couple of cases (I tested two OpenVz containers over an ad hoc wireless network, and sent ping (which required ARP and IPv4 to work) as well as OSPFv3 for IPv6 (which required unicast and multicast IPv6 to work)). I think this should be committed now as well as whatever the resulting Icmp fix is (which there are bits of in this patch).
changeset: 88434ff8f0a5