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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/ath10k
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
