Bug 569

Summary:	tap bridge USE_LOCAL not working with virtual machines
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	devices	Assignee:	Craig Dowell <craigdo>
Status:	RESOLVED FIXED
Severity:	normal	CC:	mathieu.lacage, ns-bugs
Priority:	P1
Version:	ns-3-dev
Hardware:	PC
OS:	Linux
Attachments:	start of a patch to fix Fully Implemented Patch

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