[PATCH] carl9170: fix spurious transmissions in sniffer mode

[PATCH] carl9170: fix spurious transmissions in sniffer mode

[Christian Lamparter]

Several people have complained about an unusual
and undocumented feature of the AR9170 hardware:

In siffer mode, the hardware generates spurious
ACK frames for every received frame... even
broadcasts.

The reason for this malfunction is unknown:
<http://marc.info/?l=linux-wireless&m=134517238506033>
But there's a workaround: Instead of the special
sniffer mode, the hardware will be put into
station mode and all rx filters are disabled.

Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Marco Fonseca <marco@tampabay.rr.com>
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
 drivers/net/wireless/ath/carl9170/mac.c |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/mac.c b/drivers/net/wireless/ath/carl9170/mac.c
index e3b1b6e..24d75ab 100644
--- a/drivers/net/wireless/ath/carl9170/mac.c
+++ b/drivers/net/wireless/ath/carl9170/mac.c
@@ -343,7 +343,24 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
 			break;
 		}
 	} else {
-		mac_addr = NULL;
+		/*
+		 * Enable monitor mode
+		 *
+		 * rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER;
+		 * sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC;
+		 *
+		 * When the hardware is in SNIFFER_PROMISC mode,
+		 * it generates spurious ACKs for every incoming
+		 * frame. This confuses every peer in the
+		 * vicinity and the network throughput will suffer
+		 * badly.
+		 *
+		 * Hence, the hardware will be put into station
+		 * mode and just the rx filters are disabled.
+		 */
+		cam_mode |= AR9170_MAC_CAM_STA;
+		rx_ctrl |= AR9170_MAC_RX_CTRL_PASS_TO_HOST;
+		mac_addr = common->macaddr;
 		bssid = NULL;
 	}
 	rcu_read_unlock();
@@ -355,8 +372,6 @@ 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;
-		sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC;
 		enc_mode |= AR9170_MAC_ENCRYPTION_RX_SOFTWARE;
 	}
 
-- 
1.7.10.4

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Richard Farina]

On 09/11/2012 05:18 PM, Christian Lamparter wrote:
> Several people have complained about an unusual
> and undocumented feature of the AR9170 hardware:
> 
> In siffer mode, the hardware generates spurious
> ACK frames for every received frame... even
> broadcasts.
> 
> The reason for this malfunction is unknown:
> <http://marc.info/?l=linux-wireless&m=134517238506033>
> But there's a workaround: Instead of the special
> sniffer mode, the hardware will be put into
> station mode and all rx filters are disabled.
I am by no means an expert here but wouldn't it be better to disable
ACK? Or is this not really an option?

Did you test to see if this actually does receive the same number of
packets as "special sniffer mode"? If so, that really should be in the
commit message imho. (I know you tested it, but since you didn't say it
the commit message reads like you didn't).

Thanks,
Zero
> 
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Reported-by: Marco Fonseca <marco@tampabay.rr.com>
> Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
>  drivers/net/wireless/ath/carl9170/mac.c |   21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/carl9170/mac.c b/drivers/net/wireless/ath/carl9170/mac.c
> index e3b1b6e..24d75ab 100644
> --- a/drivers/net/wireless/ath/carl9170/mac.c
> +++ b/drivers/net/wireless/ath/carl9170/mac.c
> @@ -343,7 +343,24 @@ int carl9170_set_operating_mode(struct ar9170 *ar)
>  			break;
>  		}
>  	} else {
> -		mac_addr = NULL;
> +		/*
> +		 * Enable monitor mode
> +		 *
> +		 * rx_ctrl |= AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER;
> +		 * sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC;
> +		 *
> +		 * When the hardware is in SNIFFER_PROMISC mode,
> +		 * it generates spurious ACKs for every incoming
> +		 * frame. This confuses every peer in the
> +		 * vicinity and the network throughput will suffer
> +		 * badly.
> +		 *
> +		 * Hence, the hardware will be put into station
> +		 * mode and just the rx filters are disabled.
> +		 */
> +		cam_mode |= AR9170_MAC_CAM_STA;
> +		rx_ctrl |= AR9170_MAC_RX_CTRL_PASS_TO_HOST;
> +		mac_addr = common->macaddr;
>  		bssid = NULL;
>  	}
>  	rcu_read_unlock();
> @@ -355,8 +372,6 @@ 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;
> -		sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC;
>  		enc_mode |= AR9170_MAC_ENCRYPTION_RX_SOFTWARE;
>  	}
>  
> 

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Christian Lamparter]

