[PATCH 3/3] ath10k: implement mesh support

[Peter Oh]

On 09/17/2015 10:48 AM, Yeoh Chun-Yeow wrote:
> Hi, Bob
>
> I have also tested with nwifi mode for non-secured mesh. It seems to
> be worked for me with the following two test scenarios:
>
> Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k]
> Node 1 [ath10k] <---> Node 2 [ath9k]
>
> I am using the following:
> compat-wireless-2015-07-21 from OpenWRT
> firmware-5.bin_10.2.4.70.6-2
>
> I just wondering whether using raw wifi is better for encrypted mesh
> later?
nwifi mode will be in trouble when SNAP/LLC encapsulation used since 
firmware and hardware have no way to distinguish if it's SNAP header or 
Mesh Control field.

--
Peter
>
> ----
> Chun-Yeow
>
> On Wed, Sep 16, 2015 at 8:39 PM, Bob Copeland <me at bobcopeland.com> wrote:
>> On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote:
>>> Hi, Bob
>>>
>>>> Yes: you don't want to enable raw mode TX / RX decap in the normal
>>>> case because it's fairly inefficient compared to "native" wifi mode,
>>>> according to my understanding.  The latter doesn't support mesh
> framing
>>>> however.
>>>>
>>> The native WiFi mode doesn't support mesh framing. Can you elaborate
>>> more on this?
>> Sorry, missed this before -- the 'nwifi' mode which is the normal
>> datapath for ath10k discards the QoS header and following mesh header
>> when transmitting, if I recall correctly.  I also had some issues with
> the
>> received frames when using nwifi RX decap with raw mode TX, but I don't
>> recall exactly the problem.  I can retest with these modes if you really
>> want the details.
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k