[PATCH] P2P return a successful response for p2p presence request if driver has return noa_len greater than 0

[Johannes Berg]

On Sun, 2011-12-11 at 17:14 +0200, Jouni Malinen wrote:

> > > 4) supplicant get this notification and update beacon template  + probe_resp
> > > 5) supplicant set new beacon.
> 
> This sounds unnecessary.. The driver can do this anyway (just add
> another P2P IE with NoA attribute to the end of the frame).
> 
> > Right now our firmware will update beacons, and our driver will append
> > NoA to all probe responses. Since we can't turn off the beacon part,
> > we'll definitely need to handle this.
> 
> This seems to be what most vendors have ended up doing (or well
> firmware/driver, but anyway, somewhere much lower in the stack than
> wpa_supplicant).

Right. And given that it's just appending an IE, it's really not a big
deal.

> > I suspect right now our firmware can't actually deal with presence
> > requests properly at all, I believe it'll start a NoA schedule for
> > example when you ask it to scan. So for this case it would be better to
> > reject any presence request.
> > 
> > I'm not quite sure what we gain from having the supplicant handle all
> > this. Is this a lot of code if we required drivers handle it?
> 
> Agreed. I did a small change based on the thread: reject Presence
> Request if current NoA cannot be fetched from the driver. That sounds
> like a safer option and if someone really wants to support Presence
> Request properly, that can be implemented in the driver/firmware.

Cool, thanks. I think this change makes sense. The question will be how
to implement presence requests, I think it would also be a bit silly to
have the driver implement all of it, but I don't think I need a solution
at all right now. If somebody wants to do it, it will probably require
asking the driver about each request, and if the driver accepts it it
would return an updated NoA schedule & keep track of the request to be
able to actually honour it, e.g. by scheduling scans around it.

johannes