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

[Neeraj Kumar Garg]

Hello Jouni, Johannes
I think my 2 below proposals somehow got un-notices. I think handling presence request should still be done in supplicant. Otherwise driver has to parse all action frames and then if received presence request, need to take an action.
I came up with below 2 proposals (A and B):

Proposal A):
1) Upon getting presence request, supplicant can simply call set_noa() with received presence request NOA attribute. Let the driver take care of modifying the NOA attribute in NOA frames depending upon the received presence request. Driver will also disable oppps upon this set_noa call.
2) We need to modify current set_noa function prototype to tell the driver somehow that the attached NOA attributes are from the presence request. Otherwise driver will not have anyway to find out if he has to do the modify NOA schedule based on presence request OR they are new NOA values from the application itself.
3) The disadvantage with this approach is that it doesn't look clean. Or we need to comeup with a new driver function (*handle_presence) or something like that.
Proposal B): 
1) Upon getting presence request, supplicant will call get_noa(). Supplicant will disable the current NOA schedule completely and will also disable oppps by simply calling set_noa(). Also multiple presence requests from different clients will do the same. 
2) Once all clients sends a presence request with 0 values (whoevers sent a presence request earlier), we will again enable the previous NOA schedule. 
3) Advantage here is it is clean approach and doesn't increase the supplicant complexity to calculate revised NOA schedule.

If you want to redesign the power-mgmt stuff later, I think Proposal B) would be a good alternative for near future, rather than not supporting the presence request completely if driver has an NOA schedule going on. 
Let me know your thoughts on this. I can accordingly send a patch.

Regards,
-Neeraj

-----Original Message-----
From: hostap-bounces at lists.shmoo.com [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Johannes Berg
Sent: Sunday, December 11, 2011 8:54 PM
To: Jouni Malinen
Cc: hostap at lists.shmoo.com
Subject: Re: [PATCH] P2P return a successful response for p2p presence request if driver has return noa_len greater than 0

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

_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap