[PATCH] AP: Do not reply to probe request with DS IE mismatch

[Peer, Ilan]

> -----Original Message-----
> From: hostap-bounces at lists.shmoo.com [mailto:hostap-
> bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
> Sent: Saturday, February 07, 2015 11:03
> To: hostap at 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.