On Wed, Mar 05, 2014 at 09:16:44AM +0000, Grumbach, Emmanuel wrote: > > > > On Tue, Mar 04, 2014 at 04:50:14PM +0200, Emmanuel Grumbach wrote: > > > This logic is already implemented in ieee80211_rx_mgmt_beacon. > > > The purpose is to ignore probe responses that are received on adjacent > > > channels. This can happen in 2.4GHz since channels overlap. > > > > Why would this be done? I can understand not updating signal information, > > but dropping Probe Response frames completely sounds quite undesirable. > > These can be used to help optimize partial scans and any additional > > information that can be used without having to change channels sounds > > helpful to me. > So I guess you want me to revert the code we currently have in ieee80211_rx_mgmt_beacon ;) I'm not sure about Beacon frames, but possibly. Anyway, I was more thinking about use of active scanning on 2.4 GHz band and that would be more applicable for Probe Response frames. > Don't know really... If you are associated to an AP and hear its beacons / probe responses on another channel you really have a big problem in your radio? Is this only for the case of Beacon/Probe Response frames from the AP with which the device is associated? The commit log seemed to imply that this is for all Probe Response frames. I have no problems with the Probe Response from the current AP being ignored from other channels; it is the case of finding other APs that I'm much more interested in in this context. -- Jouni Malinen PGP id EFC895FA -- 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