On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
> On 09/11/2012 05:18 PM, Christian Lamparter wrote:
> > Several people have complained about an unusual
> > and undocumented feature of the AR9170 hardware:
> > 
> > In siffer mode, the hardware generates spurious
> > ACK frames for every received frame... even
> > broadcasts.
> > 
> > The reason for this malfunction is unknown:
> > <http://marc.info/?l=linux-wireless&m=134517238506033>
> > But there's a workaround: Instead of the special
> > sniffer mode, the hardware will be put into
> > station mode and all rx filters are disabled.
> I am by no means an expert here but wouldn't it be better to disable
> ACK? Or is this not really an option?
Oh AFAIK there's some nifty software which emulates
some sort of accesspoint by (ab-)using monitor mode
and injection. And in this case having a device which
ACKs any frame destined for the semi-fake ap might be
a "good thing".

> Did you test to see if this actually does receive the same number of
> packets as "special sniffer mode"? If so, that really should be in the
> commit message imho.
One problem is that you can't really take two devices,
attach them to separate machines (one machine is patched,
the other isn't) and do a "head-to-head" comparison.
The device on the machine without the "fix" will happily
generate spurious messages which will be picked up by
everyone else (including the other machine). However,
the device on the patched machine does not generate
bogus ACKs, so the device without the patch does not
notice anything unusual... (Yep, this is very confusing.)

Note: The AR9170 MAC hardware does not feed generated
control frames like ACK,RTS/CTS,BACKs, etc... back to
the driver. Only those from other peers are picked up!

> (I know you tested it, but since you didn't say it
> the commit message reads like you didn't).
You are right, but what I need are "Tested-by" tags.
It's sort of pointless if I just add a "works-for-me",
as I do very little with monitor mode.

Regards,
	Chr

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Richard Farina]

On 09/11/2012 07:26 PM, Christian Lamparter wrote:
> On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
>> On 09/11/2012 05:18 PM, Christian Lamparter wrote:
>>> Several people have complained about an unusual
>>> and undocumented feature of the AR9170 hardware:
>>>
>>> In siffer mode, the hardware generates spurious
>>> ACK frames for every received frame... even
>>> broadcasts.
>>>
>>> The reason for this malfunction is unknown:
>>> <http://marc.info/?l=linux-wireless&m=134517238506033>
>>> But there's a workaround: Instead of the special
>>> sniffer mode, the hardware will be put into
>>> station mode and all rx filters are disabled.
>> I am by no means an expert here but wouldn't it be better to disable
>> ACK? Or is this not really an option?
> Oh AFAIK there's some nifty software which emulates
> some sort of accesspoint by (ab-)using monitor mode
> and injection. And in this case having a device which
> ACKs any frame destined for the semi-fake ap might be
> a "good thing".
Are you referencing airbase-ng here?  Airbase-ng assumes the hardware
does not ack in monitor mode and therefore does it itself.  Mind you,
I'm not saying it wouldn't be nice to have the hardware ack (VASTLY
improved response time for one) but a monitor mode vif is assumed to not
transmit anything at all, unless we specifically inject it.

An ack on/off (default off) would be awesome, but baring that the only
sane choice is off.

Thanks,
Zero
> 
>> Did you test to see if this actually does receive the same number of
>> packets as "special sniffer mode"? If so, that really should be in the
>> commit message imho.
> One problem is that you can't really take two devices,
> attach them to separate machines (one machine is patched,
> the other isn't) and do a "head-to-head" comparison.
> The device on the machine without the "fix" will happily
> generate spurious messages which will be picked up by
> everyone else (including the other machine). However,
> the device on the patched machine does not generate
> bogus ACKs, so the device without the patch does not
> notice anything unusual... (Yep, this is very confusing.)
> 
> Note: The AR9170 MAC hardware does not feed generated
> control frames like ACK,RTS/CTS,BACKs, etc... back to
> the driver. Only those from other peers are picked up!
> 
>> (I know you tested it, but since you didn't say it
>> the commit message reads like you didn't).
> You are right, but what I need are "Tested-by" tags.
> It's sort of pointless if I just add a "works-for-me",
> as I do very little with monitor mode.
> 
> Regards,
> 	Chr
> 

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Christian Lamparter]

On Wednesday 12 September 2012 01:46:01 Richard Farina wrote:
> On 09/11/2012 07:26 PM, Christian Lamparter wrote:
> > On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
> >> On 09/11/2012 05:18 PM, Christian Lamparter wrote:
> >>> Several people have complained about an unusual
> >>> and undocumented feature of the AR9170 hardware:
> >>>
> >>> In siffer mode, the hardware generates spurious
> >>> ACK frames for every received frame... even
> >>> broadcasts.
> >>>
> >>> The reason for this malfunction is unknown:
> >>> <http://marc.info/?l=linux-wireless&m=134517238506033>
> >>> But there's a workaround: Instead of the special
> >>> sniffer mode, the hardware will be put into
> >>> station mode and all rx filters are disabled.
> >> I am by no means an expert here but wouldn't it be better to disable
> >> ACK? Or is this not really an option?
> > Oh AFAIK there's some nifty software which emulates
> > some sort of accesspoint by (ab-)using monitor mode
> > and injection. And in this case having a device which
> > ACKs any frame destined for the semi-fake ap might be
> > a "good thing".
>
> Are you referencing airbase-ng here? Airbase-ng assumes
> the hardware does not ack in monitor mode and therefore
> does it itself.  Mind you, I'm not saying it wouldn't be
> nice to have the hardware ack (VASTLY improved response
> time for one) but a monitor mode vif is assumed to not
> transmit anything at all, unless we specifically inject
> it.
> 
> An ack on/off (default off) would be awesome, but baring
> that the only sane choice is off.
I'm no expert either, but isn't airbase-ng more of a client
attack tool suite than a useful softAP? No, it must have
been a different software then.

Anyway, now the hardware will only react to frames that
are "directed" (DA matches either the main, or one of
the 8 vif mac addresses) to it (is this now sane or
not?). So, the hardware ack ability is not going to just
disappear, if someone is already depending on it.

(BTW: wasn't there once some sort of a "tx ack" control
interface in mac80211 debugfs path? Does anybody know
what happend to it?)

Regards,
	Chr

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Johannes Berg]

On Wed, 2012-09-12 at 03:08 +0200, Christian Lamparter wrote:

> Anyway, now the hardware will only react to frames that
> are "directed" (DA matches either the main, or one of
> the 8 vif mac addresses) to it (is this now sane or
> not?).

That's reasonable. A lot of hardware behaves that way, and for many
injection use cases it is actually desired while normal monitoring use
cases aren't really affected. If you'd want to not have this you could
inject with a different MAC address, so it's still fine.

> (BTW: wasn't there once some sort of a "tx ack" control
> interface in mac80211 debugfs path? Does anybody know
> what happend to it?)

It moved into cfg80211/nl80211, but it's only applicable for properly
transmitted QoS frames anyway.

johannes

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Christian Lamparter]

