Hello,
I am using newest compat-wireless + newest-firmware.
Next I setup monitor mode + channel and run wireshark - I do that to
record TCP flow on the channel.
Before that I had TCP throughput about 30Mbit/s and after run
wireshark I see TP drop - about 3Mbit/s (after setting monitor mode).
This TP is between AP and other STA on the same channel.
Should I set/check something more to not see this TP drop?
BR
Janusz
On Wednesday, April 25, 2012 07:28:18 AM Janusz Dziedzic wrote:
> W dniu 23 kwietnia 2012 19:45 u?ytkownik Christian Lamparter
> <[email protected]> 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.
Regards,
Chr
On Thursday, April 26, 2012 09:45:22 AM Janusz Dziedzic wrote:
> W dniu 25 kwietnia 2012 20:54 u?ytkownik Christian Lamparter
> So, what steps you suggest?
> I would like to record traffic from channel 6 and would like to not
> have this SNIFFER ACK.
>
> This is what I tried:
> - ifconfig wlan0 up (no matter if up or down)
> - iw phy phy0 interface add moni0 type monitor
> - iw phy phy0 set channel 6
> - ifconfig moni0 up
>
> After last step I still see TP drop between AP and STA1 on channel6
Uh that's right. it was:
iw phy0 interface add moni type monitor flags none
the "flags none" is the important bit.
Regards,
Christian
W dniu 23 kwietnia 2012 19:45 u?ytkownik Christian Lamparter
<[email protected]> napisa?:
> On Monday, April 23, 2012 06:27:03 AM Janusz Dziedzic wrote:
>> This is a scenario:
>> AP <--> STA1 (channel 6)
>> STA2 == carl_monitor (channel 6)
> ah, I assumed you were running the STA & Monitor on the same
> device [which is possible for most mac80211 devices!].
>
>> This is what I can see on STA1:
>> # iperf -c 192.168.254.1 -t 100 -i 5
>> ------------------------------------------------------------
>> Client connecting to 192.168.254.1, TCP port 5001
>> TCP window size: ?512 KByte (default)
>> ------------------------------------------------------------
>> [ ?3] local 192.168.254.181 port 46048 connected with 192.168.254.1 port 5001
>> [ ID] Interval ? ? ? Transfer ? ? Bandwidth
>> [ ?3] ?0.0- 5.0 sec ?17.4 MBytes ?29.2 Mbits/sec
>> [ ?3] ?5.0-10.0 sec ?19.6 MBytes ?32.9 Mbits/sec
>> [ 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
>> [ ?3] 45.0-50.0 sec ?2.50 MBytes ?4.19 Mbits/sec
>> [ ?3] 50.0-55.0 sec ?3.00 MBytes ?5.03 Mbits/sec
>>
>> Seems I don't even need to start wireshark here ... and see this TP drop.
> Well, there's the "AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER = bit (30)"
> in "AR9170_MAC_REG_RX_CONTROL = (0x1c3c40)". ?If you have enabled
> CONFIG_CARL9170_DEBUGFS build option, you can disable this
> bit (on the fly) by executing:
>
> echo "0x1c3c40 0x10000003" > /sys/kernel/debug/ieee80211/phyX/carl9170/hw_iowrite32
>
> (phyX needs to be the phy dev of the carl9170 instance)
>
> and there's the AR9170_MAC_SNIFFER_ENABLE_PROMISC (bit 0) in
> AR9170_MAC_REG_SNIFFER (0x1c3674). Which can be disabled in a
> similar way:
>
> echo "0x1c3674 0x02000000" > /sys/...
>
Hello,
Thanks Christian.
I disabled this in code.
diff --git a/drivers/net/wireless/ath/carl9170/mac.c
b/drivers/net/wireless/ath/carl9170/mac.c
index 53415bf..f3a7669 100644
--- a/drivers/net/wireless/ath/carl9170/mac.c
+++ b/drivers/net/wireless/ath/carl9170/mac.c
@@ -354,7 +354,7 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
enc_mode |= AR9170_MAC_ENCRYPTION_RX_SOFTWARE;
if (ar->sniffer_enabled) {
- rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER;
+// rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER;
sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC;
enc_mode |= AR9170_MAC_ENCRYPTION_RX_SOFTWARE;
}
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?
BR
Janusz
On Monday, April 23, 2012 06:27:03 AM Janusz Dziedzic wrote:
> This is a scenario:
> AP <--> STA1 (channel 6)
> STA2 == carl_monitor (channel 6)
ah, I assumed you were running the STA & Monitor on the same
device [which is possible for most mac80211 devices!].
> This is what I can see on STA1:
> # iperf -c 192.168.254.1 -t 100 -i 5
> ------------------------------------------------------------
> Client connecting to 192.168.254.1, TCP port 5001
> TCP window size: 512 KByte (default)
> ------------------------------------------------------------
> [ 3] local 192.168.254.181 port 46048 connected with 192.168.254.1 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 5.0 sec 17.4 MBytes 29.2 Mbits/sec
> [ 3] 5.0-10.0 sec 19.6 MBytes 32.9 Mbits/sec
> [ 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
> [ 3] 45.0-50.0 sec 2.50 MBytes 4.19 Mbits/sec
> [ 3] 50.0-55.0 sec 3.00 MBytes 5.03 Mbits/sec
>
> Seems I don't even need to start wireshark here ... and see this TP drop.
Well, there's the "AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER = bit (30)"
in "AR9170_MAC_REG_RX_CONTROL = (0x1c3c40)". If you have enabled
CONFIG_CARL9170_DEBUGFS build option, you can disable this
bit (on the fly) by executing:
echo "0x1c3c40 0x10000003" > /sys/kernel/debug/ieee80211/phyX/carl9170/hw_iowrite32
(phyX needs to be the phy dev of the carl9170 instance)
and there's the AR9170_MAC_SNIFFER_ENABLE_PROMISC (bit 0) in
AR9170_MAC_REG_SNIFFER (0x1c3674). Which can be disabled in a
similar way:
echo "0x1c3674 0x02000000" > /sys/...
Regards,
Christian
On Friday 20 April 2012 09:41:15 Janusz Dziedzic wrote:
> Hello,
>
> I am using newest compat-wireless + newest-firmware.
> Next I setup monitor mode + channel and run wireshark - I do that to
> record TCP flow on the channel.
>
> Before that I had TCP throughput about 30Mbit/s and after run
> wireshark I see TP drop - about 3Mbit/s (after setting monitor mode).
> This TP is between AP and other STA on the same channel.
>
> Should I set/check something more to not see this TP drop?
Well, I don't know how you exactly setup the mode. But If
the monitor interface is set to PROMISC, then it's likely
that the hardware will be set into a special "sniffer"
operation mode. This mode is great if you are interested in
frames with bad PLCPs and FCS but it is not so great for
throughput because the rx filter won't filter anymore and
the tons of garbage that usually is dropped early on gets
passed to the host and on it's way it competes for FIFO
resources with the data.
(One more thing: Isn't it possible to get the TCP flow,
from the "ethernet" (as ifconfig calls it) interface of
the wlan device as well?)
Regards,
Christian
On Wednesday, April 25, 2012 08:24:23 PM Janusz Dziedzic wrote:
> W dniu 25 kwietnia 2012 19:28 u?ytkownik Christian Lamparter
> <[email protected]> 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
W dniu 25 kwietnia 2012 20:54 u?ytkownik Christian Lamparter
<[email protected]> napisa?:
> On Wednesday, April 25, 2012 08:24:23 PM Janusz Dziedzic wrote:
>> W dniu 25 kwietnia 2012 19:28 u?ytkownik Christian Lamparter
>> <[email protected]> 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].
>
So, what steps you suggest?
I would like to record traffic from channel 6 and would like to not
have this SNIFFER ACK.
This is what I tried:
- ifconfig wlan0 up (no matter if up or down)
- iw phy phy0 interface add moni0 type monitor
- iw phy phy0 set channel 6
- ifconfig moni0 up
After last step I still see TP drop between AP and STA1 on channel6
BR
Janusz
On Mon, 2012-04-23 at 06:27 +0200, Janusz Dziedzic wrote:
> This is a scenario:
> AP <--> STA1 (channel 6)
> STA2 == carl_monitor (channel 6)
>
> This is what I can see on STA1:
> # iperf -c 192.168.254.1 -t 100 -i 5
> ------------------------------------------------------------
> Client connecting to 192.168.254.1, TCP port 5001
> TCP window size: 512 KByte (default)
> ------------------------------------------------------------
> [ 3] local 192.168.254.181 port 46048 connected with 192.168.254.1 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 5.0 sec 17.4 MBytes 29.2 Mbits/sec
> [ 3] 5.0-10.0 sec 19.6 MBytes 32.9 Mbits/sec
> [ 3] 10.0-15.0 sec 20.4 MBytes 34.2 Mbits/sec
> [ 3] 15.0-20.0 sec 19.8 MBytes 33.1 Mbits/sec
> [ 3] 20.0-25.0 sec 19.8 MBytes 33.1 Mbits/sec
> [ 3] 25.0-30.0 sec 19.8 MBytes 33.1 Mbits/sec
> [ 3] 30.0-35.0 sec 19.6 MBytes 32.9 Mbits/sec
> [ 3] 35.0-40.0 sec 18.1 MBytes 30.4 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
> [ 3] 45.0-50.0 sec 2.50 MBytes 4.19 Mbits/sec
> [ 3] 50.0-55.0 sec 3.00 MBytes 5.03 Mbits/sec
>
> Seems I don't even need to start wireshark here ... and see this TP drop.
FWIW, I have observed this as well (in the past, my ar9170 devices all
died now)
johannes
W dniu 25 kwietnia 2012 19:28 u?ytkownik Christian Lamparter
<[email protected]> napisa?:
> On Wednesday, April 25, 2012 07:28:18 AM Janusz Dziedzic wrote:
>> W dniu 23 kwietnia 2012 19:45 u?ytkownik Christian Lamparter
>> <[email protected]> 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.
>
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?
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?
BR
Janusz
W dniu 20 kwietnia 2012 19:59 u?ytkownik Christian Lamparter
<[email protected]> napisa?:
> On Friday 20 April 2012 09:41:15 Janusz Dziedzic wrote:
>> Hello,
>>
>> I am using newest compat-wireless + newest-firmware.
>> Next I setup monitor mode + channel and run wireshark - I do that to
>> record TCP flow on the channel.
>>
>> Before that I had TCP throughput about 30Mbit/s and after run
>> wireshark I see TP drop - about 3Mbit/s (after setting monitor mode).
>> This TP is between AP and other STA on the same channel.
>>
>> Should I set/check something more to not see this TP drop?
>
> Well, I don't know how you exactly setup the mode. But If
> the monitor interface is set to PROMISC, then it's likely
> that the hardware will be set into a special "sniffer"
> operation mode. This mode is great if you are interested in
> frames with bad PLCPs and FCS but it is not so great for
> throughput because the rx filter won't filter anymore and
> the tons of garbage that usually is dropped early on gets
> passed to the host and on it's way it competes for FIFO
> resources with the data.
>
> (One more thing: Isn't it possible to get the TCP flow,
> from the "ethernet" (as ifconfig calls it) interface of
> the wlan device as well?)
>
This is a scenario:
AP <--> STA1 (channel 6)
STA2 == carl_monitor (channel 6)
This is what I can see on STA1:
# iperf -c 192.168.254.1 -t 100 -i 5
------------------------------------------------------------
Client connecting to 192.168.254.1, TCP port 5001
TCP window size: 512 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.254.181 port 46048 connected with 192.168.254.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 17.4 MBytes 29.2 Mbits/sec
[ 3] 5.0-10.0 sec 19.6 MBytes 32.9 Mbits/sec
[ 3] 10.0-15.0 sec 20.4 MBytes 34.2 Mbits/sec
[ 3] 15.0-20.0 sec 19.8 MBytes 33.1 Mbits/sec
[ 3] 20.0-25.0 sec 19.8 MBytes 33.1 Mbits/sec
[ 3] 25.0-30.0 sec 19.8 MBytes 33.1 Mbits/sec
[ 3] 30.0-35.0 sec 19.6 MBytes 32.9 Mbits/sec
[ 3] 35.0-40.0 sec 18.1 MBytes 30.4 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
[ 3] 45.0-50.0 sec 2.50 MBytes 4.19 Mbits/sec
[ 3] 50.0-55.0 sec 3.00 MBytes 5.03 Mbits/sec
Seems I don't even need to start wireshark here ... and see this TP drop.
BR
Janusz
On Thu, 2012-05-03 at 23:44 +0200, Christian Lamparter 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.
> >
> > 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?
No, see 4b6f1dd6a6faf4ed8d209bbd548e78b15e55aee8
johannes
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
> > > <[email protected]> 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
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
> > <[email protected]> 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.
johannes