Re: [RFCv2] mac80211: Don't let regulatory make us deaf

[Paul Stewart <pstew@chromium.org>]

On Mon, Feb 27, 2012 at 5:46 AM, Jouni Malinen <j@w1.fi> wrote:
> 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.

Discussions seem to have come to an end here, however I'm not sure
what we ended up deciding. :-)  I see mention of HT+TKIP -- not sure
I'm familiar enough with what the issues are there -- as well as
pushing the channel configuration earlier and perhaps changes to the
association process.  Since I may not have a complete handle on all
these adjacent issues, where do we want to go with the current change
(fixes a real-life issue) and how do we want to stage that with
respect to the other issues this seems to have brought to the surface?

--
Paul