On Fri, May 11, 2012 at 11:32:52AM +0200, Johannes Berg wrote: > On Thu, 2012-05-10 at 09:35 -0700, Seth Forshee wrote: > > > > On passive channels, when scanning, mac80211 will send a probe only > > > after receiving a frame on that channel. When associating, it has no > > > such behaviour, at least not directly, but I suppose it could be > > > implemented (waiting for the beacon) > > > > The background is that brcmsmac contains a bunch of code for regulatory > > support that is either duplicated (and in conflict) with the > > protocol-level support or else it would better be handled there. This is > > causing problems on pretty much any channel that isn't part of the > > default world regulatory domain. > > > > I've sent RFC patches that strip out the vast majority of this code in > > favor of better integration with the protocol-level regulatory support. > > The piece that's under discussion here is a behavior I maintained in my > > changes, which mutes tx on passive scan channels until data is received > > on a given channel. But in my opinion, if this sort of behavior is > > desired it ought to be implemented at the protocol level instead of in > > the driver, so I'd really prefer to see it removed from brcmsmac. > > This isn't implemented in mac80211, and since some HW (e.g. ours) > implements it in lower levels, I don't think you can just generally say > it has to be in mac80211 now. I guess I need to familiarize myself with the situation for other hardware then, which I will do next week when I'm not at a conference. It just seems to me that if we want to enforce consistent regulatory behavior for all HW then mac80211 is the logical place to implement it. Seth -- 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
