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:chunkeey@xxxxxxxxxxxxxx] > Sent: Friday, August 17, 2012 3:35 AM > To: Johannes Berg > Cc: Marco Fonseca; linux-wireless@xxxxxxxxxxxxxxx; 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
