Bug 722

Summary: tap-wifi-dumbbell.cc busted
Product: ns-3 Reporter: Craig Dowell <craigdo>
Component: devicesAssignee: Craig Dowell <craigdo>
Status: RESOLVED FIXED    
Severity: major CC: mathieu.lacage, ns-bugs, tomh, vkawadia
Priority: P3    
Version: ns-3-dev   
Hardware: All   
OS: All   

Description Craig Dowell 2009-10-14 19:44:22 UTC
The non-trivial operating modes demonstrated by tap-wifi-dumbell.cc have stopped working.
Comment 1 Tom Henderson 2009-10-16 21:18:46 UTC
I just tried to test this on ns-test and found the following:

the example cases 1,2,3 and 5 in examples/tap/tap-wifi-dumbbell.cc worked for me in repeated trials.  Previously, when I reported this bug verbally, I was on a different machine and could not get any of the modes to work, but I suspect now that the other machine did not have tap framework working properly.

case 4 (doesn't work on ns-test) is the following:

// 4) Try to run this in UseLocal mode.  This allows you to provide an existing
//    pre-configured tap device to the simulation.  The IP address and MAC 
//    address in this mode do not have to match those of the ns-3 device.
//
//    sudo tunctl -t mytap
//    sudo ifconfig mytap hw ether 08:00:2e:00:00:01
//    sudo ifconfig mytap 10.1.1.1 netmask 255.255.255.0 up
//    ./waf --run "tap-wifi-dumbbell --mode=UseLocal --tapName=mytap"&
//    ping 10.1.1.3

In this mode, the TapBridge discovers, during run-time, the overlying MAC address of the tap device, and sets the underlying ns-3 NetDevice to have the same mac address.

What is going on in this example is that the simulation starts, and a little while later, the TapBridge gets a packet and sets the underlying wifi address.  However, the client has already associated to the ap with a previous mac address (the one that ns-3 initially assigned).  This generates the following drop message in NqstaWifiMac:
"Received data frame not from the BSS we are associated with:  ignore 08:00:2e:00:00:01"

Recall that we introduced this mode of "UseLocal" to work around some issues with hooking TapBridge to other virtual machine frameworks.  This doesn't seem to be easy to make work with infrastructure-mode-- am not sure about whether it still works with ad hoc mode.

For the release, I suggest that we remove use case 4) from the example (actually, leave a comment in the example that UseLocal presently doesn't work with this example because the underlying devices associate with the original mac addresses) and keep open a bug named such as "TapBridge UseLocal mode not robust enough" and deal with it post-release.