From: Christian Lamparter <chunkeey@googlemail.com>
To: Javier Cardona <javier@cozybit.com>
Cc: Javier Lopez <jlopex@cozybit.com>,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] carl9170: Add support for NL80211_IFTYPE_MESH_POINT interfaces
Date: Fri, 27 Jul 2012 16:30:05 +0200 [thread overview]
Message-ID: <201207271630.06025.chunkeey@googlemail.com> (raw)
In-Reply-To: <CAPjQAd_0sD69dunzyd4Bx9Ys_XgTA9-Zr5TJkfNweopJWNBTJQ@mail.gmail.com>
On Friday 27 July 2012 05:52:49 Javier Cardona wrote:
> On Thu, Jul 26, 2012 at 1:12 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Thursday 26 July 2012 21:59:03 Javier Lopez wrote:
> >> This patch contains following modifications:
> >>
> >> - Add mesh capabilities on fw.c to permit creation of mesh
> >> interfaces using this driver.
> >>
> >> - Modify carl9170_set_operating_mode, to use AP-style beaconing
> >> with mesh interfaces.
> >>
> >> - Allow beacon updates for NL80211_IFTYPE_MESH_POINT type in
> >> carl9170_handle_command_response.
> >>
> >> Signed-off-by: Javier Lopez <jlopex@cozybit.com>
> > Hm, what about virtual interfaces?
> >
> > Do you think it's save to share a MESH node with
> > a STA, IBSS, AP interface on the same hardware?
>
> Does this hardware support multiple beacons?
> If not, we probably should limit the driver
> to only accept one beaconing vif at a time
> (e.g. one mesh vif + multiple STAs vifs ok).
oh yes. In fact, Due to your modifycations to fw.c
you have to update carl9170_op_add_interface as well.
As you are currently claiming any mesh/ap/sta
combination, even though it's not supported in the
code atm.
Just add a case for NL80211_IFTYPE_MESH in the
switch (main_vif->type) block and to the
if ((vif->type == ...) below.
> > On a side node: Can you tell me anything about
> > the crypto of mesh traffic? Because currently,
> > the code will disable any hardware crypto
> > offload for any mode other than STA and AP.
>
> The hardware crypto needs to support one tx/rx
> pairwise key per peer, a groupwise key for each
> peer and management frame protection.
> Not sure if this is the case for this hardware,
> so until we do, it seems reasonable to disable
> crypto offload.
ok, a groupwise key for each peer is not possible
with the hw. (no need to change anything, swcrypto
is selected in this case).
Regards,
Chr
BTW: Did you do any experiments? I.e.: Does it really
work?
next prev parent reply other threads:[~2012-07-27 14:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 19:59 [PATCH] carl9170: Add support for NL80211_IFTYPE_MESH_POINT interfaces Javier Lopez
2012-07-26 20:12 ` Christian Lamparter
2012-07-27 3:52 ` Javier Cardona
2012-07-27 14:30 ` Christian Lamparter [this message]
2012-07-27 15:12 ` Javier Cardona
2012-07-27 21:16 ` Christian Lamparter
2012-07-30 23:40 ` Javier Lopez
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=201207271630.06025.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=javier@cozybit.com \
--cc=jlopex@cozybit.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).