From: Jouni Malinen <j@w1.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Paul Stewart <pstew@chromium.org>,
linux-wireless@vger.kernel.org,
Rajkumar Manoharan <rmanohar@qca.qualcomm.com>,
Arik Nemtsov <anamtsov@gmail.com>,
Eliad Peller <eliad@wizery.com>
Subject: Re: [RFCv2] mac80211: Don't let regulatory make us deaf
Date: Mon, 27 Feb 2012 15:46:10 +0200 [thread overview]
Message-ID: <20120227134610.GA5070@w1.fi> (raw)
In-Reply-To: <1330342730.3483.34.camel@jlt3.sipsolutions.net>
On Mon, Feb 27, 2012 at 12:38:50PM +0100, Johannes Berg wrote:
> On Mon, 2012-02-27 at 13:32 +0200, Jouni Malinen wrote:
> > However, there
> > could be some hardware/firmware designs that would refuse HT+TKIP at
> > lower layer, so skipping the channel (re-)configuration could
> > potentially cause some problems.
> That's a good point, but I don't really think is likely to exist. I can
> see this in a full-MAC scenario, but there you get all the relevant
> parameters in the nl80211 connect() call so can do the right choices
> earlier than mac80211 can with auth/assoc calls.
Even full MAC designs may end up moving towards auth/assoc calls for
things like IEEE 802.11r.. (And maybe even more so with 802.11ai
eventually.)
> Of course, if this we actually happen to come across a device that needs
> this it could set a flag somehwere and mac80211 could re-configure the
> channel to non-HT on the assoc request, but right now I'd rather not
> worry about that since we're moving towards multi-channel and have no
> indication of such devices existing. Agree?
Yeah, that works for me.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2012-02-27 13:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-21 5:25 [RFC] mac80211: Don't let regulatory make us deaf Paul Stewart
2012-02-21 5:25 ` [RFCv2] " Paul Stewart
2012-02-21 18:01 ` Mahesh
2012-02-23 13:39 ` Johannes Berg
2012-02-23 14:53 ` Sam Leffler
2012-02-23 14:59 ` Johannes Berg
2012-02-23 15:14 ` Paul Stewart
2012-02-24 1:53 ` Luis R. Rodriguez
2012-02-24 4:15 ` Paul Stewart
2012-02-21 5:25 ` [PATCH] " Paul Stewart
2012-02-24 4:25 ` [RFCv2] " Sam Leffler
2012-02-26 11:15 ` Johannes Berg
2012-02-26 11:25 ` Johannes Berg
2012-02-27 10:34 ` Johannes Berg
2012-02-27 11:32 ` Jouni Malinen
2012-02-27 11:38 ` Johannes Berg
2012-02-27 13:46 ` Jouni Malinen [this message]
2012-03-07 5:46 ` Paul Stewart
2012-03-07 7:36 ` Johannes Berg
2012-03-07 18:40 ` John W. Linville
2012-03-07 18:52 ` Johannes Berg
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=20120227134610.GA5070@w1.fi \
--to=j@w1.fi \
--cc=anamtsov@gmail.com \
--cc=eliad@wizery.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=pstew@chromium.org \
--cc=rmanohar@qca.qualcomm.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).