From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Kazior Date: Thu, 25 Apr 2013 08:59:37 +0200 Subject: [ath9k-devel] [RFC 0/2] ath10k: fix qos workaround In-Reply-To: <87wqrrw1oq.fsf@kamboji.qca.qualcomm.com> References: <87k3ntawjy.fsf@kamboji.qca.qualcomm.com> <1366798243-11662-1-git-send-email-michal.kazior@tieto.com> <20855.47516.43566.209338@gargle.gargle.HOWL> <5177D4CD.6020804@tieto.com> <87wqrrw1oq.fsf@kamboji.qca.qualcomm.com> Message-ID: <5178D459.9090603@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 25/04/13 08:43, Kalle Valo wrote: > Hi Michal, > > Michal Kazior writes: > >> 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). > > From prioritising point of view I consider that mode as a very low > priority feature. For me most important is to support the real monitor > mode (iw wlan0 set type monitor), anything else is just nice to have. > > I haven't even looked at your patches, but I'm worried that if a very > low priority feature jeopardizes normal functionality. What if we just > don't support the monitor mode while associated feature? Can we do that? The issue would be seen even if we had no explicit monitor mode support in the driver. The following: ; ifconfig wlan0 up ; iw wlan0 connect -w dd-wrt-open ; iw wlan0 interface add mon type monitor ; ifconfig mon up ; wireshark -pkni mon Starts wireshark in non-promiscuous mode. This allows us to see tx/rx from wlan0 (and possibly other running interfaces) in raw instead ethernet frames. The driver doesn't even know if `mon` exists, nor if the `mon` interface is `up` nor if wireshark is running. mac80211 simply passes all traffic as-is to mon interface. Perhaps this is a 'nice to have' thing, but it also fixes the QoS Control stripping issue in one go. We could simply do QoS restoring upon tx completion to make mac80211 happy on ieee80211_tx_status(), but the aforementioned monitor case will still be broken. However the patch may introduce tx performance regression due to skb_copy(). We could possibly optimize it (allocate skbuff and do memcpy instead of memmove for the qos workaround). -- Pozdrawiam / Best regards, Michal Kazior.