[ath9k-devel] [RFC 0/2] ath10k: fix qos workaround

[Michal Kazior <michal.kazior@tieto.com>]

On 25/04/13 08:43, Kalle Valo wrote:
> Hi Michal,
>
> Michal Kazior <michal.kazior@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.