Bug 520

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.