Re: carl9170 - monitor mode TP drop

[Christian Lamparter <chunkeey@googlemail.com>]

On Wednesday, April 25, 2012 08:24:23 PM Janusz Dziedzic wrote:
> W dniu 25 kwietnia 2012 19:28 użytkownik Christian Lamparter
> <chunkeey@googlemail.com> napisał:
> > On Wednesday, April 25, 2012 07:28:18 AM Janusz Dziedzic wrote:
> > You see without the BIT set, the hardware won't sent any ACKs
> > (Not even those which are directed at this interface - which of
> > course is also bad, or even worse?) and with the BIT set (and if
> > the HW is in Sniffer Mode) then the hardware acks every frames,
> > even if they are for a different stations.
> > So your fix might break someone else's setup.
> >
> 
> As I understand, some time ago we had wpa_supplicant AP (GO) mode
> as a two interfaces: AP + MONITOR.
> But now MONITOR is not used.
> Do you know other setup?
I think you are refering to the "cooked" monitor interface, which is
just a monitor interface that gives you frames that mac80211 has
not used internally [mac80211: Add cooked monitor mode support].

In fact, most monitors are purly virtual interfaces, unless the
device only has one interface and it is set into monitor mode.
[So, if you don't want to deal with the RX_CTRL_ACK_IN_SNIFFER
bit all you need to do is: add a monitor interface (rather than
set the current interface into this mode) on your STA2 "client" 
<http://linuxwireless.org/en/users/Documentation/iw#Adding_interfaces_with_iw>

Note: This is actually the prefered, because you can use the "normal"
station interface to connect to the web and listen to the air with
the virtual monitor interface on the same device at the same time!]

> So, maybe firmware should ACK  frames with correct destination address
> only (if AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER)?
> Or that is not possible because of HW limitation?
The ACK mechanism (as well as most of the MAC) is done by the hardware
because of the critical timing [and lack of free space]. 

Regards,
	Chr