On Tuesday 11 September 2012 23:18:34 Christian Lamparter wrote:
> Several people have complained about an unusual
> and undocumented feature of the AR9170 hardware:
> 
> In siffer mode, the hardware generates spurious
> ACK frames for every received frame... even
> broadcasts.
> 
> The reason for this malfunction is unknown:
> <http://marc.info/?l=linux-wireless&m=134517238506033>
> But there's a workaround: Instead of the special
> sniffer mode, the hardware will be put into
> station mode and all rx filters are disabled.
> 
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Reported-by: Marco Fonseca <marco@tampabay.rr.com>
> Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
John,

Do you have doubts about this patch, or is there a problem 
that I don't know about?

Regards,
	Chr

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[Christian Lamparter]

On Saturday 13 October 2012 10:59:53 Christian Lamparter wrote:
> On Tuesday 11 September 2012 23:18:34 Christian Lamparter wrote:
> > Several people have complained about an unusual
> > and undocumented feature of the AR9170 hardware:
> > 
> > In siffer mode, the hardware generates spurious
> > ACK frames for every received frame... even
> > broadcasts.
> > 
> > The reason for this malfunction is unknown:
> > <http://marc.info/?l=linux-wireless&m=134517238506033>
> > But there's a workaround: Instead of the special
> > sniffer mode, the hardware will be put into
> > station mode and all rx filters are disabled.
> > 
> > Reported-by: Johannes Berg <johannes@sipsolutions.net>
> > Reported-by: Marco Fonseca <marco@tampabay.rr.com>
> > Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > ---
> John,
> 
> Do you have doubts about this patch, or is there a problem 
> that I don't know about?

John,

can you comment? Or do you need a resend? Or should I stop
asking about it ;)?

Regards,
	Chr

Re: [PATCH] carl9170: fix spurious transmissions in sniffer mode

[John W. Linville]

On Fri, Oct 26, 2012 at 08:07:16PM +0200, Christian Lamparter wrote:
> On Saturday 13 October 2012 10:59:53 Christian Lamparter wrote:
> > On Tuesday 11 September 2012 23:18:34 Christian Lamparter wrote:
> > > Several people have complained about an unusual
> > > and undocumented feature of the AR9170 hardware:
> > > 
> > > In siffer mode, the hardware generates spurious
> > > ACK frames for every received frame... even
> > > broadcasts.
> > > 
> > > The reason for this malfunction is unknown:
> > > <http://marc.info/?l=linux-wireless&m=134517238506033>
> > > But there's a workaround: Instead of the special
> > > sniffer mode, the hardware will be put into
> > > station mode and all rx filters are disabled.
> > > 
> > > Reported-by: Johannes Berg <johannes@sipsolutions.net>
> > > Reported-by: Marco Fonseca <marco@tampabay.rr.com>
> > > Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > ---
> > John,
> > 
> > Do you have doubts about this patch, or is there a problem 
> > that I don't know about?
> 
> John,
> 
> can you comment? Or do you need a resend? Or should I stop
> asking about it ;)?
> 
> Regards,
> 	Chr

It looks fine.  There was a lot of comments in the original thread,
which probably explains why I've been overlooking it.  I'll try to
include it when I get back to merging for -next (soon).

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.