[Ns-bugs] [Bug 520] New: tap-bridge does not support virtual machines

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=520

           Summary: tap-bridge does not support virtual machines
           Product: ns-3
           Version: ns-3-dev
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: devices
        AssignedTo: craigdo at ee.washington.edu
        ReportedBy: tomh at tomh.org
                CC: ns-bugs at isi.edu
   Estimated Hours: 0.0


Current tap-bridge works when the packets are being sourced/sinked by the host
machine via the tap device, if the host's tap device parameters are lined up
with the ns-3 device:

device      mac
---------------
tap0        00:00:00:00:00:01
tap-bridge
wifi        00:00:00:00:00:01

It exploits (but is constrained by) the fact that tap0 (or "left" in the
example script) and wifi0 have both the same IP address and same mac address. 
The tap-bridge calls the (Wifi)NetDevice::Send() method, which adds mac
addresses.

In the use case I'm interested in, the device being bridged is not a tap device
but another host virtual device, such as an OpenVz "veth" device.  Here, the
various mac addresses may be different:

device
------
eth0 (on virtual machine)  00:00:00:aa:00:00
veth1000.0 (on host)  00:bb:00:aa:00:00
tap0   00:00:00:aa:00:01
tap-bridge
wifi     00:00:00:00:00:01

This will not work as present.  It is not always possible to change the mac
address on the virtual machine (eth0 in this case).  It is not necessarily easy
for ns-3 to know this mac address other than by configuration side information. 

To make this work now, the tap-bridge needs to bridge frames from a foreign
address (00:00:00:aa:00:00) to the wifi adapter, which has 00:00:00:00:00:01. 
The tap-bridge itself thinks it has 00:00:00:00:00:01 (it learns this from the
wifi device), so address 00:00:00:aa:00:00 looks foreign to it.

This necessitates two changes:
1) tap-bridge.cc has some code where it throws away unicast frames destined to
OTHERHOST.  These should be permitted in this case.
2) tap-bridge needs to promiscuously receive from wifi device and be able to
map between the wifi mac address and the eth0 address.  wifi should not reply
to any arps or process any incoming frames at the IP layer or above.

The way I thought it might work is:
- in the virtual machine to ns-3 direction, the tap-bridge learns of the eth0
source mac address.  there can only be one mac address-- if two unique source
addresses are observed, then assert.
- tap bridge calls NetDevice::Send()-- the source mac address will be
overwritten to the mac of the wifi netdevice
- in the ns-3 to virtual machine direction, the tap-bridge will receive frames
destined to the wifi mac address.  Here, the tap-bridge can swap out the wifi
mac for the learned eth0 mac.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.