[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: Sunday, February 08, 2015 13:23
> To: hostap at 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.