[PATCH v2 4/4] P2P: Handle driver NOA notification

[Janusz Dziedzic]

2011/12/6 Jouni Malinen <j at w1.fi>:
> On Tue, Nov 29, 2011 at 07:24:37AM +0200, Janusz.Dziedzic at tieto.com wrote:
>> ?Update NOA attribute in beacon and probe response
>> frames after we will get NOA change/set notification
>> from the driver.
>
> Could you please provide some more details on how drivers would use this
> mechanism and why Beacon and Probe Response updates for NoA should go
> through wpa_supplicant?
In case driver/firmware will not update beacon/probe_response frames
by itself can just use
this NOA change/set notification. After that supplicant will set correct IEs.
Extra start time can be used here to be sure beacon/probe_resp will be
updated correctly and all clients will sync ...

> Wouldn't it be cleaner and more efficient to
> handle this within the driver especially to handle non-periodic NoA
> cases depending on offchannel operations?
>
Driver/firmware could menage NOA itselft and report NOA change/set in
case will not update IEs itself.
In case will do that internally don't need to call this NOA
notification. So, nothing will change for drivers/firmware handle this
internally.

Currently in our environtment we are testing two cases for P2P_GO and NOA:
1) when firmware using beacon/probe_resp templates - and in such case
after we set NOA firmware will update templates and add NOA attr. This
have one limitation. Supplicant will never get probe_requests and will
not build p2p_peers table correctly (invite), but there is one pro
(big pro in case of mobile market) - we will not send probe_requests
to the driver (firmware will handle this internally) - so our platform
could be in deep sleep in case no traffic.
So, probably best here could be implement p2p_find (scan) in GO (but I
think this is not so trivial) and using this firmware
beacon/probe_resp templates.

2) probe_resp is handled by wpa_supplicant/driver. So we have two
options here, first catch this probe_resp frames in the driver and add
NOA attr. Second send NOA notification to wpa_supplicant and update
probe_Response IEs. I choose second option because supplicant already
have an API for create/update NOA Attrs. So, was easy to do.
I also test this with mac80211 driver succesfully.

> It looks like this designs seems to assume that there is only a single
> NoA timing schedule in the NoA attribute. What if the driver wants to
> use two concurrent schedules?
Yes, this is first version and we can improve that.

>
>
> PS.
>
> As far as contributions to hostap.git are concerned, I would appreciate
> an explicit acknowledgment of the licensing terms as described in the
> CONTRIBUTIONS file:
> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=CONTRIBUTIONS
>
> --
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>



-- 
Janusz Dziedzic