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

[Neeraj Kumar Garg]

Hello Johannes,

Yes, we need basic form of presence request handling and in my opinion this should be done in supplicant as supplicant already takes care of rest of the action frames..
Now there are some challenges in implementing it in supplicant, and to start with, we can simply call handle_presence function from supplicant. And let the driver handle it.

I am fine to implement another function called handle_presence(). Upon handle_presence(with client addr). Then driver can take a call what to do for revised NOA schedule. A simple driver may decide to disable the NOA schedule completely until all the connected clients send a presence request with 0 values. Supplicant should here also make sure that it calls handle_presence function only when it knows that presence request has come from a connected client. Driver need to maintain a list of clients who has sent the presence request.

But this will also involve adding one notification from driver to supplicant which is to update the revised NOA schedule in the beacons and probe responses. Or we need not do this, driver can put the modified NOA schedule in the beacons and probe responses.

More thoughts of yours?

Regards,
-Neeraj

-----Original Message-----
From: Johannes Berg [mailto:johannes at sipsolutions.net] 
Sent: Monday, December 12, 2011 2:29 PM
To: Neeraj Kumar Garg
Cc: Jouni Malinen; 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

Hi Neeraj,

Maybe instead of proposals, you should describe what you want first. It
seems that you want a basic form of presence request handling?

> 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.

Using set_noa() is definitely not a good plan. Adding handle_presence(),
which can return an error as well, is a better plan. HOWEVER -- for
symmetry you will have to also give the driver which station this was so
it can *remove* the presence request again when the station requests a
new one/none any more, and the supplicant should also tell the driver to
remove it before it removes that station from the driver. So I think
there are a bunch of corner cases to get right wrt. updating the
presence request and removing it.

> 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.

This doesn't seem right either -- forget set_noa() completely, it's for
testing. Anything should, in my opinion, be done through specific APIs.

johannes