On Wed, 2012-04-25 at 19:28 +0200, Christian Lamparter wrote:

On Wednesday, April 25, 2012 07:28:18 AM Janusz Dziedzic wrote:

quoted

W dniu 23 kwietnia 2012 19:45 użytkownik Christian Lamparter
[off-list ref] napisał:

quoted

quoted

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.

johannes