| Message ID | 1423186624-27547-1-git-send-email-ilan.peer@intel.com |
|---|---|
| State | Accepted |
| Headers | show |
On Thu, Feb 05, 2015 at 08:37:04PM -0500, Ilan Peer wrote: > Do not reply to a probe request with a DS IE in which the channel > is different than the operating channel of the AP, as the sending > station is not found on the AP's operating channel. Strictly speaking, this seems to be non-compliant with IEEE Std 802.11-2012. The AP shall do this if dot11RadioMeasurementActivated is true (so yes, for that case, this change is indeed required), but the standard language seems to imply that the AP shall reply to the Probe Request that matches all the described rules and in case of dot11RadioMeasurementActivated false, that would include the case of DSS Parameter Set element value not matching the current channel.. I'm not sure this is really the real intent behind the design that was added in 802.11k, but that's what the current standard says. In addition to that, I've heard of some scanning optimizations that would potentially depend on the AP replying on neighboring channel. That said, it is also desirable to reduce the number of unnecessary Probe Response frames (whether that response is unnecessary or not depends on whether the STA is likely to receive it).
> -----Original Message----- > From: hostap-bounces@lists.shmoo.com [mailto:hostap- > bounces@lists.shmoo.com] On Behalf Of Jouni Malinen > Sent: Saturday, February 07, 2015 11:03 > To: hostap@lists.shmoo.com > Subject: Re: [PATCH] AP: Do not reply to probe request with DS IE mismatch > > On Thu, Feb 05, 2015 at 08:37:04PM -0500, Ilan Peer wrote: > > Do not reply to a probe request with a DS IE in which the channel is > > different than the operating channel of the AP, as the sending station > > is not found on the AP's operating channel. > > Strictly speaking, this seems to be non-compliant with IEEE Std 802.11-2012. > The AP shall do this if dot11RadioMeasurementActivated is true (so yes, for > that case, this change is indeed required), but the standard language seems > to imply that the AP shall reply to the Probe Request that matches all the > described rules and in case of dot11RadioMeasurementActivated false, that > would include the case of DSS Parameter Set element value not matching the > current channel.. > Yep. Somehow the spec. does read very complete around this. It states that adding the DSSS IE is optional if dot11RadioMeasurementActivated is not set, but does not describe the behavior in such a case. > I'm not sure this is really the real intent behind the design that was added in > 802.11k, but that's what the current standard says. In addition to that, I've > heard of some scanning optimizations that would potentially depend on the > AP replying on neighboring channel. That said, it is also desirable to reduce > the number of unnecessary Probe Response frames (whether that response > is unnecessary or not depends on whether the STA is likely to receive it). > This is the main motivation here. I guess that whoever want to add the scan optimization would need to handle this later. Thanks, Ilan.
On Sun, Feb 08, 2015 at 10:49:40AM +0000, Peer, Ilan wrote: > > Strictly speaking, this seems to be non-compliant with IEEE Std 802.11-2012. > > The AP shall do this if dot11RadioMeasurementActivated is true (so yes, for > > that case, this change is indeed required), but the standard language seems > > to imply that the AP shall reply to the Probe Request that matches all the > > described rules and in case of dot11RadioMeasurementActivated false, that > > would include the case of DSS Parameter Set element value not matching the > > current channel.. > > Yep. Somehow the spec. does read very complete around this. It states that adding the DSSS IE is optional if > dot11RadioMeasurementActivated is not set, but does not describe the behavior in such a case. The standard does describe the behavior: "An AP shall respond to all probe requests meeting the above criteria". This means that an AP with dot11RadioMeasurementActivated set to false shall reply regardless of DSSS Parameter Set matching while an AP with dot11RadioMeasurementActivated set to true shall reply if the channel matches or DSSS Parameter Set is not present in the Probe Request frame. Sure, you may not agree with that being a good behavior, but anyway, the standard seems to be unambiguous on this. It could be useful to change the standard to match the desired behavior here, though.. I'll try to remember to add a comment on the P802.11-REVmc sponsor ballot for this. > This is the main motivation here. I guess that whoever want to add the scan optimization would need to handle > this later. I'm tempting to apply this patch (or well, with some cleanup and comments pointing out the conflict with the standard). Though, I had thought about doing this same change when adding the DSSS Parameter Set element into Probe Request frame. For some reason, I did not at this on the AP side.. I just can't remember why,
> -----Original Message----- > From: hostap-bounces@lists.shmoo.com [mailto:hostap- > bounces@lists.shmoo.com] On Behalf Of Jouni Malinen > Sent: Sunday, February 08, 2015 13:23 > To: hostap@lists.shmoo.com > Subject: Re: [PATCH] AP: Do not reply to probe request with DS IE mismatch > > On Sun, Feb 08, 2015 at 10:49:40AM +0000, Peer, Ilan wrote: > > > Strictly speaking, this seems to be non-compliant with IEEE Std 802.11- > 2012. > > > The AP shall do this if dot11RadioMeasurementActivated is true (so > > > yes, for that case, this change is indeed required), but the > > > standard language seems to imply that the AP shall reply to the > > > Probe Request that matches all the described rules and in case of > > > dot11RadioMeasurementActivated false, that would include the case of > > > DSS Parameter Set element value not matching the current channel.. > > > > Yep. Somehow the spec. does read very complete around this. It states > > that adding the DSSS IE is optional if dot11RadioMeasurementActivated is > not set, but does not describe the behavior in such a case. > > The standard does describe the behavior: "An AP shall respond to all probe > requests meeting the above criteria". This means that an AP with > dot11RadioMeasurementActivated set to false shall reply regardless of DSSS > Parameter Set matching while an AP with dot11RadioMeasurementActivated > set to true shall reply if the channel matches or DSSS Parameter Set is not > present in the Probe Request frame. > I agree. I meant that the 802.11k addition was incomplete in the sense that it did not address the case that the AP did not support RRM. > Sure, you may not agree with that being a good behavior, but anyway, the > standard seems to be unambiguous on this. It could be useful to change the > standard to match the desired behavior here, though.. I'll try to remember to > add a comment on the P802.11-REVmc sponsor ballot for this. > Thanks. > > This is the main motivation here. I guess that whoever want to add the > > scan optimization would need to handle this later. > > I'm tempting to apply this patch (or well, with some cleanup and comments > pointing out the conflict with the standard). Though, I had thought about > doing this same change when adding the DSSS Parameter Set element into > Probe Request frame. For some reason, I did not at this on the AP side.. I just > can't remember why, > When I talked with Johannes about this, he also was under the impression that this was already handled :) Thanks, Ilan.
On Sun, Feb 08, 2015 at 11:37:55AM +0000, Peer, Ilan wrote: > > I'm tempting to apply this patch (or well, with some cleanup and comments > > pointing out the conflict with the standard). Though, I had thought about > > doing this same change when adding the DSSS Parameter Set element into > > Probe Request frame. For some reason, I did not at this on the AP side.. I just > > can't remember why, > When I talked with Johannes about this, he also was under the impression that this was already handled :) That was my recollection as well.. I did find my in-progress patch from August 2010 (i.e., from the time when I added the parameter into Probe Request frames in mac80211), but no explanation of why that hostapd side change was left pending. I don't think I'll find any more information on this or other reasons to avoid making the change in AP behavior.
On Thu, Feb 05, 2015 at 08:37:04PM -0500, Ilan Peer wrote: > Do not reply to a probe request with a DS IE in which the channel > is different than the operating channel of the AP, as the sending > station is not found on the AP's operating channel. Thanks, applied. > + if (elems.ds_params && elems.ds_params_len == 1) { > + u8 chan; > + > + if (ieee80211_freq_to_chan(hapd->iface->freq, > + &chan) == NUM_HOSTAPD_MODES) { I changed that to use hapd->iconf->channel to avoid unnecessary operations. In addition, I made this apply only on 2.4 GHz band just to make sure there are no interop issues on 5 GHz where this element is not supposed to be included in Probe Request frames.
diff --git a/src/ap/beacon.c b/src/ap/beacon.c index b0a74e0..63c8d6d 100644 --- a/src/ap/beacon.c +++ b/src/ap/beacon.c @@ -579,6 +579,28 @@ void handle_probe_req(struct hostapd_data *hapd, return; } + /* No need to reply if the probe request was send on an adjacent + * channel + */ + if (elems.ds_params && elems.ds_params_len == 1) { + u8 chan; + + if (ieee80211_freq_to_chan(hapd->iface->freq, + &chan) == NUM_HOSTAPD_MODES) { + wpa_printf(MSG_ERROR, + "Failed to get interface channel for freq=%u", + hapd->iface->freq); + return; + } + + if (chan != elems.ds_params[0]) { + wpa_printf(MSG_DEBUG, + "Ignore Probe Request due to DS mismatch. chan=%u != ds.chan=%u", + chan, elems.ds_params[0]); + return; + } + } + #ifdef CONFIG_P2P if (hapd->p2p && elems.wps_ie) { struct wpabuf *wps;
Do not reply to a probe request with a DS IE in which the channel is different than the operating channel of the AP, as the sending station is not found on the AP's operating channel. Signed-off-by: Ilan Peer <ilan.peer@intel.com> --- src/ap/beacon.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)