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

[Neeraj Kumar Garg]

Johannes,
Good point of disconnection. I think we need to call handle_presence from supplicant if a presence request was earlier received from the client and client is disconnecting without clearing the presence request.
As per the spec, a client can give up presence request (or clear its presence request) by sending another presence request with 0 NOA attributes.
I also feel that adding NOA attribute in the driver/firmware automatically may be a good idea at the moment. Later we can think of notifying supplicant for changes in IEs in beacons and probe-responses.

Regards,
-Neeraj

-----Original Message-----
From: Johannes Berg [mailto:johannes at sipsolutions.net] 
Sent: Tuesday, December 13, 2011 7:06 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,

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

Yes, this sounds reasonable. Not sure how the client disconnect etc.
should be handled though (and I'm not sure if a client can "give up" a
presence request, maybe by sending a new one?)

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

I don't think that's necessary -- we've kept this in the driver (device
in some cases), and it's trivial to do it there, so I see no reason to
let it go through wpa_supplicant.

johannes