Agreed.  Probably just a copy-paste bug.

(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)

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 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. 

(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.

(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.

(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.

(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.

(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.

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 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.

Is the above okay with you Mathieu?  If so, I'll push the change before
Wednesday.

(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.

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.