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

[Janusz Dziedzic]

2011/11/21 Johannes Berg <johannes at sipsolutions.net>:
> On Mon, 2011-11-21 at 10:10 +0100, Johannes Berg wrote:
>
>> If the driver returned noa_len > 0, that means that a NoA schedule is in
>> effect. That means that we don't know, without parsing the NoA schedule,
>> whether or not the presence request can be fulfilled. Therefore, we must
>> return UNABLE_TO_ACCOMODATE.
>>
>> With nl80211, unfortunately this logic is broken because the driver
>> doesn't return a NoA schedule, so noa_len is always == 0 (I think?) and
>> we shouldn't be returning SUCCESS even in that case because the driver
>> or device might internally have a NoA schedule in effect.
>>
>> I'm not convinced that get_noa/set_noa is the right answer to this.
>> get_noa is virtually impossible to implement in a race-free manner at
>> least as far as presence requests are confirmed, and set_noa is really
>> only a testing hook.
>>
>> I think the right answer may be to ask the driver for each presence
>> request and return UNABLE_TO_ACCOMODATE if the driver doesn't implement
>> the function.
>
> I also just noticed that the P2P core code (src/p2p) appears to attempt
> to distinguish between drivers having get_noa support and those that
> don't by checking p2p->cfg->get_noa, but obvious that is always set
> since it's the p2p_supplicant's function, not the driver's.
>
> So all this seems really really buggy right now. :-(
>
> johannes
>

Hello Johannes,

I think someone should propose architecture for NOA feature.
Currently I am not sure what part should be done in the driver and
what in supplicant.
I am not sure get noa is required/usefull at all.

Some my ideas:
P2P GO NOA:
- Seems we could have set_noa() callback (for certification tests
purpose) and possible presence_request handling in the future
- 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 can secure here correct StartTime (add some time) during NOA change
to be sure we will update beacon + probe_response correcly - and to be
sure all stations will get correct NOA settings.

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?


BR
Janusz