Re: [ath9k-devel] [RFC 0/2] ath10k: fix qos workaround
Hi Michal, Michal Kazior michal.kaz...@tieto.com 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? Disclaimer: I haven't looked at your patches -- Kalle Valo ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC 0/2] ath10k: fix qos workaround
On 25/04/13 08:43, Kalle Valo wrote: Hi Michal, Michal Kazior michal.kaz...@tieto.com 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. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [RFC 0/2] ath10k: fix qos workaround
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 think we'll need to make a copy of skb, work on that copy and keep the original skbuff pointer as a cookie to use with mac80211 functions (tx_status, free_txskb). I'm hoping this won't degrade tx performance (well, we already do a memmove()). Yuck. Any comments? Michal Kazior (2): ath10k: make more space in ath10k_skb_cb ath10k: copy skb during tx drivers/net/wireless/ath/ath10k/core.h | 32 drivers/net/wireless/ath/ath10k/mac.c | 21 +++-- drivers/net/wireless/ath/ath10k/txrx.c |8 +--- 3 files changed, 44 insertions(+), 17 deletions(-) -- 1.7.9.5 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC 0/2] ath10k: fix qos workaround
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 ? Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC 0/2] ath10k: fix qos workaround
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. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
