From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Kazior Date: Wed, 24 Apr 2013 14:49:17 +0200 Subject: [ath9k-devel] [RFC 0/2] ath10k: fix qos workaround In-Reply-To: <20855.47516.43566.209338@gargle.gargle.HOWL> References: <87k3ntawjy.fsf@kamboji.qca.qualcomm.com> <1366798243-11662-1-git-send-email-michal.kazior@tieto.com> <20855.47516.43566.209338@gargle.gargle.HOWL> Message-ID: <5177D4CD.6020804@tieto.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 24/04/13 12:53, Sujith Manoharan wrote: > Michal Kazior wrote: >> >From what I've observed so far is frames in >> monitor mode (non promiscuous) are corrupted. They >> have the QoS Control stripped, with LLC header >> finding itself in the QoS Control. Wireshark shows >> such packets as A-MSDU corrupted frames. I tried >> restoring the QoS Control but it didn't fix that. > > I don't understand. Why should pure monitor mode care about > the TX path ? This is not concerned with the pure (I hope we don't have a misunderstanding here) monitor mode. You can create monitor vif when associated and you might want to listen to the traffic *without* going into the promiscuous mode (no monitor vdev is created). It simply passes raw 802.11 frames that pass through mac80211 (both tx and rx) on other interfaces (i.e. associated station interface). -- Pozdrawiam / Best regards, Michal Kazior.