Bug 510 - NqstaWifiMac Lies About SupportsSendFrom?
NqstaWifiMac Lies About SupportsSendFrom?
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: devices
pre-release
All All
: P1 normal
Assigned To: Mathieu Lacage
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-24 18:28 EST by Craig Dowell
Modified: 2009-03-16 21:56 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Dowell 2009-02-24 18:28:04 EST
I believe these are contradictory ...

bool
NqstaWifiMac::SupportsSendFrom (void) const
{
  return true;
}

void
NqstaWifiMac::Enqueue (Ptr<const Packet> packet, Mac48Address to, Mac48Address from)
{
  NS_FATAL_ERROR ("Qsta does not support enqueue");
}
Comment 1 Gustavo J. A. M. Carneiro 2009-02-25 12:30:19 EST
Agreed.  Probably just a copy-paste bug.
Comment 2 Tom Henderson 2009-02-26 00:06:07 EST
(In reply to comment #1)
> Agreed.  Probably just a copy-paste bug.
> 

Hopefully you mean this is the copy-paste bug:
void
NqstaWifiMac::Enqueue (Ptr<const Packet> packet, Mac48Address to, Mac48Address
from)
{
  NS_FATAL_ERROR ("Qsta does not support enqueue");
}


(stations need to support bridging also to enable the tap-mode emulation on those devices)
Comment 3 Gustavo J. A. M. Carneiro 2009-02-26 05:13:33 EST
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.
Comment 4 Tom Henderson 2009-02-26 09:20:54 EST
(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. 
Comment 5 Mathieu Lacage 2009-02-26 09:39:04 EST
(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. 


Well, you can try to, but you won't escape the fact that the 802.11 MAC protocol has no way to support bridging outside of infrastructure mode. This would require the use of extensions to the protocol. As far as I am concerned, this bug report is about the fact that NqstaWifiMac::SupportsSendFrom should return false.

Comment 6 Gustavo J. A. M. Carneiro 2009-02-26 09:42:44 EST
(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.
Comment 7 Tom Henderson 2009-02-26 09:58:11 EST
(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.

Comment 8 Aleksey Kovalenko 2009-02-27 03:39:41 EST
(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.
> 
In the dot11 standard exists 4-address scheme for DS-to-DS communications. The 4th address is real source address(SA) , the others as usual RA, DA,TA. In bridging mode one  can utilize this ability of the protocol to send packet transparently through bridging STA. It can be done by maintaining WDS table, filled on-demand. 
About real world:  All drivers used net80211 stack( all FreeBSD wireless subsystem, MadWifi( for Atheros  ) provide bridging functionality on the STA in the way described above.
Comment 9 Gustavo J. A. M. Carneiro 2009-02-27 04:55:49 EST
(In reply to comment #8)
> (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.
> > 
> In the dot11 standard exists 4-address scheme for DS-to-DS communications. The
> 4th address is real source address(SA) , the others as usual RA, DA,TA. In
> bridging mode one  can utilize this ability of the protocol to send packet
> transparently through bridging STA. It can be done by maintaining WDS table,
> filled on-demand. 

But DS-to-DS is meant only to be used between APs, never STAs, so my statement that only APs can do bridging is still true.  :-)

But you make a good point.  One option to implement the needed functionality would be to add WDS support to NqapWifiMac.

> About real world:  All drivers used net80211 stack( all FreeBSD wireless
> subsystem, MadWifi( for Atheros  ) provide bridging functionality on the STA in
> the way described above.

Correction, they provide bridging functionality in a "WiFi NIC", not a "STA".  I would call STA more of a role rather than a hardware.

And I know from experience that not all cards support this.  For instance, the Cisco cards that I used do not support it at all.  This is very non-standard.
Comment 10 Craig Dowell 2009-02-27 17:07:39 EST
I added this bug primarily due to an impedance mismatch regarding whether or not STA nodes supported SendFrom.

I rather hazily remembered an issue with SendFrom, but I think the answer is that the impedance in NqstaWifiMac is correct -- the resolution to this bug is along the lines of,

bool
NqstaWifiMac::SupportsSendFrom (void) const
{
  //
  // The 802.11 MAC protocol has no way to support bridging outside of
  // infrastructure mode
  //
  return false;
}

void
NqstaWifiMac::Enqueue (Ptr<const Packet> packet, Mac48Address to, Mac48Address
from)
{
  NS_FATAL_ERROR ("Qsta does not support SendFrom");
}

And the tap-bridge just has to deal with it ...
Comment 11 Tom Henderson 2009-03-01 13:55:57 EST
I would just support closing this bug out with (In reply to comment #10)
> I added this bug primarily due to an impedance mismatch regarding whether or
> not STA nodes supported SendFrom.
> 
> I rather hazily remembered an issue with SendFrom, but I think the answer is
> that the impedance in NqstaWifiMac is correct -- the resolution to this bug is
> along the lines of,
> 
> bool
> NqstaWifiMac::SupportsSendFrom (void) const
> {
>   //
>   // The 802.11 MAC protocol has no way to support bridging outside of
>   // infrastructure mode
>   //
>   return false;
> }
> 
> void
> NqstaWifiMac::Enqueue (Ptr<const Packet> packet, Mac48Address to, Mac48Address
> from)
> {
>   NS_FATAL_ERROR ("Qsta does not support SendFrom");
> }
> 
> And the tap-bridge just has to deal with it ...
> 

I think we'll be able to fix the tap bridge another way, so I support closing this out with the above.
Comment 12 Rajib Bhattacharjea 2009-03-13 11:45:40 EDT
Is the above okay with you Mathieu?  If so, I'll push the change before Wednesday.
Comment 13 Mathieu Lacage 2009-03-13 14:23:47 EDT
(In reply to comment #12)
> Is the above okay with you Mathieu?  If so, I'll push the change before
> Wednesday.
> 

yes, please. sorry for not handling this patch myself.
Comment 14 Craig Dowell 2009-03-13 14:51:36 EDT
I volunteered to investigate this bug and do the massive changes required to fix it.  It is done and will go in parallel with tracing changes.