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

[Johannes Berg]

On Mon, 2011-11-21 at 11:53 +0100, Janusz Dziedzic wrote:

> I think someone should propose architecture for NOA feature.

Agree, are you volunteering? :-)

> Currently I am not sure what part should be done in the driver and
> what in supplicant.

Me neither.

> I am not sure get noa is required/usefull at all.

Agree here too. Our device will add NoA in beacons by itself, and we
thus add it to probe responses in the driver.

> Some my ideas:
> P2P GO NOA:
> - Seems we could have set_noa() callback (for certification tests
> purpose)

Agree with this.

>  and possible presence_request handling in the future

Not sure I agree here -- it seems it might be easier to let the
driver/device handle figuring out whether or not a given request can be
handled and how it should be handled.

> - maybe we can remove get_noa() callback and instead of that send NOA
> notification from the driver after driver will set, change NOA params
> (specially index + start time).

We could do that, but I'm not sure it's really the best way to handle
it. If there's a presence request, wpa_supplicant should obviously
filter it according to its policies (if any), but I'm not convinced the
final determination & actually putting it into effect shouldn't be done
by the driver. Wouldn't the device also have to be aware of it for
OppPS?

> Current scenario we could have:
> 1) supplicant set_noa() or driver set defaults
> 2) driver secure correct startTime to be sure we will update
> beacons/probe_res and all STAs will sync
> 3) driver send notification to upper layer with NOA values
> 4) supplicant get this notification and update beacon template  + probe_resp
> 5) supplicant set new beacon.
> x) we should remember startTime is 4 bytes TSF and change NOA every 70minutes
> 
> Or driver/firmware should update beacons, check all Probe_Resp frames
> and will add correct NOA attribute?
> How this should work in the future?

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.

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?

johannes