[Ns-bugs] [Bug 510] NqstaWifiMac Lies About SupportsSendFrom?

[code@nsnam.ece.gatech.edu]

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





--- Comment #7 from Tom Henderson <tomh at tomh.org>  2009-02-26 09:58:11 EDT ---
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > No, I mean the other way around.  I think we had already concluded in the
> > > mailing list that STAs cannot do bridging, only APs.  This is a limitation of
> > > real world, not of NS-3.
> > > 
> > 
> > Since one of my primary use cases for ns-3 is to hook virtual machines to ad
> > hoc wifi interfaces, I would like to revisit that conclusion now that the
> > mechanism for doing so relies on being able to bridge the TapBridge device to
> > the Wifi device. 
> > 
> 
> Maybe I'm preempting Mathieu's response, here, but.. :-)
> 
> I don't think making a STA work with SendFrom can be done in a way that is
> understandable, since STAs are connection oriented, and the AP is supposed to
> drop frames from a STA that isn't associated.
> 
> However for the AdhocWifiMac it could make some sense, since it's not
> connection oriented.  However the transmission mode algorithm (I lack the
> terminology) won't be very efficient since the other side wifi MAC will have
> one RemoteStationManager per source MAC address; if the MAC address keeps
> changing on a per packet basis, things may not work as expected...  It's as if
> we had N terminals instead of a single terminal.
> 

Let me just explain for a moment why this is presently needed.  We need to
control the source mac address of frames that originate on the Wifi device that
is on the ghost node that represents the virtual machine.  These frames
originally come from the virtual machine.  If Send() is called, the source mac
of the frame originated from the virtual machine becomes the same as the Wifi
device.  This is problematic as follows:
- if the packets in the receive direction do not have the virtual machine's mac
address, they will not be delivered
- it may be possible to line up the mac address of the ns-3 wifi device with
that of the virtual machine.  However, what I observed is that the ns-3 wifi
device will also consume the packet.  For instance, two arp replys (one from
the ghost node, one from the virtual machine) will be generated (unless this
wifi device is detached from the ghost node's internet stack.  

It may be possible to fix some of the above issues without overloading
ns3::SendFrom (), but the TapBridge will need to be able to figure out what mac
address of the virtual machine it should write into the ethernet header.  There
may be benefit to doing this (and avoiding SendFrom() reliance) if we want to
hook virtual machines to interfaces that can't support SendFrom () (rather than
in this case "won't support SendFrom ()" due to a policy decision).  But, it
may be a configuration issue (how does the ns-3 program know the mac addresses
that it needs to use?)

I suggest that we evaluate whether we can easily support this mode of
tap/emulation operation without SendFrom () before we try to patch the wifi
code.


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