Bug 569 - tap bridge USE_LOCAL not working with virtual machines
tap bridge USE_LOCAL not working with virtual machines
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: devices
ns-3-dev
PC Linux
: P1 normal
Assigned To: Craig Dowell
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-21 01:27 UTC by Tom Henderson
Modified: 2009-06-24 01:20 UTC (History)
2 users (show)

See Also:


Attachments
start of a patch to fix (7.05 KB, patch)
2009-06-17 18:04 UTC, Tom Henderson
Details | Diff
Fully Implemented Patch (23.02 KB, patch)
2009-06-19 03:54 UTC, Craig Dowell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2009-05-21 01:27:31 UTC
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.
Comment 1 Tom Henderson 2009-05-23 09:13:26 UTC
changed subject; this needs a test case and debugging.
Comment 2 Tom Henderson 2009-06-17 18:04:04 UTC
Created attachment 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
Comment 3 Craig Dowell 2009-06-19 03:54:49 UTC
Created attachment 473 [details]
Fully Implemented Patch

Completes Tom's patch.  Untested on VM testcase.
Comment 4 Tom Henderson 2009-06-23 12:48:06 UTC
(In reply to comment #3)
> Created an attachment (id=473) [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).
Comment 5 Craig Dowell 2009-06-24 01:20:35 UTC
changeset:  88434ff8f0a5