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