Hello All,
I've noticed unexpected transmissions from the AR9170 while in monitor mode
and using tcpdump (and sometimes without tcpdump running). These
transmissions degrade (pretty significantly) performance of other STA/AP on
the channel (as seen by iperf going from 60mbit/s to almost nill). As best I
can tell these transmissions never coalesces into an actual frame in the air
(at least not one I'm able to pick up with a second different adapter in
monitor mode).
Are there any known reasons/bugs on this? Is there anyway to completely
silence the transmitter of the AR9170 while still allowing reception?
Some additional information that may give some context:
- This seems to happen over a wide range of releases of compat wireless I've
tried, I've tested between compat wireless 2.6.39-rc6-1 and 2012-7-03,
various drivers and firmware (the latest being driver 1.9.4 and firmware
1.9.5). I've also seen the problem across multiple AR9170 adapters, as well
as different linux hosts.
- I've put a few printk's in the carl driver & stubbed out (somewhat blindly)
some of the tx functions in wlan.c in the firmware to see if I could silence
or get a clue on whats going on, with not much success. The problem still
occurred (No prink's told me the kernel wasn't actively generating any
pkts).
- Seems like the transmissions only occur when monitoring 802.11n speeds.
(That is if I manual configure the AP to 54mbit/s, I don't see the
issue). Happens in both 2.4 or 5ghz band.
- I was able to also observe this behavior with a single ping. Only seemed to
occur with larger ICMP pings (would occur with -s 2000 pings, but not a
standard (56 byte) ping).
- Along with iperf degradation, I've verified transmissions with a spectrum
analyzer.
Thank you,
Marco Fonseca
Q2FuIHdlIHRlbGwgd2hhdCBraW5kIG9mIHVuZXhwZWN0ZWQgZnJhbWUgYXJlIGJlZW4gdHJhbnNt
aXR0ZWQ/IChEYXRhIGZyYW1lIG9yIHdoaWNoIGtpbmQgb2YgY29udHJvbCBmcmFtZT8pDQpUaGF0
IG1heSBnaXZlIHVzIGEgY2x1ZS4NCg0KDQpUaGFuayB5b3UuDQpTdGVwaGVuDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RpYW4gTGFtcGFydGVyIFttYWlsdG86Y2h1
bmtlZXlAZ29vZ2xlbWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTIgMzoz
NSBBTQ0KVG86IEpvaGFubmVzIEJlcmcNCkNjOiBNYXJjbyBGb25zZWNhOyBsaW51eC13aXJlbGVz
c0B2Z2VyLmtlcm5lbC5vcmc7IENoZW4sIFN0ZXBoZW4NClN1YmplY3Q6IFJlOiBjYXJsOTE3MDog
VW5pbnRlbnRpb25hbCB0cmFuc21pc3Npb24gaW4gbW9uaXRvciBtb2RlPw0KDQpPbiBUaHVyc2Rh
eSwgQXVndXN0IDE2LCAyMDEyIDA5OjIwOjU1IFBNIEpvaGFubmVzIEJlcmcgd3JvdGU6DQo+IE9u
IFRodSwgMjAxMi0wOC0wOSBhdCAyMTo0MyArMDIwMCwgQ2hyaXN0aWFuIExhbXBhcnRlciB3cm90
ZToNCj4gPiBPbiBUaHVyc2RheSwgQXVndXN0IDA5LCAyMDEyIDA2OjU0OjM0IFBNIE1hcmNvIEZv
bnNlY2Egd3JvdGU6DQo+ID4gPiBIZWxsbyBBbGwsDQo+ID4gPiANCj4gPiA+IEkndmUgbm90aWNl
ZCB1bmV4cGVjdGVkIHRyYW5zbWlzc2lvbnMgZnJvbSB0aGUgQVI5MTcwIHdoaWxlIGluIA0KPiA+
ID4gbW9uaXRvciBtb2RlIGFuZCB1c2luZyB0Y3BkdW1wIChhbmQgc29tZXRpbWVzIHdpdGhvdXQg
dGNwZHVtcCANCj4gPiA+IHJ1bm5pbmcpLiAgVGhlc2UgdHJhbnNtaXNzaW9ucyBkZWdyYWRlIChw
cmV0dHkgc2lnbmlmaWNhbnRseSkgDQo+ID4gPiBwZXJmb3JtYW5jZSBvZiBvdGhlciBTVEEvQVAg
b24gdGhlIGNoYW5uZWwgKGFzIHNlZW4gYnkgaXBlcmYgZ29pbmcgDQo+ID4gPiBmcm9tIDYwbWJp
dC9zIHRvIGFsbW9zdCBuaWxsKS4gIEFzIGJlc3QgSSBjYW4gdGVsbCB0aGVzZSANCj4gPiA+IHRy
YW5zbWlzc2lvbnMgbmV2ZXIgY29hbGVzY2VzIGludG8gYW4gYWN0dWFsIGZyYW1lIGluIHRoZSBh
aXIgKGF0IA0KPiA+ID4gbGVhc3Qgbm90IG9uZSBJJ20gYWJsZSB0byBwaWNrIHVwIHdpdGggYSBz
ZWNvbmQgZGlmZmVyZW50IGFkYXB0ZXIgaW4gbW9uaXRvciBtb2RlKS4NCj4gPiA+IA0KPiA+ID4g
QXJlIHRoZXJlIGFueSBrbm93biByZWFzb25zL2J1Z3Mgb24gdGhpcz8gIElzIHRoZXJlIGFueXdh
eSB0byANCj4gPiA+IGNvbXBsZXRlbHkgc2lsZW5jZSB0aGUgdHJhbnNtaXR0ZXIgb2YgdGhlIEFS
OTE3MCB3aGlsZSBzdGlsbCBhbGxvd2luZyByZWNlcHRpb24/DQo+ID4gPiANCj4gPiB5ZXMuIDxo
dHRwOi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2xpbnV4LXdpcmVsZXNzL21zZzg4ODk2Lmh0bWw+
DQo+ID4gDQo+ID4gYSBzb2x1dGlvbiBpcyBkZXNjcmliZWQgaW46DQo+ID4gPGh0dHA6Ly93d3cu
c3Bpbmljcy5uZXQvbGlzdHMvbGludXgtd2lyZWxlc3MvbXNnODkyNzkuaHRtbD4NCj4gPiANCj4g
PiAoaXcgZGV2IHdsYW5YIHNldCBtb25pdG9yIG5vbmUgLSBpZiBJJ20gbm90IG1pc3Rha2VuKQ0K
PiANCj4gSSd2ZSBzZWVuIHRoaXMgYmVmb3JlIHRvbyAtLSB3aGF0IGZsYWcgY2F1c2VzIHRoZSBp
c3N1ZSwgYW5kIHdoeT8NCldlbGwgdGhhdCB3b3VsZCBiZToNCkZJRl9PVEhFUl9CU1Mgb3IgRklG
X1BST01JU0NfSU5fQlNTDQoNCmVpdGhlciBvbmUgb2YgdGhlc2Ugd2lsbCBzZXQgZm9sbG93aW5n
IGZsYWdzIGZvciB0aGUgaGFyZHdhcmU6DQoNCkFSOTE3MF9NQUNfUlhfQ1RSTF9BQ0tfSU5fU05J
RkZFUg0KQVI5MTcwX01BQ19TTklGRkVSX0VOQUJMRV9QUk9NSVNDDQoNCkFib3V0IHRoZSBpc3N1
ZSwgSSdtIHJlYWxseSBjYW4ndCB0ZWxsIHcvbyBzY2hlbWF0aWNzIG9mIHRoZSBoYXJkd2FyZS4g
SXQgY291bGQgYmUgdGhhdCBBQ0tfSU5fU05JRkZFUiBpcyBtb3JlIG9mIGEgZGVidWcvdGVzdCBm
bGFnIHRoYW4gYSByZWFsIGZlYXR1cmU/DQoNCihBbnl3YXksIEkgY2MnZCBTdGVwaGVuLiBNYXli
ZSBoZSBrbm93cyBtb3JlKQ0KDQpSZWdhcmRzLA0KCUNocg0K
On Thu, 2012-08-09 at 21:43 +0200, Christian Lamparter wrote:
> On Thursday, August 09, 2012 06:54:34 PM Marco Fonseca wrote:
> > Hello All,
> >
> > I've noticed unexpected transmissions from the AR9170 while in monitor mode
> > and using tcpdump (and sometimes without tcpdump running). These
> > transmissions degrade (pretty significantly) performance of other STA/AP on
> > the channel (as seen by iperf going from 60mbit/s to almost nill). As best I
> > can tell these transmissions never coalesces into an actual frame in the air
> > (at least not one I'm able to pick up with a second different adapter in
> > monitor mode).
> >
> > Are there any known reasons/bugs on this? Is there anyway to completely
> > silence the transmitter of the AR9170 while still allowing reception?
> >
> yes. <http://www.spinics.net/lists/linux-wireless/msg88896.html>
>
> a solution is described in:
> <http://www.spinics.net/lists/linux-wireless/msg89279.html>
>
> (iw dev wlanX set monitor none - if I'm not mistaken)
I've seen this before too -- what flag causes the issue, and why?
johannes
On Thursday, August 09, 2012 06:54:34 PM Marco Fonseca wrote:
> Hello All,
>
> I've noticed unexpected transmissions from the AR9170 while in monitor mode
> and using tcpdump (and sometimes without tcpdump running). These
> transmissions degrade (pretty significantly) performance of other STA/AP on
> the channel (as seen by iperf going from 60mbit/s to almost nill). As best I
> can tell these transmissions never coalesces into an actual frame in the air
> (at least not one I'm able to pick up with a second different adapter in
> monitor mode).
>
> Are there any known reasons/bugs on this? Is there anyway to completely
> silence the transmitter of the AR9170 while still allowing reception?
>
yes. <http://www.spinics.net/lists/linux-wireless/msg88896.html>
a solution is described in:
<http://www.spinics.net/lists/linux-wireless/msg89279.html>
(iw dev wlanX set monitor none - if I'm not mistaken)
Regards,
Chr
To be honest, I have no idea why the device was transmitting invalid frame.
If the device is not in monitor mode, will it still transmit invalid frame in your setup?
Thank you.
Stephen
-----Original Message-----
From: Marco Fonseca [mailto:[email protected]]
Sent: Friday, August 17, 2012 10:30 AM
To: Chen, Stephen
Cc: Christian Lamparter; Johannes Berg; [email protected]
Subject: Re: carl9170: Unintentional transmission in monitor mode?
In my setup I had used a secondary sniffer in order to see what was going on.
I was able to reproduce the problem with a single ping with a payload of 2000 (less to look at in wireshark), but I was never able to capture a valid frame from the AR9170. I do know it was transmitting though, as I could see it on the spectrum analyzer. I just assumed whatever was going out wasn't a valid
frame...(?)
Marco
On Fri, Aug 17, 2012 at 02:03:00AM +0000, Chen, Stephen wrote:
> Can we tell what kind of unexpected frame are been transmitted? (Data
> frame or which kind of control frame?) That may give us a clue.
>
>
> Thank you.
> Stephen
>
> -----Original Message-----
> From: Christian Lamparter [mailto:[email protected]]
> Sent: Friday, August 17, 2012 3:35 AM
> To: Johannes Berg
> Cc: Marco Fonseca; [email protected]; Chen, Stephen
> Subject: Re: carl9170: Unintentional transmission in monitor mode?
>
> On Thursday, August 16, 2012 09:20:55 PM Johannes Berg wrote:
> > On Thu, 2012-08-09 at 21:43 +0200, Christian Lamparter wrote:
> > > On Thursday, August 09, 2012 06:54:34 PM Marco Fonseca wrote:
> > > > Hello All,
> > > >
> > > > I've noticed unexpected transmissions from the AR9170 while in
> > > > monitor mode and using tcpdump (and sometimes without tcpdump
> > > > running). These transmissions degrade (pretty significantly)
> > > > performance of other STA/AP on the channel (as seen by iperf
> > > > going from 60mbit/s to almost nill). As best I can tell these
> > > > transmissions never coalesces into an actual frame in the air
> > > > (at least not one I'm able to pick up with a second different adapter in monitor mode).
> > > >
> > > > Are there any known reasons/bugs on this? Is there anyway to
> > > > completely silence the transmitter of the AR9170 while still allowing reception?
> > > >
> > > yes. <http://www.spinics.net/lists/linux-wireless/msg88896.html>
> > >
> > > a solution is described in:
> > > <http://www.spinics.net/lists/linux-wireless/msg89279.html>
> > >
> > > (iw dev wlanX set monitor none - if I'm not mistaken)
> >
> > I've seen this before too -- what flag causes the issue, and why?
> Well that would be:
> FIF_OTHER_BSS or FIF_PROMISC_IN_BSS
>
> either one of these will set following flags for the hardware:
>
> AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER
> AR9170_MAC_SNIFFER_ENABLE_PROMISC
>
> About the issue, I'm really can't tell w/o schematics of the hardware. It could be that ACK_IN_SNIFFER is more of a debug/test flag than a real feature?
>
> (Anyway, I cc'd Stephen. Maybe he knows more)
>
> Regards,
> Chr
On Thu, Aug 09, 2012 at 09:43:28PM +0200, Christian Lamparter wrote:
> On Thursday, August 09, 2012 06:54:34 PM Marco Fonseca wrote:
> > Hello All,
> >
> > I've noticed unexpected transmissions from the AR9170 while in monitor mode
> > and using tcpdump (and sometimes without tcpdump running). These
> > transmissions degrade (pretty significantly) performance of other STA/AP on
> > the channel (as seen by iperf going from 60mbit/s to almost nill). As best I
> > can tell these transmissions never coalesces into an actual frame in the air
> > (at least not one I'm able to pick up with a second different adapter in
> > monitor mode).
> >
> > Are there any known reasons/bugs on this? Is there anyway to completely
> > silence the transmitter of the AR9170 while still allowing reception?
> >
> yes. <http://www.spinics.net/lists/linux-wireless/msg88896.html>
>
> a solution is described in:
> <http://www.spinics.net/lists/linux-wireless/msg89279.html>
>
> (iw dev wlanX set monitor none - if I'm not mistaken)
>
> Regards,
> Chr
Excellent, this solved my problem. Thank you Christian.
Marco
In my setup I had used a secondary sniffer in order to see what was going on.
I was able to reproduce the problem with a single ping with a payload of 2000
(less to look at in wireshark), but I was never able to capture a valid frame
from the AR9170. I do know it was transmitting though, as I could see it on
the spectrum analyzer. I just assumed whatever was going out wasn't a valid
frame...(?)
Marco
On Fri, Aug 17, 2012 at 02:03:00AM +0000, Chen, Stephen wrote:
> Can we tell what kind of unexpected frame are been transmitted? (Data frame or which kind of control frame?)
> That may give us a clue.
>
>
> Thank you.
> Stephen
>
> -----Original Message-----
> From: Christian Lamparter [mailto:[email protected]]
> Sent: Friday, August 17, 2012 3:35 AM
> To: Johannes Berg
> Cc: Marco Fonseca; [email protected]; Chen, Stephen
> Subject: Re: carl9170: Unintentional transmission in monitor mode?
>
> On Thursday, August 16, 2012 09:20:55 PM Johannes Berg wrote:
> > On Thu, 2012-08-09 at 21:43 +0200, Christian Lamparter wrote:
> > > On Thursday, August 09, 2012 06:54:34 PM Marco Fonseca wrote:
> > > > Hello All,
> > > >
> > > > I've noticed unexpected transmissions from the AR9170 while in
> > > > monitor mode and using tcpdump (and sometimes without tcpdump
> > > > running). These transmissions degrade (pretty significantly)
> > > > performance of other STA/AP on the channel (as seen by iperf going
> > > > from 60mbit/s to almost nill). As best I can tell these
> > > > transmissions never coalesces into an actual frame in the air (at
> > > > least not one I'm able to pick up with a second different adapter in monitor mode).
> > > >
> > > > Are there any known reasons/bugs on this? Is there anyway to
> > > > completely silence the transmitter of the AR9170 while still allowing reception?
> > > >
> > > yes. <http://www.spinics.net/lists/linux-wireless/msg88896.html>
> > >
> > > a solution is described in:
> > > <http://www.spinics.net/lists/linux-wireless/msg89279.html>
> > >
> > > (iw dev wlanX set monitor none - if I'm not mistaken)
> >
> > I've seen this before too -- what flag causes the issue, and why?
> Well that would be:
> FIF_OTHER_BSS or FIF_PROMISC_IN_BSS
>
> either one of these will set following flags for the hardware:
>
> AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER
> AR9170_MAC_SNIFFER_ENABLE_PROMISC
>
> About the issue, I'm really can't tell w/o schematics of the hardware. It could be that ACK_IN_SNIFFER is more of a debug/test flag than a real feature?
>
> (Anyway, I cc'd Stephen. Maybe he knows more)
>
> Regards,
> Chr
No, I don't believe so. I didn't do much testing in managed mode but when I
did try it, it didn't exhibit the issue.
Marco
On Fri, Aug 17, 2012 at 02:59:40AM +0000, Chen, Stephen wrote:
> To be honest, I have no idea why the device was transmitting invalid frame.
> If the device is not in monitor mode, will it still transmit invalid frame in your setup?
>
>
> Thank you.
> Stephen
>
>
On Thursday, August 16, 2012 09:20:55 PM Johannes Berg wrote:
> On Thu, 2012-08-09 at 21:43 +0200, Christian Lamparter wrote:
> > On Thursday, August 09, 2012 06:54:34 PM Marco Fonseca wrote:
> > > Hello All,
> > >
> > > I've noticed unexpected transmissions from the AR9170 while in monitor mode
> > > and using tcpdump (and sometimes without tcpdump running). These
> > > transmissions degrade (pretty significantly) performance of other STA/AP on
> > > the channel (as seen by iperf going from 60mbit/s to almost nill). As best I
> > > can tell these transmissions never coalesces into an actual frame in the air
> > > (at least not one I'm able to pick up with a second different adapter in
> > > monitor mode).
> > >
> > > Are there any known reasons/bugs on this? Is there anyway to completely
> > > silence the transmitter of the AR9170 while still allowing reception?
> > >
> > yes. <http://www.spinics.net/lists/linux-wireless/msg88896.html>
> >
> > a solution is described in:
> > <http://www.spinics.net/lists/linux-wireless/msg89279.html>
> >
> > (iw dev wlanX set monitor none - if I'm not mistaken)
>
> I've seen this before too -- what flag causes the issue, and why?
Well that would be:
FIF_OTHER_BSS or FIF_PROMISC_IN_BSS
either one of these will set following flags
for the hardware:
AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER
AR9170_MAC_SNIFFER_ENABLE_PROMISC
About the issue, I'm really can't tell w/o schematics
of the hardware. It could be that ACK_IN_SNIFFER is
more of a debug/test flag than a real feature?
(Anyway, I cc'd Stephen. Maybe he knows more)
Regards,
Chr