All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Oh <poh@codeaurora.org>
To: Yeoh Chun-Yeow <yeohchunyeow@gmail.com>,
	Bob Copeland <me@bobcopeland.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
	Jason Andryuk <jandryuk@gmail.com>
Subject: Re: [PATCH 3/3] ath10k: implement mesh support
Date: Thu, 17 Sep 2015 16:56:14 -0700	[thread overview]
Message-ID: <55FB531E.1030001@codeaurora.org> (raw)
In-Reply-To: <CAEFj986tjgK-=eBaoR3G8m7wf0m32WLutRypPzMfjj2+MW5ybw@mail.gmail.com>


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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Peter Oh <poh@codeaurora.org>
To: Yeoh Chun-Yeow <yeohchunyeow@gmail.com>,
	Bob Copeland <me@bobcopeland.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
	Jason Andryuk <jandryuk@gmail.com>
Subject: Re: [PATCH 3/3] ath10k: implement mesh support
Date: Thu, 17 Sep 2015 16:56:14 -0700	[thread overview]
Message-ID: <55FB531E.1030001@codeaurora.org> (raw)
In-Reply-To: <CAEFj986tjgK-=eBaoR3G8m7wf0m32WLutRypPzMfjj2+MW5ybw@mail.gmail.com>


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@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


  reply	other threads:[~2015-09-17 23:56 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27 10:57 [PATCH 0/3] mesh support for ath10k Bob Copeland
2015-08-27 10:57 ` Bob Copeland
2015-08-27 10:57 ` [PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested Bob Copeland
2015-08-27 10:57   ` Bob Copeland
2015-08-27 10:57 ` [PATCH 2/3] ath10k: check for encryption before adding MIC_LEN Bob Copeland
2015-08-27 10:57   ` Bob Copeland
2015-08-27 10:57 ` [PATCH 3/3] ath10k: implement mesh support Bob Copeland
2015-08-27 10:57   ` Bob Copeland
2015-08-29 17:11   ` Jason Andryuk
2015-08-29 17:11     ` Jason Andryuk
2015-08-29 22:25     ` Bob Copeland
2015-08-29 22:25       ` Bob Copeland
2015-08-30 17:43       ` Yeoh Chun-Yeow
2015-08-30 17:43         ` Yeoh Chun-Yeow
2015-09-16 12:39         ` Bob Copeland
2015-09-16 12:39           ` Bob Copeland
2015-09-17 17:48           ` Yeoh Chun-Yeow
2015-09-17 17:48             ` Yeoh Chun-Yeow
2015-09-17 23:56             ` Peter Oh [this message]
2015-09-17 23:56               ` Peter Oh
2015-09-01  3:02       ` Jason Andryuk
2015-09-01  3:02         ` Jason Andryuk
2015-09-09  7:57   ` Kalle Valo
2015-09-09  7:57     ` Kalle Valo
2015-09-09  9:10     ` Kalle Valo
2015-09-09  9:10       ` Kalle Valo
2015-09-09 16:49       ` Bob Copeland
2015-09-09 16:49         ` Bob Copeland
2015-09-10  5:46         ` Kalle Valo
2015-09-10  5:46           ` Kalle Valo
2015-09-10  7:22         ` Johannes Berg
2015-09-10  7:22           ` Johannes Berg
2015-09-15  7:21           ` Peter Oh
2015-09-15  7:21             ` Peter Oh
2015-09-16 12:32             ` Bob Copeland
2015-09-16 12:32               ` Bob Copeland
2015-09-09 11:08     ` Bob Copeland
2015-09-09 11:08       ` Bob Copeland
  -- strict thread matches above, loose matches on Subject: below --
2015-08-16 15:25 [PATCH 0/3] ath10k " Bob Copeland
2015-08-16 15:25 ` [PATCH 3/3] ath10k: implement " Bob Copeland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55FB531E.1030001@codeaurora.org \
    --to=poh@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=jandryuk@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=me@bobcopeland.com \
    --cc=yeohchunyeow@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.