carl9170: fix spurious transmissions in sniffer mode
Christian Lamparter
maintainerPATCH 1/1 carl9170: fix spurious transmissions in sniffer mode
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.
--- drivers/net/wireless/ath/carl9170/mac.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/carl9170/mac.c +18 -3
@@ -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 ; }
Signature · 1 line
1.7.10.4
Quoted 7 lines · 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.
Quoted 5 lines
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
Quoted 49 lines
Reported-by Johannes Berg <[email protected]>Reported-by Marco Fonseca <[email protected]>Reported-by Janusz Dziedzic <[email protected]>Signed-off-by Christian Lamparter <[email protected]>--- drivers/net/wireless/ath/carl9170/mac.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)drivers/net/wireless/ath/carl9170/mac.c +18
-3@@ -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 ; }
Christian Lamparter
maintainerQuoted 8 lines · On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
Quoted 7 lines · 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.
Quoted 7 lines
Quoted 5 lines
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".
Quoted 3 lines
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!
Quoted 2 lines
(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
Quoted 14 lines · Christian Lamparter
Quoted 13 lines · On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
Quoted 12 lines · 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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 27 lines
Quoted 4 lines
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!
Quoted 2 lines
(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
Christian Lamparter
maintainerQuoted 31 lines · On Wednesday 12 September 2012 01:46:01 Richard Farina wrote:
Quoted 14 lines · Christian Lamparter
Quoted 13 lines · On Wednesday 12 September 2012 00:03:40 Richard Farina wrote:
Quoted 12 lines · 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.Quoted 7 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 4 lines · Christian Lamparter
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.
Quoted 3 lines
(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
Christian Lamparter
maintainerQuoted 13 lines · 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.
Quoted 5 lines
Reported-by Johannes Berg <[email protected]>Reported-by Marco Fonseca <[email protected]>Reported-by Janusz Dziedzic <[email protected]>Signed-off-by Christian Lamparter <[email protected]>---
John,
Do you have doubts about this patch, or is there a problem that I don't know about?
Regards,
Chr
Christian Lamparter
maintainerQuoted 19 lines · On Saturday 13 October 2012 10:59:53 Christian Lamparter wrote:
Quoted 13 lines · 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.Quoted 5 lines
Reported-by Johannes Berg <[email protected]>Reported-by Marco Fonseca <[email protected]>Reported-by Janusz Dziedzic <[email protected]>Signed-off-by Christian Lamparter <[email protected]>---
Quoted 4 lines
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
Quoted 25 lines · Christian Lamparter
Quoted 19 lines · On Saturday 13 October 2012 10:59:53 Christian Lamparter wrote:
Quoted 13 lines · 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.Quoted 5 lines
Reported-by Johannes Berg <[email protected]>Reported-by Marco Fonseca <[email protected]>Reported-by Janusz Dziedzic <[email protected]>Signed-off-by Christian Lamparter <[email protected]>---
Quoted 4 lines
John,
Do you have doubts about this patch, or is there a problem that I don't know about?
Quoted 7 lines
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
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.