[PATCH v2 4/4] P2P: Handle driver NOA notification
Tue Dec 6 10:33:31 PST 2011
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? 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?
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?
As far as contributions to hostap.git are concerned, I would appreciate
an explicit acknowledgment of the licensing terms as described in the
Jouni Malinen PGP id EFC895FA
More information about the Hostap