Re: carl9170 - monitor mode TP drop

[Christian Lamparter <chunkeey@googlemail.com>]

On Thursday, May 03, 2012 09:58:28 AM Johannes Berg wrote:
> On Wed, 2012-04-25 at 19:28 +0200, Christian Lamparter wrote:
> > On Wednesday, April 25, 2012 07:28:18 AM Janusz Dziedzic wrote:
> > > W dniu 23 kwietnia 2012 19:45 użytkownik Christian Lamparter
> > > <chunkeey@googlemail.com> napisał:
> > > >> This is what I can see on STA1:
> > > >> # iperf -c 192.168.254.1 -t 100 -i 5
> > > >> [ 3] 10.0-15.0 sec  20.4 MBytes  34.2 Mbits/sec
> > > >>
> > > >> =====> here I setup carl monitor on second PC, like this:
> > > >> =====> iw dev wlan0 set type monitor
> > > >> =====> iw dev wlan0 set freq 2437
> > > >> =====> ifconfig wlan0 up
> > > >>
> > > >> [  3] 40.0-45.0 sec  2.38 MBytes  3.98 Mbits/sec
> > > > Well, there's the "AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER = bit (30)"
> > > > in "AR9170_MAC_REG_RX_CONTROL = (0x1c3c40)".
> > > I disabled this in code.
> > > 
> > > -               rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER;
> > > +//             rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER;
> > > 
> > > After that I don't see any TP drop and can see all packets in
> > > wireshark (as expected).
> > > 
> > > Why carl try to ACK rx packets in monitor mode?
> > > Is that a correct behaviour?
> > Well, it depends.
> > 
> > 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.
> 
> You may want to implement the new monitor-mode-vif-to-driver thing in
> mac80211 which tells you when you're in *pure* monitor mode.

"the new monitor-mode-vif-to-driver"?
Do you mean like adding a new IFTYPE flag? Or more like a FIF_* flag
(probably)? for the "pure" monitor/sniffer mode?

Regards,
	Chr