| Message ID | 1393944614-4465-2-git-send-email-emmanuel.grumbach@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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.
> > 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 ;) 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? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > 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 ;) 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? FWIW: this logic is there since: commit d91f36db51661018f6d54ff5966e283bcec4c545 Author: Johannes Berg <johannes@sipsolutions.net> Date: Thu Apr 16 13:17:26 2009 +0200 mac80211: implement beacon filtering in software -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
On Wed, Mar 05, 2014 at 09:20:07AM +0000, Grumbach, Emmanuel wrote: > > So I guess you want me to revert the code we currently have in > > ieee80211_rx_mgmt_beacon ;) 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? > > FWIW: this logic is there since: > > commit d91f36db51661018f6d54ff5966e283bcec4c545 > Author: Johannes Berg <johannes@sipsolutions.net> > Date: Thu Apr 16 13:17:26 2009 +0200 > > mac80211: implement beacon filtering in software The frequency related areas in this commit are in a location that has a clear comment about it being for the current BSS. Your patch did not look like it would be for that case. If it is, the commit log should really say that clearly.
> > On Wed, Mar 05, 2014 at 09:20:07AM +0000, Grumbach, Emmanuel wrote: > > > So I guess you want me to revert the code we currently have in > > > ieee80211_rx_mgmt_beacon ;) 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? > > > > FWIW: this logic is there since: > > > > commit d91f36db51661018f6d54ff5966e283bcec4c545 > > Author: Johannes Berg <johannes@sipsolutions.net> > > Date: Thu Apr 16 13:17:26 2009 +0200 > > > > mac80211: implement beacon filtering in software > > The frequency related areas in this commit are in a location that has a clear > comment about it being for the current BSS. Your patch did not look like it > would be for that case. If it is, the commit log should really say that clearly. > V2 with a better commit log on the way - thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > On Wed, Mar 05, 2014 at 09:20:07AM +0000, Grumbach, Emmanuel wrote: > > > > So I guess you want me to revert the code we currently have in > > > > ieee80211_rx_mgmt_beacon ;) 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? > > > > > > FWIW: this logic is there since: > > > > > > commit d91f36db51661018f6d54ff5966e283bcec4c545 > > > Author: Johannes Berg <johannes@sipsolutions.net> > > > Date: Thu Apr 16 13:17:26 2009 +0200 > > > > > > mac80211: implement beacon filtering in software > > > > The frequency related areas in this commit are in a location that has > > a clear comment about it being for the current BSS. Your patch did not > > look like it would be for that case. If it is, the commit log should really say > that clearly. > > > > V2 with a better commit log on the way - thanks! Seems that my patch is useless since the because will still be processed by the scan code even when we are associated. So my patch didn't change anything for probes from APs we are not associated to, but it didn't change anything for probes of our AP either... -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index e3f71b0..d982d61 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -2805,6 +2805,7 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb) { struct ieee80211_mgmt *mgmt = (void *)skb->data; + struct ieee80211_chanctx_conf *chanctx_conf; struct ieee80211_if_managed *ifmgd; struct ieee80211_rx_status *rx_status = (void *) skb->cb; size_t baselen, len = skb->len; @@ -2814,6 +2815,19 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata, sdata_assert_lock(sdata); + rcu_read_lock(); + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); + if (!chanctx_conf) { + rcu_read_unlock(); + return; + } + + if (rx_status->freq != chanctx_conf->def.chan->center_freq) { + rcu_read_unlock(); + return; + } + rcu_read_unlock(); + if (!ether_addr_equal(mgmt->da, sdata->vif.addr)) return; /* ignore ProbeResp to foreign address */
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. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> --- net/mac80211/mlme.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)